September 19, 2005
This week our work revolves around the plant’s operational philosophy and operator access to modules from the HMI. Should an operator be allowed to run an equipment module from the HMI? If the equipment module is in auto mode, can an operator change operational parameters? Should modules be locked into auto mode by recipes or should operators be allowed to put modules in manual mode while a recipe is operating? If an operator changes an equipment module to manual mode, should the recipe automatically transition to a hold state?
These operational questions arise with every project and get different answers from nearly every customer. In fact, we even get different answers for one customer at different facilities. To address the variety of operational philosophies previously encountered, we have tried to design our modules with the flexibility to meet any reasonable operational requirement. These features include:
Module parameters can only be changed at the HMI from module faceplates. The faceplates include functions to secure parameter access and to log changes. Limiting parameter changes to a single user interface component ensures consistent security control and data historization
Faceplate parameter changes are logged with the module tag, parameter name, module description, module type, change message, timestamp in local time and UTC, workstation name, user name, user’s security group, old value, and new value. Logged actions are written to a local text file or to a SQL database via Microsoft Message Queue
All modules have a ModeLock parameter. When a module is mode locked, a user is not allowed to change a module’s mode. Modules may be mode locked by a recipe to prevent operator interaction with many functions. Recipes that set the mode lock parameter should reset the parameter when finished
All parameters are individually secured. Each parameter is assigned a security level. A user must have an access level that is greater than or equal to the security level of the parameter. Parameter security levels are maintained in an XML configuration file
On this project we have encountered a new twist that is not easily covered by the features described above. The customer has asked that recipes auto lock all equipment modules and when in auto mode, operator parameters should not be changeable by operators. Each equipment module is designed with a set of parameters designed to be used by operators and, therefore, called “Operator Parameters”. Since operators at the HMI may operate an equipment module for non-recipe use, these parameters provide the flexibility to take advantage of well-tested sequences to meet abnormal plant operational needs. These parameters are always available from an equipment module faceplate. This approach will significantly limit the capability of an operator to intervene during recipe execution short of aborting the entire recipe—something all other customers have found too constraining.
These issues of operator access have long lasting and wide reaching impact on the daily operation of the plant, plant efficiency, and the frequency and magnitude of operator errors. Despite the ardent supporters of one philosophy or another, the best approach is one that is considered carefully by personnel from operations, process engineering, maintenance, automation and any other discipline involved with daily plant operation.
Details of the UF design will be discussed next week.
