-1

I've got an idea, but I wonder whether somebody else already has named it.

I'm writing code to control a machine with actuators, motors, etc., and software will be responsible for preventing collisions between some of its moving parts.

It's mostly useful to organize everything as a hierarchy, but collisions are possible between different sub-systems. The need for collision avoidance cuts across the hierarchy.

My idea is to create objects that I will call "hazard recognizers" for the present. Each hazard recognizer watches for one specific hazard by monitoring the machine's sensors and, is injected into the places were each motor and actuator that contributes to the hazard is controlled. The software that controls actuator X will consult a list of recognizers before each time it changes the state of the actuator.

Never mind how I will define the list of recognizers or, how I will ensure that each one is injected into every place where it is needed. My question is, has somebody already given this pattern a name?

Or, Has somebody already given this problem a name? I'd like to learn more about how other people have solved it, but I'm not sure what to search for.

2
  • Re, the close vote: I'm not asking for an opinion. I'm asking, "does this pattern have a name? and if so, what is the name?" May 23 '17 at 17:53
  • I've heard the term canary used in the context of stack integrity protection.
    – gardenhead
    May 24 '17 at 3:23
2

The closest thing that comes to mind (from industrial automation software) is a watchdog. But watchdogs typically monitor whether the primary control task is still active or not. And if not, the watchdog just shuts down the hardware to prevent accidents. This is particularly meaningful in robotics. If the primary control task is lagging, the arm's position may be drifting too far from the desired position and the brakes should be put on to prevent damage.

But your idea is weird. First, those sensors are not going anywhere so there is nothing to follow for these hazard recognizers, making injection pointless. They should just have access to the sensors driver. Did you perhaps pick up some talk about dependency injection with the notion that it is a good thing?

What do you picture when you say "inject each into every place where it is needed"? If you inject something, you suggest that the receiver would have to actively call methods on the injected object as needed. This would defeat the purpose of any safety function. It is like having an airbag in your car with a button next to it that reads "press in case of crash".

5
  • It's more of an assertion mechanism than an active hazard control. Higher-level algorithms are supposed to ensure that lever A does not crash into slider B. But higher level algorithms may have reasons to change in the future. I want something that operates at the lowest possible level--something that will never have any reason to change as long as lever A and slider B still exist--that will stop the machine if a bug has been introduced by an "improvement" in the higher level code. May 23 '17 at 19:35
  • I over simplified the "injection" part. The higher level algorithms would operate on injected "DigitalInput" and "DigitalOutput" objects, but instead of operating directly on the hardware, those objects would be owned by a "hazard recognizer." If the high level called digitalOutputA.setState(ACTIVE), then the hazard recognizer that owned that DigitalOutput object would either throw an exception, or it would foward the request to another DigitalOutput, possibly owned by another hazard recognizer, ... until the request finally reached the actual hardware. May 23 '17 at 19:41
  • I do not fully understand your intend. But if I understand your need you may be better off with a thread in your application that monitors the positions of lever A and slider B (say, every 0,01 s) and apply the brakes on a worrying combination of co-ordinates. This way your main logic will not be polluted with safety measures and the safety measure will be truly independent of your logic. To make it really safe, the thread may also toggle a digital output at a say, one kHz. You could have an analog filter detect if that signal drops (meaning the watchdog has stopped), and apply emergency stop. May 23 '17 at 19:58
  • ...or, you've got me thinking,... by monitoring the system log: Every sensor change and every actuator command is logged... Anyway, thanks for your input. May 23 '17 at 20:05
  • Monitoring the log seems dangerous. You would go through the file system's API and may encounter locking issues that have nothing to do with your problem but may stall you for an unknown period. May 23 '17 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.