Where would you protect this control system?

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.

In article , Chris Carlen wrote: [...]

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.

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.

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

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

Paul

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

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.

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.

Interesting addition. I'll consider that.

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.

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.

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.

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.

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?

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

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.

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.

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?

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.

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

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.

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

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.

Wise move.

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.

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.

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.

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.

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.

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.

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.

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).

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

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.

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

Thanks for the input.

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

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 snipped-for-privacy@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

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