I'm no fan of the mitigation of killing the throttle if somebody stomps on the brake.
If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
The article also says that global variables will kill you, putting variables on the stack will kill you but doesn't say where it is safe to put variables. I can't imagine the heap is any better, that a garbage collector isn't going to pause and kill you, etc.
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.
> If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
This does not seem like a valid use case for driving on public roads.
> This does not seem like a valid use case for driving on public roads.
Driving in the snow often requires this because the brake acts as a poor man’s diff lock which gives you more traction. You can see the effect at speeds as low as 30kph in snow – a nice slow speed even in the city.
There is no way that 99% of drivers under 99% of realistic conditions will be anywhere near as effective as automatic traction control, much less more effective. It is absolutely a fair tradeoff to have a drive-by-wire that's better than virtually everyone and almost as good as that one guy under perfect controlled conditions.
I question the practice of building solutions around people and ceasing to train people why they are there. You aren't empowering people at that point. You're creating a centralized control mechanism the information asymmetry.
If people don't come out of a system interaction smarter than they went in, you're not doing it right. You're writing checks their continued ignorance will increasingly extort hogher costs from, and which will culminate in the formation of a lever of control in the form of manufacturers making decisions for people, usurping ultimate end agency.
I just don't buy that that's how the world should work. You can't build a better world without building better, more knowledgable people. We engineers spend too long making machines that do things for people without making clear why they exist and how they work.
I've never heard of this, and I learned how to drive in places with very rough winters.
You just hold the brake (lightly) with one foot, and gas with the other? This doesn't sound as useful as putting the car in 2nd, or rocking back and forth?
You're using the brake to prevent a slipping tire from taking all of the power. This is a non-issue for any car made in the last decade since traction control is mandatory.
That assumes that all traction control systems are equal. A lot of them are hot garbage and won't get a car moving when only a single tire is off the ground.
> This doesn't sound as useful as putting the car in 2nd, or rocking back and forth?
Neither of those cause the wheel with more traction to get any torque. Applying the brakes lightly will. Rocking and manually preventing wheelspin with the brake can be combined.
In theory, traction control will as well, but traction control may also intervene and decrease power right when you need it as you're getting unstuck, so there's potential merit in turning it off and preventing excess wheelspin with the brake yourself.
Source: I learned to drive in Alaska, and I have used this technique.
yeah, Alaska and Sibera are pretty much the only places with worse winters than where I learned. I'll keep this in my pocket for times when I'm spinning a wheel and am out of other options. We only get a few inches a year here, but my traction control might be out someday.
Frankly it's also fine if there isn't. Taking street cars to the track is a tiny niche and Toyota needn't cater to it. Aftermarket modding is an option anyway.
That would depend on what kind of racing you do. I'm pretty sure Spec Miata requires you to run a stock ECU. And it's literally the most popular racing series on the planet.
And Spec Miata is a pretty terrible example anyways... at the point where you're dumping 10k into a $500 motor I don't think you can talk about stock anything...
I feel empowered when I don't have to worry as much about how to safely operate my car, and it's just automatically safer. And when I don't have to worry as much about other drivers on public roads because their cars are automatically safer. The amount I'd be happy to pay to make that functionality configurable in order to accommodate people with different preferences, is $0.00.
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.
Indeed, spaghetti code is bad, but spaghetti data manipulated by spaghetti code is orders of magnitude worse.
The thing that I never got is why there are plenty of high level languages that have 'global' more or less as the default. This is asking for trouble. Side effects should be very carefully introduced and reasoned about and kept to an absolute minimum, not be the default sauce to sprinkle across your codebase, the possible number of states increases very rapidly if you do that.
Dynamic allocation is generally forbidden in this application so all system state has to be in global or static variables. Otherwise you'd have to invest in formal analysis tools to prove that memory won't be exhausted.
The rumor I heard at the time was that large portions of the code were autogenned out of a Matlab model of the engine, and that was where the globals and awful code complexity metrics came from.
Yep. This is widespread practice in the industry and is arguably far superior to someone actually trying to model it all in C. It just looks weird in a disassembler because you end up with a million global variables and essentially no control flow.
(It's specifically Matlab Simulink for those playing along at home)
> If you're trying to go around corners as fast as possible in a front-wheel drive car
1. Please don't do circus on public roads.
2. If you're on private roads, well, you know, front-wheel-drive cars tend to handle poorly in fast corners. Do yourself a favour and get a RWD or AWD or something.
> you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
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.
I hate that technique, maybe it's a motorcycle instinct to use the foot brake for finer control. But more importantly, the Mercedes I had to two-foot up onto the ramps didn't have a handbrake. My current car has hill assist but I still have to use two feet for backing up sharp hills.
> If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
I track my street-legal Miata. It's a garbage argument to say "it's not a race car"--plenty of cars out there have not stupidly shoddy software and don't need crutches like brake override to get their safety.
> If you're trying to go around corners as fast as possible
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).
Yeah the trail braking part makes sense to me, but I can't think of why you'd be continuing to press the throttle when you're in the braking zone. Is this some kind of trick to prevent an automatic transmission from downshifting out of the power band while you're in the braking zone?
Nope, OP wasn't even talking about "trail braking" but about poor-man's-LSD-braking.
When cornering hard, because of weight transfer, the inner wheel loses almost all traction, which makes it impossible to send any torque to it without wheel spin.
This means that you can't really accelerate out of a sharp turn with an open-diff vehicle, because an open diff always sends the same torque to both wheels, i.e. if the inner wheel spins without much resistance, that resistance equals the torque sent to the outer wheel.
A poor-man's-LSD-solution to this is applying a bit of brakes while also giving it a lot of gas. The brakes prevent the inner wheel from spinning freely and add artificial resistance, which increases the torque available at the outer wheel.
Ideally you'd only want to apply the brake on the inner wheel, which is what some cars actually do automatically as a fake-LSD solution, but applying both and wasting engine power is better than nothing.
Using the brakes all the way into the apex of the corner helps to increase cornering speed by transferring more weight to the front wheels to increase grip. It's called trail braking.
This isn't relevant for your example as in your example, you are entering the freeway on-ramp at a low speed and accelerating throughout the entire corner. Navigating a corner at highest possible speed means you're arriving at the corner at a high speed and must decelerate in order to make the corner.
It's not immediately clear to me why you would use gas and brake at the same time in an automatic transmission vehicle. The only reason I can think of would be to keep the revs of the engine in the powerband and prevent the car from downshifting so that you can immediately have full power when you accelerate out of the apex. In a manual transmission vehicle, there's a technique called heel-and-toe where you blip the gas pedal with your heel to rev-match the engine on your downshift while braking with your toe and depressing the clutch with your left foot, but you're never introducing force to the front wheels that would counter the force of the brakes.
Yes, that's exactly right, it's to keep the engine in the powerband. Automatic transmissions take both engine speed and throttle position into account when selecting a gear. More throttle while braking pushes the transmission to downshift more aggressively.
> If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
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.
> If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
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).
> 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.
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're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
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.
> If you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
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.
> 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.
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.
> The article also says that global variables will kill you, putting variables on the stack will kill you but doesn't say where it is safe to put variables. I can't imagine the heap is any better, that a garbage collector isn't going to pause and kill you, etc.
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();
}
a MyFile.h header:
#ifndef _MY_FILE_H_
#define _MY_FILE_H_
#include <stdint.h>
void setup_myFile(void);
void loop_myFile(void);
#endif // End include guard
and a MyFile.cpp library:
#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 variables are definitely the only the way to go.
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.
It doesn't say that global or stack variables will kill you, you're reading it wrong. Their problem was using excessive amounts of both, including corruption and accessing variables in very unsafe ways. There's nothing inherently wrong with either globals or stack space, and both are used heavily in even more critical software such as on space-grade parts.
The failure mode of a physical throttle cable is almost always much more gradual than with a computer bug, which can effectively kill you instantly without warning.
My grandfather had a truck on his farm with an occasionally sticky throttle. He failed to mention this when I had just gotten my learners permit and was trying to get some practice. So the family hopped in the back and he took shotgun so we could drive over to the cattle pasture and check on the herd. Halfway there I hit a bump in the dirt road and accidentally smacked the throttle with my foot, which causes it to stick on the floorboard just as we are approached the stream to crossing.
Luckily for everyone involved my grandfather knew what to do and slapped the stick into neutral before we all went careening over the rocky crossing. I was a bit slower getting the clutch in and the brakes on being a new driver. It was pretty weird feeling stopped in the middle of a stream with brakes fully on and the engine roaring. He then reached over and turned off the key, making me feel like an even bigger idiot for not thinking of it.
The point is if you're not mentally prepared for a runaway engine it's hard to figure it out on the fly in the mere moments you have before your doom.
Follow on note: Grandpa gave that truck to my uncle a few years later and my uncle managed to blow up the engine almost immediately. Turns out some of the head bolts were not fully tightened down at the factory but my grandfather drove it so gently that it wasn't a problem except for a persistent but low grade oil consumption issue for its entire life.
They did, but at least you were aware of it, besides, throttle cables breaking was far more common than them getting stuck. And typically if a throttle cable got stuck it wasn't really the cable but the butterfly valve attached to it that got stuck, usually on gunk in the throttlebody itself.
I have a feeling you DO understand that going back to driver-operated throttles would mean going back to 90s emissions standards, but you just don't care, am I right?
You know, there are those that see the slow delegation and abstraction away from operators the finer details of operating a machine and locking them behind unauditable, undocumented blackboxes to be a regression and power grab, right?
I have not seen any independent confirmation that the Toyota problem was caused by a software issue (and indeed the slides mention that NASA looked at it and did not find such an issue).
NASA looked at it well before the analysis mentioned in the slide deck, and it was a much shorter analysis and simply did not find this flaw. Toyota had their own technical experts and plenty of opportunity to publish technical reports rebutting it. I am not aware of any place where they did so, and they certainly had the opportunity (nobody is muzzling them.) I believe that maybe Toyota did argue that there was no evidence that this flaw caused the actual events in the field, which is true but also not a rebuttal exactly.
The list of issues seems pretty independent of any bias of the presenter:
> 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.
They also followed almost none of the guidelines in the MISRA C standard, which is a standard developed by the automotive industry specifically for helping to ensure that code running on car computers is up to at least some standard.
> > • Many large functions – 200 functions exceeded 75 lines of non-comment code [NASA App. A p. 23]
> Large functions with no comments?
I don't think that's what the citation says. It says the functions had more than 75 lines of code not counting any comments. It doesn't say there were no comments in these functions.
Nitpick aside, I'm sure we can all agree that a large number of such lengthy functions is not good practice.
Toyota lost the lawsuit on their development processes and firmware design. As far as I know, no specific bug that would cause unintended acceleration was ever found.
IIRC, they did identify a bit that if it were flipped in a certain way at a certain time, would lead to the struck throttle condition, and were able to successfully replicate the stuck throttle condition by 'manually' flipping that bit. So they never reproduced the problem in the field, but they could force a condition that would cause it -- and for a one-in-a-million thing like a cosmic ray bit flip, that seems like a reasonable methodology.
(and was only a problem because they didn't handle critical variables correctly, by having mirrors of the values that could be compared to protect against various types of corruption)
Koopman is the real deal. Big fan of the RTX-2000 here, and his embedded software book is excellent. But my recollection is that he and Barr found no such particular bit - the argument was, if one task failed, which could be due to any number of potential bugs, perhaps just one bit getting flipped, the unintended acceleration could happen.
The material from Barr is worth reading too (google it), and if you want some amusement:
> Toyota lost the lawsuit on their development processes and firmware design. As far as I know, no specific bug that would cause unintended acceleration was ever found.
I truly believe that it was human factors and not a computer failure.
I've been in similar situations and had a acquaintance drive through a wall because of human factors. In our case, the parking lot was relatively flat but had a drainage channel at the front. So, you could put your car into reverse, release the brake, and your car would roll forward. Quite unnerving if you are driving a stick, but your brain processes it because you are used to rolling in the wrong direction. If you are driving an automatic, you smack the accelerator, jump across way too small gap between you and a building, and bury your car trunk in an office wall.
Nevertheless, I'm also quite happy that Toyota got smacked as their development process was TERRIBLE. They 100% deserved what they got even if it wasn't a computer bug.
When this first came out, I recall reading that the reason the watchdog timer was reset from the timer interrupt was because as they added more software and overloaded the CPU, things got slower and the timer started triggering during normal operation. This caused the engine to hiccup if the vehicle was moving, or stall if you were at a stop. (IIRC reboot takes ~125ms, so no spark during this time)
The watchdog is the last-ditch failsafe, in a safety-critical system, and they basically disabled it because it was inconvenient. In some businesses (aviation?) you could probably be convicted of something for doing that, whether or not it ever hurt anyone.
What's infuriating is, think about how much of that software was probably worthless bloat for features no one needs. As many as 89 people may have died so Toyota could claim Bluetooth and MP3s in their latest models.
You're correct, this is the ETCS, which is a piece of the electronics in a Toyota. It's responsible for feeding speed, sensor, and drive control inputs in, and figuring out EFI, throttle, timing and stuff like that.
Yeah, GP is wrong in assuming bluetooth or MP3 processing had anything to do with this.
The CAN bus is what rules in cars, and infotainment systems are generally isolated and off of it. In some cases infotainment can read the CAN bus for things like pulling speed to display on GPS, but generally cannot place items on the bus
No security or authentication. IIRC, any attached device has full control over the physical layer by design. I don't really see why this is a problem in a car with isolated buses for safety-critical components.
Many newer vehicles contain systems, OEM and/or after-market, that are permanently connected to the internet via cellular modem. Other systems with insecure RF tech used for various gimmicks. Other systems that communicate with external and potentially malicious devices like chargers. Etc. Most of these systems have enough access to (in)directly destroy or booby trap the car. My car is able to receive ECU(!), firmware, software updates OTA from the manufacturer. These critical systems are just as "closed" or "isolated" as cloud-enabled "CCTV." Scary stuff.
My car (2014) has seven or so different CAN busses, with a gateway in between. Whether that constitutes a different "network" or not can be argued, but at least something that brings the entertainment CAN bus down, be it just by e.g. shorting it, won't (easily) bring down the other busses.
You're comparing apples and oranges. Compare how many cars Toyota vs Tesla puts on the road. Then divide the number of cases here 89 by that multiplier. You will find that even if Tesla had similar issues, they would in many cases just not be detected.
One thing that I found amusing/interesting/horrifying back when I read about this originally is that you can measure the computer reboot time in feet. IIRC, in the problem vehicles, the reboot time was something like 150 feet @ 60mph.
Well, good thing is during that reboot time your brakes will likely work to its full potential, you'll have engine braking, your clutch will work, your transmission might work if you have a separate TCM, your steering will work with power steering.
You will just lose power, as though you let off the throttle fully, during this time.
In fact your car turns off fueling when you let off the throttle fully to conserve fuel.
I think the only danger is that if you were going full tilt on a sports car, and the throttle failed close, you will get lift off oversteer probably.
I used to have a Honda Civic with a sticky throttle. Luckily it was a manual transmission so it wasn't a big deal. Just push in the clutch and pull the pedal up with my toe then replace/repair the throttle whenever is convenient. No unintended acceleration and no fiery wrecks.
I kind of wonder if we're heading the wrong direction with drive by wire cars. In aerospace it makes a lot of sense, especially when you are super dedicated to safe coding. But in a consumer vehicle? Not so great. Then again, Boeing hasn't been doing great with it either.
I remember when this was happening and I was surprised to learn that not only were there no good standards in automotive, reputable manufacturers like toyota didn’t even follow their own internal standards when developing software for critical bits.
Or to rephrase: it would appear they made no credible effort given the types of defects that occurred.
In my mind, the software for at least the first two is typically written by people who don't primarily have an IT background, and at least in the past it was very clear that no skilled IT security engineers with any even reasonably recent knowledge were involved.
The truth is that embedded, safety critical software requires a set of skills that is not normally taught in computer science or in electrical engineering degrees unless the students intentionally specialize in that direction.
According to the PDF, they are not actually required to adhere to any software standards, and they did not always follow their own coding rules. An internal email admitted that "technology such as failsafe is not part of the Toyota’s engineering division’s DNA". They didn't even have bug trackers, config management OR COMMENTS in the 250k+ lines of code that were looked at. The software was full of bugs and terrible coding practices, plus the CPU was routinely pushed way too close to 100%. The ETCS code in question also had no unit tests, but it would be impossible to have them anyway due to their use of recursion in the code, which is also not supposed to be used in safety-critical systems.
There are loads of people on here who have never driven cable-controlled throttles, rack-and-pinion assisted steering... I'd even guess there are a few that haven't used manual windows or hand-adjusted rear view mirrors (the kind you have to lean waaaay over to fix), and probably lots that haven't driven brakes without ABS, especially in the winter.
I can't believe I didn't think of it, but... I didn't realize that older throttles could get stuck.
I do know that power steering is literally the difference between smaller women being able to drive and not. I had an old Ford Aspire that a couple of my friends just couldn't drive because they couldn't turn it if it wasn't moving at road speeds.
Yeah, that Civic didn't have a passenger side mirror. Visibility was so great anyways I never felt the lack. Probably would have killed me to death in a rollover since it was just a bubble of sheet metal and glass. But oh boy could I see things around me.
>I do know that power steering is literally the difference between smaller women being able to drive and not
Only because once it's a standard feature other engineering departments start doing things that requires the system to be there in order to get good results.
The steering geometry that keeps modern (like mid 00s on up, the "wide tread, narrow sidewall" era) cars from wandering on crowned roads substantially increases steering force required.
It's not like small women didn't drive 60s barges just fine without power steering.
My mom used to drive an old Volvo wagon. It weighed a ton and didn't even come with power steering. Just a huge wheel to make the leverage a bit easier. She knew the real trick though, turn the wheel while the car was even just slightly moving. Even less than 1mph was enough movement to lighten the steering feel.
That’s not a trick, that’s just good driving. Turning the wheel while stationary is called dry steering and is not good for the power steering system, the tires, or even the road surface.
That's like saying under-cooked vegetables will wear out your cutlery faster than cooked vegetables. It's probably technically true but in practice it doesn't matter.
I learned this lesson the hard way, when they just re-paved our street I took my dad's truck out and dry steered on the fresh asphalt. It carved a rut in the road. It's pretty bad for your tires too.
> It's not like small women didn't drive 60s barges just fine without power steering.
Those vehicles had almost no castor (you mention that) but also had huge steering wheels. The advent of power steering led to the evolution of other components actually requiring it.
>I can't believe I didn't think of it, but... I didn't realize that older throttles could get stuck.
I had a 1991 Taurus SHO (manual) that did this. I'm pretty sure it wasn't the throttle assembly, but the cable would bind somewhere and it would keep the throttle open. I could never figure out where it was binding and neither could any mechanics.
I usually had to pull over to turn the car off and back on again.
The SHO accelerated very fast (at the time) so thankfully it never happened when I was facing a wall.
That Civic didn't even have power steering. I think it was a fancy option that the previous owner didn't feel they needed. If you were moving more than 1 mph you could turn it easily if the tires were properly inflated. You could feel the texture of the road through the steering wheel and stay in your lane by the feel of the worn pavement. If you were elderly or disabled, it sucked terribly. However it was a good little shoe car for a teenager who didn't have much money for gas.
One thing I absolutely hate these days is cars without a shifter lever. The stupid knobs that killed Anton Yelchin, the new Ford junk that won't shift if the car doesn't have battery, etc.... Also, electric parking breaks.
I wish I had Youtube car repair videos as a kid. So many things are so much easier now that I don't have to rely on a Haynes manual with skipped steps and barely legible images.
When the driver pressed the brake pedal, why doesn't the vehicle disengage the throttle? I remember when this happened and many demonstrations were done that even if you were pressing the pedal to the floor, the brake disengages the throttle and brings the car to a stop.
That's really not true at all. Generally, as braking systems pick up heat, they become continually less and less efficient at slowing the car down and will eventually stop working entirely. This will be especially true when fighting against an engine running at wide open throttle. It's called brake fade.
Brake fade is a thing, but firm deliberate use of the brakes would slow the car down enough for you to turn it off well before your brake fluid was cooked.
The problem is having the presence of mind to do that when confronted with such an unusual situation
In my experience brake fade doesn't kick in until an inordinate amount of heat gets generated (think like full send down a steep mountain for tens of minutes) or you're doing something stupid (like full send down a steep mountain for tens of minutes)
Malcolm Gladwell has a long history of taking every opportunity available to use misleading interpretations of evidence to justify his fables [0 for a notable example]. I would take anything he puts an "always" behind with a very large (boulder-sized) grain of salt.
Ironically on a car with vacuum assisted brakes and no mechanical vacuum pump, it's the other way round: when full throttle, there is no vacuum available and (after a few uses) the brakes become substantially weaker. That's on naturally-aspirated engines without a software override, anyway.
Also, the general guidance for someone who thinks their brakes are failing is to pump them to try to build pressure. In this case that guidance is the exact opposite of what you should do. The guidance is for a different but more common failure mode: brake line rupture.
The correct solution to a runaway engine is to slap the car into neutral and then apply brakes and pull over if necessary. But that's not something most driving schools teach nor is it something your average person will practice.
My father was gifted a 1972 Buick Regal. I was asked to drive it on I-85 (interstate) During acceleration on the onramp, the cable controlling the throttle got stuck and the gas was flowing into the carb and UA continued to occur. I was reaching speeds in excess of 100 MPH (160 Kmph). The brakes did nothing to slow me me down. My wife, driving adjacent to me in another vehicle, thought I was showboating or just being wreckless. I had to kill the engine with the key, slow down, and then crank the car, begin accelerating, then kill the engine to 'manage' the vehicle until I could get off the interstate. Terrifying ordeal.
In such cases, if you can't brake or release the throttle, one other out is to gear-shift into neutral. The result of slamming that power into neutral won't be great for the engine or transmission, but at least you'll be able to stop accelerating and coast to a stop.
I recall riding with a friend who had an automatic, and his engine was racing at every stoplight (I don't recall the name of the hardware that's supposed to disengage the engine when the brake is fully applied, but clearly it was broken).
So, he sat at every light with the brake pushed hard to the floor, trying to keep it from plunging into the intersection. As a long-time stick shift driver, I asked him why he didn't just shift it into neutral.
And most older engine will float the valves and, assuming nothing collides or comes apart (floating valves isn't good for the rest of the valvetrain), self limit that way.
But almost any engine with electronic ignition (so early 80s or later for a standard car or motorcycle, with plenty earlier having that feature) will cut spark to control RPM as needed. Unless you just start getting ignition breakup at RPM (not enough dwell time for the coil).
Most modern ECUs won't cut fuel intermittently but will instead just hold RPM steady at some defined max speed. However, I guess you'd have to be pretty unlucky to have this happen with a drive by wire setup...
I actually saw a small block Chevrolet or Mopar (don't remember which) dent the hood this way. I suppose the rocker rotated when the valves floated, when the valve broke the stem went right through the valve cover. Funniest thing I'd ever seen at a drag strip.
If it's only an issue at stop lights, it might just be a very high idle for whatever reason, and putting it in neutral wouldn't necessarily redline.
For throttle stuck fully open, going very fast on the highway, yeah you're gonna redline, but it's probably better to redline in neutral while you pull over than to turn the key off while you're still driving.
Not sure, but you might still have power steering if you leave it on but in neutral. If you turn it off, you'll definitely lose hydraulic steering assistance.
I have dealt with 1 modern-ish/heavy car that stalled its engine on a downhill slope and my braking ability in this case was reduced to a mere suggestion. If you are strong enough to bring down an unpowered 4000lb+ vehicle to a complete stop on a downslope, more power to you but it is a bit unfeeling to assume that everyone shares your extraordinary pedal-pounding strength. Edit:s/freakish/extraordinary.
You have a tiny master cylinder compared to a vehicle with power brakes, so it should work fine... this is different than having a big master cylinder + power brakes disabled.
At any respectable speed in a well constructed car with a mechanical steering linkage, power steering is basically unnecessary. My old car used to have glitchy power steering— at 35mph, I could generally tell when it wasn’t working, but it wasn’t very obvious. At 5 mph it was quite obvious when it wasn’t working.
It’s really dependent on the car. I was driving a C7 Z06 and the power steering cut (it overheated—car warned me well ahead of time). Let me assure you it was not trivial at all to steer the thing. It was shocking how heavy the steering became. I could turn the wheel—barely. Would not really call it control.
The next day my friends e90 BMW m3 power steering boiled over. And another friends F80 M4 had multiple power steering failures. They weren’t exactly happy about it either.
You don't need an ECU to act as a rev limiter. Gasoline engines have had rev limiters in all different kinds and types for over 100 years. Some cut fuel, some cut spark, some cut both.
Even my push mower has a rev limiter, it just gets called a governor on that engine.
The majority of large American engines used the valves as the rev limiter. The valve springs were so weak that past a certain RPM the performance of the engine falls off so fast it isn't going to rev anymore, even in neutral. The valves never fully close, so performance is very poor. This is well below the mechanical limitations of the crankshaft, so nothing is really going to happen. Once interference engines showed up as common place in the market, it became mandatory to have a rev limiter. This happened as electronic ignition and fuel injection became more common, so it was logically incorporated into the ECU as time went on.
> I would take a blown engine over flying into an intersection any day of the week.
And this is why we need to build experience. Young drivers very often are confronted with decisions like this but their mind phrases it as "Blown engine that I do not have to funds to pay for in Dad's car, or just hold this pedal firmly and everything will be all right".
Unfortunately, the problem with experience is that the lesson comes only after the test.
If replacing an engine would not be economically sensible in whatever you're driving you should probably chance it running the intersection or whatever. If you fail you're buying a new car, but if you blow up an engine you're buying a new car too. But you might not fail so the relative expected value is greater. I hope your horn works...
> Maybe turning it off might be a safer alternative.
Young drivers might not understand the difference between the powered-down and the pull-the-key-out positions. There is a real danger of locking the steering wheel in this case.
I suspect a lot of people find themself in a situation where driving a car with a mechanical problem is a sensible local optimum for some period of time.
The statute of limitations has passed on all of my “she’ll be a’ight” endeavors, but they included having to manually apply throttle to keep the engine lit, driving on partial service brakes, driving without a working charging system, having to push start the car, reckoning speed by gear and RPM, and fueling based on ded reckoning with an INOP fuel gauge and odometer.
The partial brakes is the only thing on that list I'd consider to be more than just an inconvenience.
Obviously if you want to drive like a jerk you need the car to be in tip top shape so that you have the most freedom to make control inputs but if you just want to putt along and drive in a mild mannered way having a bunch of mechanical oddities that constrain what you can do isn't a big deal.
I notice that a lot of people who have never driven 1980's era and earlier cars have no idea that cars were _always_ broken in some form or another. Every single car had developed some problem or another every year, one simply got used to this car having a bad window motor, that car having a bad started solenoid, this one torque steering to the left, that one thumping on brakes, this other one running rough when driving to the east, that one leaks transmission fluid, that other one won't restart after five minutes but will restart after half an hour, this one has no A/C, this one has terrible wind noise, this one blinks left when the radio is on FM, this one drips radiator fluid into the cabin when the heat is on, that one will spontaneously activate ABS in the last second before coming to a complete stop 50% of the time, this one squirts washer fluid onto the roof of the car to your right, this one dims the dash lights when the radio DJ talks instead of playing music, that one overheats, etc etc.
Shifting to neutral under load is probably not harmful. It's the opposite that is harsh on the drivetrain.
However if the throttle is stuck and you are in neutral you'll end up revving at redline until you turn off the engine. Not the end of the world momentarily but you don't want to leave the engine revving that high for a prolonged period of time.
"Funny" enough, my family had a similar experience. My parents owned a 1984 Ford conversion van. On a family road trip, a squirrel got up into the engine and built a nest or something around the component which was used to control the amount of gas going into the engine (I don't remember the exact specifics), my dad had to shift it between drive and neutral until we could make it off the highway as well.
I was boating and same issue - broke to full throttle on a gas engine. So I just came flying in and killed engine. I could have restarted probably if needed. These things are almost always stoppable.
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.
A place I worked years ago was a manufacturer of industrial lifting cranes. They had a problem one particularly hot summer of the diesels in the cranes starting up in their own.
These were massive engines. The block was bigger than my whole car. Terrifying watching one of them run away. They tended towards "violent, unscheduled disassembly" if they couldn't be shut down.
Hijacking (kinda): diesels are vulnerable to a phenomenon called "diesel runaway", where unintended fuel (for instance, engine oil leaks) seems into the intake/cylinder. The engine is controlled by how much fuel is injected, so if you just add an extra amount of fuel it will start increasing torque all on its own, and in the worst case, will cause unintended acceleration.
Nowadays diesels actually come with throttle bodies for emissions reasons which I think also will serve a safety function against runaways.
A major part of diesel efficiency comes from a lack of a throttle plate. I’d be surprised if adding one was beneficial for emissions. Do you have any reference here? I couldn’t find one with a quick googling.
I'd guess too-lean combustion in idle is bad, and throttling the intake so that it starts out with reduced pressure and at the fixed compression ratio, won't reach as-high pressures (which waste power by some of the adiabatic heating coupling to the cylinder walls).
Might only work on individual cylinders, as it seems like it'd easily prevent ignition, but still...
I don't know if it's for emissions reasons, and I doubt it does anything for emissions, but Volkswagen diesels have a throttle that's there to make engine shutoff much less shaky. It's called the anti-shudder valve, and it activates every time the engine is stopped, and it would stop a runaway diesel.
what the heck are you talking about, if you're at partial throttle, by design a normal diesel has no control over how much air is entering the engine, so your only way of modulating torque is changing the injection. This means your air fuel ratio will be uncontrolled, which is bad for emissions.
Vaccum leaks can do the same, in idle that is. My '82 Rover V8 has that attitude sometimes when it's hot and not a lot air gets to the engine (traffic jams and so). Needs some load to get revs down, ideally the engine get cooled down. Have to hunt the issue down.
Apparently it can happen with carbs in general. I knoe people tgat had issues switching this engine off in the desert because the fuel in the carbs evaporated and continued to be pulled in the engine. Which was hot enough to to ignite it for a while...
Doesn't steering wheel get locked on some cars when you kill the engine? Seems switching to Neutral is safer option.
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.
If you write dirty code knowing it is going to be used in a car, you should be charged with manslaughter, children endangerment and any form of legal punishment arising from creating long functions with high cyclomatic complexity being called in spaghetti in the context of controlling a vehicle that can cause people to die.
Seriously, when will the excuses for dirty code end? Whatever you think the business is, clearly killing 89 people is not it. Use a linter and remember your contribution to the business as a programmer is programming properly.
If programming is below you go do something else. If you have management aspirations go interview for a management job. If you don't like coding properly go code something else or consider another career.
Write proper code and stop talking about how dirty code is good for the business. Not only it is not true, nobody wants to hear about it, and nobody should have to deal with your 4d jenga tower in a professional setting, goddamn it.
This actually marks the second incident I had tucked away in my brain where the initial story was "Sometimes the world is just weird" and the actual issue was computer systems.
The reason we all keep seatbelts bucked in flight even when the sign is off these days is Qantas Flight 72, which took two sharp nose-dives in flight, rebounding passengers and crew off the ceiling and causing severe injuries. At the time, initial reporting was that they'd caught two freak mid-Pacific downdrafts, which had me nervous about flying for awhile.
Turns out, the root cause was bad angle-of-attack data coming in from a faulty inertial measurement unit, which should have been caught by a safety system but proved so aggressively faulty that the safety system was overruled. It resulted in the plane's avionics becoming convinced it was flying belly-on into the wind at cruising speed and about to stall, so it did the thing it's supposed to do: pitched down hard to stall-recover.
Don't ask me why I'm more comfortable with the story being "Sometimes computer engineers screw up" than "Sometimes our understanding of the physics of aviation just breaks down," but I am. ;)
From a software design and engineering perspective, I agree with the NASA report's take on global variable use.
... but I've also done game development, where maximum performance in minimum time is absolutely essential, and I wonder if it was actually feasible to maintain the performance the control system needed without global state.
There's also the possibility of a culture clash. I've noticed that in embedded systems architecture development, global variables aren't frowned upon nearly as hard as they are in enterprise software, mostly because of the industry history of doing more with less. So I imagine a software culture risk developing from getting a bunch of hardware guys on a project where they now have access to microcontrollers with more memory than ever, but their risk tradeoff mindset is still "take the risk to squeeze every byte because we might run out."
I don't understand where there is a kill switch when you can just turn off your vehicle using the key? Besides killing the engine will mean no power to the brakes and steering as well.
Motorcycle kill switches are always on the handlebars, so you can reach it without letting go of the handlebars. Also makes it easier to find - some bikes have the keyswitch on the side, but the kill switch is always on the handlebars.
The brake booster will hold some vacuum for a few brake applications and, if the car remains in gear, the rotation will continue to create vacuum to recharge the brake booster (and turn the power steering pump, but power steering is not needed in practice at anything approaching “runaway car” speed).
My understanding is it was never clear if it actually happened in the first place or was just operator error. I seem to remember there was also a recall on floor mats that could have caused issues.
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.
you going 100mph and turning off your car is not a great idea since that locks up the steering wheel all but guaranteeing a crash. I am pretty sure most cars should be able to switch into neutral though which would be advisable. who knows though how someone operates under pressure like that. they did call 911 and you can hear the final moments iirc.
If you have a safe area it's worth testing how your car works, usually push-to-start is actually a multi-state button between Ignition & Accessory On, Ignition Off & Accessory On, and All Off.
It's really tough to say with any certainty unless there is a standard out there for this behavior. seems like it's a different thing for each car manufacturer but that's just my hunch based off a small subset of cars i've driven.
It doesn't guarantee a crash. I've had power steering failures (I've driven cars up to 400K miles). On the highway you don't need to crank wheel over so it's not impossible to hold a lane. The wheel doesn't lock if you turn car off either if that's the concern.
Remember, when you turn car off you are stopping, that's your goal. With brakes you don't need to "drive" that far once car is off. Turn off car, press on brakes, done.
Why is a crash guaranteed? I've driven with a car off (manual start when alternator out). It works OK (tight turns excepted without power steering)
When this happened the vast majority of people I talked to were convinced that there was no unintended acceleration problem and that the US government was going after Japanese automakers to protect the investment it made in US automakers with the auto bailout (because of the 2008 financial crisis).
Several years ago, my last company hired Denzo to write firmware for a new thermostat project. Denzo does electronics for Toyota. The software quality was so bad, it all had to be scrapped. Their software engineers were doing things like making their own mutexes instead of using the rtos builtins.
It's been a while, so maybe there has been a reckoning since.
I had a 2007 4Runner; I got the recall notices. I ignored them because I knew they were not getting to the root of the problem and were just trying to wallpaper over it.
Though that may be true, you put yourself at liability in case of collision resulting in bodily harm. The recalls protect you from liability as well as wallpaper over existing issues.
227 comments
[ 3.5 ms ] story [ 351 ms ] threadIf you're trying to go around corners as fast as possible in a front-wheel drive car you're going to drive with one foot on the brake and one foot on the gas and will apply the brakes and the gas at the same time.
The article also says that global variables will kill you, putting variables on the stack will kill you but doesn't say where it is safe to put variables. I can't imagine the heap is any better, that a garbage collector isn't going to pause and kill you, etc.
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.
This does not seem like a valid use case for driving on public roads.
Driving in the snow often requires this because the brake acts as a poor man’s diff lock which gives you more traction. You can see the effect at speeds as low as 30kph in snow – a nice slow speed even in the city.
If people don't come out of a system interaction smarter than they went in, you're not doing it right. You're writing checks their continued ignorance will increasingly extort hogher costs from, and which will culminate in the formation of a lever of control in the form of manufacturers making decisions for people, usurping ultimate end agency.
I just don't buy that that's how the world should work. You can't build a better world without building better, more knowledgable people. We engineers spend too long making machines that do things for people without making clear why they exist and how they work.
I'm done with the "for their own good" BS.
You just hold the brake (lightly) with one foot, and gas with the other? This doesn't sound as useful as putting the car in 2nd, or rocking back and forth?
Neither of those cause the wheel with more traction to get any torque. Applying the brakes lightly will. Rocking and manually preventing wheelspin with the brake can be combined.
In theory, traction control will as well, but traction control may also intervene and decrease power right when you need it as you're getting unstuck, so there's potential merit in turning it off and preventing excess wheelspin with the brake yourself.
Source: I learned to drive in Alaska, and I have used this technique.
Thanks!
https://www.mazdamotorsports.com/2019/02/07/a-better-faster-...
And Spec Miata is a pretty terrible example anyways... at the point where you're dumping 10k into a $500 motor I don't think you can talk about stock anything...
We should empower people, not manipulate them through engineering usecases to/to not accommodate.
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.
The thing that I never got is why there are plenty of high level languages that have 'global' more or less as the default. This is asking for trouble. Side effects should be very carefully introduced and reasoned about and kept to an absolute minimum, not be the default sauce to sprinkle across your codebase, the possible number of states increases very rapidly if you do that.
(It's specifically Matlab Simulink for those playing along at home)
1. Please don't do circus on public roads.
2. If you're on private roads, well, you know, front-wheel-drive cars tend to handle poorly in fast corners. Do yourself a favour and get a RWD or AWD or something.
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.
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).
When cornering hard, because of weight transfer, the inner wheel loses almost all traction, which makes it impossible to send any torque to it without wheel spin. This means that you can't really accelerate out of a sharp turn with an open-diff vehicle, because an open diff always sends the same torque to both wheels, i.e. if the inner wheel spins without much resistance, that resistance equals the torque sent to the outer wheel.
A poor-man's-LSD-solution to this is applying a bit of brakes while also giving it a lot of gas. The brakes prevent the inner wheel from spinning freely and add artificial resistance, which increases the torque available at the outer wheel.
Ideally you'd only want to apply the brake on the inner wheel, which is what some cars actually do automatically as a fake-LSD solution, but applying both and wasting engine power is better than nothing.
This isn't relevant for your example as in your example, you are entering the freeway on-ramp at a low speed and accelerating throughout the entire corner. Navigating a corner at highest possible speed means you're arriving at the corner at a high speed and must decelerate in order to make the corner.
It's not immediately clear to me why you would use gas and brake at the same time in an automatic transmission vehicle. The only reason I can think of would be to keep the revs of the engine in the powerband and prevent the car from downshifting so that you can immediately have full power when you accelerate out of the apex. In a manual transmission vehicle, there's a technique called heel-and-toe where you blip the gas pedal with your heel to rev-match the engine on your downshift while braking with your toe and depressing the clutch with your left foot, but you're never introducing force to the front wheels that would counter the force of the brakes.
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.
It is better to leave options open rather than to lock things behing explicit configuration in the abscence of readily available documentation.
Which I assure you, Service/Operators manuals are not.
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).
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’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.
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
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:
a MyFile.h header: and a MyFile.cpp library: Statically allocated variables are definitely the only the way to go.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.
Of course you just put the clutch in and nothing to worry about.
Luckily for everyone involved my grandfather knew what to do and slapped the stick into neutral before we all went careening over the rocky crossing. I was a bit slower getting the clutch in and the brakes on being a new driver. It was pretty weird feeling stopped in the middle of a stream with brakes fully on and the engine roaring. He then reached over and turned off the key, making me feel like an even bigger idiot for not thinking of it.
The point is if you're not mentally prepared for a runaway engine it's hard to figure it out on the fly in the mere moments you have before your doom.
Follow on note: Grandpa gave that truck to my uncle a few years later and my uncle managed to blow up the engine almost immediately. Turns out some of the head bolts were not fully tightened down at the factory but my grandfather drove it so gently that it wasn't a problem except for a persistent but low grade oil consumption issue for its entire life.
This slide is written by someone that has a bias.
I have not seen any independent confirmation that the Toyota problem was caused by a software issue (and indeed the slides mention that NASA looked at it and did not find such an issue).
> 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.
> Large functions with no comments?
I don't think that's what the citation says. It says the functions had more than 75 lines of code not counting any comments. It doesn't say there were no comments in these functions.
Nitpick aside, I'm sure we can all agree that a large number of such lengthy functions is not good practice.
(and was only a problem because they didn't handle critical variables correctly, by having mirrors of the values that could be compared to protect against various types of corruption)
The material from Barr is worth reading too (google it), and if you want some amusement:
https://www.embedded.com/why-every-embedded-software-develop...
https://www.embedded.com/a-rebuttal-to-why-every-embedded-so...
I truly believe that it was human factors and not a computer failure.
I've been in similar situations and had a acquaintance drive through a wall because of human factors. In our case, the parking lot was relatively flat but had a drainage channel at the front. So, you could put your car into reverse, release the brake, and your car would roll forward. Quite unnerving if you are driving a stick, but your brain processes it because you are used to rolling in the wrong direction. If you are driving an automatic, you smack the accelerator, jump across way too small gap between you and a building, and bury your car trunk in an office wall.
Nevertheless, I'm also quite happy that Toyota got smacked as their development process was TERRIBLE. They 100% deserved what they got even if it wasn't a computer bug.
The watchdog is the last-ditch failsafe, in a safety-critical system, and they basically disabled it because it was inconvenient. In some businesses (aviation?) you could probably be convicted of something for doing that, whether or not it ever hurt anyone.
The CAN bus is what rules in cars, and infotainment systems are generally isolated and off of it. In some cases infotainment can read the CAN bus for things like pulling speed to display on GPS, but generally cannot place items on the bus
You don't have to stay infuriated anymore.
The computers for in-car-entertainment is different and decoupled from the one for engine and throttle management.
As for the bloat, my observation (which could be wrong) is that Toyota seems to have comparatively less bloat.
Somewhat unrelated to this particular case, but terrifyingly, the network isn't and CAN is one of the least secure BUS's imaginable.
Can you elaborate on this?
We choose to ignore it because it's rarely exploited, but by that logic, we should just ignore all zero-days.
https://www.eetimes.com/hacked-jeep-whom-to-blame/
Learning the lessons from the aviation industry all over again.
You will just lose power, as though you let off the throttle fully, during this time.
In fact your car turns off fueling when you let off the throttle fully to conserve fuel.
I think the only danger is that if you were going full tilt on a sports car, and the throttle failed close, you will get lift off oversteer probably.
This is why well engineered vehicles have a separate computer for everything and not just one little chip.
I kind of wonder if we're heading the wrong direction with drive by wire cars. In aerospace it makes a lot of sense, especially when you are super dedicated to safe coding. But in a consumer vehicle? Not so great. Then again, Boeing hasn't been doing great with it either.
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.
Or to rephrase: it would appear they made no credible effort given the types of defects that occurred.
Do you disagree that the software for medical devices is written badly, or are you just saying that it should be written well? I don't think the latter is in dispute. For the former, https://www.theguardian.com/technology/2017/aug/31/hacking-r...
According to the PDF, they are not actually required to adhere to any software standards, and they did not always follow their own coding rules. An internal email admitted that "technology such as failsafe is not part of the Toyota’s engineering division’s DNA". They didn't even have bug trackers, config management OR COMMENTS in the 250k+ lines of code that were looked at. The software was full of bugs and terrible coding practices, plus the CPU was routinely pushed way too close to 100%. The ETCS code in question also had no unit tests, but it would be impossible to have them anyway due to their use of recursion in the code, which is also not supposed to be used in safety-critical systems.
I can't believe I didn't think of it, but... I didn't realize that older throttles could get stuck.
I do know that power steering is literally the difference between smaller women being able to drive and not. I had an old Ford Aspire that a couple of my friends just couldn't drive because they couldn't turn it if it wasn't moving at road speeds.
Do you mean side mirrors? I recall when you needed to lean over to the passenger side to adjust it.
Only because once it's a standard feature other engineering departments start doing things that requires the system to be there in order to get good results.
The steering geometry that keeps modern (like mid 00s on up, the "wide tread, narrow sidewall" era) cars from wandering on crowned roads substantially increases steering force required.
It's not like small women didn't drive 60s barges just fine without power steering.
[1] https://en.m.wikipedia.org/wiki/Steering_ratio
I had a 1991 Taurus SHO (manual) that did this. I'm pretty sure it wasn't the throttle assembly, but the cable would bind somewhere and it would keep the throttle open. I could never figure out where it was binding and neither could any mechanics.
I usually had to pull over to turn the car off and back on again.
The SHO accelerated very fast (at the time) so thankfully it never happened when I was facing a wall.
One thing I absolutely hate these days is cars without a shifter lever. The stupid knobs that killed Anton Yelchin, the new Ford junk that won't shift if the car doesn't have battery, etc.... Also, electric parking breaks.
https://www.pushkin.fm/episode/blame-game/
That's really not true at all. Generally, as braking systems pick up heat, they become continually less and less efficient at slowing the car down and will eventually stop working entirely. This will be especially true when fighting against an engine running at wide open throttle. It's called brake fade.
The problem is having the presence of mind to do that when confronted with such an unusual situation
[0] http://askakorean.blogspot.com/2013/07/culturalism-gladwell-...
Most brakes don't actually lockout engine operation, because there are cases where you want the engine to rev while the brake is applied.
Just because at first blush it seems the use case is pointless, doesn't mean it is.
You think the Camry was designed for track duty?
But that's a big assumption to make for people panicking.
The correct solution to a runaway engine is to slap the car into neutral and then apply brakes and pull over if necessary. But that's not something most driving schools teach nor is it something your average person will practice.
2-3 in practice.
So, he sat at every light with the brake pushed hard to the floor, trying to keep it from plunging into the intersection. As a long-time stick shift driver, I asked him why he didn't just shift it into neutral.
What if the engine free-revs and redlines on neutral?
Maybe turning it off might be a safer alternative.
But almost any engine with electronic ignition (so early 80s or later for a standard car or motorcycle, with plenty earlier having that feature) will cut spark to control RPM as needed. Unless you just start getting ignition breakup at RPM (not enough dwell time for the coil).
For throttle stuck fully open, going very fast on the highway, yeah you're gonna redline, but it's probably better to redline in neutral while you pull over than to turn the key off while you're still driving.
Not to drop old man wisdom here but back in the day power brakes were an option that you could pay for.
The next day my friends e90 BMW m3 power steering boiled over. And another friends F80 M4 had multiple power steering failures. They weren’t exactly happy about it either.
For example pre 1900:
https://en.wikipedia.org/wiki/Hit-and-miss_engine
Later:
https://www.jalopyjournal.com/forum/threads/mechanical-rev-l...
1970s electronic type:
https://www.428cobrajet.org/id-governor
Even my push mower has a rev limiter, it just gets called a governor on that engine.
The majority of large American engines used the valves as the rev limiter. The valve springs were so weak that past a certain RPM the performance of the engine falls off so fast it isn't going to rev anymore, even in neutral. The valves never fully close, so performance is very poor. This is well below the mechanical limitations of the crankshaft, so nothing is really going to happen. Once interference engines showed up as common place in the market, it became mandatory to have a rev limiter. This happened as electronic ignition and fuel injection became more common, so it was logically incorporated into the ECU as time went on.
Unfortunately, the problem with experience is that the lesson comes only after the test.
Which one are you optimizing for?
The statute of limitations has passed on all of my “she’ll be a’ight” endeavors, but they included having to manually apply throttle to keep the engine lit, driving on partial service brakes, driving without a working charging system, having to push start the car, reckoning speed by gear and RPM, and fueling based on ded reckoning with an INOP fuel gauge and odometer.
Obviously if you want to drive like a jerk you need the car to be in tip top shape so that you have the most freedom to make control inputs but if you just want to putt along and drive in a mild mannered way having a bunch of mechanical oddities that constrain what you can do isn't a big deal.
Likely he just had a high idle due go some vacuum leak or whatever, as you said.
However if the throttle is stuck and you are in neutral you'll end up revving at redline until you turn off the engine. Not the end of the world momentarily but you don't want to leave the engine revving that high for a prolonged period of time.
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.
These were massive engines. The block was bigger than my whole car. Terrifying watching one of them run away. They tended towards "violent, unscheduled disassembly" if they couldn't be shut down.
Nowadays diesels actually come with throttle bodies for emissions reasons which I think also will serve a safety function against runaways.
from what i understand it's mostly to have a control over the air fuel ratio.
It’s for emissions
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.
Apparently it can happen with carbs in general. I knoe people tgat had issues switching this engine off in the desert because the fuel in the carbs evaporated and continued to be pulled in the engine. Which was hot enough to to ignite it for a while...
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.
Seriously, when will the excuses for dirty code end? Whatever you think the business is, clearly killing 89 people is not it. Use a linter and remember your contribution to the business as a programmer is programming properly.
If programming is below you go do something else. If you have management aspirations go interview for a management job. If you don't like coding properly go code something else or consider another career.
Write proper code and stop talking about how dirty code is good for the business. Not only it is not true, nobody wants to hear about it, and nobody should have to deal with your 4d jenga tower in a professional setting, goddamn it.
The reason we all keep seatbelts bucked in flight even when the sign is off these days is Qantas Flight 72, which took two sharp nose-dives in flight, rebounding passengers and crew off the ceiling and causing severe injuries. At the time, initial reporting was that they'd caught two freak mid-Pacific downdrafts, which had me nervous about flying for awhile.
Turns out, the root cause was bad angle-of-attack data coming in from a faulty inertial measurement unit, which should have been caught by a safety system but proved so aggressively faulty that the safety system was overruled. It resulted in the plane's avionics becoming convinced it was flying belly-on into the wind at cruising speed and about to stall, so it did the thing it's supposed to do: pitched down hard to stall-recover.
Don't ask me why I'm more comfortable with the story being "Sometimes computer engineers screw up" than "Sometimes our understanding of the physics of aviation just breaks down," but I am. ;)
... but I've also done game development, where maximum performance in minimum time is absolutely essential, and I wonder if it was actually feasible to maintain the performance the control system needed without global state.
There's also the possibility of a culture clash. I've noticed that in embedded systems architecture development, global variables aren't frowned upon nearly as hard as they are in enterprise software, mostly because of the industry history of doing more with less. So I imagine a software culture risk developing from getting a bunch of hardware guys on a project where they now have access to microcontrollers with more memory than ever, but their risk tradeoff mindset is still "take the risk to squeeze every byte because we might run out."
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.
Was the key not usable? Ie, turn off vehicle?
Was neutral not available?
To get my car to go I need key in the on position AND the gear in drive. I can go to neutral and turn off key anytime.
These stories of barreling down the highway with key locked, throttle locked, gear selector locked seem bogus.
To the best of my knowledge, steering locks only engage when the key is removed.
But I wonder what would happen if I was travelling and I just pressed the start/stop button, if the car would actually switch off.
Neutral is the solution. But when panicking you’re unlikely to use something you likely never use outside of an automatic car wash.
Remember, when you turn car off you are stopping, that's your goal. With brakes you don't need to "drive" that far once car is off. Turn off car, press on brakes, done.
Why is a crash guaranteed? I've driven with a car off (manual start when alternator out). It works OK (tight turns excepted without power steering)
It's been a while, so maybe there has been a reckoning since.
[1] https://users.ece.cmu.edu/~koopman/lectures/index.html
[2] https://youtu.be/DKHa7rxkvK8