Author Topic: EEVblog #517 - Car Airbag Controller Teardown  (Read 23862 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).
 

Online tom66

  • Super Contributor
  • ***
  • Posts: 6707
  • 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.
 

Online tom66

  • Super Contributor
  • ***
  • Posts: 6707
  • 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)
 

Online tom66

  • Super Contributor
  • ***
  • Posts: 6707
  • 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.
 

Offline Kompost

  • Contributor
  • Posts: 16
  • Country: pl
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #25 on: September 12, 2013, 12:58:27 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.
Can't see what more could be done to make it even more reliable. Considering the whole controller may fail and the system will still do it's work.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #26 on: September 12, 2013, 01:27:22 am »
I wonder if avionics would have similar safety characteristics, or be even more stringent...

go read up how the ARINC 429 bus works...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #27 on: September 12, 2013, 07:28:53 am »
I would also guess that all the assemblies have to withstand much more severe overvoltage conditions and power surges. In automotive setting I think most violent event of thatnature is so called 'load dump' which occurs after very heavy load (eg. battery) gets disconnected from alternator and there are voltage spike until regulator catches - up to 500V or so.

Now an aircraft has a pretty healthy chance of being struck by lightning... I have no idea against what overvoltage levels are avionic electronics devices specified.
I love the smell of FR4 in the morning!
 

Offline BravoV

  • Super Contributor
  • ***
  • Posts: 7547
  • Country: 00
  • +++ ATH1
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #28 on: September 12, 2013, 07:48:35 am »
Now an aircraft has a pretty healthy chance of being struck by lightning... I have no idea against what overvoltage levels are avionic electronics devices specified.

I always thought Faraday cage effect takes care of that ?  ???

Offline hikariuk

  • Supporter
  • ****
  • Posts: 206
  • Country: gb
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #29 on: September 12, 2013, 12:09:43 pm »
Yea well the EU has a little more respect to privacy than on this side of the pond.

You apparently missed the furore when people figured out that GCHQ and the NSA share data :)

(It's almost like no-one had ever heard of UKUSA before)
I write software.  I'd far rather be doing something else.
 

Offline JackOfVA

  • Supporter
  • ****
  • Posts: 350
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #30 on: September 12, 2013, 12:36:30 pm »
Yea well the EU has a little more respect to privacy than on this side of the pond.

You apparently missed the furore when people figured out that GCHQ and the NSA share data :)

(It's almost like no-one had ever heard of UKUSA before)

Although the agreement is titled "UKUSA," Australia and NZ are participants and share signals intelligence data, or so I've read.
 

Offline Stonent

  • Super Contributor
  • ***
  • Posts: 3824
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #31 on: September 13, 2013, 12:24:40 am »
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!

Well maybe not.  A coworker's wife's Honda suddenly fired all the airbags while she was driving down the road. She almost got in a wreck trying to control the car without seeing anything.

Honda wouldn't fix it because the car was out of warranty and she had to use her insurance to cover the repair.
The larger the government, the smaller the citizen.
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9018
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #32 on: September 13, 2013, 02:52:21 am »
http://techno-fandom.org/~hobbit/cars/batbox/
Scroll all the way to the bottom and you'll see the inside of the backup capacitor pack used for an ABS system.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline cosmos

  • Regular Contributor
  • *
  • Posts: 110
  • Country: 00
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #33 on: September 13, 2013, 12:49:28 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!

Well maybe not.  A coworker's wife's Honda suddenly fired all the airbags while she was driving down the road. She almost got in a wreck trying to control the car without seeing anything.

Honda wouldn't fix it because the car was out of warranty and she had to use her insurance to cover the repair.

Goes to show that safety systems can and will fail ... it is just that the rate is reduced (strange how many think that safe means it can suddenly never fail) .
Put enough cars/trains/robots/etc  in service for enough time and faults will start to surface.
 

Offline hikariuk

  • Supporter
  • ****
  • Posts: 206
  • Country: gb
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #34 on: September 13, 2013, 04:44:12 pm »
Yea well the EU has a little more respect to privacy than on this side of the pond.

You apparently missed the furore when people figured out that GCHQ and the NSA share data :)

(It's almost like no-one had ever heard of UKUSA before)

Although the agreement is titled "UKUSA," Australia and NZ are participants and share signals intelligence data, or so I've read.

Correct, so are Canada.  It's basically the English speaking intelligence club.
I write software.  I'd far rather be doing something else.
 

Offline brainwash

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: de
    • Hack Correlation
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #35 on: September 27, 2013, 09:17:14 pm »
Here's more than you'd want to know about this:

Parts
The automotive parts like these sell in the millions so it makes sense to have dedicated product lines. Another requirement is that car manufacturers need to have certain certifications (someone mentioned MISRA but there are also SPICE/ISO, CMMI and others) and all those certification requirements trickle down to the last component. So if you really want to use jellybean parts you will be responsible for the mishaps, because the certification implies complete traceability.

Certain automotive parts are the exact technical equivalent of their hobby-grade stuff but they went through some cert tests and are proven automotive-capable. You sometimes pay 5x the price without getting anything extra. Obviously you cannot use other parts (even better and much cheaper) since the manufacturers did not go through the trouble of getting things certified. That's a sure way of getting easy money. Case in point: harddrives made for entertainment units.

Software
The airbag logic is very complex and it's usually done by a specialized company or outsourced from some universities. That's because big auto parts companies employ generally mediocre people. That's because they need a lot of them and cannot afford the best ones nor are they able to find so many. It's just how corporations work.

The designers/developers responsible with the product mostly change parameters and write them to the EEPROM.
There are well over 20 inputs for each of these units (accelerometers, crash sensors, speed, engine, doors, seatbelt, occupancy/weight, roll-over, ...) and AFAIK the default fail-safe behavior is to NOT trigger the airbag.


The airbag units involved in a crash that resulted in deployment generally cannot be reused. They blow some fuses up or make some other irreversible changes to the unit. I'm sure enterprising individuals can restore them but hopefully that is not happening. Usually the units get exchanged for a new one or from a another car. With newer cars the units need to be coded as well so that the CAN gateway can recognize them.

On a lot of [european] cars the battery also has a pyro charge that interrupts the positive lead in case of a crash. I am not sure if the detonation happens before airbag deployment or after, but I would guess the later.


Regarding the code, AFAIK there is absolutely no ASM allowed, no pointers, no C++ crazy features, no "funny" obfuscation, no multithreading and a few other "hacker" things which I forgot about. Exceptions have to be heavily reviewed and innovations (algorithm, optimisations) are most often discouraged.

Design
On the electronics side, most of the automotive supply stuff is heavily over-engineered. All kinds of watchdogs are put into place and all possible recordable errors are written to the EEPROM and counted. The generic OBD stuff cannot find all of them but a car-specific tool can.


Misc
IANAL but I haven't heard of any case where the data stored in the EEPROM was being used to monitor someone or make a spectacular legal case.

I find it more interesting that for motorcycles the stuff is less regulated and generally less safe and reliable, with the exception of [big] BMW motorcycles which share a lot of technology with their car counterparts from 5-10 years before.

Interesting
A bit off-topic but on my 2001 BMW I can access at least 100 individual CAN-speaking chips giving me access to thousands of parameters. They tell me how many times the electric windows have had an overload (trying to lower while frozen), wiper failures, ~20 PID parameters for the cruise control (I don't even have the buttons for that), 10 parameters for the auxiliary heating unit (no control over that either), >15 parameters for the interior heating, at least 4 points of calibration data for each parking sensor (8 of them). And that's just the small stuff.
Interestingly enough, the 2007 BMW K1200 motorcycle entertainment unit has the same innards as my original one. Including the cassette drive! And it speaks the same CAN protocol that has been made obsolete since 2004.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #36 on: September 28, 2013, 10:32:22 am »
Quote
The airbag units involved in a crash that resulted in deployment generally cannot be reused. They blow some fuses up or make some other irreversible changes to the unit. I'm sure enterprising individuals can restore them but hopefully that is not happening.
http://www.airbagreset.com/[/quote]
I'd be highly surprised if it's anything other than eeprom data. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9018
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #37 on: September 30, 2013, 01:36:01 am »
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!

Well maybe not.  A coworker's wife's Honda suddenly fired all the airbags while she was driving down the road. She almost got in a wreck trying to control the car without seeing anything.

Honda wouldn't fix it because the car was out of warranty and she had to use her insurance to cover the repair.
Might be covered under a recent recall.
http://www.carcomplaints.com/news/2013/honda-recalls-honda-odyssey-acura-mdx-air-bags.shtml
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline MFX

  • Regular Contributor
  • *
  • Posts: 93
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #38 on: September 30, 2013, 09:53:07 pm »
Funnily enough this teardown came right at the time when I was researching airbag systems for ideas for a pyrotechnic firing system I'm in the (long) process of designing. One particular patent I came across was US6597181  http://www.google.com/patents/US6597181 Basically the squib is between a high side and low side FET you insert a current limited (not enough to fire the squib) voltage that is around half the voltage of the firing voltage at the mid point of the FET's. If either of the FET's is faulty (short) then the test voltage will get pulled high or low depending on which FET is faulty, if that test passes then you can turn on each FET in turn to test their operation and also measure squib resistance. For my initial tests I'm using "Smart FETs" again designed specifically for the automotive industry, they are particularly resistant to blowing due to short circuits without affecting their ability to provide peak inrush currents. I'm using ITS428L2 for the high side and BTS3160D for the low side (mainly because I could easily get them from RS).

Martin.
 

Offline brainwash

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: de
    • Hack Correlation
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #39 on: October 02, 2013, 07:27:12 am »
I thought the firing mosfets were shot after deployment, did not know of the special ones.
Nevertheless, even if possible, it might seem like a bad idea to reuse controllers. The plus side might be that the unit was already tested and found working :)

I had a friend who did all these kinds of resets: airbag and light controllers, ECUs, car stereos. While the airbag stuff has only a safety side to it (if YOU reuse it) lying on the mileage, reusing a stolen stereo or selling a shot controller as new is completely wrong. I never knew what he did with the dirty money, he already had a good job anyway.

Most of the grey-area automotive 'resets' are operations performed on EEPROMS. However, I suspect some units also need parts (fuse) replacement.
 

Offline MFX

  • Regular Contributor
  • *
  • Posts: 93
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #40 on: October 02, 2013, 05:26:36 pm »
Sorry didn't make the MOSFET bit clear, although the ones I'm using are designed for automotive use they are more intended for controlling lights hence they have short circuit protection but also open circuit detection built in so they can signal a blown filament. Airbag MOSFETS seem to often be integrated into the main control processor. I'd be surprised if the MOSFET did blow on deployment as that would indicate it's operating right on the edge/beyond it's safe working area which would be a bad thing for reliable operation, how can you guarantee that the MOSFET has done it's job before it blows? I regularly fire squibs around 1 ohm 24Volts from fairly small MOSFETS (RFD14N05L is a common one I use) and they are fine. Occasionally a squib will blow but then go short which can blow an unprotected MOSFET but there are ways to protect against that, either use a MOSFET with built in protection or fit an external protection circuit. One of the simplest protection methods I've seen in a 24V firing system was two car headlamp bulbs in series, cold they provide a very low resistance so don't limit the current to the squib that much  but in the event of a short they quickly heat up, resistance increases and protects the FET. Downside is their fragility.
« Last Edit: October 07, 2013, 10:28:48 pm by MFX »
 

Offline Mister_Elektro

  • Newbie
  • Posts: 1
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #41 on: October 07, 2013, 06:17:18 am »
Wow, it's very interesting to whats inside one of those things. I'm in the fire department so i the those things sometimes "in action".
 

Offline castironman

  • Contributor
  • Posts: 17
  • Country: 00
  • If I can only take it apart....
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #42 on: January 04, 2014, 10:46:45 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!

Well maybe not.  A coworker's wife's Honda suddenly fired all the airbags while she was driving down the road. She almost got in a wreck trying to control the car without seeing anything.

Honda wouldn't fix it because the car was out of warranty and she had to use her insurance to cover the repair.

I always wondered about this system, a little worried when I work around it. I wonder if the system was not triggered before she started to drive and then all parameters just perfected lined up... My truck had a front impact that took the whole front and the air bags did not deployed. Maybe a Dodge thing.
 

Offline orion242

  • Supporter
  • ****
  • Posts: 746
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #43 on: January 12, 2014, 04:58:09 pm »
Misc
IANAL but I haven't heard of any case where the data stored in the EEPROM was being used to monitor someone or make a spectacular legal case.

A quick google turned up a few cases where they did retrieve it.

http://bangordailynews.com/2013/08/21/news/midcoast/police-pull-information-from-cars-computer-in-fatal-port-clyde-crash/
http://www.trivalleycentral.com/casa_grande_dispatch/area_news/archer-trial-begins-on-tuesday/article_ea68209a-7a10-11e3-9926-001a4bcf887a.html
http://www.postbulletin.com/news/local/divers-find-rd-body-in-the-mississippi-after-weekend-crash/article_f8ae21b0-c311-5d2c-8428-519b6e6dde5e.html


Companies specializing in the retrieval of this data.  Must be a market for it....

http://www.meaforensic.com/technical/event-data-recorders/
http://www.crashforensics.com/automobiledatarecorders.cfm

I read somewhere that a local cop shop was talking about review this data on every crash as part of a normal investigation.  I can't seem to find this now.

How about turning them into a revenue generator?

http://articles.latimes.com/2013/oct/26/nation/la-na-roads-black-boxes-20131027
« Last Edit: January 12, 2014, 05:14:57 pm by orion242 »
 

Offline fkoran

  • Newbie
  • Posts: 3
  • Country: us
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #44 on: February 07, 2017, 05:10:38 am »
Anyone notice this unpopulated QFP footprint with the vias and fiducial? Guessing that's some sort of test pattern for optical inspection?

 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3240
  • Country: gb
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #45 on: February 07, 2017, 09:08:45 am »
I find it more interesting that for motorcycles the stuff is less regulated and generally less safe and reliable, with the exception of [big] BMW motorcycles which share a lot of technology with their car counterparts from 5-10 years before.


The only safety systems on a modern bike are ABS and sometimes traction control (inc. anti-wheelie).  What makes you believe these systems are less safe and reliable than those deployed in a car?
 

Offline brainwash

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: de
    • Hack Correlation
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #46 on: February 07, 2017, 09:24:45 am »
I said in general, not just for those two systems. I'm sure ABS and TCS work just fine, even though on cars I've had varying experience with different manufacturers.
While there are probably some models out there that have at least one of these suggestions, these things are missing: active handlebar dampening, airbags (at least for precious areas), high-side prevention, fatigue detection, night vision, active cruise control with imminent impact warning.
I'm sure if the manufacturers were required to put those in, through regulation, they would find a way to do it cost-effectively. Except night vision (yet), that's a bit of a stretch.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3240
  • Country: gb
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #47 on: February 07, 2017, 09:56:35 am »
I said in general, not just for those two systems. I'm sure ABS and TCS work just fine, even though on cars I've had varying experience with different manufacturers.
While there are probably some models out there that have at least one of these suggestions, these things are missing: active handlebar dampening, airbags (at least for precious areas), high-side prevention, fatigue detection, night vision, active cruise control with imminent impact warning.
I'm sure if the manufacturers were required to put those in, through regulation, they would find a way to do it cost-effectively. Except night vision (yet), that's a bit of a stretch.

By "less safe and reliable" you actually mean "not available".  Quite a big difference.

FWIW traction control should prevent high-sides in the majority of cases but I suspect it would be almost impossible to achieve complete immunity from them.

Airbags are now available built into motorcycle clothing which is the only valid place for them to exist.

Active handlebar dampening is a slightly bizarre suggestion IMO, why not strive to make engines well balanced instead?

The rest of the stuff sound like you basically want a two wheeled car. IMO one of joys of motorcycling is to get away from this complexity.
 

Offline brainwash

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: de
    • Hack Correlation
Re: EEVblog #517 - Car Airbag Controller Teardown
« Reply #48 on: February 07, 2017, 10:23:32 am »
My post should read: the motorcycles are less safe and reliable because of missing systems. I NEVER said that safety systems that are already implemented are less safe than their automobile counterpart, but you still insist on reading it like that.

Active handlebar dampening - if you've never had the handlebars slam against the tank in a turn you wouldn't understand this. Yes, I know that motorcycles are inherently self-stabilizing and doing nothing is better, but we are talking about safety and prevention.
Airbags - ok, cannot argue with that
TCS - a friend of mine managed to do a low-speed high-side last year with a new bike (VFR1200). I don't know the exact details and his proficiency, though he has a few years and around 100k miles under the belt. Not drawing any conclusions, just stating a fact.

Cars vs. motorcycles argument: ok, I agree, but they share the same street. Track racing is something else. I never even had a bike with ABS, not complaining about that and not really missing it. But why not try to prevent accidents if the technology is already there in the mass-market?

So, again, my post should read: motorcycle technology is behind automotive by at least 5-10 years, with regard to both safety and reliability. Technically, it's possible, just not being done (voluntarily or enforced).

Same thing for emissions and economy, but I don't want to be perceived as 'that guy'; personally I think small vehicles are negligible w.r.t. emissions. I just find it strange that a bike with 600cc and <300kg eats as much fuel at 120km/h as one 2000kg car with 2500cc, same production year.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf