Alarm Management versus Procedure Enforcement
Procedure enforcement is the holy grail of operations of the future. In today's market we are seeing expertise disappear on a daily basis. Fewer college grads choose the automation market. Regulations and competition push us to have less people in the plant. The EPA discourages us from making products that require carbon-based fossil energy consumption. The government makes onerous requirements for any employer silly enough to actually employ people. Training of personnel is an afterthought. Personal legal responsibility is being assigned to people who are only doing their jobs. And systems continue to become more complex.
Frankly, I'd be scared half to death to be an operator in a plant today. And management knows this. So, how do we continue to run ever more complex manufacturing systems given such a dilema? The real answer lies in procedure enforcement, and today's Process Automation vendors are in a postion where we need them to arise to meet this requirement. The unfortunate part of that statement is that few automation vendors would have the expertise to understand ALL of the processes that need to be procedurally enforced, and I'm not sure they are the proper source for that anyway. But just as they provided control engineers with the platform that we needed to institute process control, and then advanced process control, they now need to meet this need.
What it will mean is that they need to make a systems that STOP alarming operators unless they can also give information on the next step that needs to be taken. It is a major shortcoming that there is no control over the steps an operator can take after receiving an alarm. The same operator can handle the same alarm a different way each time. The problem is that the next step is not always something that can be written by prescription. Sometimes, it requires investigation, and further input from the operator. In this way, the DCS becomes a true guidance system for the operator. It must be accessible by a number of vendors who understand their equipment, systems, and procedures to insert the proper logic necessary to make a system work.
We know this can be done. We have seen it done. It was a promise made to us by Expert Systems, Neural Networks, and Fuzzy Logic systems in the 90's. The promise was not followed up on, mainly due to the high maintenance component of such systems. But that maintenance component was there simply because the DCS systems of the day did not lend themsleves readily to logic-based guidance systems. Thus each of these types of technologies was subject to Human-Machine interactions designed by people who had very little experience in the systems on which it would need to be deployed. It created a mis-match, and training requirement that was hard to undertake.
In my past I have seen sever such systems successfully deployed. The unfortunate part of their deployment was that since they were not done on mainstream software, for which there was a ready supply of trained individuals, there was little chance ithey would continue operating correctly once the original designers left the building. This can be remedied by incorporating some of the inventions of those systems into the basic control technology employed in the plant. Just like modern automobiles that employ systems that you could once only buy at an add-on shop. I believe we are seeing some of that today. Yesterday's third-party option is slowly becoming todays off-the-shelf offering.
This is where automation vendors need to be focusing their attention. Give us systems that allows us to put our process knowledge into the guidance the operator will receive. Let us automate when necessary, calculate when necessary, ask for input when necessary, and call on the human when all else fails. And lastly, let us tell that human how to go about remedying the situation when he is called on to do so. We'd like to reserve alarms for situations where's there's been a breach in the outer hull. Alarm management will still have its place- it will be the external monitor that audits with checks and balances on the alarm system to be certain it does not invoke human action unnecessarily.
Frankly, I'd be scared half to death to be an operator in a plant today. And management knows this. So, how do we continue to run ever more complex manufacturing systems given such a dilema? The real answer lies in procedure enforcement, and today's Process Automation vendors are in a postion where we need them to arise to meet this requirement. The unfortunate part of that statement is that few automation vendors would have the expertise to understand ALL of the processes that need to be procedurally enforced, and I'm not sure they are the proper source for that anyway. But just as they provided control engineers with the platform that we needed to institute process control, and then advanced process control, they now need to meet this need.
What it will mean is that they need to make a systems that STOP alarming operators unless they can also give information on the next step that needs to be taken. It is a major shortcoming that there is no control over the steps an operator can take after receiving an alarm. The same operator can handle the same alarm a different way each time. The problem is that the next step is not always something that can be written by prescription. Sometimes, it requires investigation, and further input from the operator. In this way, the DCS becomes a true guidance system for the operator. It must be accessible by a number of vendors who understand their equipment, systems, and procedures to insert the proper logic necessary to make a system work.
We know this can be done. We have seen it done. It was a promise made to us by Expert Systems, Neural Networks, and Fuzzy Logic systems in the 90's. The promise was not followed up on, mainly due to the high maintenance component of such systems. But that maintenance component was there simply because the DCS systems of the day did not lend themsleves readily to logic-based guidance systems. Thus each of these types of technologies was subject to Human-Machine interactions designed by people who had very little experience in the systems on which it would need to be deployed. It created a mis-match, and training requirement that was hard to undertake.
In my past I have seen sever such systems successfully deployed. The unfortunate part of their deployment was that since they were not done on mainstream software, for which there was a ready supply of trained individuals, there was little chance ithey would continue operating correctly once the original designers left the building. This can be remedied by incorporating some of the inventions of those systems into the basic control technology employed in the plant. Just like modern automobiles that employ systems that you could once only buy at an add-on shop. I believe we are seeing some of that today. Yesterday's third-party option is slowly becoming todays off-the-shelf offering.
This is where automation vendors need to be focusing their attention. Give us systems that allows us to put our process knowledge into the guidance the operator will receive. Let us automate when necessary, calculate when necessary, ask for input when necessary, and call on the human when all else fails. And lastly, let us tell that human how to go about remedying the situation when he is called on to do so. We'd like to reserve alarms for situations where's there's been a breach in the outer hull. Alarm management will still have its place- it will be the external monitor that audits with checks and balances on the alarm system to be certain it does not invoke human action unnecessarily.
Comments