Proofread a fail-safe half-bridge

[AaronD]

This is still very much in the concept phase.  Despite what any labels might say, I haven't chosen any specific parts yet.  Just looking at the overall architecture for now.

It's meant to control a solenoid or other direct-drive electro-mechanical device, with ABSOLUTELY NO MORE FORCE THAN THE OPERATOR INTENDS.  Ever.  It's okay to suddenly shut off at any time, but never to do any more than the operator told it.  Thus, any and all failure modes MUST result in the output going either LOW or Hi-Z.  It should never stick HIGH for any reason, nor should it produce a higher duty cycle than intended either.  Slightly lower is okay, but not too much lower.  (don't want it to suddenly recover while the operator is over-commanding it)


Here's what I've come up with so far.  (expand below)

It's essentially two half-bridges in parallel to drive the same raw switched node, with a physically separate controller for each, and a fuse that blows if the two controllers disagree.  This arrangement also automatically covers the case of any FET failing short, or its driver getting stuck on.

The one remaining case that I can think of as being a problem, is if both low-sides failed open, and then a high-side failed short.  (any other order would blow the fuse)  For that, there's a detection circuit that uses the controllers' internal analog comparator, fed from an internal DAC, to see if the raw switched node falls a diode drop below GND.  If it does, then both low-sides are open and the load current is freewheeling through the body diodes instead of the FET channels.  If that persists for more than the deadtime, the controllers shut down.
Also test it periodically by turning all 4 FET's off while the load still has some current.  If that doesn't produce a fault signal, then the detector doesn't work, which also triggers a shutdown.  If it does, then switch back to normal mode and keep running.

(shut down, in this context, means holding the low-side on and the high-side off, so that if only one shuts down and the other tries to continue, it blows the fuse if the corresponding low-side is still functional)

Each thing to measure has 2 sensors on it, one for each controller, and the controllers cross-check each other.  Any significant difference also triggers a shutdown.  Passing all of that, they take the smaller of their outputs to become the PWM duty cycle for both, just to keep the timing exactly equal to avoid nuisance-blowing the fuse.

They do have a connection to a single supervisor, but it's only a supervisor.  This function is entirely self-contained, with its own dedicated sensors and actuator.  The supervisor controls the Ext_Sync signal to stop and align the PWM counters, and receives a separate status report from each controller.  No more interaction than that.


So:

• Does the circuit match the theory?  (Have I done the analysis right?)
• Are there any remaining failure modes that would either directly result in the output sticking HIGH, or create an undetected single point of failure that could cause it to happen later?
  (I think) I solved one of those with the switched-node-below-GND detector.
• Are there any opportunities to simplify without creating a single point of failure, either now or later?

[NiHaoMike]

I think you have to synchronize the reset signal with the clock to guarantee they start up in step.

Maybe look at power steering control modules? They have to meet pretty strict safety requirements - uncommanded force in either direction is obviously bad but so is a sudden shutdown.

[SiliconWizard]

I would also be wary of the timings. They will be slightly different for both controllers. Would require to make sure that the dead times are long enough that there couldn't be any unintended overlap between the two half-bridges.

[AaronD]

I think you have to synchronize the reset signal with the clock to guarantee they start up in step.

Just sharing an external clock between controllers isn't enough?  I guess if an edge comes at just the right time, a slight difference in propagation delay could make them one clock cycle different.  For that same reason, I can't use an internal synchronizer.  It would have to be a single external chip, with the synchronized output fed to both controllers.  I guess I can do that; the reset/sync signal itself isn't safety-critical.

Also, I was thinking that it wouldn't necessarily be a master reset.  Just stop and reset the PWM counters.  The firmware sees that and resets the rest of its logic, so that when the counters are released, they continue from there.  (or if it's only a gate to enable the counter, then the firmware can reset the count too)

Maybe look at power steering control modules? They have to meet pretty strict safety requirements - uncommanded force in either direction is obviously bad but so is a sudden shutdown.

I have no experience with those - all that I've worked with are purely hydraulic, and then only from the outside as "keep or replace" - but you do have a point.

Update:

This application-specific chip from TI was on the first page of Google search results for "electric power steering schematic".  It has a different way of handling faults, but seems like it could work.  I never would have thought of directly checking the health of a single controller by "quizzing" it periodically with different prompts and expecting a specific different answer to each in a specific time.

Also, the bridge itself, for that chip, is not meant to be redundant like I made mine, but is meant to be powered by a "relay", which is shown in the datasheets as a high-side FET.  I guess I can put two FET's there, in series, optimized for Rds_on at the expense of speed (they're DC anyway), and have a startup routine that turns them on one at a time while checking the midpoint to see if either one has failed.
Maybe even add a crowbar (thyristor or 2 more FET's in parallel) to pull the bridge power to ground, with a fuse on top of everything?  Or is that a bit too much?

I would also be wary of the timings. They will be slightly different for both controllers. Would require to make sure that the dead times are long enough that there couldn't be any unintended overlap between the two half-bridges.

Why would the timings be different?  They don't use their internal oscillators, but share the same external clock, along with the reset synchronizer that NiHaoMike suggested.  Analog noise from the sensors, through the control logic, would result in slightly different duty cycles, but that's handled by taking the smaller of both as the agreed-upon value to drive both bridges with.  (if the cross-check is within tolerance, of course; if not, then it shuts down completely)  Am I missing something?

[AaronD]

Okay, here's a first draft with the "power steering" driver chip.  Looks like it's really designed to work with TI's redundant microcontroller, which is behind an NDA from what I saw, so here's what I came up with using two "ordinary" MCU's instead.  The driver datasheet still leaves a few unknowns, like what the configuration registers do, but it's a proof-of-concept at least.

Since there's only one SPI interface, I changed the redundancy a bit.  Instead of both running the same code and blowing the fuse if they disagree, I have one completely in charge of the bridge driver and the other monitoring it as a "black box".  The monitor has control of the main power and the controller's reset.  The power stays off at startup until the monitor sees the correct setup over SPI, and the controller waits to see power on before it tries to actually do anything.

Anything not like it's supposed to be, gets the power shut off and the controller's reset asserted.  And the controller also has some checks to make sure the monitor is working as well.  If not, hold the load at 0V.

As before, this is entirely a standalone function, with the only connection to the outside world being a status report from each to a common supervisor.

Did I miss anything egregious in this version?

[AaronD]

I got to thinking: since some of the important functions of TI's chip are not in the datasheet^(*), and since an important part of their intended system is behind an NDA, I probably won't be able to use their stuff in a way that actually works.
^{(*) There's enough that I can read and write the config registers, but nothing about what they do.  And while there's plenty about what constitutes a fault condition, there's nothing about what the chip does in that case.}

So I took what I learned from that exercise and translated it back to my own design.  Non-redundant half-bridge, driven by only one MCU, but powered by another half-bridge that is designed to provide DC either way, and is controlled by a different MCU.  As before, both MCU's cross-check each other, in addition to monitoring each others' physical inputs and outputs.  And to help guarantee a successful shutdown, each can also hard-reset the other, which allows the pull-up/down resistors to enforce 0V out instead.  Enforcing 0V instead of all-off, causes a stuck-on high side to blow the fuse.

Is there anything in this one that could cause the output to be stronger than what the sensors say?

[SiliconWizard]

I would also be wary of the timings. They will be slightly different for both controllers. Would require to make sure that the dead times are long enough that there couldn't be any unintended overlap between the two half-bridges.

Why would the timings be different?  They don't use their internal oscillators, but share the same external clock, along with the reset synchronizer that NiHaoMike suggested.  Analog noise from the sensors, through the control logic, would result in slightly different duty cycles, but that's handled by taking the smaller of both as the agreed-upon value to drive both bridges with.  (if the cross-check is within tolerance, of course; if not, then it shuts down completely)  Am I missing something?

One reason is that you're filtering the control signals (R11, R12, C11, C12, R13, R14, and similar for the second one) and those passive components have significant tolerance (especially the capacitors), so that's where the timings could diverge as far as I can tell.

[AaronD]

I would also be wary of the timings. They will be slightly different for both controllers. Would require to make sure that the dead times are long enough that there couldn't be any unintended overlap between the two half-bridges.

Why would the timings be different?  They don't use their internal oscillators, but share the same external clock, along with the reset synchronizer that NiHaoMike suggested.  Analog noise from the sensors, through the control logic, would result in slightly different duty cycles, but that's handled by taking the smaller of both as the agreed-upon value to drive both bridges with.  (if the cross-check is within tolerance, of course; if not, then it shuts down completely)  Am I missing something?

One reason is that you're filtering the control signals (R11, R12, C11, C12, R13, R14, and similar for the second one) and those passive components have significant tolerance (especially the capacitors), so that's where the timings could diverge as far as I can tell.

Okay.  I see where you get that.  I didn't specify values for all of those parts, but my intent was to have the cutoff frequency much lower than the PWM rate.  (~220Hz for C11 and R14 alone, with PWM hopefully above audible)  So that whole block essentially becomes a wire for normal operation, but it automatically goes to "the safe state" if the MCU gets stuck.

The new version solves that problem differently: a literal wire between the MCU and the FET driver, with pull-up/down resistors to set the default state, and the other MCU can hard-reset it so that the outputs go Hi-Z.  It relies on the other MCU being okay while the first one isn't - a shared clock or external reset can be a way to get both stuck - but it also removes the requirement to stay in lock-step.  So I can use the internal oscillators instead, and delete the external reset/sync.

[jbb]

Is there a specific reason you’re drawing schemes with synchronous rectifiers? It seems like your final solenoid output is ground referenced, so I wouldn’t expect to see negative current flow. Maybe you can say less parts = less problems and accept reduced efficiency?

Can you make any comments on approximate voltages, currents and required tolerances?

In general, it seems that you’ll need >= two switches in series.

In the event of a problem, is there any requirement to get the current out of the solenoid as fast as possible? A typical buck converter circuit will clamp to 1 diode drop, so it can take a while for the current to decay.  One circuit that came to mind is the 2 switch forward converter…

[AaronD]

Is there a specific reason you’re drawing schemes with synchronous rectifiers? It seems like your final solenoid output is ground referenced, so I wouldn’t expect to see negative current flow. Maybe you can say less parts = less problems and accept reduced efficiency?

My initial, default thought was efficiency, like you mentioned.  But then it quickly became a matter of necessity as I saw it, in case a high-side FET failed short-circuit.  (because semiconductors do that)  If that happens, then turning the low-side on while it's supposed to be 0V anyway, would blow the fuse and de-energize the output.  A diode can't do that.

Can you make any comments on approximate voltages, currents and required tolerances?

Not hard and fast at this moment, but likely a 3S LiPo or Li-Ion battery.  ~9.6V to ~12.6V depending on where the BMS cutoffs end up.  For current, I have no idea.  That needs a lot of testing, just to see what kind of mechanical travel and force is required, and *then* I might have some numbers for the electrical side.

This is very much in the concept / general architecture stage right now.

In general, it seems that you’ll need >= two switches in series.

The first version was a brute-force attempt at that.  It was essentially two half-bridges superimposed on each other, with the high-sides in series and the low-sides in parallel, and each high/low pair driven by its own physically separate MCU.  The idea was to make it difficult enough to avoid blowing the fuse that anything going wrong *would* blow the fuse.

So the two MCU's shared the same clock and external reset, and would run the same code, so that their PWM counters would stay in sync.  If either of them locked up, an R-C highpass between it and its respective FET driver would force the high-side off and the low-side on.  If their cross-checks disagreed, they would hold that active-0V state in software.  Etc.

Then someone here suggested to look at electric power steering, which led me to a chip by TI that is meant specifically for that exact application.  It's a 3-phase brushless motor FET driver (3 half-bridges), with a TON of monitoring in addition to just being a FET driver.  One thing that stood out to me is that it uses a non-redundant half-bridge for each phase, but the power rail for all 3 phases is controlled by another safety monitor.  So I took that back to my own design.

The latest version (so far) has a non-redundant synchronous half-bridge, that is powered from another synchronous half-bridge, so that either one can blow the fuse if it needs to de-energize and its high-side fails short.  And there does indeed end up being two of them in series to energize the load, and two independent ways to de-energize it.  The fuse guarantees that a conflict will always de-energize.


What I absolutely DON'T want to do, is have an undetected failure somewhere, that allows one more failure to uncontrollably energize the output.  Simply having two switches in series is one such failure.  If either fails short, without monitoring the midpoint somehow, then the system continues to run like normal until the other fails short as well.  And then we have an uncontrollable 100% on.  Likewise for any number of switches, unless they're monitored, in which case two is probably sufficient.

And of course the low-sides need to be checked as well, to make sure that they can indeed force 0V.  So I put a high-value resistor around the power supply switch.  Enough to not do anything significant if it got through to the load.  If everything works correctly, then releasing that low-side should cause VBUS to float up to something less than the full supply, and the correct voltage both before and after, means that it's safe to turn that high-side on.  If it then goes to the full supply voltage, then we can start running the actual output controller.

I think the only remaining failure to detect would be the final low-side failing open-circuit, so that it can't blow the fuse if the high-side then fails short.  TI's power steering chip does that by monitoring Vds, gated by the drive signals.  So maybe that could be a clue?  Can you see any more?
Or is it okay as-is, because the feedback would be wrong, which would cause the MCU software to kill the power bridge anyway?  (and there are several redundant ways to do that)

In the event of a problem, is there any requirement to get the current out of the solenoid as fast as possible? A typical buck converter circuit will clamp to 1 diode drop, so it can take a while for the current to decay.  One circuit that came to mind is the 2 switch forward converter…

A few 10's of milliseconds is okay.  I'd rather have that than not be able to shut it off at all.  So my default configuration, or "safe state", is to keep the low-side on.  This blows the fuse if the high-side were to misbehave.

[AaronD]

I think the only remaining failure to detect would be the final low-side failing open-circuit, so that it can't blow the fuse if the high-side then fails short.  TI's power steering chip does that by monitoring Vds, gated by the drive signals.  So maybe that could be a clue?  Can you see any more?
Or is it okay as-is, because the feedback would be wrong, which would cause the MCU software to kill the power bridge anyway?  (and there are several redundant ways to do that)

I've added something for that now, and clarified the power path.  Anything still missing?