Though the fact that none of the other manufacturers spoke up about the violation of emissions standards when when they must have done their own tests to see how VW managed to get emissions so low, seems to point to the fact they they were all doing it to some degree. Perhaps not as brazenly as VW, but still no one wants to rock the boat they are in.
If you presume they are doing their job and not cheating, why would you cross check that your emissions were valid in both the dyno test and on the track? It requires that you assume your fellow workers are cheating, which is hard to do at most places.
Well, in any case, it shows that ethical codes will probably not work for engineering professions (or any profession for that matter).
Unless this is the tip of the iceberg and everyone is cheating but hasn't been caught yet...
The CEO of VW was just fired for allowing this scandal on his watch, and he was replaced by a guy guilty of (at the very least) the same exact thing.
Whenever the topic of automotive software comes up on HN there are comments alongs the lines of "global variables bad", but not much construtive feedback.
I want to explain some of the tradeoffs that lead to the architecture used in automotive software to get a better discussion going with HN readers about that architecture.
tl;dr Given the hardware restrictions, real-time requirements and measurement capabilities required in automotive software, shared global variables without locks is a fast and safe way to share state between different software components as long as each variable is only written in one place in the program.
The microprocessor has to run for 10+ years in a wide range of temperatures and be dirt cheap, so you end up with specs like 180 MHz, 4 MB of flash and 128 KB of RAM.
The program must run deterministicly with respect to memory. There is no malloc/new in the code. All variables are statically allocated.
Because the physical world doesn't pause, no code is allowed to block while waiting for resources, especially synchronization primitives like mutexes.
The software architecture is in 2 main parts: basic software containing the real-time OS and hardware drivers, and the application layer which has the domain-specific code for controlling the engine, brakes, etc.
The basic software is implemented using usual C programming techniques. It has an API provided by function calls and structs to hide implementation details of each microcontroller.
The application software is where the programming model is different.
To understand why, you need to know where automotive software comes from and what it is trying to acheive.
Originally all controllers were mechanical: a valve opens proportionally to the vacuum in a part of the system. Then some controllers were implemented in analog electronics: take multiple voltages, feed them through an op-amp and use the output to control a valve.
So automotive software reproduces this: get some inputs, compute the same physical equations at a regular rate and generate outputs.
This is dataflow programming. Blocks of code have inputs and outputs. They are executed at a fixed rate that depends on the physical phenomena (air flow changes fast, temperature changes slowly). Different blocks are conneceted together in a hierachical way to form subsystems. Encapsulation is acheived by viewing these blocks as black boxes: you don't need to care how the block works if you are only interested in knowing which inputs it uses and outputs it produces.
Here's an example component to control a gizmo.
It might be implemented in a visual environment like Simulink by MathWorks, or it implemented by hand from a spec.
#include "GizmoController_data.h"
void GizmoController_100ms() {
Gizmo_Gain = interpolate2d(Gizmo_Gain_MAP, EngineSpeed, CoolantTemp);
}
void GizmoController_10ms() {
Gizmo_Error = Gizmo_PositionDesired - Gizmo_Position;
Gizmo_DutyCycle = limit(Gizmo_Gain * Gizmo_Error + Gizmo_Offset_VAL, 0, 100);
}
The header GizmoController_data.h is auto-generated at compile time by a tool from the XML file mentioned above. It will contain global variable definitions for the inputs, intermediates and outputs with the appropriate volatile, const, static and extern storage classes/type qualifiers. This ensures that the compiler will enforce that inputs can't be written to, intermediate values are private to the component and outputs can be read by other modules.
Note that no explicit synchronization is needed to access inter-process variables like Gizmo_Gain or inter-component variables like Gizmo_Position. It's shared memory between 2 processes scheduled in OS tasks that can potentially interrupt each other, but since the write is atomic and happens only in one place, there is no data race. This is huge! Concurrent programming, without locks, with the best efficiency possible, using a simple technique anybody can understand: only one place in the program is allowed to write to any global memory location.
Calibration is another aspect of automotive software. In most software the constants either never change or can be set in some kind of configuration file. For an automotive controller, the value of constants (gains, offsets, limits, etc) depend on the vehicle so they must be configurable at run time during development. This is implemented in the C code by putting all constants in a memory area that is ROM in production units, but RAM in development units. The compiler enforces that application software cannot change constants, but the basic software includes code so that constants can be changed from the outside in development. This process is called calibration and is done by calibration engineers who are usually not the ones who wrote the software. Note that calibration can drastically affect the behavior of the software. What would happen if Gizmo_Gain_MAP is set to all zeros?
Measurement of variables is essential to understanding what's going on inside the embedded controller. Having all that state available in global variables makes it possible for the calibration tool request the value of any variable in the software at a fixed rate and display it in a virtual oscilloscope.
The measurement and calibration tool needs to know how to access the variables and constants. It uses a file that maps from names to addresses for a particular version of software. That file can easily be generated a compile time since all allocations are static.
Going back to the architecture of the application software, let's look at where our gizmo controller fits. It is not the only component needed to make the gizmo work. You also need components to calculate the gizmo position from some external signal (let's say an analog voltage), to route the output signal to the powerstage driver on the PCB, to determine which position the gizmo should currently occupy. These would form the gizmo subsystem package.
When the supplier releases gizmo 2.0 (TM) they upgrade the input signal to be a PWM input instead of an analog input. Modularity in the software allows the software team to simply replace the gizmo position component with one that reads a PWM instead of an analog voltage and keep the rest of the gizmo subsystem the same. In the future, projects that use gizmo 1.0 use one version of the gizmo subsystem and projects that use 2.0 use another.
This is true at any level in the hierarchy: as long as the inputs and outputs are the same, a component or subystem package can be replaced by another.
Version control in automotive software reflects this. Instead of having one tree of versions and releases like a typical software project, each component, subsystem package and software project has its own tree of versions. Each software project will reference the subsystem packages required for their engine type, vehicle platform, sensors and actuators, etc. This is how code reuse is acheived.
Testing is a mix of simulation (the sensor/actuator is simulated in Simulink and connected to Simulink block diagram of the software component), hardware-in-the-loop (a computer simulates the vehicle, but the real electronic control unit is used) and vehicle testing.
Thanks for reading. I hope this improves your understanding of how automotive software is structured.
I'm hoping the discussion will bring examples from other fields like robotics, drones and aeronautics that have similar real-time requirements on how they architect their software.
For example, I know there's an embedded systems company that writes everything in Haskell, and running their Haskell program actually generates "safe" C code that they compile down to their chips.
My impression from the oft-cited Toyota report was not only that there was a lot of global variable stuff, but that these "write-once" principles weren't super respected.
EDIT: It basically provided at least two implementations for an ASIC by independent teams. The ASIC guys would implement the real deal in an HDL and test it. However, full system tests where the HDL simulation is hooked up with CPU simulation were too slow. By implementing the same spec in C, you gain simulation performance and get a second implementation and set of eyes that can help find bugs.
If some of these timers are implemented as separate OS tasks that can interrupt each others, what's to stop one from taking a bit too much time and throwing off the timing of another?
There is only one OS task for each rate (10ms, 100ms, etc). The order of the function calls in each task is determined at compile time while respecting constraints (A_10ms must run before B_10ms because B_10ms uses values computed in A_10ms).
In addition each OS task has an overrun monitor that triggers if a task is scheduled to run but the previous run has not finished yet. This type of error typically sets a "control module performance" diagnostic trouble code.
> The microprocessor has to run for 10+ years in a wide range of temperatures and be dirt cheap, so you end up with specs like 180 MHz, 4 MB of flash and 128 KB of RAM.
If I'm paying tens of thousands of dollars for a car, how come they're using the cheapest possible components? If tinkerers can ship the Raspberry Pi for $30 per board, inc. a 900Mhz quad-core chip and 1GB RAM, you'd think GM could get components at least that modern for an insignificant cost relative to the car they are controlling.
These "really slow" parts are actually tested and built for much more extreme conditions. For microchips that go into satelites, you even have hand-checked chips that go through a very long (and costly compared to something like a Pi) testing process. Multiply this by all the eletrical components, and you got yourself a lot of things to check.
Put your Raspberry Pi next to a car motor, and it's pretty likely(1) a part will fail in the heat and grime conditions.
(1) actually, I'm not sure about the likelihood, but there's no assurance that it will be fine
The car components are made to different spec than consumer electronics (for starters, there are several types of component, depending on what "range of temperatures" you need to operate them in; e.g. the stuff that goes into the traffic lights in northern parts of Europe is not something you buy off Farnell for your hobby project), and they also need to be reliable and tested. Add, of course, the usual graft and overhead.
Another thing is that a engine controller doesn't need a near-GHz quad-core chip and shit ton of RAM. It's not meant to stream HD videos or run Python, it has to run a bunch of feedback loops fast enough. Less powerful chips tend to be cheaper and more reliable.
Save a dollar on the part, and you make a million cars, how much does that add up to? Or conversely, why spend more than you have to if the quoted specs do the job? What the hell am I going to do with four cores if I follow the well-written description above?
And I'd give your Raspberry Pi a lifespan of about a month if you were to strap it to the firewall of your car while you drive it. Less if you actually powered it up.
Economy of scales is huge of course. A lot of the parts are actually shared between many different cars at different price points. There can be on the order of 50+ micro-controller in that car. Do you want to pay 10$ extra for each of them just because they have cooler specs?
The various parts are designed at various times so that car might have controllers for the anti-lock braking system that were designed 5 years ago.
Hard real-time applications (brakes, ECU, etc.) don't magically need more gigahertz, that engine with direct injection only needs to calculate fuel volume maybe 20000 times per seconds (once per cylinder per 2 rpm) and that would probably be a ridiculous upper bound.
In-car navigation and entertainment packages are completely separate from the hardware actually controlling the car.
In a side project I was involved in. We were using 60mhz chips to modulate data at 1khz. I kept worrying about running out of cpu cycles, I mean after all, I was doing a few thousand things per second. But in reality, I still had a ton of head room to go :)
When coming to work from university (1989-90), I made a somewhat similar though more primitive design for the embedded software of a redundancy controller of a satellite modem. The various tasks (control of RF and baseband electronics, display and buttons UI, network management interface, etc) would run according to a scheduler, each in turn. No dynamic memory allocation, internal communication via global variables that are written only in one place. There was no mechanism to actually enforce this, it was just the principle in code, and the enforcement was possible because it was a one-man software project so I had no one else to blame.
This was written in PL/M (which looks like Pascal but is more similar to a primitive variant of C) on a 8031 microcontroller, from scratch (no 3rd party SW components at all - that was a long ago).
Later on, I used the same platform for a design we did on a telephone/data cable modem we designed for domestic use (We saw a need for internet enabled cable modem in 1992 and started work on a thing that provided POTS and 128 kbit/s over SLIP). That was also running a 8031, but as we wanted to make it dirt cheap, the board did not have dual-port RAM. The hardware wizards made it run with a hack on the regular RAM access so that the SW could only access RAM if it read any memory location twice: first read would just place the address bits on the bus, and doing another read would actually fetch the content. This enabled us to save several dollars per device.
(This was possible because the 8031 has an architecture which is not strictly von Neumann design: the code and address spaces are different memory spaces and you use different CPU instructions to access the different memories, so your program memory on EPROM works normally but your data memory in external RAM does not. There's also a small internal RAM in yet another overlapping address space which was not impacted by address bus weirdness.)
This is just to show what kind of strange limitations you sometimes have on the hardware in embedded devices. Unlimited virtual memory, large non-volatile storage instead of a puny i2C bus EEPROM... you just dreamed of those. Modern controllers with 4G flash are really huge compared to that, but they are still far below what people have on desktop computers, or even an Android phone.
The limitations in embedded devices indeed come from cost per device as well as heat, vibration, radiation, humidity and similar environmental factors.
May I ask why you left the industry?
As alleged in the NOV, VW manufactured and installed software in the electronic control module of these vehicles that senses when the vehicle is being tested for compliance with EPA emissions standards. When the vehicle senses that it is undergoing a federal emissions test procedure, it operates in a low NOx “temperature conditioning” mode. Under that mode, the vehicle meets emission standards. At exactly one second after the completion of the initial phases of the standard test procedure, the vehicle immediately changes a number of operating parameters that increase NOx emissions and indicates in the software that it is transitioning to “normal mode,” where emissions of NOx increase up to nine times the EPA standard, depending on the vehicle and type of driving conditions. In other tests where the vehicle does not experience driving conditions similar to the start of the federal test procedure, the emissions are higher from the start, consistent with “normal mode.”
I have not read a substantive response from any part of VW to today's allegations.
One firm, run by the guy who saved Jack In The Box with the ubiquitous sphere-head Jack commercials after an E. Coli outbreak killed 4 kids, said that VW should run an ad of a new executive blowing up the boardroom to symbolize changing the old guard.
Another firm suggested they crowdsource answers to how they can fix the problem/make it up to the public.
The last firm said they should just shut up and not draw attention to themselves. They're not in a good position to say anything right now, and they should just let the collective public forget about it and move onto the next scandal.
I'm assuming the third options is what VW's retainer-ed marketing firm has opted for.
[1] http://www.thisamericanlife.org/radio-archives/episode/569/p...
The funny thing is this:
Porsche could sue over £25 a day congestion charge (2008)
http://www.theguardian.com/business/2008/feb/19/travelandtra...
> The mayor's office responded saying the threatened legal action was "a double attack on Londoners".
> "First Porsche are trying to deprive Londoners of their democratic right to decide in the mayoral election on 1 May whether they want gas guzzling and polluting cars to drive in London when there is absolutely no need for them to do so. Second they are trying to impose on all Londoners unnecessary levels of pollution and greenhouse gases by a tiny minority," said a spokesman for the mayor.
> "No one is allowed to throw their rubbish in the street and Porsche should not be allowed to impose gas guzzling polluting cars on Londoners who do not want them."
I hope Porsche get taken to the cleaners.
Schadenfreude?
The point of that article is to show that Porsche are a company with total disregard for emissions, pollution and noise. It is in their DNA, it is what they do. Hence it is great that they finally get their comeuppance.
Environment Canada, a "regulatory group"? It's a department of the Government of Canada, yo.
Also, diesel trucks that emit black smoke do fail emissions test - in counties that actually have emissions tests.
It's also very much a local issue that varies widely across the country, as emissions testing programs are generally administered at a county level.
I have a 2015 Q5 TDI which while not specifically mentioned has the same size engine as several of the ones that are mentioned (3.0-liter). I would be shocked if they just started using the defeat device in the 2016 model year for the Q5 considering they were already getting pushback from the EPA before the 2016 models even got announced.
I bought the diesel specifically because of the high mileage and supposedly clean emissions. What a crock.
It's also possible that EPA just hasn't finished testing all of the vehicles yet and your particular car may get added to the list. Sorry about that. I actually test drove the Touraeg TDI that shares the same engine and almost bought one a couple of years ago...
0 - http://yosemite.epa.gov/opa/admpress.nsf/0/4A45A5661216E66C8...
I'm surely not going to defend VW or any of the associated companies for cheating. But it should be kind of obvious that a car with such an engine does all but clean emmisions.
If that is the case, then this is an example of the maxim: When you provide a feature, someone will use it to their own ends -- meaning, "misuse" it.
Another example to wave in front of all those politicians and people advocating for encryption "back doors".
If you put the feature in there, people will use it any way that suits them. Including and especially ways that you did not intend nor want.
If it wasn't Bosch, perhaps there was nonetheless some "legitimate" argument within VW for adding this functionality. Enough to get the software folks -- particularly those not making big bucks off of the deal -- to implement this.
But an observant engineer might nonetheless ask themself, 'what might hypothetically be done with this?' And the engineer with a little more real world experience ("the cynic" ;-) might assume that someone will do it, sooner or later.
That was part of my reputation, for a while: Thinking of what was possible, and assuming -- or insisting -- it needed to be addressed. A year or two later, having done so would prove to have been of benefit. It would sometimes piss Management off, in the short term. But eventually, they came around.
Anyway, looking from the outside or the inside: If it's there and can be used "that way", someone's going to get around to doing so.
However, this was later rejected by Bosch who claim that writing additional code is required by the car manufacturer to get the emissions test detection feature [2].
[1] http://blog.caranddriver.com/report-bosch-warned-vw-about-di... [2] http://www.reuters.com/article/2015/10/07/volkswagen-emissio...
But what about used ones? Seems like prices will be plummeting. And if you like the cars, seems like a great time to buy.
Considering it's doing the automotive equivalent of leaving a turd on the sidewalk everywhere it goes, I'd be really disappointed if its perf and mileage were merely average.
Hey, if you want to buy a shit car, I don't think ethics really factor into it.
All kidding aside, despite being in absolutely no danger of ever buying another VW, I would think of it like I think of buying from (to pick a recent popular whipping boy) Amazon: does giving money to the company vote for the world you want to live in? I like workers to be treated fairly and with respect, so no more Amazon for me. I like clean air and products that win because they're great products that don't rely on cheating to make them great, so no more VWs for me.
As for used ones (assuming non-diesel), I'll use another metaphor. I'm a vegetarian. What if my veggie pizza shows up with pepperoni (and assume I otherwise like pepperoni)? I eat it. Cow's already dead, I didn't request that it be killed for my meal, and they're just going to throw it away if I send it back. Might as well eat it. Used VWs? Money's already in the pocket of a crooked company, might as well buy one if it suits your needs. Just take it somewhere other than the dealer when it needs work. :-)
"But even so, Bosch still supplied the “defeat” code EDC 16 engine management system at the heart of the #Dieselgate scandal"
"the high temperatures heat the selective catalytic reduction system ("catalyst") and improves the catalyst's ability to reduce tailpipe NOx emissions"
There has been recently http://www.thestar.com/autos/2015/09/30/canadian-trios-exhau...
I wonder if this tech would work for SCR systems or not.
http://junkscience.com/2012/10/new-documents-prove-falsifica...
They were experimenting on human subjects without informed consent and using the data to overstate results that favored the regulations they wanted to impose.
These regulations set the particulate limits diesel powered vehicles must meet.
The real problem is drawing any conclusion from a sample size of 1.
While I want clean air, and believe in global warming; I'm afraid that the EPA will use VW as a reason to tighten emmission standards to to point where we will need to buy new vechicles in order to drive. I can't afford, nor really want a new vechicle.
I'm at the point now that I pray my vechicles passes smog checks. I'm not working as a mechanic now, but I have been to automotive school. I take those smog results, I get every two years, and tune my vechicles appropriately. My vechicles are tuned properly. I use a secondary 02 sensor attached to secondary bung holes before, and after the catalytic converter. All, so I can get the engines in perfect stoichiometric values. I clean out my erg valves. I change the oil. I double check some emmission sensors with a DVOM. I look for that lazy sensor and replace it if it's not in spec.
Even with all that, it seems like it's a crap shoot on wether my vechicles pass.
(I can't blame the EPA, or CARB totally. I have found gross errors in Motor Emission publications. Off subject, but smog stations are only required to have one emmission's reference on site. Most shops usually just have the current copy of Motor's Emmisson Manual. It's cheap, and that's what they show you if your vechicle fails the visual. The publication is filled with errors. If you failed the visual on your smog test, double check the information with Mitchell Manuals. I have never found an error in a Mitchell manual. Off subject--yes, but when your arguing with a smog tech. you might remember this post.)
There is some chance that better testing will result in lower emissions standards, if the better tests reveal the existing standards to be unrealistic.
Requiring VW reimburse purchase price would make more sense, but still would not account for time spent having to look for new car etc.
On the other hand, there are numerous reports of owners not wanting to return their cars for software updates out of fear that such fixes would change performance characteristics of their vehicle for the worse.
In terms of banning sales, that would be an effective strategy to 'press' VW into acting faster but is likely to severely impact the co financially - something Germany simply can't allow due to huge numbers of people employed/at stake.
The value of X should not matter.
do they have the legal authority to do so? If they did, I doubt the republican led congress would stand by idly.
I guess they saw everyone cheats by at least 2x, as some reports have also said.
Bottom line- VW group cheated, was caught, and Im sure has a few dozen scapegoats lined up in accordance with automotive scandal rules and regulations. People will use this as a platform to get their names in the spotlight as a crusader for the people, the managers that made the decision will go largely unpunished, and the world will move on. I think its crappy behavior, but in the scheme of things they did not directly murder anyone and people willingly participate in much more dangerous activities than breathing excessive NOX fumes... I think that they should just fine them make VW say "We are truly deeply heartfeltly sorry" and then we can worry about the bigger problems in life.
Pollution has very diffuse, but very real human and ecological consequences. One of the reasons this fight is so hard is because they are so hard to reason about or even witness. It took systematic study of events like https://en.wikipedia.org/wiki/Great_Smog_of_1952 to realize how many people stuff like NOX emissions kill and disable.
What if doing something took a day off of the life of every single person in the world. In terms of "days of life destroyed" you would have an event unparalleled by any genocide in history, but yet how many people would even care?
What does that have to do with anything? If Alice chooses to wrestle sharks in her spare time, that's completely irrelevant to Bob being forced to breathe toxic fumes.