|
Upon investigation, it turned out that there was a safety interlock that had been tripped in order to prevent chemicals from flowing. Actually, it prevented the valves from
being “enabled” so that the signals from the software could open them. The technician had caused the software to send signals to the valves properly, but since the valves were
not enabled, their state did not change. This turn of events generated several discussions and meetings with the software engineering group to find out whether this was really
the way the system worked. It was the correct action according to the software design. From the software engineer’s point of view, the operator had requested that a control
signal be sent to the valve. This was done, but the valve icon on the screen didn’t really represent the state of the valve — it represented the state of the software. Thus,
when the signal was sent, the icon changed to indicate that this action had occurred. Of course, to the operator, the icon’s change in appearance seemed to indicate that the
valve had opened. We have since made a few changes to the system to give the operator a more accurate view into what’s actually happening.
The most interesting aspect of this situation is that it was created by the different viewpoints of the various players. From the software engineer’s point of view, the control
screens need to reflect as accurately as possible the state of the software and control system. The software engineer is thinking about the system in terms of how it “looks”
from the software. However, the operator doesn’t care about the software; in fact, he doesn’t even consider it. The operator views the controls as a reflection of the state of
the system being controlled. Thus, if the icon of a valve changes from “closed” to “open,” then the operator assumes that the valve has actually changed position.
|
|
I’ve run into similar problems when dealing with software designers in the past. One of these was in a drive-by-wire vehicle. The driver controls didn’t really connect to
any of the controlling devices; they were all connected to electrical position and rate sensors that were read by the computer. The computer then used various algorithms to
control the vehicle. As the safety engineer on the project, I got into a rather in-depth discussion with the software engineer concerning what happened if the computer
detected a power glitch or an internal error. The answer was very simple, and a little shocking to me. The software had built-in safety algorithms to protect the computer if
either of these conditions were to happen. The “fail-safe” approach being used was to turn off the computer, saving it from damage by electrical problems and potential
computer errors. This was all good until I pointed out that the computer was likely to get crushed and broken when the vehicle crashed at seventy or eighty miles per hour.
That realization seemed to wake up the software designer. He really didn’t want the computer to be ruined in a vehicle crash, so he started looking into degradation modes that
didn’t just take all control away from the operator of the vehicle.
I continually find it amazing how deeply into their own point of view designers and engineers can become. It isn’t just software engineers who do this — it’s all engineers. I
used a couple of examples from the software community because they’re easy to understand. However, software developers are by no means the only ones with this habit of wearing
blinders.
I bring this up because we need to remember that part of our job is to maintain the system point of view — i.e., that overall viewpoint encompassing the equipment, operators,
operations and environment. It’s not unusual for us to be the only ones on a project stepping back to see the “big picture.” This larger view is one of the more valuable
attributes that we can bring to a project — one that might have even more value than the safety tasks we perform.
|
