Author Topic: EEVblog #517 - Car Airbag Controller Teardown  (Read 23860 times)

0 Members and 1 Guest are viewing this topic.


Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #1 on: September 09, 2013, 09:54:15 pm »
the cap is indeed the last line of defense.

if the car gets hit on the corner where the battery sits and the battery is destroyed this cap is the last power source to ignite the explosive charge

i did the igniter chip for airbags long ago. the silicon has a metal heater element on it. this silicon chip is 'implanted' in the explosive charge that detonates the gas cartridge. there is a local 'big cap' in the discharge system as well.

in case the connection betwene the controller and igniter is severed the detonator will ignate. there is a continuous stream of challenge and response between controller and igniter.
that is why you have to be careful unplugging those suckers. if you unplug under the wrong condition the detonator will go off.

we need to ensure that the glow element would ignite so the dilemma is : how do you test this ? you can;t set it off as it is destructive. ( you want sparks )
so the heating element had a sidetap. during test we actually tested the short tap and heated up that one. a readback mechanism checks the resistance chance of the copper between hot and cold( we used top layer copper on these ic's )

so whenever you run a powerup of the car this selftest is run.
the real igniter is 5 times longer than the short one. since they are ont he same ic processed by the same chemistry we do the following :
take a cold reading. of the short stub. the long stub needs to be about 5x that resistance value.
heat the short stub and check the delta-r. this in confidence the heater is within spec.
cylce smart current through the long run to test the driver stage.

if all passes : we are ok and will be able to ignite when the need comes.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 6706
  • Country: gb
  • Electronics Hobbyist & FPGA/Embedded Systems EE
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #2 on: September 09, 2013, 10:45:14 pm »
Interestingly it seemed SQUIB driver was rated for up to 35V Vignite, separate from car battery voltage. I wonder if they boost the voltage as well as use the big cap for storage, or in case of collision under low battery due to dead charging system.

The ignition time specified was <1ms at 2.24A for one channel. I don't know why they need 8,400uF for that? Multiple igniters in each airbag?

And extra accelerometers, for the side curtain airbags?
 

Offline cosmos

  • Regular Contributor
  • *
  • Posts: 110
  • Country: 00
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #3 on: September 09, 2013, 10:48:55 pm »
The second large device (ST with end V6) could conceivable be a second uC, ST makes some nice ARM M3s for instance.
Firing the Airbag is certainly a safety issue (you better not do it when you should not and equally also not fail to firing it when it is needed).
Having redundant processing and sensing (explains the two sensors) would make it easier to get rid of common cause failures.
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 6706
  • Country: gb
  • Electronics Hobbyist & FPGA/Embedded Systems EE
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #4 on: September 09, 2013, 11:15:20 pm »
Also presumably two different architectures, with firmware developed by two different engineering teams.
That way bugs common to misunderstandings by one team do not affect the other.

I know NASA had quintuply redundant space shuttle computers: four standard plus one additional basic computer, having an entirely different architecture and being developed completely independently.

I wonder how much there is to go wrong with an airbag controller? Is it simply looking for an acceleration momentarily higher than a certain figure, or is it doing an integral energy calculation to decide if airbags are necessary? If it's the latter I'd expect a fairly beefy DSP algorithm but the Freescale app note showed an 8-bit redundant controller, which doesn't seem like it would have much DSP capability.
 

Offline DavidDLC

  • Frequent Contributor
  • **
  • Posts: 755
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #5 on: September 10, 2013, 05:11:51 am »
The conforming coating I don't think is applied with a brush, it will be inconsistent. When I worked on the automotive industry, we made similar product ( different brand ) and we use a X/Y robot to apply the coating.

David.
 

Offline moemoe

  • Regular Contributor
  • *
  • Posts: 105
  • Country: de
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #6 on: September 10, 2013, 06:49:25 am »
I think it's very clear why the pcb isn't dipped into the coating: All the nice press fit contacts and the programming/readout/jtag-connector on the back would be coated as well, making no more contact.
https://github.com/maugsburger/
Breadboard Adapters featured in EEVBlog #573 on Tindie
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #7 on: September 10, 2013, 07:34:09 am »
It's not unusual for automotive ECUs to have 2 or even 3 microcontrollers in them. They are either redundant, or they work in some sort of lockstep scheme or there is a main controller doing all the processing and a smaller "safety controller" that is typically much more simple, but very reliable (think PIC16, 8051 derivatives and the like). I doubt though, that it's an ARM chip. IMO ARM controllers didn't really make it to the automotive industry (save for maybe some infotainment stuff). I've torn down some ECUs in the past and never saw an ARM processor or controller.

As for Infineon: they are very dedicated to automotive stuff, and generally pleasure to work with. And I can assure you that their microcontrollers have a fair share of the market. Maybe not in the uber-high volume stuff like airbags, but rather braking systems, stability, powertrain control, comfort modules etc. They also have some unique features like for example three core lockstep architecture. They also offer some other highly integrated chips like the PMIC in this module. For example one  that has all communication interfaces and transceivers on a single chip.


One comment about the coating: what you seen on this airbag module is most definitely not brush-painted, but rather selectively coated. This is because you generally do not want conformal coating to be in between pcb and enclosure as it is relatively soft. When it deforms from applied forces, the pcb may start rattling in the enclosure. There are a few methods of selective coating, but two are dominant: cnc-driven spray nozzle or mask that shades some areas and large spray. To be honest the coating quality on that one is terrible (irregular, lots of air bubbles). It does not matter that the contacts are press-fitted or that there are programming pads. Coating is usually the last step before putting the pcb into the enclosure. There are many test pads that are coated so in-circuit test must be done before coating, and programming can be done at the same time. Here it can be different though, because of the capacitor holder thingie, which obviously was mounted after coating (there seems to be coating underneath it).



The EEPROM usually contains two types of info: first of all the parametrization data and checksums. Typically the OEM writes only a few software versions which are then parametrized using data stored in external eeprom/flash (for example vehicle mass, number of airbags, sensor angle and position etc). Crash data for analysis is sometimes stored in the flash, but some ECUs have non-erasable memory to prevent crash-code deletion (makes it harder to sell crashed and repaired car to unaware buyer).

Common mode choke is definitely for CAN bus, because from EMC compliance and EMI robustness point of view CAN one of the biggest interference sources inside the ECU and has to be heavily filtered and routed with extreme care on the pcb.


As for the airbag control algorithms, they can be quite complex. I can't say for sure how the software works, but I'd guess the following:
-tests airbag charges on startup, loads config data from eeprom
-gets the data from acceleration sensor
-gets the data about speed and if there is acceleration or deceleration going on
-senses the presence of passengers
-applies digital filtering to all the incoming signals
-calculates angle and force of impact taking into account speed and acceleration
-calculates inertia force which will affect the passengers
-determines whether to deploy airbag and is yes, than which airbags (for example only side curtains if it's a side impact)

and obviously a shitload of verification, checking, testing etc to rule out any false conditions like a road bump, driving over a curb, sudden engine stall etc. You don;t wan't an airbag to blow up in your face for no reason :)
« Last Edit: September 10, 2013, 07:45:54 am by poorchava »
I love the smell of FR4 in the morning!
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #8 on: September 10, 2013, 07:47:13 am »
The big unusual looking diode is a beefy transient voltage suppressor by Vishay, SM8S series.
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #9 on: September 10, 2013, 10:06:53 am »
similar stuff can also be bought from Diodes Inc / Zetex
I love the smell of FR4 in the morning!
 

Offline Eliminateur

  • Regular Contributor
  • *
  • Posts: 179
  • Country: ar
  • Electronic's Technician
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #10 on: September 10, 2013, 12:17:44 pm »
Seeing as airbags are a ultrareliable thing, i do wonder how big the code for those MCUs is..., and if they program it in C or assembly...(i guess at this point C...)
on one hand you want it as short and simple as possible(as it needs to be VERY fast to trigger), on the other you have all the complex algorithms(the selftest sequence is not complex even if it has tons of steps, it'¿s just a step by step thing) and multiple simultaneous input sensors that need to be polled (unless they program the acceleromoters with a threshold and use the "ARM" function to trigger an interrupt.
Also how they deal with the main/failover MCU, if they have some sort of watchdog thing between them or they're completely separate(i doubt they have comms between them, because a software bug could keep the watchdog alive but not fire the airbags)
 

Offline tom66

  • Super Contributor
  • ***
  • Posts: 6706
  • Country: gb
  • Electronics Hobbyist & FPGA/Embedded Systems EE
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #11 on: September 10, 2013, 12:42:43 pm »
Well, in the UK now it is an MOT (roadworthiness) failure to have a lit airbag fault light. I'd imagine that maybe the lesser microcontroller is perhaps only for fault detection? The documentation I could find seems to suggest a lot of DSP algorithms involved in calculating the angle and deceleration to determine if and what airbags should deploy. I'm not sure how the little processor could do that all.
 

Offline Eliminateur

  • Regular Contributor
  • *
  • Posts: 179
  • Country: ar
  • Electronic's Technician
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #12 on: September 10, 2013, 12:50:27 pm »
Well, in the UK now it is an MOT (roadworthiness) failure to have a lit airbag fault light. I'd imagine that maybe the lesser microcontroller is perhaps only for fault detection? The documentation I could find seems to suggest a lot of DSP algorithms involved in calculating the angle and deceleration to determine if and what airbags should deploy. I'm not sure how the little processor could do that all.

Check the block diagram, whilst the main MCU has SPI bus to the firing banks, the failsafe only has a "single" line, i think that the failsafe just fires everything(i mean, it's failsafe after all, what's safer than "in case of failure, deploy all", you can't go wrong with that) and since it doesn't needs to calculate direction, it only has a threshold that might be higher than the main DSP(so that it doesn't overrides it on any impact with it's "fire all" signal) or maybe the banks inhibit the failsafe line if they receive valid firing "data" signals.
At least that's what i can think of the top of my head...
wait.. i figured out one that would work more easily: if the banks receive the failsafe fire signal and have no valid "data/SPI" fire signal then after a timeout they fire(assuming main MCU failure), that way you satisfy all conditions!
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #13 on: September 10, 2013, 01:19:19 pm »
Code for this kimd of stuff is typically written in 'automotive' c. Also called MISRA. The MISRA rules are very specific and classified accordance to level of safety and security.MISRA is an analysys tool , a kind of linter, that goes over your code and flags all potential dangers. Void pointers, uninitialised memory , and tons of other dangerous constructions are trapped and flagged. A MISRA compliant compiler will not produce output as long as your code is not clean.
There is no such thing as 'we have 500 warnings, but we will produce output anyway...'

Motor Industry Software Reliabilty Association. Look it up

There is a misunderstanding in this thread. The squib is the detonator element. A squib is just a heating element with a phosphorous , or other flammable coating, attached to a pellet of explosive. It has no 'brains'. The squibs used for airbags are more comlicated. The heating element is sometimes part of the chip. This removes chances of bad contacts between the control logic and the heater.

We had a chip with a serpentine heater made from copper on its top layer. The chip was wired to a big reservoir capacitor and a connector. The entire thing was coated in some epoxy, leaving the heater part exposed. This got the flammable coating applied and the explosive pellet. This whole thing sat in a holder with a gas cartridge. These cartridges are very similar to what is used in whipped cream makers, safety vest for airplanes and other stuff. The explosive shoots a pin through the seal.

The airbag controller and airbag igniters are always powered in a car. There is no mechanical switch between battery and that electronics as it is a point of failure.

When the motor is started there is the whole selftest including the heater element continuity test , charge test ( they verify the capacitor is charged at high voltage and ready to go ) and verify the driver mosfets are operational. The heater element sits in an h-bridge. So they test one side at a time. They fire with an ac voltage. If one of the fets dies there is still a 50% duty cycle signal, enough to detonate.

If anythign fails you het the warning light and the entire system is shut down. The caps are discharged and that's it.

Once that is passed the system is active and armed. There is constant communication between the airbags and airbagcontrollers to detect wiring problems or catastrophical failure.

I dont remeber the exact details , but one of the i terlocks is like this :
If communication fails and within x milliconds power fails : detonate.
If the car gets hit in such a fashion the battery is destroyed , the controller has a big cap and enough time to send a command : detonate. The airbag also has abig cap to do the work. So the system works even in absense of battery power.
If cable harnesses are destroyed or sheared off the same happens. Communication will fail , with power loss followed : detonate.

There are commands being sent identifying the state of the car: motor off, stationary. Motor on , stationary, motor on , moving, motor on , accelerating and so on. Depending on the 'state' of the car
The trigger conditions change.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline Eliminateur

  • Regular Contributor
  • *
  • Posts: 179
  • Country: ar
  • Electronic's Technician
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #14 on: September 10, 2013, 01:25:22 pm »
modern car electronics are certainly fascinating, i know i have a ton of delight everytime i connect to the CANbus in my Volkswagen, the sheer ammount of sensor data going through is astounding(even the DOORS are separate entities with their own canbus controllers), and everything is connected together(anb my VW is a 2006 model even!)
 

Offline G7PSK

  • Super Contributor
  • ***
  • Posts: 3861
  • Country: gb
  • It is hot until proved not.
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #15 on: September 10, 2013, 02:40:51 pm »
Having made a number of special steering wheels, I know that in order to remove the wheel without setting the airbag off it is best to remove the battery and let the capacitors discharge over night otherwise you can get quite a surprise.

I dismantled the electronics connector for a Chrysler PT cruiser steering wheel which also contains the air bag as well as various switches and found a piece of flat flex connector 4.1 meters long in a coil with 5 conductors 2 of which were dedicated to the airbag, the copper was of very heavy gauge for flat flex and all connections to pins were welded.

 

Offline bitwelder

  • Frequent Contributor
  • **
  • Posts: 967
  • Country: fi
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #16 on: September 10, 2013, 08:04:36 pm »
The big cap block seemed to have more than two contacts.
What were for, just to better anchor mechanically the cap support to the board, or was there some additional component?
 

Offline orion242

  • Supporter
  • ****
  • Posts: 746
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #17 on: September 11, 2013, 12:45:25 am »
Great video Dave!

The EEPROM usually contains two types of info: first of all the parametrization data and checksums. Typically the OEM writes only a few software versions which are then parametrized using data stored in external eeprom/flash (for example vehicle mass, number of airbags, sensor angle and position etc). Crash data for analysis is sometimes stored in the flash, but some ECUs have non-erasable memory to prevent crash-code deletion (makes it harder to sell crashed and repaired car to unaware buyer).


This is something that has been rolling around in the back of my mind for some time.  The thought of my own property reporting my speed, braking, etc to the authorities really rubs me wrong.

So if someone want to disable the cars ability to snitch on its owner, a possible vector may be to insert a uC in between the ECU and EEPROM and only allow read/write to the parameter data and discard all other writes.  In the case of the non-erasable memory is it typically an external memory chip or is it part of one of the processors?

How generic are these modules, are they vehicle specific?

Before seeing this, I assumed it may be easier to just sense the airbag deployment and unleash a few kilo-volt charge on the 12v supply as close to the airbag electronics as possible.  Sure it may fry all the electronics in the vehicle, but after a airbag worthy crash I'm not to concerned about driving that again.
 

Offline garak

  • Contributor
  • Posts: 32
  • Country: au
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #18 on: September 11, 2013, 05:47:47 am »
This is something that has been rolling around in the back of my mind for some time.  The thought of my own property reporting my speed, braking, etc to the authorities really rubs me wrong.

So if someone want to disable the cars ability to snitch on its owner, a possible vector may be to insert a uC in between the ECU and EEPROM and only allow read/write to the parameter data and discard all other writes.  In the case of the non-erasable memory is it typically an external memory chip or is it part of one of the processors?

How generic are these modules, are they vehicle specific?

Before seeing this, I assumed it may be easier to just sense the airbag deployment and unleash a few kilo-volt charge on the 12v supply as close to the airbag electronics as possible.  Sure it may fry all the electronics in the vehicle, but after a airbag worthy crash I'm not to concerned about driving that again.

Not to discourage you or anything, but messing around with safety systems in your car sounds like a spectacular mistake. Especially when they can literally blow up in your face.

IANAL, but I wouldn't be too concerned about the ECU "dobbing you in", since all evidence that's presented in a court of law needs to be cross-examinable. This would mean that the manufacturer would have to reveal exactly how the data was obtained and what further processing was done to it. I really don't think that's going to happen.
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #19 on: September 11, 2013, 07:33:04 am »
Also how they deal with the main/failover MCU, if they have some sort of watchdog thing between them or they're completely separate(i doubt they have comms between them, because a software bug could keep the watchdog alive but not fire the airbags)

What I write is based mainly on other safety devices (ABS, stability control etc) but they have to comply with the same standards as airbags.

There are numerous solutions for protection against MCU crash. Simplest one is a small external supervisory device which receives a heartbeat signal from main controller. If the heartbeat signal stops (it's usually averaged by a low pass filter) the supervisor trips the reset. There are controllers which have multiple cores that operate in a lockstep. It means that two cores perform same set of operations and periodically compare the results, if the results differ then something went wrong. Obviously there is a problem of determining which core worked correctly and which one did not. Another way is to use an external supervisory controller which keeps bidirectional communication with main controller. If communication stops or the response is incorrect the supervisor will reset the main controller.

Reaction to fault condition differs. Some systems will only disable outputs (i'm pretty sure it's a part of some international standard, but can't recall the exact number right now) and light the warning lamp on the console. Some will disable the outputs, reset the system and enable outputs again if everything is ok (aside from the fact that some systems cannot perform POST if the vehicle is moving or something like that). Most critical stuff (think for example a circuit that transmits braking signal or a gearbox/retarder controller in 18-wheeler) can have double or even triple redundant circuits and when one of them fails it gets restarted while the other two still work.

Some MCU's have limited amounts of triple RAM memory. Hardware compares all three copies and makes sure they are identical to prevent accidental bit flips or single bit failures. This takes quite a lot of silicon space though, which is why the amount of such memory will be rather limited. Nonvolatile memory is usually fairly standard, with all the errror correction functions you can find anywhere, but whole software is checksumed and verified upon boot to prevent running corrupt program.

Great video Dave!

The EEPROM usually contains two types of info: first of all the parametrization data and checksums. Typically the OEM writes only a few software versions which are then parametrized using data stored in external eeprom/flash (for example vehicle mass, number of airbags, sensor angle and position etc). Crash data for analysis is sometimes stored in the flash, but some ECUs have non-erasable memory to prevent crash-code deletion (makes it harder to sell crashed and repaired car to unaware buyer).
So if someone want to disable the cars ability to snitch on its owner, a possible vector may be to insert a uC in between the ECU and EEPROM and only allow read/write to the parameter data and discard all other writes.  In the case of the non-erasable memory is it typically an external memory chip or is it part of one of the processors?

How generic are these modules, are they vehicle specific?

Before seeing this, I assumed it may be easier to just sense the airbag deployment and unleash a few kilo-volt charge on the 12v supply as close to the airbag electronics as possible.  Sure it may fry all the electronics in the vehicle, but after a airbag worthy crash I'm not to concerned about driving that again.

If this is implemented correctly, then definitely a part of a processor. If it was external one could simply desolder the chip either to replace it with erasable one, a blank otp one or just to destroy evidence. Expect something more along the lines of e-fuses that prevent software downgrades in xbox 360. Replacing the main controller is nto an option anyway, because you wouldn't have the proper bootloader and application program to flash it.

I don't know how is that for other countries, but in eastern EU it is a common practice (and in the gray zone of most law codes) to import crashed cars from wealthier countries (Germany, Switzerland, Scandinavia etc), repair them and sell to people without informing them. It's because a new car costs something like 1.5years worth of average sallary and 80% people earn below 2/3 of the average. The idea behind this was actually to prevent 3rd party workshops from repairing cars after crashes and failures, but has a side effect of making it harder for wreckage importers to scam people.

As for being generic, it depends on how do you define generic. On this module you can see Hyundai and Kia logos (it's the same corporation). But I'd bet some money on TRW selling those devices to other car manufacturers too. Hardware would be the same (or a slightly different variant - notice the unpopulated footprints and missing pins in connector). Application software could be identical with only parametrization being different.

In most cases automotive OEMs design one device in such a way, that it can be customized to fit multiple customers and configurations with slight hardware of software changes.

Funny thing: I drive a 2002 Opel Omega caravan (http://en.wikipedia.org/wiki/Opel_Omega) and it also has TRW airbag system :). Can tell if the ECU was the same, because I've only seen the airbag itself, not the controller. Not that I expect it to work after 11 years anyway :)
« Last Edit: September 11, 2013, 07:38:39 am by poorchava »
I love the smell of FR4 in the morning!
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #20 on: September 11, 2013, 08:47:41 am »

Check the block diagram, whilst the main MCU has SPI bus to the firing banks, the failsafe only has a "single" line, i think that the failsafe just fires everything(i mean, it's failsafe after all, what's safer than "in case of failure, deploy all", you can't go wrong with that)
I would think it would be the other way round  - if a fault is found by the supervisor, don't fire. The risks of injury with a bag firing when it shouldn't are much higher than not firing when it should, if only because almost all of the time, it shouldn't be firing.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #21 on: September 11, 2013, 10:23:04 am »
I wonder if avionics would have similar safety characteristics, or be even more stringent...
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #22 on: September 11, 2013, 11:35:44 am »
Most likely the latter. Logic behind being, that even a small plane crash can cause many times as much damage as even the largest and heaviest truck.
I love the smell of FR4 in the morning!
 

Offline DarkPrince

  • Regular Contributor
  • *
  • Posts: 107
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #23 on: September 11, 2013, 10:59:05 pm »
I wonder... depending on the air bag configuration in my car I could possibly yank the airbag controller on it. My dad and I bought the car from an auction after it was "totaled". New radiator + a few mods and it is good to go... minus the air bags. Both* airbags, drivers and passengers, have deployed already and were not replaced. Also the charges on both drivers and passenger seat belt have blown. A quick dis-assembly to release the belt mechanism and restore the latching mechanism.  A waiver saying I understand that if I die in a crash it isn't the car companies fault anymore due to the non-functioning safety system and it is road legal once more.
 

Offline orion242

  • Supporter
  • ****
  • Posts: 746
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #24 on: September 12, 2013, 12:23:07 am »
I don't know how is that for other countries, but in eastern EU it is a common practice (and in the gray zone of most law codes) to import crashed cars from wealthier countries (Germany, Switzerland, Scandinavia etc), repair them and sell to people without informing them. It's because a new car costs something like 1.5years worth of average sallary and 80% people earn below 2/3 of the average. The idea behind this was actually to prevent 3rd party workshops from repairing cars after crashes and failures, but has a side effect of making it harder for wreckage importers to scam people.

Yea well the EU has a little more respect to privacy than on this side of the pond.  Its not far from becoming standard fair for the data to be pulled out on any traffic accident.  I can see the day were insurance companies use the data to decline coverage because you were speeding a few over the limit.  All this on equipment I purchased.

Sounds like the "electrical storm" after deployment is the most likely to be effective across the board.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf