Where would you protect this control system?

[Chris Carlen]

Hi:

We have a 4 channel motion control servo system for electrohydraulic
actuation of four engine valves. The basic components in reverse from
the business end are as follows:

1. voice coil motor (to actuate hydraulic valves)
2. PWM H-bridge power amplifier (to drive voice coils, with fuses to
protect coils from pegged amplifiers)
3. TI 6711 DSP with 16 channels each of 100kHz 16-bit A/D and D/A to
digitally implement closed-loop control algorithms
4. LVRT position sensors (for precise control) and proximity (for
monitoring and for a backup check on control)
5. absolute encoder on engine camshaft to inform DSP where valves
should be (position reference data)
6. extra incremental encoder on crankshaft (with one index mark blanked
by a hall sensor on the cam) feeds to DSP to give a backup check on cam
encoder alignment.

Additionally:

1. low voltage power +5V and +/-15V for DSP board and it's analog IO
system.
2. two 48V 600W switchers to power PWM amps.
3. PC connected via USB to DSP to implement GUI. This link need not be
active for the DSP to do its job.

The main safety issue is that we must prevent the valves from
accidentally crashing into the piston. Due to the complexity of the
research engines (with optical access) involved, the cost in repair time
which would result from a failure of the valve control would be huge.
This must be avoided in any fault modes where the mitigation cost/repair
cost ratio is <= 1.

In analyzing possible failure modes of this system which could lead to
this undesirable occurance, I have enumerated the following
possibilities in decreasing order of likelyhood and indicate whether the
problem has been mitigated. If not, in the next paragraph I describe
what is being planned to mitigate an unsolved problem.

POSSIBLE PROBLEMS (feel free to comment on the prioritization order):

1. position sensor failure (mitigated by use of redundant sensors)
2. DSP software or hardware failure (see below)
3. encoder alignment slippage (mitigated by use of redendant encoders)
4. line power failure (mitigated by putting system on a UPS)
5. internal DC power supply failure (see below)
6. power amplifier failure (see below)

FIXES:

re: #2. To deal with the DSP hardware or software going bonkers, I plan
to utilize a watchdog timer (WDT). The DSP board has one built into its
FPGA, but it is of little use because it doesn't have an adjustable
timeout. Rebooting the DSP takes a long time, much too long to wait to
regain control. Thus, an external custom watchdog is being designed.

I plan to use the simplest possible discrete logic to build a WDT using
some one-shots and flip-flops plus a few glue gates. It will detect the
absence of a 20kHz pulse train from the DSP (from the control loop
iteration) and if the pulses stop, will first apply a withdraw pulse to
the valves, then disable the PWM amplifiers. Thus, the WDT must include
4 pairs of analog multiplexers to switch the inputs of the PWM amps
from the DSP to a constant voltage source of appropriate polarity and
magnitude to force the valves to close quickly.

re: #5. To deal with a power failure of one of the DC power supplies
(either high or low power supplies), I am considering using redundant
supplies with a diode network to allow them to be paralleled. This
should mitigate the problem to an extremely low likelyhood of causing a
disaster. Furthermore, the WDT circuit could include power monitoring
comparators to signal the DSP if a supply was malfunctioning.

re: #6. I had considered a means of dealing with power amplifier
failure. Solid state relays could be employed to build a multiplexer
for the voice coils that could switch the coils to a constant withdraw
voltage in the event of the detection of a serious control discrepancy
by the DSP. However, the differential output of the H-bridges combined
with the fact that the motor currents are bidirectional makes this
tricky. I have concluded that the cost of fixing vs. the probablility
of occurence makes this fault mode something we will just have to hope
doesn't happen.

The cost of fixing this might be less than the cost of a failure, but at
present we require that the system be put into service shortly in
prototype configuration, and there isn't enough time to deal with this.
It is still possible to include this capability later when the system
is being finalized.

Would you consider solving the faults in the methods described?

Would you agree with the decision to give up attempting to mitigate the
possibility of amplifier failure while the system is being used for a
few months before packaging and finalizing?

Thanks for input.

--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Paul Hovnanian P.E.]

I'd leave the controller h/w as simple as possible and build a redundant
hydraulic actuator that is as separate from the main system as possible.
Have a secondary hydraulic valve system that, when energized, will drive
the valves to a safe position (closed) regardless of the primary system
commands. Using a separate crank angle sensing system that provides a
signal when the piston approaches a 'minimum safe clearance' position
around TDC and separate valve position sensors that provide a signal
when the valve is open. ANDing each 'valve open' signal with the 'crank
near TDC' signal drives the backup hydraulic controls to shut the
valves.

If the valves close under spring force, even a complete power failure
will save the engine as long as the default (de-energized) backup
hydraulic valve position is to allow the valves to close.

 

[Ken Smith]

I plan to use the simplest possible discrete logic to build a WDT using
some one-shots and flip-flops plus a few glue gates. It will detect the
absence of a 20kHz pulse train from the DSP (from the control loop
iteration) and if the pulses stop, will first apply a withdraw pulse to
the valves, then disable the PWM amplifiers. Thus, the WDT must include
4 pairs of analog multiplexers to switch the inputs of the PWM amps
from the DSP to a constant voltage source of appropriate polarity and
magnitude to force the valves to close quickly.

I have used just about exactly this sort of watchdog. I suggest you make
it so that the watchdog timer defaults to the disabling condition at power
on and require that the DSP write so some port or something before it gets
control.

Doing this somewhat protects you against the DSP waking up in the middle
of the code because the reset cirduit didn't work etc.

re: #5. To deal with a power failure of one of the DC power supplies
(either high or low power supplies), I am considering using redundant
supplies with a diode network to allow them to be paralleled. This
should mitigate the problem to an extremely low likelyhood of causing a
disaster. Furthermore, the WDT circuit could include power monitoring
comparators to signal the DSP if a supply was malfunctioning.

If you have the room, you can put great huge capacitors on the supply and
fire the watchdog if the input drops out. If the capacitors are big
enough, you can get things safe just using the energy in them.

 

[Jim Granville]

Would you consider solving the faults in the methods described?

What about mechanical stops, and a mechanical design such that the valve
_cannot_ contact the piston. Even if that means an additional cam...

This is a research engine, so that sounds like very cheap insurance...

Anything else is going to struggle with arbitary loss of power while
the engine is spining, or an arbirary loss of phase information due
to Software crashes.... ?

-jg

 

[Paul Keinanen]

POSSIBLE PROBLEMS (feel free to comment on the prioritization order):

1. position sensor failure (mitigated by use of redundant sensors)
2. DSP software or hardware failure (see below)
3. encoder alignment slippage (mitigated by use of redendant encoders)
4. line power failure (mitigated by putting system on a UPS)
5. internal DC power supply failure (see below)
6. power amplifier failure (see below)

7. Loss of system hydraulic pressure (use pressure sensors)

Paul

 

[Paul Keinanen]

I'd leave the controller h/w as simple as possible and build a redundant
hydraulic actuator that is as separate from the main system as possible.
Have a secondary hydraulic valve system that, when energized, will drive
the valves to a safe position (closed) regardless of the primary system
commands.

When using a redundant system, put the hydraulic valves in _series_
when driving towards the 'active' position, thus both systems must
agree on driving to the 'active' state.

Put the hydraulic valves in _parallel_ when driving towards the 'safe'
state, thus either system alone would drive to the 'safe' state. This
would eliminate the tug of war situation if the failed systems drives
towards opposite direction.

Alteratively a triple redundant system could mechanically vote in a
tug of war situation.

If instead of a fully redundant system an accurate main system and a
crude security system is used, put the security system 'active' state
on/off valve in series with the main system 'active' control valve and
open the security system valve as soon as it is safe and close as late
as possible. Let the main system control valve do the actual timing
within the window.

On the 'safe' side, put the safety system on/off valve in parallel
with the accurate main system control valve and activate the safety
system 'safe' state valve only during times, when there could be a
catastrophic failure during each cycle. Thus, the complex fine control
system would only be allowed to actually control within some safe
timing windows.

Of course, this assumes that the hydraulic pressure is present and
there are no leaks.

Paul

 

[Chris Carlen]

I'd leave the controller h/w as simple as possible and build a redundant
hydraulic actuator that is as separate from the main system as possible.

Not possible to alter the hydraulics.

Have a secondary hydraulic valve system that, when energized, will drive
the valves to a safe position (closed) regardless of the primary system
commands. Using a separate crank angle sensing system that provides a
signal when the piston approaches a 'minimum safe clearance' position
around TDC and separate valve position sensors that provide a signal
when the valve is open. ANDing each 'valve open' signal with the 'crank
near TDC' signal drives the backup hydraulic controls to shut the
valves.

If the valves close under spring force, even a complete power failure
will save the engine as long as the default (de-energized) backup
hydraulic valve position is to allow the valves to close.

It's not that simple. The voice coil position determines whether or not
the hydraulics can vent or not, so unless the voice coil is retracted,
the valve spring (which is present) can't help. There is a spring which
forces the voice coils into the "retract valve" position when unpowered,
but this won't close the valves fast enough when the engine is running.

The only other way for the valves to retract is if they are pushed with
greater force than the hydraulic force, which would occur if hit by the
piston. So at least they won't catastrophically burst something, but we
don't know if the forces involved which would also involve some lateral
force on the valve guides would damage things or not. We assume damage
would occur and so must be avoided.

Thanks for the input.

--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Chris Carlen]

I have used just about exactly this sort of watchdog. I suggest you make
it so that the watchdog timer defaults to the disabling condition at power
on and require that the DSP write so some port or something before it gets
control.

Doing this somewhat protects you against the DSP waking up in the middle
of the code because the reset cirduit didn't work etc.

Interesting addition. I'll consider that.

If you have the room, you can put great huge capacitors on the supply and
fire the watchdog if the input drops out. If the capacitors are big
enough, you can get things safe just using the energy in them.

Yes, I haven't quite decided whether to rely on caps or redundant
supplies. The caps might be easier and tolerable space-wise. Some
testing will need to be done...

Thanks for the input.


--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Chris Carlen]

What about mechanical stops, and a mechanical design such that the valve
_cannot_ contact the piston. Even if that means an additional cam...

This is a research engine, so that sounds like very cheap insurance...

Unfortunately, such mechanical solutions are impossible. The engine is
a mid-size diesel, which must retain realistic compression ratios and
combustion chamber structure. The point is to research real engine
conditions with real engines. But the engines are modified with
extensive instrumentation and optical access.

Anything else is going to struggle with arbitary loss of power while
the engine is spining, or an arbirary loss of phase information due
to Software crashes.... ?

But it does seem like a software crash can be detected quite readily and
dealt with quickly enough. Also, power loss can be dealt with. Control
needn't be retained in these circumstances, only rapid valve retraction
is essential. Going open-loop to accomplish that is acceptable.

Thanks for the input.


--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Chris Carlen]

7. Loss of system hydraulic pressure (use pressure sensors)

Oh yeah, that's a big one! Thanks, I don't know if this has been
addressed by the folks on the mechanical side of things.




--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Nico Coesel]

Hi:

We have a 4 channel motion control servo system for electrohydraulic
actuation of four engine valves. The basic components in reverse from
the business end are as follows:

A bit far fetched: What if you could have an electrical simulation of
the fly-wheel (using a servo motor system). Doing this makes it
possible to stop the engine almost instantly. A system which keeps
track of valve and piston position can choose to stop the engine when
it gets critical. Besides, an electronic fly-wheel can be told to stop
pushing beyond a certain force preventing damage when things do go
wrong.

By the way: only 4 valves? I assume a 2-stroke turbo charged diesel
engine?

 

[Rich Grise]

Hi:

We have a 4 channel motion control servo system for electrohydraulic
actuation of four engine valves. The basic components in reverse from
the business end are as follows:

1. voice coil motor (to actuate hydraulic valves)
2. PWM H-bridge power amplifier (to drive voice coils, with fuses to
protect coils from pegged amplifiers)
3. TI 6711 DSP with 16 channels each of 100kHz 16-bit A/D and D/A to
digitally implement closed-loop control algorithms
4. LVRT position sensors (for precise control) and proximity (for
monitoring and for a backup check on control)
5. absolute encoder on engine camshaft to inform DSP where valves
should be (position reference data)
6. extra incremental encoder on crankshaft (with one index mark blanked
by a hall sensor on the cam) feeds to DSP to give a backup check on cam
encoder alignment.

Additionally:

1. low voltage power +5V and +/-15V for DSP board and it's analog IO
system.
2. two 48V 600W switchers to power PWM amps.
3. PC connected via USB to DSP to implement GUI. This link need not be
active for the DSP to do its job.

The main safety issue is that we must prevent the valves from
accidentally crashing into the piston. Due to the complexity of the
research engines (with optical access) involved, the cost in repair time
which would result from a failure of the valve control would be huge.
This must be avoided in any fault modes where the mitigation cost/repair
cost ratio is <= 1.

In analyzing possible failure modes of this system which could lead to
this undesirable occurance, I have enumerated the following
possibilities in decreasing order of likelyhood and indicate whether the
problem has been mitigated. If not, in the next paragraph I describe
what is being planned to mitigate an unsolved problem.

POSSIBLE PROBLEMS (feel free to comment on the prioritization order):

1. position sensor failure (mitigated by use of redundant sensors)
2. DSP software or hardware failure (see below)
3. encoder alignment slippage (mitigated by use of redendant encoders)
4. line power failure (mitigated by putting system on a UPS)
5. internal DC power supply failure (see below)
6. power amplifier failure (see below)

FIXES:

re: #2. To deal with the DSP hardware or software going bonkers, I plan
to utilize a watchdog timer (WDT). The DSP board has one built into its
FPGA, but it is of little use because it doesn't have an adjustable
timeout. Rebooting the DSP takes a long time, much too long to wait to
regain control. Thus, an external custom watchdog is being designed.

I plan to use the simplest possible discrete logic to build a WDT using
some one-shots and flip-flops plus a few glue gates. It will detect the
absence of a 20kHz pulse train from the DSP (from the control loop
iteration) and if the pulses stop, will first apply a withdraw pulse to
the valves, then disable the PWM amplifiers. Thus, the WDT must include
4 pairs of analog multiplexers to switch the inputs of the PWM amps
from the DSP to a constant voltage source of appropriate polarity and
magnitude to force the valves to close quickly.

re: #5. To deal with a power failure of one of the DC power supplies
(either high or low power supplies), I am considering using redundant
supplies with a diode network to allow them to be paralleled. This
should mitigate the problem to an extremely low likelyhood of causing a
disaster. Furthermore, the WDT circuit could include power monitoring
comparators to signal the DSP if a supply was malfunctioning.

re: #6. I had considered a means of dealing with power amplifier
failure. Solid state relays could be employed to build a multiplexer
for the voice coils that could switch the coils to a constant withdraw
voltage in the event of the detection of a serious control discrepancy
by the DSP. However, the differential output of the H-bridges combined
with the fact that the motor currents are bidirectional makes this
tricky. I have concluded that the cost of fixing vs. the probablility
of occurence makes this fault mode something we will just have to hope
doesn't happen.

The cost of fixing this might be less than the cost of a failure, but at
present we require that the system be put into service shortly in
prototype configuration, and there isn't enough time to deal with this.
It is still possible to include this capability later when the system
is being finalized.

Would you consider solving the faults in the methods described?

Would you agree with the decision to give up attempting to mitigate the
possibility of amplifier failure while the system is being used for a
few months before packaging and finalizing?

Thanks for input.

FWIW, on two separate occasions, with two different cars, I've lost the
timing chain/belt. In both cases, there was no valve damage because they
were "clearance engines", i.e., even open, the piston wouldn't hit the
valves.

That would probably lower the effeciency, because you couldn't use as
high a compression ratio, but you're virtually guaranteed not to
break any valves or pistons.

As an aside, it somehow pleases me to see someone actually working
on electric valve actuators - saves HP for the camshaft and all that
schtuff.

Good Luck!
Rich

 

[Paul Hovnanian P.E.]

When using a redundant system, put the hydraulic valves in _series_
when driving towards the 'active' position, thus both systems must
agree on driving to the 'active' state.

Put the hydraulic valves in _parallel_ when driving towards the 'safe'
state, thus either system alone would drive to the 'safe' state. This
would eliminate the tug of war situation if the failed systems drives
towards opposite direction.

I was thinking more along the lines of a hydraulic safety system that
would be inactive during normal operations, but override the operating
controls in the event of a fault. The philosophy is to keep as much of
the backup system separate from the control loop as possible.

But, it appears as though mods to the hydraulics cannot be made.

 

[Paul Hovnanian P.E.]

Not possible to alter the hydraulics.


It's not that simple. The voice coil position determines whether or not
the hydraulics can vent or not, so unless the voice coil is retracted,
the valve spring (which is present) can't help. There is a spring which
forces the voice coils into the "retract valve" position when unpowered,
but this won't close the valves fast enough when the engine is running.

I'd still pursue the goal of keeping as much of the safety system out of
the main control loop as possible. In this case, you're stuck with a
shared path (the voice coils). So I'd design the voice coil drives with
the capability of 'crowbaring' the voice coils into the 'close valve'
position when commanded by the safety. Then, I'd keep as much of the
crowbar circuitry separate from the control drive.

 

[Paul E. Bennett]

Hi:

We have a 4 channel motion control servo system for electrohydraulic
actuation of four engine valves. The basic components in reverse from
the business end are as follows:

This begins to sound like your organisation doesn't have anyone used to
doing full risk assessments of the equipment to be controlled. We have a
list of items that you intend to use in the control system at a stage much
earlier than I would consider appropriate. Has anyone in the team
understood the dynamics of the whole system yet?

1. voice coil motor (to actuate hydraulic valves)

So, these are not the electrically driven engine valves like Aura do. They
are hydraulically operated valves with pilot spool valves to control the
hydraulic side of things.

2. PWM H-bridge power amplifier (to drive voice coils, with fuses to
protect coils from pegged amplifiers)

Depending on the powers involved you may find other means of power removal
may work more dependably.

3. TI 6711 DSP with 16 channels each of 100kHz 16-bit A/D and D/A to
digitally implement closed-loop control algorithms

Is a centralised controller the most appropriate solution for this system?
You have to ask yourself such questions as by working through the
consideration of such questions you may see the best solution structure
emerge.

4. LVRT position sensors (for precise control) and proximity (for
monitoring and for a backup check on control)

Needs more explanation of where you are using these. Are they attached to
the voice coils.

5. absolute encoder on engine camshaft to inform DSP where valves
should be (position reference data)

6. extra incremental encoder on crankshaft (with one index mark blanked
by a hall sensor on the cam) feeds to DSP to give a backup check on cam
encoder alignment.

Additionally:

1. low voltage power +5V and +/-15V for DSP board and it's analog IO
system.
2. two 48V 600W switchers to power PWM amps.
3. PC connected via USB to DSP to implement GUI. This link need not be
active for the DSP to do its job.

The main safety issue is that we must prevent the valves from
accidentally crashing into the piston. Due to the complexity of the
research engines (with optical access) involved, the cost in repair time
which would result from a failure of the valve control would be huge.
This must be avoided in any fault modes where the mitigation cost/repair
cost ratio is <= 1.

Do you have enough information to describe the safe states of these valves
and how the valves achieve the safe state. Do they need to be driven to the
safe state or can they return to the safe state under their own power.

In analyzing possible failure modes of this system which could lead to
this undesirable occurance, I have enumerated the following
possibilities in decreasing order of likelyhood and indicate whether the
problem has been mitigated. If not, in the next paragraph I describe
what is being planned to mitigate an unsolved problem.

POSSIBLE PROBLEMS (feel free to comment on the prioritization order):

1. position sensor failure (mitigated by use of redundant sensors)
2. DSP software or hardware failure (see below)
3. encoder alignment slippage (mitigated by use of redendant encoders)
4. line power failure (mitigated by putting system on a UPS)
5. internal DC power supply failure (see below)
6. power amplifier failure (see below)

I know that someone else pointed out the hydraulic system failure that you
missed from the list. Some others that may impinge on the overall system,
brought on by increasing complexity of the whole system, would be potential
failure of the UPS. I know you added this to mitigate one of the failure
potentials but the mere fact of adding it is a complication of the system
and has to also be considered. It can have a bearing dependent on the way
the UPS is implemented.

FIXES:

re: #2. To deal with the DSP hardware or software going bonkers, I plan
to utilize a watchdog timer (WDT). The DSP board has one built into its
FPGA, but it is of little use because it doesn't have an adjustable
timeout. Rebooting the DSP takes a long time, much too long to wait to
regain control. Thus, an external custom watchdog is being designed.

Wise move.

I plan to use the simplest possible discrete logic to build a WDT using
some one-shots and flip-flops plus a few glue gates. It will detect the
absence of a 20kHz pulse train from the DSP (from the control loop
iteration) and if the pulses stop, will first apply a withdraw pulse to
the valves, then disable the PWM amplifiers. Thus, the WDT must include

Be careful with the complexity of the design of this WDT. You want something
ultra simple and dependable. You will also want to ensure that component
failures in the WDT circuitry lead to achieving safe states.

4 pairs of analog multiplexers to switch the inputs of the PWM amps
from the DSP to a constant voltage source of appropriate polarity and
magnitude to force the valves to close quickly.

So, the valves are powered to the closed position. By switching the input of
the PWM amplifiers you will not guarantee the valve closure if the PWM
amplifiers themselves have a fault.

re: #5. To deal with a power failure of one of the DC power supplies
(either high or low power supplies), I am considering using redundant
supplies with a diode network to allow them to be paralleled. This
should mitigate the problem to an extremely low likelyhood of causing a
disaster. Furthermore, the WDT circuit could include power monitoring
comparators to signal the DSP if a supply was malfunctioning.

There have been some incidence of such parallel power arrangements suffering
if the protective diode network goes short circuit in one of the supplies
which later fails, dragging the power rails down in the process. Attention
to detail here will be required, particularly in how you guard the circuits
that are meant to prevent such problems occurring.

re: #6. I had considered a means of dealing with power amplifier
failure. Solid state relays could be employed to build a multiplexer
for the voice coils that could switch the coils to a constant withdraw
voltage in the event of the detection of a serious control discrepancy
by the DSP. However, the differential output of the H-bridges combined
with the fact that the motor currents are bidirectional makes this
tricky. I have concluded that the cost of fixing vs. the probablility
of occurence makes this fault mode something we will just have to hope
doesn't happen.

What have you against real relays.There are techniques which will help to
speed up their operation so that they could quickly achieve a suitable
state to divert the valve supply voltage to a withdraw power rail. Real
relays also have the option of multiple contacts so one relay could divert
all the valves power simultaneously. Then, of course, you need to ensure
such a power rail was still active when needed.

The cost of fixing this might be less than the cost of a failure, but at
present we require that the system be put into service shortly in
prototype configuration, and there isn't enough time to deal with this.

Pressures on time often lead to poor analysis and decision making. The
decision on one real relay shouldn't hold you up that long anyway.

It is still possible to include this capability later when the system
is being finalized.

What is the time cost of wrecking an engine with the prototype control
system. How much is simulatable. Would the client prefer a simulated run of
the prototype controller before they let you loose on an engine.

Would you consider solving the faults in the methods described?

Whether or not your chosen methods (or those implied in my response) are
appropriate would require some more information about your system. Yes, you
are getting into the realms of spending money on consultancy.

Would you agree with the decision to give up attempting to mitigate the
possibility of amplifier failure while the system is being used for a
few months before packaging and finalizing?

No. I would spend more time understanding the failures and consequences of
failures, doing a proper job of designing the system to ensure that you
achieve the simplest approach commensurate with the risks posed. I would
prototype areas of the system that are ill-defined or not well enough
understood to gain the required knowledge to assist a proper design (not
the whole thing).

--
********************************************************************
Paul E. Bennett ....................<email://[email protected]>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

 

[Paul Keinanen]

Oh yeah, that's a big one! Thanks, I don't know if this has been
addressed by the folks on the mechanical side of things.

Even if you do not expect a loss of hydraulic pressure, you would
still need a pressure sensor for the startup phase, since it does not
make sense to try to control the system, until the hydraulic pressure
is within specified limits.

One practical note about any system containing multiple safeguard
mechanisms. At the user interface, create one display screen that
displays _all_ the signals at a single glance that may prevent the
system from operating normally.

While the state of all the disabling signals are available in separate
displays or commands, finding the last signal that prevents operation
may be quite time consuming, unless all disabling signals are readily
visible at once.

Paul

 

[Chris Carlen]

A bit far fetched: What if you could have an electrical simulation of
the fly-wheel (using a servo motor system). Doing this makes it
possible to stop the engine almost instantly. A system which keeps
track of valve and piston position can choose to stop the engine when
it gets critical. Besides, an electronic fly-wheel can be told to stop
pushing beyond a certain force preventing damage when things do go
wrong.

Wow, that's a different approach. But it really is much easier to
withdraw the valves than do this. The engine actually is turned by a
dynamometer, but from experiences with other labs it takes quite a few
revs to stop the engine even with the dyno at 150% current.

By the way: only 4 valves? I assume a 2-stroke turbo charged diesel
engine?

No, a single 4-valve cylinder of a 4-stroke diesel, running in HCCI
combustion mode.

Thanks for the input.


--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Jim Granville]

Paul Hovnanian P.E. wrote:

I'd still pursue the goal of keeping as much of the safety system out of
the main control loop as possible. In this case, you're stuck with a
shared path (the voice coils). So I'd design the voice coil drives with
the capability of 'crowbaring' the voice coils into the 'close valve'
position when commanded by the safety. Then, I'd keep as much of the
crowbar circuitry separate from the control drive.

Good idea, maybe even to the point of small batteries at the voice
coils ? then the system has to frequently ask for position,
and no-ask => rapid retraction ?

Still leave the issue of loosing phase sync (engine angle), and not
knowing it...

-jg

 

[Chris Carlen]

Still leave the issue of loosing phase sync (engine angle), and not
knowing it...

There are redundant encoders, so I think this has been addressed, no?



--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
[email protected]
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

 

[Jim Granville]

There are redundant encoders, so I think this has been addressed, no?

I was thinking not so much of a hardware failure, but something along
the lines of the Ariane Rocket.... - the SW _thinks_ it knows where the
engine is - is this software part of the research ?

if you have an absolute encoder, I'd be tempted to put a small CPLD in
the VoiceCoil Driver(s), which can contain a simple drive over-ride and
ROMs for 'not legal' areas. A digital index signal on the valve would
complete this very simple 'sanity checker'.

-jg