ABS on track / competition car?
Discussion
The Bosch Motorsport ABS system is very good indeed. It just uses the std production ABS 8.0 Hydraulic/control module with a revised calibration enabling the driver to select the blend between yaw control (cross axle stability) and maximum longitudinal decceleration.
However, considering they are selling your something that comes tumbling out of a factory literally by the million, their prices are astronomical!
The 8.0 system is a 12 solenoid Hydraulic modulator, so it can do the full ABS/TRAC/DSC intervention, although i have no idea if the profesional teams using this system actually take advantages of the full functionality.
I was just wondering if anyone runs a road car system in their track car? Now that we are all so used to ABS in our road cars it seems a bit of a backward step to go back to a driver modulated system for racing? (where it is not prohibited by the rules obviously)
However, considering they are selling your something that comes tumbling out of a factory literally by the million, their prices are astronomical!
The 8.0 system is a 12 solenoid Hydraulic modulator, so it can do the full ABS/TRAC/DSC intervention, although i have no idea if the profesional teams using this system actually take advantages of the full functionality.
I was just wondering if anyone runs a road car system in their track car? Now that we are all so used to ABS in our road cars it seems a bit of a backward step to go back to a driver modulated system for racing? (where it is not prohibited by the rules obviously)
Munter said:
Max_Torque said:
I was just wondering if anyone runs a road car system in their track car? Now that we are all so used to ABS in our road cars it seems a bit of a backward step to go back to a driver modulated system for racing? (where it is not prohibited by the rules obviously)
I'm wondering if the question then is "Which OEM ABS system is closest to a race system, or is there one that can be easily fiddled with, which wouldn't cost anywhere near as much as the bosch setup"Not that I have an answer.
It clearly makes sense to use production h/w so choosing either of the best selling ABS systems would be a starting point (Bosch 8.0 or ATE Mk70 probably). This issue is one of software and safety imo.
I.E.
1) It is unlikely that one could easily gain access to the calibration data within the production systems, and even then, you would have to account for all the correct system integration to get it to work seamlessly (without popping up fault codes etc).
2) The best approach is to subsitute your own microcontroller for the production version, giving complete control / calibration flexibility. But, as soon as you do this you open a nasty can of worms on safety and system failure modes for what is a "mission critical" application. Even Bosch themselves will not apparently fit their Motorsport system to a road car i believe?
In reality, production ABS systems are immensely reliable (i am not aware of ANY serious accidents being put down to their failure? ) but even a "track only" or a "limited liability" system would need to possess a robust software framework etc.
Of course, although most people probably don't realise it, many of the aftermarket motorsport parts (like throttle systems, pedal boxes, brake calipers, springs/dampers etc etc) all can cause death or injury due to unexpected failure and people fit these to their cars all the time! At least with a electronic system, a degree of sentience can be build in, and the system can indicate potential issues as they occur.
Here's the insides of a basic ATE Mk20 ABS system (ABS only, no TCS/DSC etc)
8 solenoids for 4 channel abs (1x isolator 1x pressure relief per wheelbrake)
And here's the control pcb side:
For the geeks the components are as follows:
1: ATE proprietry control ASIC (Application Specific Integrate Circuit). Almost certainly based on some Motorola / Freescale microcontroller for this automotive application. Interesting that a "single chip" design is used suggesting any safety supervisor system shares the same silicon (possibly a seperate die in the same package etc?). Most likely to be a 16b controller given it's age and relatively simple control task. It had a sticker on it, suggesting it's main memory is probably a OneTimeProgrammable (OTP) architecture, which makes sense for a mass produced safety critical device.
2: XTAL oscilator @ 6MHz. Good chance that the ASIC runs a 4x PLL for a 24MHz main system clock speed
3: Pump motor switching N channel MOSFETS. 2 in parallel of International Rectifier FR3303 (33V 20A @ 25degC) Very conservatively rated to drive the hydraulic pump electric motor (probably as this device is engine bay mounted and hence needs to maintain full operation to >100degC. Pump circuit detection is voltage feedback to ASIC via a 0.5MO pullup resistor and diode from the logic power input, relying on the pumps low impedance to pull down the voltage when connected / normal
4: at a guess this is a Quad schmitt trigger ABS sensor input signal conditioner (ATE ASIC). used to descretise the ABS signals into pure digital information with nice square edges to allow the comparitor in the main ASIC to identify edge-to-edge timing information (and hence wheel speed)
5: Controller Area Network (CAN) common mode data choke and 120Ohm split bus termination. Std automotive CAN bus termination architecture.
6: CAN tranciever: One of the few commercially availible IC's on this board, an NXP A82C250 soic8 packaged device. NXP CAN TCVR
7: Dual high side N channel MOSFET driver IC As the pump and solenoid power supply Fets are "high side" the gates of the drive devices must be lifted above the supply voltage. This driver IC must include an oscilator and charge pump to be able to do this at 100% duty.
8: ATMEL EEPROM AT25010A - 1Kb (128byte) EEPROM with SPi interface - likely to only contain specific vehicle "coding" info such as chassis number etc as this is only 128bytes of memory. Probably also might contain basic "model specific" data such as tyre size / mass etc) Easy enough to pull the data out for a look see ;-)
9: ATE ASIC, but it has got to be an octal lowside driver IC. Likely to be controlled over the same SPi bus as the EEPROM is on (due to their close physical mounting). This IC effectively switches on each of the hydraulic control solenoids as commanded. It is difficult to know if the device is purely ON/OFF or modulates the solenoid current via PWM for a "peak hold" type effect. (would have to log the output signals from a running system to see that)
10: ATE ASIC, most likely the system power supply regulator, probably a smart LDO (Low DropOut regulator) with built in diagnostic output (to identify a "healthy" supply) to allow the main control ASIC to suspend operation in low battery conditions etc
11: Power Gound terminals in I/O connector (earth for pump and logic/solenoids)
12: Pump power input terminal (Vbat to pump switching Fets)
13: Solenoid & Logic power input terminal (Vbat to logic/sols) - connected (via lower layer of pcb) to diode(16)
14: Pump output power terminals - pump motor plugs into the connector to which these are attached on the other side of the module
15: Solenoid power switch: High side N channel MOSFET (another FR3303) used to supply power to the hydraulic solenoids. Part of the safety concept because this is independant of the low side driver(9) that actually switches the solenoids on/off in operation. If power is cut to the sols, they default to "no ABS" mode, where the master cylinder is directly connected to the wheel cylinders.
16: Solenoid/logic reverse battery connection diode - large T0252 diode that prevents current flowing through the logic circuits if the battery is connected backwards! Note the pump motor does not have a similar device (due to power losses) and so will run backwards for a bit due to the intrinsic diodes in the N channel fets (this almost certainly won't cause any damage)
And that is pretty much it, really quite a simple system, without all the extra complication of TCS/DSC etc. Of course, the really clever parts are locked up inside the main control ASIC software.
A few other interesting points are obvious:
a) pcb is thin (<1mm rather than typical 1.6mm) and mounted on a thick (>2mm) ally plate for support and thermal performance
b) Designers were clearly worried about EMC performance as the enclosure is not metal (limtied shielding for electrical noise) so they included a footprint for a dedicated EMC sheild "tinbox" over the main control ASIC. In fact, this part isn't fitted, and so there must have been no EMC issue!
c) Lots of ASICS - when you make millions of something, you can get your own name of the box ;-)
d) Physical size of hydraulic module dominates the pcb layout, hence no requirement for super small components and routing etc. Most descretes are 0805 sized or larger. Makes it easy to hack ;-)
e) Pretty much every signal track on the pcb has a "testpad". This suggests that they used 100% end-of-line testing after pcb manufacture to ensure zero faults. This will have been done via an automated EOL test device, using a "bed of nails" test fixture. This also makes it easy to gain access to all the signals for reverse engineering purposes.......
f) unusally for an automotive environment pcb, no potting or conformal coating is present on the pcb. Possibly to facilitate EOL tests, but perhaps because they were very confident in the environmental protection capability of the modules plastic enclosure etc
When i get a chance i'll try a quick attack on CAN using UDS(ISO15765), which might turn up some of the internal calibration info
/geek ;-)
8 solenoids for 4 channel abs (1x isolator 1x pressure relief per wheelbrake)
And here's the control pcb side:
For the geeks the components are as follows:
1: ATE proprietry control ASIC (Application Specific Integrate Circuit). Almost certainly based on some Motorola / Freescale microcontroller for this automotive application. Interesting that a "single chip" design is used suggesting any safety supervisor system shares the same silicon (possibly a seperate die in the same package etc?). Most likely to be a 16b controller given it's age and relatively simple control task. It had a sticker on it, suggesting it's main memory is probably a OneTimeProgrammable (OTP) architecture, which makes sense for a mass produced safety critical device.
2: XTAL oscilator @ 6MHz. Good chance that the ASIC runs a 4x PLL for a 24MHz main system clock speed
3: Pump motor switching N channel MOSFETS. 2 in parallel of International Rectifier FR3303 (33V 20A @ 25degC) Very conservatively rated to drive the hydraulic pump electric motor (probably as this device is engine bay mounted and hence needs to maintain full operation to >100degC. Pump circuit detection is voltage feedback to ASIC via a 0.5MO pullup resistor and diode from the logic power input, relying on the pumps low impedance to pull down the voltage when connected / normal
4: at a guess this is a Quad schmitt trigger ABS sensor input signal conditioner (ATE ASIC). used to descretise the ABS signals into pure digital information with nice square edges to allow the comparitor in the main ASIC to identify edge-to-edge timing information (and hence wheel speed)
5: Controller Area Network (CAN) common mode data choke and 120Ohm split bus termination. Std automotive CAN bus termination architecture.
6: CAN tranciever: One of the few commercially availible IC's on this board, an NXP A82C250 soic8 packaged device. NXP CAN TCVR
7: Dual high side N channel MOSFET driver IC As the pump and solenoid power supply Fets are "high side" the gates of the drive devices must be lifted above the supply voltage. This driver IC must include an oscilator and charge pump to be able to do this at 100% duty.
8: ATMEL EEPROM AT25010A - 1Kb (128byte) EEPROM with SPi interface - likely to only contain specific vehicle "coding" info such as chassis number etc as this is only 128bytes of memory. Probably also might contain basic "model specific" data such as tyre size / mass etc) Easy enough to pull the data out for a look see ;-)
9: ATE ASIC, but it has got to be an octal lowside driver IC. Likely to be controlled over the same SPi bus as the EEPROM is on (due to their close physical mounting). This IC effectively switches on each of the hydraulic control solenoids as commanded. It is difficult to know if the device is purely ON/OFF or modulates the solenoid current via PWM for a "peak hold" type effect. (would have to log the output signals from a running system to see that)
10: ATE ASIC, most likely the system power supply regulator, probably a smart LDO (Low DropOut regulator) with built in diagnostic output (to identify a "healthy" supply) to allow the main control ASIC to suspend operation in low battery conditions etc
11: Power Gound terminals in I/O connector (earth for pump and logic/solenoids)
12: Pump power input terminal (Vbat to pump switching Fets)
13: Solenoid & Logic power input terminal (Vbat to logic/sols) - connected (via lower layer of pcb) to diode(16)
14: Pump output power terminals - pump motor plugs into the connector to which these are attached on the other side of the module
15: Solenoid power switch: High side N channel MOSFET (another FR3303) used to supply power to the hydraulic solenoids. Part of the safety concept because this is independant of the low side driver(9) that actually switches the solenoids on/off in operation. If power is cut to the sols, they default to "no ABS" mode, where the master cylinder is directly connected to the wheel cylinders.
16: Solenoid/logic reverse battery connection diode - large T0252 diode that prevents current flowing through the logic circuits if the battery is connected backwards! Note the pump motor does not have a similar device (due to power losses) and so will run backwards for a bit due to the intrinsic diodes in the N channel fets (this almost certainly won't cause any damage)
And that is pretty much it, really quite a simple system, without all the extra complication of TCS/DSC etc. Of course, the really clever parts are locked up inside the main control ASIC software.
A few other interesting points are obvious:
a) pcb is thin (<1mm rather than typical 1.6mm) and mounted on a thick (>2mm) ally plate for support and thermal performance
b) Designers were clearly worried about EMC performance as the enclosure is not metal (limtied shielding for electrical noise) so they included a footprint for a dedicated EMC sheild "tinbox" over the main control ASIC. In fact, this part isn't fitted, and so there must have been no EMC issue!
c) Lots of ASICS - when you make millions of something, you can get your own name of the box ;-)
d) Physical size of hydraulic module dominates the pcb layout, hence no requirement for super small components and routing etc. Most descretes are 0805 sized or larger. Makes it easy to hack ;-)
e) Pretty much every signal track on the pcb has a "testpad". This suggests that they used 100% end-of-line testing after pcb manufacture to ensure zero faults. This will have been done via an automated EOL test device, using a "bed of nails" test fixture. This also makes it easy to gain access to all the signals for reverse engineering purposes.......
f) unusally for an automotive environment pcb, no potting or conformal coating is present on the pcb. Possibly to facilitate EOL tests, but perhaps because they were very confident in the environmental protection capability of the modules plastic enclosure etc
When i get a chance i'll try a quick attack on CAN using UDS(ISO15765), which might turn up some of the internal calibration info
/geek ;-)
Edited by anonymous-user on Tuesday 14th May 15:19
Gen1 SAS and YAW sensors were analogue devices, and so quite easy to modify their output. Gen2 devices have pretty much all moved over to CAN output, so a bit trickier to fiddle with (still fairly easy to do however)
The issue i have with fudging the input signals only is twofold:
1) You don't really know what effect you are having on the control system ultimately
2) You still need to provide the std system will all it's normal inputs, and this is a large task for an aftermarket device. There must be a market for track/kit cars (like caterhams/Ultimas etc) where the owners would like that safety net of ABS (which you can easily turn off). Now that the latest systems are down to only a few Kg in weight, this looks to be an attractive option to me?
The issue i have with fudging the input signals only is twofold:
1) You don't really know what effect you are having on the control system ultimately
2) You still need to provide the std system will all it's normal inputs, and this is a large task for an aftermarket device. There must be a market for track/kit cars (like caterhams/Ultimas etc) where the owners would like that safety net of ABS (which you can easily turn off). Now that the latest systems are down to only a few Kg in weight, this looks to be an attractive option to me?
Krikkit said:
Max_Torque said:
/geek ;-)
Epic post. Are you a systems engineer Max?I've spent very nearly 20 years now (time flies!) doing powertrain and controls engineering, including a lot of benchmarking / reverse engineering other peoples systems!
The lastest systems use two mode current output wheel speed sensors, that output 7mA /14mA depending on if they are over a "mark" or "space" on the target wheel, and the duty cycle of the pulse train also depends upon rotational direction (so the system can tell if you've spun and are now going backwards!) Even so the data rate is actually pretty low, typical 48teeth, so that's only ~1.7KHz @ 250kph. By outputting current at all times(even when wheels aren't turning system fault diagnosis becomes easy.
For basic ABS only operation, the vehicle interface requirements are generally pretty minimal:
1) Brake pedal switch (usually same as turns on brake lights)
2) Optional brake pressure sensor input (later modules have this integrated)
3) Fault lamp output
On early systems all that was hardwired to the rest of the car, later systems have moved over to a serial bus (CAN) architecture to reduce loom mass and complexity etc
For TCS/DSC/BAS then you need a whole lot more
1) SAS
2) YAW + Lat/Long accel
3) Engine torque from EMS (both current value and returning a demanded control value for TCS "torque down" or DSC "torque up" events)
4) Brake pedal position (for brake assist)
My interest is to find out if it is possible to take one of the simpler systems and appropriate it for aftermarket use etc
1) Brake pedal switch (usually same as turns on brake lights)
2) Optional brake pressure sensor input (later modules have this integrated)
3) Fault lamp output
On early systems all that was hardwired to the rest of the car, later systems have moved over to a serial bus (CAN) architecture to reduce loom mass and complexity etc
For TCS/DSC/BAS then you need a whole lot more
1) SAS
2) YAW + Lat/Long accel
3) Engine torque from EMS (both current value and returning a demanded control value for TCS "torque down" or DSC "torque up" events)
4) Brake pedal position (for brake assist)
My interest is to find out if it is possible to take one of the simpler systems and appropriate it for aftermarket use etc
^^^^ not really a sensible idea unfortunately.
Changing the tooth number will indeed offset the measured wheel speed, and result in the system reading the "wrong" areas of it's maps. Unfortunately, you don't know if the settings for any given speed are "better" than any other, and there are a number of critical "mode" changing speeds that would be also modified (for example, the speed at which abs is suspended (better to lock wheels at very low speed < ~7mph, or the point at which TCS becomes a throttle only effect (rather than brake the spinning wheel etc). Added to which your instrument cluster will now read the wrong speed, and you are likely to get an error in the EMS (which calc road speed by NOVS calc) etc
There is also the issue of tooth timer resolution and max/min counts to deal with (max/min freq of wheel sensor input signal)
Changing the tooth number will indeed offset the measured wheel speed, and result in the system reading the "wrong" areas of it's maps. Unfortunately, you don't know if the settings for any given speed are "better" than any other, and there are a number of critical "mode" changing speeds that would be also modified (for example, the speed at which abs is suspended (better to lock wheels at very low speed < ~7mph, or the point at which TCS becomes a throttle only effect (rather than brake the spinning wheel etc). Added to which your instrument cluster will now read the wrong speed, and you are likely to get an error in the EMS (which calc road speed by NOVS calc) etc
There is also the issue of tooth timer resolution and max/min counts to deal with (max/min freq of wheel sensor input signal)
To asnwer a couple of questions / points raised:
The point of ABS is to keep the longitudinal tyre slip value during braking at the optimum point. So what is the optimum point? Well, see graph:
In effect, for a given surface, there is a single slip value at which the tyre can provide the maximum retardation (i'm ignoring cornering/ESP for now)
The issue for the older style ABS systems was determining what the true longitudinal velocity of the car was during ABS brake events. During normal drivig (no braking or excess acceleration) the system just averaged all 4 wheel speeds. But during heavy braking with ABS, these speeds diverge from the true speed of the vehicle (imagine on sheet ice, where allk 4 wheels lock immediately you hit the brake pedal!) and so the system must now estimate the true speed (it is actually measuring wheel speed, so no problems with accuracy there, but it must know the true speed to determing the difference).
To overcome this, most systems moved towards a "wheel decceleration" based system. In effect they just assume that there is a maximal decceleration of the wheels that can ever be achieved (say car pulling ~1g deccel on clean dry concrete surface), and any greater decceleration must be caused by impending wheel lock up. These system just use a basic closed loop control on wheel decceleration, making control simple and easy. The problem of course is that you might actually be on a wet oily smooth tarmac road and the basic decceleration programmed into the system would be far too great for the actual vehicle deccel availible.
Luckily for all, increasing demand for ESP systems mean't that pretty much everycar now has a combined yaw gyro/accelerometer built in. So, whilst longitudinal accel is less than a certain value determined not to produce significant wheel slip (either accel or deccel) the system calculates its refference vehicle speed from the average of 4 wheel sensor inputs, but when you start braking the system blends in an "inertial" speed estimate derrived from the Long Accel sensor. Over the long term, integration errors would make this diverge from the true velocity, but during the relatively short brake event (cars now stop from 100mph in <5sec!) this calculated value is plenty accurate enough. Now, for the first time the system can accurately calculate the true value of wheel slip, and hence control it much much better. Of course, the determination of what slip % to target still exisits and the latest systems adapt for surface friction (They know the brake torque at which wheels start to slip (from the brake pressure sensor) and/or the engine torque at which the wheels slip when accelerating, and calculate an adaptive mU value to suit)
The final point is one of stability vs decceleration. Imagine a non abs car on a "split mu" surface (both lhs wheels on dry tarmac, both rhs wheels on ice (worst case!)).
When you brake, the rhs pair of wheels immediately lock, and provide just about no longitudinal force, but the lhs wheels bite into the clean grippy surface and for the same hydraulic pressure generate a massive deccel force. But, this only acts on the lhs of the car, which causes an enormous yaw moment, resulting in the car spinning off towards the left. Early systems that could NOT measure the drivers intended trajectory (via Steering Angle Sensor) and the vehicles actual trajectory (via Yaw sensor) simply had to "select low". What that means is to avoid a loss of control event, they also reduce the brake force on the grippy wheels to a similar value to that of the slippy wheels. This remove the yawing moment, but obviously massively increases stopping distance because the total brake force is reduced (and it is also why old ABS systems had that disconcerting feeling of being "locked out" of the brakes if one wheel hit a bump etc during hard braking). The latest systems DO know what is occuring, and can modulate the balance between stability and stopping distance much much better (because they can brake hard right up until stability IS compromised and only then reduce the brake torque).
However, even with this capability, the typical OEM road calibration will always er towards stability as it's primary objective. The calibration of a racing system can allow for a much more skilled driver, one who themselves can account for yaw events via adjusting their handwheel inputs etc
The point of ABS is to keep the longitudinal tyre slip value during braking at the optimum point. So what is the optimum point? Well, see graph:
In effect, for a given surface, there is a single slip value at which the tyre can provide the maximum retardation (i'm ignoring cornering/ESP for now)
The issue for the older style ABS systems was determining what the true longitudinal velocity of the car was during ABS brake events. During normal drivig (no braking or excess acceleration) the system just averaged all 4 wheel speeds. But during heavy braking with ABS, these speeds diverge from the true speed of the vehicle (imagine on sheet ice, where allk 4 wheels lock immediately you hit the brake pedal!) and so the system must now estimate the true speed (it is actually measuring wheel speed, so no problems with accuracy there, but it must know the true speed to determing the difference).
To overcome this, most systems moved towards a "wheel decceleration" based system. In effect they just assume that there is a maximal decceleration of the wheels that can ever be achieved (say car pulling ~1g deccel on clean dry concrete surface), and any greater decceleration must be caused by impending wheel lock up. These system just use a basic closed loop control on wheel decceleration, making control simple and easy. The problem of course is that you might actually be on a wet oily smooth tarmac road and the basic decceleration programmed into the system would be far too great for the actual vehicle deccel availible.
Luckily for all, increasing demand for ESP systems mean't that pretty much everycar now has a combined yaw gyro/accelerometer built in. So, whilst longitudinal accel is less than a certain value determined not to produce significant wheel slip (either accel or deccel) the system calculates its refference vehicle speed from the average of 4 wheel sensor inputs, but when you start braking the system blends in an "inertial" speed estimate derrived from the Long Accel sensor. Over the long term, integration errors would make this diverge from the true velocity, but during the relatively short brake event (cars now stop from 100mph in <5sec!) this calculated value is plenty accurate enough. Now, for the first time the system can accurately calculate the true value of wheel slip, and hence control it much much better. Of course, the determination of what slip % to target still exisits and the latest systems adapt for surface friction (They know the brake torque at which wheels start to slip (from the brake pressure sensor) and/or the engine torque at which the wheels slip when accelerating, and calculate an adaptive mU value to suit)
The final point is one of stability vs decceleration. Imagine a non abs car on a "split mu" surface (both lhs wheels on dry tarmac, both rhs wheels on ice (worst case!)).
When you brake, the rhs pair of wheels immediately lock, and provide just about no longitudinal force, but the lhs wheels bite into the clean grippy surface and for the same hydraulic pressure generate a massive deccel force. But, this only acts on the lhs of the car, which causes an enormous yaw moment, resulting in the car spinning off towards the left. Early systems that could NOT measure the drivers intended trajectory (via Steering Angle Sensor) and the vehicles actual trajectory (via Yaw sensor) simply had to "select low". What that means is to avoid a loss of control event, they also reduce the brake force on the grippy wheels to a similar value to that of the slippy wheels. This remove the yawing moment, but obviously massively increases stopping distance because the total brake force is reduced (and it is also why old ABS systems had that disconcerting feeling of being "locked out" of the brakes if one wheel hit a bump etc during hard braking). The latest systems DO know what is occuring, and can modulate the balance between stability and stopping distance much much better (because they can brake hard right up until stability IS compromised and only then reduce the brake torque).
However, even with this capability, the typical OEM road calibration will always er towards stability as it's primary objective. The calibration of a racing system can allow for a much more skilled driver, one who themselves can account for yaw events via adjusting their handwheel inputs etc
Well, i've spent a couple of hrs poking around inside the old ATE MK20 ABS controller:
And here's the low down:
Main processor communicates to the solenoid low side driver at 1ms intervals (1KHz) over SPi coms bus, with a 2MHz clock (slow!). The small 256byte eeprom on the pcb is on the same bus, and is read every 7ms. Uploading the contents of this memory shows it doesn't hold any useful cal info, and is just model variant coding and error codes unfortunately. There are some quite nice diagnostic processes going on, like checking each solenoid is still connected by pulsing each one in turn with a lower voltage (not enough to actually operate the soleniod). This happens continuously during non braking time. The MOSFET drive for the pump and solenoids themselves is also checked in a similar manner at key-on. Although the unit does have CAN coms (3 broadcast messages, not had time to work out what they are yet, although 1 is obviously the 4 wheel speeds) it is too old to use the UDS standard for diagnostics and does all that via the "old skool" K line interface. I will probably dig mine out of the cupboard (unused for about 5 years ;-) and prod the module a bit to see if any more can be gleaned about the operaton of the brake solenoids themselves. Otherwise i will have to generate 4 "wheel speed" signals and fool the unit into responding to an "abs" event!.
However, the postie brought me another victim for the operating table this morning, a nice shiney ATE MK70 unit:
This is a much more modern unit, weighing a quite impressively small amount {~1.6kg) and certainly would be no issues to package into an Ultima or even a Caterham etc.
So, to borrow someone elses phrase "Don't turn it on, take it APART"........... ;-)
And here's the low down:
Main processor communicates to the solenoid low side driver at 1ms intervals (1KHz) over SPi coms bus, with a 2MHz clock (slow!). The small 256byte eeprom on the pcb is on the same bus, and is read every 7ms. Uploading the contents of this memory shows it doesn't hold any useful cal info, and is just model variant coding and error codes unfortunately. There are some quite nice diagnostic processes going on, like checking each solenoid is still connected by pulsing each one in turn with a lower voltage (not enough to actually operate the soleniod). This happens continuously during non braking time. The MOSFET drive for the pump and solenoids themselves is also checked in a similar manner at key-on. Although the unit does have CAN coms (3 broadcast messages, not had time to work out what they are yet, although 1 is obviously the 4 wheel speeds) it is too old to use the UDS standard for diagnostics and does all that via the "old skool" K line interface. I will probably dig mine out of the cupboard (unused for about 5 years ;-) and prod the module a bit to see if any more can be gleaned about the operaton of the brake solenoids themselves. Otherwise i will have to generate 4 "wheel speed" signals and fool the unit into responding to an "abs" event!.
However, the postie brought me another victim for the operating table this morning, a nice shiney ATE MK70 unit:
This is a much more modern unit, weighing a quite impressively small amount {~1.6kg) and certainly would be no issues to package into an Ultima or even a Caterham etc.
So, to borrow someone elses phrase "Don't turn it on, take it APART"........... ;-)
So, MK20 to MK70: (there was a couple of generations of MK60 inbetween)
Quite a change really, reflecting the massive growth in capability and flexibility of the automotive electronics arena. With IC date codes mostly in early 2007, this MK70 was probably manufactured in mid 2007, 10 years or so later than the MK20 i stripped above ^^^^.
In the mid / late 1990's. if you wanted a specific and low cost high volume integrated circuit you pretty much had to roll your own, by 2007, there are a host of semiconductor suppliers desperately wanting your buisness, and this later controlle reflects that with IC's from Freescale and ST. They are still branded ATE, so are "custom" to a degree, but now based on mainsteam product lines (and they come with all the test, development and validation from those high volume lines!)
This new module is probably 60% of the size of the MK20, still just 8 solenoids ABS only flavour in this case (interestingly, unlike the Mk20, there is no provision on the pcb for the "extra 4" solenoids required for TCS/DSC etc, and hence it must be a whole new housing / design for those devices. I suspect ATE elected to get this basic ABS only system as small, light and cheap as possible, which suggests a low end target market in the mid 2000's, so fiesta's, micras, corsa's etc. (Now of course, in 2013, we expect even our shopping cars to come with all the bells and whistles)
As before:
1) Main processor - Freescale microcontroller 100pin TQFP package - almost certainly now a 32b device. Also labelled with ATE, so likely to be a semi custom bit of silicon
2) Main uC XTAL - 24MHz
3) Large (also 100pin) ATE specific ASIC - For cost reasons, integrating all the std ABS measurement and driver functions into one specific chip is a good idea. I suspect this single device does all the low level decoding of wheel speed signals, drives the solenoids and acts in a diagnostic and supervisory function. - It would be very hard to hack this device!
4) Infineon optiMOS H channel power Mosfet, used to switch hydraulic pump power. An "off-the-shelf" automotive rated device, 55V 80A 7mO RDSon.
5) ST microelectronics EEPROM 4Kb - SPi interface
6) ST D30NF04L 30V 30A N channel mosfet - supply switch for hyd solenoids
7) ST S1045 Schotkey diode - to-252 package - Reverse battery protection diode for logic/sol power
8) Interesting "spare" footprint - unknown, could be for a seperate solder-on hybrid pcb, maybe containing a gyro or accelerometer???
9) Another "spare" footprint could well be for some external NVRAM for "flight recorder" purposes?
Generally, as esxpected, this device uses smaller 0603 sized descrete components to save space / cut costs, and much more of it's functions look to be integrated into the main ASICs rather than in seperate logic (descrete or ASIC)
Also interesting is the use of pcb "piercing" solderless contacts. To avoid the issues with solder joints failing with vibration and thermal cycling, the contacts for the connectors and solenoids are just "rammed" into plated holes in the pcb that are too small a diameter. The resulting compressive interferrence fit is, when accurately tolleranced, super reliable:
This i think would make a very good candidate for hosting a new parastic control pcb, just using some of the original IC's (might as well carry across all the power switches/diodes etc) ;-)
Quite a change really, reflecting the massive growth in capability and flexibility of the automotive electronics arena. With IC date codes mostly in early 2007, this MK70 was probably manufactured in mid 2007, 10 years or so later than the MK20 i stripped above ^^^^.
In the mid / late 1990's. if you wanted a specific and low cost high volume integrated circuit you pretty much had to roll your own, by 2007, there are a host of semiconductor suppliers desperately wanting your buisness, and this later controlle reflects that with IC's from Freescale and ST. They are still branded ATE, so are "custom" to a degree, but now based on mainsteam product lines (and they come with all the test, development and validation from those high volume lines!)
This new module is probably 60% of the size of the MK20, still just 8 solenoids ABS only flavour in this case (interestingly, unlike the Mk20, there is no provision on the pcb for the "extra 4" solenoids required for TCS/DSC etc, and hence it must be a whole new housing / design for those devices. I suspect ATE elected to get this basic ABS only system as small, light and cheap as possible, which suggests a low end target market in the mid 2000's, so fiesta's, micras, corsa's etc. (Now of course, in 2013, we expect even our shopping cars to come with all the bells and whistles)
As before:
1) Main processor - Freescale microcontroller 100pin TQFP package - almost certainly now a 32b device. Also labelled with ATE, so likely to be a semi custom bit of silicon
2) Main uC XTAL - 24MHz
3) Large (also 100pin) ATE specific ASIC - For cost reasons, integrating all the std ABS measurement and driver functions into one specific chip is a good idea. I suspect this single device does all the low level decoding of wheel speed signals, drives the solenoids and acts in a diagnostic and supervisory function. - It would be very hard to hack this device!
4) Infineon optiMOS H channel power Mosfet, used to switch hydraulic pump power. An "off-the-shelf" automotive rated device, 55V 80A 7mO RDSon.
5) ST microelectronics EEPROM 4Kb - SPi interface
6) ST D30NF04L 30V 30A N channel mosfet - supply switch for hyd solenoids
7) ST S1045 Schotkey diode - to-252 package - Reverse battery protection diode for logic/sol power
8) Interesting "spare" footprint - unknown, could be for a seperate solder-on hybrid pcb, maybe containing a gyro or accelerometer???
9) Another "spare" footprint could well be for some external NVRAM for "flight recorder" purposes?
Generally, as esxpected, this device uses smaller 0603 sized descrete components to save space / cut costs, and much more of it's functions look to be integrated into the main ASICs rather than in seperate logic (descrete or ASIC)
Also interesting is the use of pcb "piercing" solderless contacts. To avoid the issues with solder joints failing with vibration and thermal cycling, the contacts for the connectors and solenoids are just "rammed" into plated holes in the pcb that are too small a diameter. The resulting compressive interferrence fit is, when accurately tolleranced, super reliable:
This i think would make a very good candidate for hosting a new parastic control pcb, just using some of the original IC's (might as well carry across all the power switches/diodes etc) ;-)
That^^^ box will basically just act as a CAN gateway module for the yaw/long accel sensor (they are combined on BOSCH systems into the box that looks like this:
In effect it will recieve the CAN data for yaw and long accel on one CAN bus (with the original CAN ID being broadcast by the module) and then multiply / divide the signal magnitudes (depending on the effect you want to have) and re-transmit that data onto the 2nd CAN bus (which will be connected to the ABS/ASR module) with the same ID. That way the modifying effect of the box is disguised from the stability module.
Yes it will work, and with no other choice it's maybe the least bad option, but i can't say i'd particularly want to trick my statility control that way without really knowing what effect it is likely to have etc (and the only way to be SURE would be to have access to the code running in the ABS/ASR module etc )
Having looked at how the MK20 and MK70 ATE abs systems work from a hardware point of view (including their diagnostic capability) it seems very do-able to substitute my own control hardware. For a low volume device (unlike the original device) it's not too costly an approach to just throw processor power at it. Something like a STMF104 series micro controller would add a massive capability for both obtaining a very high control bandwidth (easily 5KHz if you wanted, and in fact the data input rate from the wheel speed sensors would be the limiting factor (ie having to wait for a "new" speed measurement increment from the toothed wheel/sensor) and having plenty of left over power for diagnostics/safety checking, and probably running a ful physics dynamics model as well (F104 series is 32b, floating point @ 170MHz, for about a fiver in <10 quantities!)
I'd also probably go with the "two processor" approach, and chuck on a simple 8bit device (probably an ATMEL AVR of some flavour) as an Equizzer. In effect the processors will "chat" to each other, and on any unexpected response (caused by code hang ups, data errors, or power / data signal issues) EITHER device can pull the plug on the other one (luckily for an 8 sol ABS system, no power = off andjust leaves the normal hydraulic circuit un-affected). By using two different devices, with different tool chains (Manufacturers/compliers / IDEs etc) you very much minimise the chance of a "coding" failure occuring simultaneously on both processors. Beyond that, mixing power requirements (one 5v device, one 3.3v device) also brings fail safety as their power supplies are decoupled (luckily, a gross power failure (fuse pops, wire snaps etc) also means the solenoids switch off and fail safe etc).
The only thing i can't decide is if it is a good idea starting with a system that could be upgraded to DSC/TSC over and above basic ABS at a later date without a major h/w rip up. The MK70 system, which is really small and light cannot just be upgraded to DSC/TSC because it is too physically small to fit in the extra 4 solenoids required for those operating modes.
Other wise the MK70 looks ideal, and is very availible on the s/h market (i brough my test module for £12 on ebay!) it might be worth me getting hold of a BOSCH 8.0 device (like used by the BOSCH motorsport system) for a look see (although, being much newer, these are more costly (go for more like £80-120 on ebay for example). The other issue with going DSC/TCS is that it would need a dedicate EMS system, that can ask for torque requests over the CAN bus (and really a torque based EMS to get the necessary responce accuracy / repeatability)
In effect it will recieve the CAN data for yaw and long accel on one CAN bus (with the original CAN ID being broadcast by the module) and then multiply / divide the signal magnitudes (depending on the effect you want to have) and re-transmit that data onto the 2nd CAN bus (which will be connected to the ABS/ASR module) with the same ID. That way the modifying effect of the box is disguised from the stability module.
Yes it will work, and with no other choice it's maybe the least bad option, but i can't say i'd particularly want to trick my statility control that way without really knowing what effect it is likely to have etc (and the only way to be SURE would be to have access to the code running in the ABS/ASR module etc )
Having looked at how the MK20 and MK70 ATE abs systems work from a hardware point of view (including their diagnostic capability) it seems very do-able to substitute my own control hardware. For a low volume device (unlike the original device) it's not too costly an approach to just throw processor power at it. Something like a STMF104 series micro controller would add a massive capability for both obtaining a very high control bandwidth (easily 5KHz if you wanted, and in fact the data input rate from the wheel speed sensors would be the limiting factor (ie having to wait for a "new" speed measurement increment from the toothed wheel/sensor) and having plenty of left over power for diagnostics/safety checking, and probably running a ful physics dynamics model as well (F104 series is 32b, floating point @ 170MHz, for about a fiver in <10 quantities!)
I'd also probably go with the "two processor" approach, and chuck on a simple 8bit device (probably an ATMEL AVR of some flavour) as an Equizzer. In effect the processors will "chat" to each other, and on any unexpected response (caused by code hang ups, data errors, or power / data signal issues) EITHER device can pull the plug on the other one (luckily for an 8 sol ABS system, no power = off andjust leaves the normal hydraulic circuit un-affected). By using two different devices, with different tool chains (Manufacturers/compliers / IDEs etc) you very much minimise the chance of a "coding" failure occuring simultaneously on both processors. Beyond that, mixing power requirements (one 5v device, one 3.3v device) also brings fail safety as their power supplies are decoupled (luckily, a gross power failure (fuse pops, wire snaps etc) also means the solenoids switch off and fail safe etc).
The only thing i can't decide is if it is a good idea starting with a system that could be upgraded to DSC/TSC over and above basic ABS at a later date without a major h/w rip up. The MK70 system, which is really small and light cannot just be upgraded to DSC/TSC because it is too physically small to fit in the extra 4 solenoids required for those operating modes.
Other wise the MK70 looks ideal, and is very availible on the s/h market (i brough my test module for £12 on ebay!) it might be worth me getting hold of a BOSCH 8.0 device (like used by the BOSCH motorsport system) for a look see (although, being much newer, these are more costly (go for more like £80-120 on ebay for example). The other issue with going DSC/TCS is that it would need a dedicate EMS system, that can ask for torque requests over the CAN bus (and really a torque based EMS to get the necessary responce accuracy / repeatability)
Indeed, the first generation Bosch Yaw/Accel sensors did have an analogue output, so that's easy to spoof (although subject to noise etc, which would be a bit of a worry) and i wonder how they deal with the BIT (Built In test) requirement?
Anyway, back to the ABS modulator:
I have measured the activation solenoids at 8.2Ohm and 13mH, so that suggests the limiting factor for control is in fact the response time of the solenoid itself>>>
Using just battery voltage (at a nominal 13.7v) gives a first order response somewhere between 1 and 0.5Khz, so i guess having a faster control loop that that is not necessary. It would be interesting also to do a mechanical simulation of the wheel/tyre/disc/caliper, and see what the basic fundamental response frequency of that system was. The latest systems seem to claim "10 to 15" cycles per second, so, something like 75ms duration (hold/release/rebuild). With a 1KHz control bandwidth that's nearly 2 decades of headroom, so i suspect the limiting factor will be mechanical rather than electronic.
Also, the yaw and accel sensors are low pass filtered on their outputs, so there is no point running the dynamics model much faster than that (say 2Khz). An STMF104 processor @ 2MIPs is going to be sitting around and twiddling its thumbs quite a lot ;-)
I've also managed to hook up to the K line diagnostics on the MK20 device, and from that i can see that its diagnostics capabilities are very limited really, just basic "are sensors connected" std stuff (no id-ing of wires shorted to bat or gnd etc like newer stuff)
Probably the next step is to setup a dummy brake rig, with a master cyl, ABS unit and a wheel cylinder, instrument it for system pressure, and drive the MK70 solenoid block via my own "bodged up" controller and low lever driver. If that works as planned, then the route forward will be to buy the cheapest car i can find with a mk70 controller (prob an old polo or something) build my controller into a "car" version (probably not integral with the ABS unit to start with) and get to Millbrook for some skidding around to get some baseline performance data! (with a nice big "ESTOP" button mounted in easy reach of the driver......... ;-)
Anyway, back to the ABS modulator:
I have measured the activation solenoids at 8.2Ohm and 13mH, so that suggests the limiting factor for control is in fact the response time of the solenoid itself>>>
Using just battery voltage (at a nominal 13.7v) gives a first order response somewhere between 1 and 0.5Khz, so i guess having a faster control loop that that is not necessary. It would be interesting also to do a mechanical simulation of the wheel/tyre/disc/caliper, and see what the basic fundamental response frequency of that system was. The latest systems seem to claim "10 to 15" cycles per second, so, something like 75ms duration (hold/release/rebuild). With a 1KHz control bandwidth that's nearly 2 decades of headroom, so i suspect the limiting factor will be mechanical rather than electronic.
Also, the yaw and accel sensors are low pass filtered on their outputs, so there is no point running the dynamics model much faster than that (say 2Khz). An STMF104 processor @ 2MIPs is going to be sitting around and twiddling its thumbs quite a lot ;-)
I've also managed to hook up to the K line diagnostics on the MK20 device, and from that i can see that its diagnostics capabilities are very limited really, just basic "are sensors connected" std stuff (no id-ing of wires shorted to bat or gnd etc like newer stuff)
Probably the next step is to setup a dummy brake rig, with a master cyl, ABS unit and a wheel cylinder, instrument it for system pressure, and drive the MK70 solenoid block via my own "bodged up" controller and low lever driver. If that works as planned, then the route forward will be to buy the cheapest car i can find with a mk70 controller (prob an old polo or something) build my controller into a "car" version (probably not integral with the ABS unit to start with) and get to Millbrook for some skidding around to get some baseline performance data! (with a nice big "ESTOP" button mounted in easy reach of the driver......... ;-)
In order to really understand how ABS works, and to explore different control strategies from the comfort of my own home (and with less chance of a sudden and un-intended stop or trajectory change!) i have built a 1/4 car simulation model ;-)
It's a descrete stepping successive iteration model, that calculates the major chassis dynamics parameters and allows me to determine the effect of different methods and strategies for brake pressure control quickly and accurately. At the moment, to avoid having to do loads of really detailed low level system definition the model just runs at 100Hz, and although of course the absolute output values will not entirely reflect reality, they should act as a decent comparitor.
Here's some of the models output with 3 different types of brake pressure control, for a 100-0kph stop, with the added fun of a step change in surface friction (drops from 1 to 0.6, 25m down the virtual "test strip".
So, first, no ABS, just an input by the drive to build and hold a 54kg brake pedal load:
Pretty much immediately the surface changes, the wheel locks, and the car skids to a halt 49.7m down the track
Now, an (nearly)"ideal" ABS controller, that can control brake pressure with no bandwidth or noise restrictions:
Same pedal load, same surface change, but system controls tyre slip well, and stops 42.9m down the track
And finally, a more realistic 3 mode descrete controller:
Same conditions, and in fact even this basic control stragety doesn't do too badly, finishing up somewhere between the other two, at 45.4m stopping distance
This is all well and interesting i hear you say (ok, you're probably either watching Eastenders or asleep by now actually ;-) but what does it all mean?
Well, the good news is that because this model has been built as a descretised stepping model, that has a basic calculation path, it can be very simply converted into C code to run on a real time simulator (hurray!). So, that means i can build an ABS system test rig, where the physics of the car are being simulated in near real time (will probably run @ ~2Khz) meaning that i can use the actual ABS hardware within the test loop. This Hardware in the loop (HIL) test method is good because i captures the subtleties of the system. For example, rather than have to exactly model how any particular ABS component responds, i will actually just use that very component. It also means that the testing can be very repeatable, unlike in real brake test work, and avoids dangerous early code development life er, issues!
Inital HIL will be just a 1/4 car model, but if that works well it is a quite easy step to expand that out to a 1/2 or full vehicle simulation.
It's a descrete stepping successive iteration model, that calculates the major chassis dynamics parameters and allows me to determine the effect of different methods and strategies for brake pressure control quickly and accurately. At the moment, to avoid having to do loads of really detailed low level system definition the model just runs at 100Hz, and although of course the absolute output values will not entirely reflect reality, they should act as a decent comparitor.
Here's some of the models output with 3 different types of brake pressure control, for a 100-0kph stop, with the added fun of a step change in surface friction (drops from 1 to 0.6, 25m down the virtual "test strip".
So, first, no ABS, just an input by the drive to build and hold a 54kg brake pedal load:
Pretty much immediately the surface changes, the wheel locks, and the car skids to a halt 49.7m down the track
Now, an (nearly)"ideal" ABS controller, that can control brake pressure with no bandwidth or noise restrictions:
Same pedal load, same surface change, but system controls tyre slip well, and stops 42.9m down the track
And finally, a more realistic 3 mode descrete controller:
Same conditions, and in fact even this basic control stragety doesn't do too badly, finishing up somewhere between the other two, at 45.4m stopping distance
This is all well and interesting i hear you say (ok, you're probably either watching Eastenders or asleep by now actually ;-) but what does it all mean?
Well, the good news is that because this model has been built as a descretised stepping model, that has a basic calculation path, it can be very simply converted into C code to run on a real time simulator (hurray!). So, that means i can build an ABS system test rig, where the physics of the car are being simulated in near real time (will probably run @ ~2Khz) meaning that i can use the actual ABS hardware within the test loop. This Hardware in the loop (HIL) test method is good because i captures the subtleties of the system. For example, rather than have to exactly model how any particular ABS component responds, i will actually just use that very component. It also means that the testing can be very repeatable, unlike in real brake test work, and avoids dangerous early code development life er, issues!
Inital HIL will be just a 1/4 car model, but if that works well it is a quite easy step to expand that out to a 1/2 or full vehicle simulation.
BTW, to anyone saying "ABS does't make that much difference" if i re-run those same tests, under the same conditons, but with the entire "track" on wet concrete (0.6 co-efficient) the stopping distances become:
NO ABS (immediately wheel lock) = 86m
Ultimate ABS = 59m
Typical ABS = 63m
Yup, locking wheels can be bad for your health! (especially if the cliff edge was only 65m from where you started to brake........ ;-)
NO ABS (immediately wheel lock) = 86m
Ultimate ABS = 59m
Typical ABS = 63m
Yup, locking wheels can be bad for your health! (especially if the cliff edge was only 65m from where you started to brake........ ;-)
Mr2Mike said:
PhillipM said:
Provided the driver locks the wheels 
For 86 meters as well 
It would be ammusing to put in a "human" abs control case, say an expert driver having a good stab at cadence braking and see what the results were?
Jonesy23 said:
lots of interesting and useful stuff
Thanks for that document regarding Continentals ABS systems, it confirms at lot of what i had found/guessed about the two controllers i have looked at!Regarding trying to use the PC ASIC (Periferal Controller), well it would be good to leverage all the "on one chip" capabilities, but i'm not sure that it would be possible to fully reverse engineer the device from the SPI bus. Yes, most of the comands and responses can be easily interogated, but there is so much more on there (Like CAN trancievers, PSUs, Lines, WSinterfaces etc) that you could spend a very long time indeed trying to work out what was going on. And the last thing you need on a failure critical system is some unexplained / unexplored event occuring!
There are plenty of comercially availible smart driver IC's around, that are fully documented. Something like the Freescale Octal switch mc33879:
Octal SPi switch
Also, by having more descrete parts the design is more flexible (at the expense of more cost and possibly a higher failure rate.
Some simplification can also be gained by limiting the operating range of the device. Normal Automotive things are rated -40 to 125degC, so your ABS works underbonnet from Sweeden to Death Valley. Well, for 99% of people that's a bit of an overkill
Regarding the processor internal safety watchdogs, there are plenty of things you can do to provide a basic but robust level of code execution checking. For example, it is common to have a sub routine who's only purpose is to toggle an output pin. You AC couple that pin to a charge pump circuit (capacitors and a couple of diodes) so whilst it is toggling the output of that pump is "high". If the processor falls into an random state (such as an unexpected jump to a blank ISR) then the pin doesn't get toggled, the charge pump doesn't pump charge, the voltage on the output falls to zero, and you use that to say disable the main power switch to the solenoids (ie system hard off). Now of course, there is some chance (v small) that the processor might get stuck in just the "toggling" routine, so to avoid this case you turn the pin "on" in one routine, and "off" in another. No way can it get stuck in TWO seperate sub routines, so that gives you a very simple, very low code line count watchdog for your code execution.
Another trick is to have a global value, to which you simply add 1 at the start (and exit if you like) of every critical subrountine. Then you have a diagnostic routine that runs say every 100ms, in which you check how large the value of that global counter has got to. If your system is executing in a properly deterministic fashion, that value should not vary. To check for memory errors, you can store say 10 of these counters across the memory space, and any error or accidental overwriting will get caught too. Finally, i would send the value of these counters over say an internal USART link to another processor, that also checks the value is as expected.
PhillipM said:
Max_Torque said:
Of course, completely locked wheels is worst case. but tell me that if you were driving our virtual car, at 60mph, and only 65m away from the edge of a 1000m cliff you had to do an all out stop without ABS you could calmly limit brake the car to a halt? As countless numbers of people have found out, the brain saying "lift off your foot the wheels are locked" and your leg actually doing it at moments of "terror" are two very different things! ;-)
That's what the steering wheel is for Or hit the accelerator and make it a good one
PhillipM = Evil Kenevil??? ;-)
(mind you, your buggy probably has enough suspension travel to pull off the landing at the bottom!)
RE:sensor pack. I'm planning on definitely having MasterCyl hydraulic pressure, Steering Angle(SAS), YAW and Longitudinal Accel. (Possibly Lateral Accel too)
System I/O is going to be roughly speaking:
1) 12v BattV+ (KL30) (two, input pins = pump 20A fused + system pwr 5A fused)
2) 12v Ign+ (KL15) wakeup - ignition feed to power up system on key-on
3) 4 x wheelspeed sensor inputs (7/14mA two wire type sensors)
4) CAN1 bus to talk to SAS,YAW,ACCEL sensors and anything else additional (ECU, Datalogger,Dash etc)
5) CAN2 bus optional system calibration/setup bus, using CCP / UDS protocols (probably separate connector)
6) ABS system warning lamp input (low side driven dash mounted system fail indicator)
7) Brake reservoir LOW fluid level switch input
8) Brake pedal pressed input (from brake lamp switch on pedal)
9) Master cylinder Hydraulic pressure sensor input
10) ABS 'MODE' selection switch input (dash mounted rotary switch for operation mode, inc OFF)
11) Chassis Earth
12) Emergency Stop switch input (Optional and maybe only on DEV systems)
Things like the dash warning lamp will be actively "turned off" by the ABS module, so faults should definitely illuminate the lamp (will do a 5sec bulb check on key-on)
System I/O is going to be roughly speaking:
1) 12v BattV+ (KL30) (two, input pins = pump 20A fused + system pwr 5A fused)
2) 12v Ign+ (KL15) wakeup - ignition feed to power up system on key-on
3) 4 x wheelspeed sensor inputs (7/14mA two wire type sensors)
4) CAN1 bus to talk to SAS,YAW,ACCEL sensors and anything else additional (ECU, Datalogger,Dash etc)
5) CAN2 bus optional system calibration/setup bus, using CCP / UDS protocols (probably separate connector)
6) ABS system warning lamp input (low side driven dash mounted system fail indicator)
7) Brake reservoir LOW fluid level switch input
8) Brake pedal pressed input (from brake lamp switch on pedal)
9) Master cylinder Hydraulic pressure sensor input
10) ABS 'MODE' selection switch input (dash mounted rotary switch for operation mode, inc OFF)
11) Chassis Earth
12) Emergency Stop switch input (Optional and maybe only on DEV systems)
Things like the dash warning lamp will be actively "turned off" by the ABS module, so faults should definitely illuminate the lamp (will do a 5sec bulb check on key-on)
Gassing Station | Engines & Drivetrain | Top of Page | What's New | My Stuff