|
|
 |
|
 |
|
 |
| Ev Archive for December 1998 |
 |
| 1060 messages, last added Wed Aug 08 18:43:52 2001 |
[Date Index][Thread Index]
Re: Production EVs
>> It would be hard to imagine a software failure that would result
>> in a ramp up to full throttle in an AC controller.
>
>Then you have never tried to design a fault-tolerant micro. Here is just a
>sample of the things you have to think about:
>
> - a reset can occur at any time, between any two instructions, and in
> most micros, the reset process takes many clock cycles to complete.
The output must sequence properly to run the motor. Screw-ups in
software or timing screw up the sequence or the sequence timing. Thus, no
operation or wierd low-power operation, not full throttle.
> - a bit in any memory location or register can flip or stick at any
> time. You have to consider what this will do to program execution
> and data validity.
This will generally cause motor operation to stop or cause plug braking.
All must be well for proper sequencing to occur.
> - the clocks can fail, freezing the outputs, or run at the wrong frequency.
Speeding up operation could speed up the motor, but you would need to
ramp up voltage proportioanlly to keep the rotor from stalling. Multiple
faults would have to occur in just the right way. Generally the
microprocessor is operating at or very near top speed. Going faster will
trash the program and proper sequencing will not occur. Thus, you don't get
a runaway. Freezing the outputs causes plug braking on an AC drive. (On a DC
drive, however, freezing the output can easily cause full throttle runaway.)
> - input and output bits can spontaneously change states or modes,
> due to design defects in the chip (essentially all chips have them)
> or external EMI or noise.
> - undetected software bugs that arise when the right conditions occur.
> - self-test and diagnostic modes that get entered inadvertently.
> - the I/O channels blindly keep generating some output (like a PWM)
> even if the micro is distracted and off doing some unimportant task.
>
>You might say "that can't happen", but they DO! So you have to examine each
>one in detail, and be sure your design has protection.
The program must be operating properly for correct sequencing of the
phases to occur. The frequency, voltage control and current control must all
operate in concert for a runaway to occur. It would take a very odd
combinations of faults to make this happen. I'm not saying that it can't
happen. I'm just saying that a lot of things have to hit just right for it
to happen. Aside from a fault in the throttle-sensing portion of the system,
there are very few fault modes that will result in a runaway in an AC drive.
This is not the case for a DC drive. Faults often result in
full-throttle operation in a DC drive.
>
>>> Do not suppose a problem cannot be solved just because you don't
>>> know how to do it.
>
>> Excuse me. There is no known way to avoid this problem.
>
>Oh, there isn't, eh?
>
> - overdesign the switch so the chance of a failure is negligible.
There is still a momentary surge before the switch opens.
> - use another topology; boost converter, or buck-boost converter.
This is impractical in a drive the size needed for an EV. An AC drive
would be cheaper.
> - use redundant switches; if one fails, the other immediately turns off
> and won't turn on again until the problem is fixed.
Momentary surge.
> - use an electronic circuit breaker; microsecond response when fault
> is detected.
At the currents involved, such an exotic breaker would raise the cost
beyond an AC drive. Detection of the fault takes time, a surge will still occur.
> - crowbar the motor with an SCR; forces a slow fuse or circuit breaker
> to clear.
Detection of the fault takes time. Surge will be a bit shorter, but will
still occur. Detection circuitry could smoke with controller and fail to
operate SCR. All this adds to the cost.
> - mechanical solutions, like a shear pin in the drive line.
If it shears before the wheels spin on wet or icy pavement, it will
shear during normal operation of the car. If it shears at a torque greater
than that needed to spinn the tires in wet or icy conditions, it won't
protect against the problem completely. Also, the car will still launch a
few feet anyway.
>
>> An AC controller is likely less expensive (or at least more practical)
>> than these other types of DC controllers.
>
>No; all the DC/DC converter topologies use just one transistor and one diode.
But you need a big inductor or capacitor to get the boost. This would
make it more expensive.
>
>> Inherently, plug braking does not present the degree of hazard that
>> uncommanded full-throttle does. That is why OEM EVs have AC drives.
>
>If the EV-1 with its 100 HP drive goes into full braking or reverse on the
>freeway, you don't think that's a "degree of hazard"? No transmission or
>clutch, no emergency stop button; what are you going to do, my friend?
Same degree of hazard with uncommanded full throttle in the identical
driving mode. Remember, the AC motor can only plug brake as hard as the
equivalent DC motor can accelerate with the controller shorted.
You can find situations in which plug braking causes a hazard. There are
far more situations in which uncommanded full-throttle causes a hazard. The
degree of hazard is always larger or the same for uncommanded full throttle
(UFT) than it is for plug braking.
Operation mode Plug braking UFT
Parked None Large
Slow Traffic Small Large
Stopped in Traffic None Large
Highway Moderate Moderate
Parking lot None Large
Approaching Cross walk None Large
There is no driving mode in which uncommanded full throttle presents no
hazard. There are many driving modes in which plug braking presents no hazard.
With plug braking, the car comes to a stop all by itself with no driver
input. After it has stopped, there is little or no hazard. Under most
driving modes (not all) no damage or injury results. This is not the case
for uncommanded full throttle. Without driver input, the car will accelerate
until it hits something big enough to stop it.
This is why the OEMs pick AC drive.
_ /|
\'o.O' Bill Dube'
=(___)= bdube@boulder.nist.gov
U
 |
 |
|
|