Ease of Use in Engineering
In the last installment, (September issue, Inside Process) we discussed how engineering management software helps keep control system development on course and examined how it applies to continuous manufacturing processes. To review briefly, an engineering management system has to have basic core functions: The first three points were discussed in September.
In the last installment, (September issue, Inside Process, Ease of Use in Engineering ) we discussed how engineering management software helps keep control system development on course and examined how it applies to continuous manufacturing processes.
To review briefly, an engineering management system has to have basic core functions:
Ability for multiple engineers to work concurrently on the same project;
Direct mapping of the plant structure into the application software;
Efficient and intuitive configuration of continuous processes;
Efficient and intuitive configuration of sequential processes;
Transparency between engineering the control strategy and the human machine interface (HMI) software;
Overview of all engineering aspects; and,
Integration of safety functions.
The first three points were discussed in September. Here, we will consider the remainder.
Every manufacturing process has steps that have to take place in a specific sequence. For example, a valve has to open before a pump starts, or a PID loop has to engage as a process begins. A given step has to wait for a signal that the earlier step has taken place before it can begin. Depending on specific conditions or products being manufactured, the sequence may not always follow the same order, and a control system has to be adaptable to alternate branches or loops. A given chart must have capacity to hold more than one process strategy and show statuses for each. The control system should support alternate statuses and transitions between statuses.
Since individual components will likely be involved in more than one sequence, the system should allow a given component software block to be used repeatedly. Moreover, central modification capability is critical to minimize overhead when process changes and adjustments are necessary. An operator should be able to see the sequence of steps, the current step, and transition conditions at any time, and be able to change the sequence or status of any step. This information should appear in a process window without any additional effort in the engineering phase, and without any need for an operator to modify any programming. From this point, the operator can manually start, stop, or abort sequences of steps and adjust control strategies.
To facilitate easy navigation, the actual plant structure must be mapped in the software using a heirarchy of continuous and sequential function charts. To assist navigation for operators, pictures of equipment should follow the same heirarchy using static objects for pipes, reactors, etc. Dynamic objects, block icons, or faceplates should represent motors, valves, etc., showing their status in run-time. Dynamic objects should offer click-through functions to display face plates generated automatically by the system using engineering data from the control strategy. Any control strategy modifications should migrate automatically to the HMI.
Additionally, the HMI should have the following control strategy data available:
Address and structure information of all variables in all controllers;
Message texts (e.g., alarm and warning messages) defined in function blocks; and,
Pre-selection for archived variables.
Keeping the big picture
Engineers responsible for overseeing a design project must have a mechanism to create an overview of all charts, blocks, pictures, messages, archives, etc. When these data are arranged effectively, it only takes a few mouse clicks to move down a tree to any desired bit of information. This process should generally follow the same hierarchy as actual plant processes. From there, it should be simple to review or modify any aspect of process objects without having to launch a multitude of editing functions. Ideally, this function will be very intuitive and not require an extensive number of memorized steps.
Typically, dividing process objects into six registers keeps adequate separation without excessive overhead:
General—All subordinate objects (continuous function charts, sequential function charts, pictures, reports, etc.);
Parameters—Connection points for all process tags and continuous function charts;
Signals—Connection points to I/O for peripheral devices;
Messages—Display and processing for all messages associated with process tags and continuous function charts;
Picture objects—Associated objects displayed in pictures for all process tags and continuous function charts; and,
Measured-value archive—The archive connections in the operator station displayed for all process tags and blocks.
Using this approach, data can be selected or filtered in several ways to simplify searches and increase useful hits. Putting in a search parameter like “Display all range limits of measurements in plant sector V100” should retrieve all useful possibilities without large numbers of irrelevant choices.
Often it is necessary to modify the same step in a group of sequences or a series of steps. The system should do that without having to open each individually and repeat the process again and again. This saves time and eliminates possibilities that a modification to one sequence will not match another.
Integrated safety functions
Until recently, automating safety functions involved special hardware, software, and even wiring, separate from standard control mechanisms and devices. In addition to costs for additional devices and cabling, overhead increased due to engineering and maintenance required. Now, technology developments have provided ways to integrate safety functions into larger plant control systems along the following lines:
One common platform for control and fail-safe technology;
One standardized fieldbus where standard and safety-related devices operate in parallel; and,
One engineering system for standard and safety-related automation technology to minimize investment in equipment, engineering, maintenance, and training costs.
Once the systems are integrated, when there is a fault or accident in a plant, a control system can take steps to avoid injuries to workers, the surrounding community, and equipment. If a fault is severe enough, the plant should automatically enter a safe state. For such functions to work properly, the system must recognize faults and correctly ascertain their cause. These functions are usually subject to specific safety standards and may also need independent certification.
Designing safety functions begins by classifying individual plant areas so that a given safety circuit includes all relevant elements, including control devices, communication paths, actuators, and sensors, etc. Corresponding software blocks are then designed according to relevant safety requirements.
Although there are many fieldbus platforms, the requirement to support both plant control and safety functions on one system narrows the choice. While suggesting specific choices is beyond the scope of this discussion, it is important to ensure that both control and safety modules can communicate via the same fieldbus to gain the real savings available. It also facilitates designing system supported visualization of the dynamic status of a cause/effect matrix so the system and operator