Creating a Shadow Model to Control Hardware That Cannot Respond back to the Software

[rgsparber]

Reliable hardware/software systems depend on the free flow of information. Recently I had to control a piece of hardware that did not return any status information. It then became a guessing game as to what state it was in. Although I could not completely solve this problem, I was able to improve on it.

If you are interested, please see

https://rick.sparber.org/ShadowModel.pdf



Your comments are welcome. All of us are smarter than any one of us.


Thanks,

Rick

[jdurand]

Toggle systems with no feedback demand a lot of faith. Normally you would just keep a state machine in software.

Most stepping motor systems work without feedback, it's simply assumed they are following orders.

On an "intelligent" theatrical light I designed I had two stepping motors, one for an progressive neutral density filter for lamp brightness (arc lams don't dim) and a second for a color wheel.

On that one I put a sensor that would send back a pulse when it passed a "home" position.

On power up both wheels spun to find the pulse, then backed over it to find it in the other direction.

After that, in use the wheel would turn in the shortest direction to get to the newly commanded setting and I would update where I thought it was whenever the home position was passed. If the lighting guy had a lot of moves that never passed home there was the possibility of never passing home so I had to put in a timeout, eventually it WOULD pass home.

Mentioning lighting, the DMX-512a standard (ANSI E11.1) gets past no feedback by simply resending all commands at a rapid rate so if/when a light looses sync it's brought back after only a fast blip. There's also the possibility of feedback but it's mainly used for errors, status ("getting hot here, might want to change my air filter).

[rgsparber]

jdurand,

Thanks for confirming the technique. I was hoping to hear that there was a better way.

I had not thought about the similarity to steppers but, sure, they run open loop too. I've been the victim of steppers that are run too fast and get out of sync. Not good.

Rick

[mklotz]

Unless the shadow model can COMPLETELY model all failure mechanisms in the hardware, which is probably impossible, your time is probably better spent instrumenting the hardware to return a state response.

It all depends on the danger level of a hardware failure. If a failure is simply annoying the shadow approach is fine; if it's life-threatening then instrumenting the hardware is in order.

[rgsparber]

Marv,

The hardware is a camera so rather harmless. If the hardware could hurt someone, I would flat out not use it.

Rick

[mklotz]

Marv,

The hardware is a camera so rather harmless. If the hardware could hurt someone, I would flat out not use it.

Rick

Thanks for confirming my trust in you. I assumed you understood that this approach had limited application.

[tonyfoale]

Toggle systems with no feedback demand a lot of faith. Normally you would just keep a state machine in software.

Most stepping motor systems work without feedback, it's simply assumed they are following orders..

I was about to reply almost the same, even with the stepper motor analogy.
I cannot see that the state simulator does anything that you cannot do in the base software. It can only be reflecting the commands that you send out.
You cannot replace a missing real world feedback loop with a virtual perfect feedback loop. Going with the stepper analogy, you command it to move 3 steps, the state simulator can only return that it moved 3 steps, but how many did the motor move. You gain no value by being told that it was 3.

[rgsparber]

Unless the shadow model can COMPLETELY model all failure mechanisms in the hardware, which is probably impossible, your time is probably better spent instrumenting the hardware to return a state response.

It all depends on the danger level of a hardware failure. If a failure is simply annoying the shadow approach is fine; if it's life-threatening then instrumenting the hardware is in order.

Marv,

The intent is to just follow along on the hidden state changes. The only failure mode I can detect is when the hardware has no power. If there was a failure within the hardware, there would be no way for the software to detect it.

I do avoid failures in the hardware due to illegal state change requests by doing a translation in the driver. The user can request a move to any state and the driver will figure out how to legally get there.

I have updated the article with a big red warning about safety. Thanks for the reminder.

Rick

[rgsparber]

I was about to reply almost the same, even with the stepper motor analogy.
I cannot see that the state simulator does anything that you cannot do in the base software. It can only be reflecting the commands that you send out.
You cannot replace a missing real-world feedback loop with a virtual perfect feedback loop. Going with the stepper analogy, you command it to move 3 steps, the state simulator can only return that it moved 3 steps, but how many did the motor move. You gain no value by being told that it was 3.

Tony,

The strategy is that the user simply says what state they want to get to and the driver with its state machine figures out how to get there. By having all users pass their requests through the same high-level driver, I am able to prevent a user from changing the hardware and not updating the state machine.

The intent was never to simulate the position on an output shaft. It is to control a RunCam2 camera. The low-level driver accepts a shutter-button push command or a mode-button push command and sends 80 ms pulses to the camera. These commands are meaningless without knowing the current state of the camera. I get that from the high-level driver which contains the state machine including the current (assumed) state of the camera. The user then just tells the high-level driver what they want to do and the high-level driver sends a series of low-level commands to the low-level driver to get there. All the while, it is updating its state machine to reflect what should be the current state of the camera.

I'm not sure this is any clearer. I can say that this is not theory, I have fully tested these drivers and it works as expected.

Rick

[Saltfever]

Many years ago I designed a toxic gas system with on/off valves. When I commanded an action I could see a delayed response by sensing other parameters like pressure changes, temp rise, etc. However, I wanted an instantaneous visual of the valve state. I marked up the company's illustrated parts breakdown of the valve with a drawing of the modification I wanted, and sent out an RFQ. Their answer was no-quote. The following year I received their new catalog showing a new valve incorporating my idea with their patent pending on it!

Such is life . . . some things are not worth pursuing.