Sometimes you want to allow safety-sensitive equipment to be controlled by an outside entity. Let’s first consider control of safety-sensitive equipment by an operator.
When an operator is controlling safety-sensitive equipment, you will need to check conditions to make sure that the operator doesn’t harm people or cause damage to the equipment. For mechanical equipment, this is often achieved through interlocks and limits. Interlocks often prevent two parts of a piece of equipment from hitting each other. For example, you must have the brake on to shift out of park in a car. This interlock prevents you from taking off immediately or accidentally shifting into reverse. Limits refer to how much control an operator has over a piece of equipment. Some vehicles have governors that prevent the speed to go over a certain limit. There may be other check conditions, but these are the primary ones.
When you want some external control to come from another system, it is practical to do so via an API. But, if this is safety-sensitive equipment, you need to make sure that the API acts like the operator of the equipment and can’t directly take control over the equipment. For example, if a self-driving car has an interface for setting the destination, it should only do so as a set point. It is up to the self-driving car to determine how to get to its destination.
This can be applied to other heavy equipment in an industrial setting. For example, in factory automation a customer may want you to allow them to control some part of the process. For example, in an automated baking factory they may want to vary the oven temperature based on the humidity as a proprietary process. You may allow the oven to have an interface to vary the oven temperature, but you may only allow the temperature within a certain range. You may put in minimum and maximum temperature set-points based on food safety standards and equipment limits. The caller may request a lower temperature, but you will simply go to the minimum safe temperature.
Let’s take a more extreme example of a pacemaker. Let’s say that one company has custom logic to apply to the function of the pacemaker and wants to control the pacemaker, but does not manufacture the pacemaker. Or say this is for a medical study where you want to try different things with the pacemaker: voltage, heart-rate triggers, shock pattern, etc. There could be an interface to do this, or there could be a sub-processor such as a Java Card or other embedded system, that could run custom logic that had a loosely coupled interface to the pacemaker. The Pacemaker would have specific limits: voltage range (min and max), heart-rate range for triggers, min or max number of shocks in a time period, etc. These would need to be applied to that loosely coupled interface to make sure that the patient is not injured. This would have to be examined in a great deal of detail, but these are some of the things that would need to be considered.
With that said, I would say that external control of safety sensitive equipment is very risky and requires a great deal of testing to prevent nefarious activity or bugs that cause death, injury, or equipment damage. But this pattern is something that can be considered in product architectures where it makes business sense. The benefits of this complex and advanced functionality need to be weighed against the high cost and extreme risk of allowing such control. The important thing to remember is to limit the scope of the control significantly to make risk control possible, but do so in such a way that allows the functionality to be enhanced by the addition of external control.