JASUBHAI GROUP      ABOUT CHEMTECH     ADVISORY BOARD       EVENTS     PUBLICATIONS     CONTACTUS    
Chemical & Processing
EPC
Oil & Gas
Refining
Automation
Pharma Biotech
Shipping
Power
Water
Infrastructure & Design

Process Automation by Way of Good Control System Development
Process Automation or Control System play a crucial role in all the process executed in refi neries and chemical and petrochemical companies as these avert the need to monitor the process performance and quality output physically. Process Automation System (PAS) is combination of computer technology and software engineering that enable industries to operate with effi cacy. The article highlights the need of PAS, which in recent times, has been replaced with DCS (Distributed Control System). Jasbir Singh, Vice President (Inst.), Essar Oil Limited highlights the role of automation in plant performance.

Technological advancements in sensors, measurement technique, transmission of signals, for monitoring and controls has improved in every process application. This has greatly increased the confidence of the process control system performance in all manufacturing industries.

Excellent plant performance (high OPE index) is of paramount importance to improve the business goals and organisation regularly review its internal processes in order to continually improve the control system requirement with the experience earned by operators. While each process getting automated, the ROI improves rapidly - operators are relieved immediately from their manual adjustment and making expensive mistakes. Each automated process finally results into its own unique benefits. The major need for automation lies in the system software development to make the system intelligent. Its contribution to make the plant stable is always visible by financial gain in annual report card. We have a say in automation field that any process, if it can run on manual the switchover to auto, is always possible. No automation finds its useful return without the involvement of process expert, line operation and engineer. The active involvement of process, operation and instrument engineers is necessary during the full cycle of control system and application software development.

A DCS (Distributed Control System) vendor provides a custom-designed processor / controllers with its own developed ?? proprietary system software and mostly use proprietary hardware interconnections and digital data communications protocols. These Controllers are designed to have extensive computational capabilities. It has scaling function blocks, PID with proportional, integral and derivative control, logic and sequential control as part of data processing. Variety of Input and output (I/O) modules having input / output isolation and multiple signal connections are interface to the DCS with field devices, where field signals are termination. The processor digitally receives information from input modules and sends processed data to output modules after pre programmed computation called Application software.

1. Execution Frequency/Scan Time:
Unless otherwise stated due to special circumstances, the recommended execution frequencies (also called scan time in some systems) are defined according to the table (overleaf) depending upon the type of processing function or loop being configured. These recommended execution frequencies are the minimum frequencies required for good control. Faster execution frequencies will not improve control performance and should be avoided to prevent overloading of the DCS. Slower execution frequencies should only be used if necessary to avoid overloading the DCS.

Controller Execution: The system where multiple processing function blocks are used to form a control loop, all of the processing function blocks associated with the execution of the controller must execute at the same frequency. The phasing of the processing function execution in the DCS processor should be structured so that the CPU loading is as even as possible over time. Large periodic peaks in CPU load should be avoided. The system loop execution configuration should be implemented to ensure the relative order of the DCS processing functions so that they must occur in the proper sequence. The order of execution of input, calculation, control, and output functions should be configured so that the logical order of mathematical processing occurs in one execution cycle.

2. Allocation of Processing Functions Across Multiple Processors: If the processing functions for the plant are divided among multiple processors or modules, then the following care should taken while the allocation of processing: • The proces s ing load between the modules should be nearly balanced
• All controller functions related to a particular process unit of plant should be assigned in the same controller as far as possible.
• All processing functions related to a particular control loop should be located in the same controller, marshalling and other modules.
• Communication between modules required for the execution of processing functions should be minimised.
• Allocation of processing functions across multiple processors must be avoided if it interferes with the required processing rate or sequence.

3. PID Controllers: All PID controllers should have all 3 tuning functions P, I, and D available for loop tuning.

Depending upon the system, the P gain or proportional band, I integral time or reset, and the D derivative is applied. Other names may be used as well, but the functionality should be consistent with standard PID controller. If any one factor is not needed, then it is possible to „zero out‰ that factor effect by entering a „0‰ or equivalent value (i.e. integral time may require a value of 9999 to minimise its effect on the calculation) online or 1 for P gain. Where individually specified, some PID controllers will require the capability of adaptive tuning constants based upon specific logic. In some systems this is called gain scheduling.

The standard specifications for some of the key parameters for a PID controller includes Proportional action - Unless otherwise specifically stated in a project specific document, the proportional action of all PID controllers should be decided based upon the controller error (i.e. either Set Point - Process Variable, or Process Variable - Set Point, depending upon the system.); Integral action - It is also called as reset action. This should be based upon the controller error. Reset is the time it takes for the integral action to produce the same change in mv as the P modes in initial change. It adjusts the proportional bandwidth with respect to the set point to compensate for offset (droop) from set point; and Derivative action - Unless otherwise specifically stated in a project specific document, the derivative action should be based upon the Process Variable of the controller, not the Error, to prevent bumping the output on set point changes. The controller action (i.e. direct or reverse) should be defined in the Master Controller Summary data sheets of project. Special features may be required on individually specified loops. As a default, these features should not be enabled unless it has been specified for a particular loop in the control strategy description. However, it should be possible to enable the required feature online without having to reconfigure the system offline. In most of the systems this may require enabling the feature as a default, but leaving a related tuning constant set to zero. These features include:

• Non-linear control
• Gap-action control

All PID controllers in a cascade control must be configured with anti-reset windup protection. This prevents the primary controller from continuing to calculate and send an output if the secondary controller is unable to process it. Otherwise, this could happen under the following circumstances:

• The secondar y controller is not in CASCADE or AUTOMATIC/REMOTE mode
• The secondary controller output has saturated (i.e. its valve is fully open or fully closed)
• The secondary controller has reached its high or low set point limit
• The secondary controller has reached its high or low output limit
• The secondar y controller has been overridden by another controller

This windup protection must propagate up through the entire cascade structure of a control loop, regardless of how many controllers exist in the complex cascade loop.

4. Anti-Reset Windup: Control loops shall be configured to avoid reset windup during any conditions. This includes the following conditions: • A controller that has reached its high or low output limit
• A controller that has been overridden by another controller
• A primary controller with a secondary controller that is not in CASCADE or AUTOMATIC/REMOTE mode
• A primary controller with a secondary controller that has a saturated output (i.e. its valve is fully open or fully closed)
• A primary controller with a secondary controller that has reached its high or low set point limit
• A primary controller with a secondary controller that has reached its high or low output limit
• A primary controller with a secondary controller that has been overridden by another controller

5. Logic: The configuration requirements for logic functions (i.e. AND, OR, exclusive OR, inversion, latch, time delay, timer, counter, <, >, =, NE, LE, GE, branching, etc.) depend upon the specific processing required.

6. Interlocked Control Valves: All controllers with interlocked control valves should be set into MANUAL mode, when the respective interlock is activated. Once the feedback signal indicates that the valve is on its fail safe position, the controller output should be set accordingly.

7. Default Specifications: The default specifications for some of the key parameters for all controllers are listed below:

• All control algorithms should have set point limits (e.g. high, low, and rate of change) that prevent other connected controllers or operators from selecting a set point that is outside those limits. As a default, unless otherwise specified in the design documents, all set point high and low limits should be set to their respective end of range values and the rate of change limits should be set to their respective span. These values should be tunable online.
• All control algorithms should have output limits (e.g. high, low, and rate of change) that prevent the controller sending an output value that is outside those limits. As a default, unless otherwise specified in the design, the low and high output limits should be set to their respective end of range values (i.e. normally 0 to 100 per cent) and the rate of change limit should be set to the output span (i.e. normally 100 per cent). In this case, for emergency or startup/shutdown reasons, the operators should be able to override the output limits when the controller is in MANUAL mode. These limits should be tunable online by the appropriate privileged user.

When the DCS is initially turned on or when an individual controller is turned on the controller should take its default to a predefined initial mode. As a default, unless otherwise specified in the design, the initial mode of all controllers should be set to MANUAL mode.

• When the DCS is initially turned on (i.e. powered up), the controller output value should default to a predefined initial value. This initial output value should not occur in the case where a controller should initialise in output TRACK OR INIT mode. As a default, unless otherwise specified in the design, the initial output value of all controllers should be set to a value that is the equivalent of closing the valve.
• When an individual controller is returned to an on scan status (after being off scan when a configuration change is being loaded), the controller output value should initialise at its last value prior to being placed off scan. This output value initialisation should not occur in the case where a controller should initialise in output TRACK OR INIT mode.
• In most cases, the set point of the controller will initialise its set point when in TRACK or INIT mode. In those cases where set point tracking is not specified, then an initial set point value must be configured. This must be defined as part of the design and should be specified in the Master Controller Summary.
• Unless specifically noted in the project documents, all alarms should default to the disabled position to prevent an overload of alarms. If an enabled alarm is specified, but a value is not given, then the following defaults should be used:
• High alarms should default to 80 per cent of scale for flow loops and 75 per cent of scale for all other loops.
• Low alarms should default to 30 per cent of scale for flow loops and 25 per cent of scale for all other loops.
• For discrete alarms, input contact open is the default alarm state.

The input modules receive information from field instruments installed in the process line and the output modules transmit controlled signals calculated by the controller to the actuators/final element in the field. Proprietary Network buses connect the processor and I/O modules. However Ethernet communication is most popular due its high-speed data transmission. Buses also connect the distributed controllers in different location and to the Human- Machine Interface (HMI) or control consoles at place of operation (Central control Room / area control room close to individual unit).

Application Software Development and Testing
Normally a team of process, instrumentation and software experts work together, keeping the process requirement in mind and its interfaces with other affected system to design and develop the application software. The application software should have all capability to execute all complex function block to manage the control loop in safe and efficient manner. The entire software are tested and debugged before installed in the plant for commissioning.

If a software developer does limited offline testing during the software development process, there will be a chances of mistakes in the process control application for smooth running of the unit/plant. In such cases the software will have to be debugged later during pre commissioning process or during start-up of the manufacturing equipment in the facility. It is significantly more costly to check and debug software during start-up of unit than at the application development process.

The sooner a developer (along with operation engineer and design engineer) catches a mistake, the cheaper it is to fix the same. Elaborate software testing can reduce overall project cost, last minute surprises and minimise rework during commissioning. Inappropriate / casual way of testing will lengthen the development time and increase the man-hour cost of developer.

Offline Testing determines if the automation system meets the licensorĘs defined requirements to operate plant trouble free. If a strong process automation professional and operation engineer has good knowledge of design requirement test together, it is relatively much easier for control and logic testing. The best practices always call for a detail offline testing to meet the process requirements.

The development process normally consists of testing the software at every stage of the process. The testing starts with the individual software module, and then the complete units operation should be completely tested.

The module and unit testing uses „test functions‰ that can test even small portions of the whole system software as considered by developer. It is important to define test scripts so the observed results are clear and concise. This testing is frequently conducted in an off-line or development system.

Once all the individual loops have been tested, the overall system is again tested as a whole along with inter panel communication and third party data exchange. System Vendor does the staging of all panels at one location.

This is called as a Factory Acceptance Test or FAT at developer works. The Final testing in the in every industry is often defined as onsite acceptance testing or site acceptance test SAT. This is often part of performance qualification of the entire system under site condition and software execution to run the unit.

Quality has to be enforced into the process of manufacturing the system Hardware and the software, which controls the process. Good projects implementation calls for systematic and correct automation design with only 10 per cent of the effort on software design and coding, but 90 per cent of the effort need to be put on offline testing and producing final documentation.