0% found this document useful (0 votes)
68 views

EEE4118 Lecture 3 Control and Operability 2023

The document discusses control and operability (CO-OP) specifications, which have three main purposes: 1) to ensure systems are designed to match operational needs, 2) to define the scope of work required for all operational aspects, and 3) to form the basis for technology decisions and plant control/information systems. CO-OP specifications go through three phases and are developed iteratively. They define the various philosophies that guide automation and control system design, including business, process, operating, automation, and maintenance philosophies.

Uploaded by

Daniel Jones
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
68 views

EEE4118 Lecture 3 Control and Operability 2023

The document discusses control and operability (CO-OP) specifications, which have three main purposes: 1) to ensure systems are designed to match operational needs, 2) to define the scope of work required for all operational aspects, and 3) to form the basis for technology decisions and plant control/information systems. CO-OP specifications go through three phases and are developed iteratively. They define the various philosophies that guide automation and control system design, including business, process, operating, automation, and maintenance philosophies.

Uploaded by

Daniel Jones
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 37

EEE4118

Automation and control


Control and Operability
Control and Operability

https://m.xkcd.com/1319/
2023/02/20 2
Control and Operability (CO-OP)
Specifications
• Purpose of CO-OP Specs
• Ensure that systems are designed to match operational needs of process and
business objectives
• Vital for competitive business
• Response to marketplace
• Philosophy of continuous improvement
• Quality assurance depend on meeting these requirements.
• Documentation
• Force interdisciplinary, visionary thinking during project planning (initial design
phases).
• Define scope of work required on all operational aspects. Forms a basis for project
budget allocation.
• Main automation deliverable in design stage. Basis for technology decisions  plant
control and information systems.

2023/02/20 3
Control and Operability Specs
3 distinct phases
C o -O p Sp ec 1 2 3a 3b

P ro c es s D ev e lo p m en t

Pro c e ss d e fin it io n

D e sig n

P ro c ure m e n t & C o n stru ct io n

C o m m issio n in g

O p er at io n

Sa n ct io n H a nd o ve r
2023/02/20 4
Co-Op 1
• First document in control and operability specification series.
• Generated in parallel with process development & process definition.
• Outlines plant and business operating philosophies.
• The Co-Op1 must address:
• Business Philosophy
• Process Philosophy
• Operating Philosophy
• Automation Philosophy
• Maintenance Philosophy
• Obtain agreement of all players - active participation in discussion & review
• Co-Op1 must be kept up to date  automation quality & relevance.

2023/02/20 5
The Business Philosophy
• Specifications related to overall business philosophy relevant to plant management. Specify
business factors which affect plant & control system design & operation of business as a whole.
• Business Strategy
• What will factory make? Where & how will it be sold (local / export, small / bulk)? How will it be
made and sold (stock or JiT)? Profit improvement - fixed : variable costs, optimisation possibilities?
• Ownership
• Reporting needs. Relationship between operations, management & shareholders?
• Location & Interaction with other plants
• Is plant independent? Does it share infrastructure? Raw materials sources? Ordering &
accounting?
• Development Strategy
• Production capacity expansion. Scope for new products / broadening product range.
• Timing
• How long will design and procurement last? How long will commissioning last? When must the
plant be fully operational.

2023/02/20 6
The Business Philosophy (cont.)
• Business and Manufacturing control: Is integration between business &
manufacturing systems required? Level & justification
• Information security: Which data is sensitive? How will security be managed?

• Examples Issues
Business Strategy
New diamond mine
Ownership
Police force Location & Interaction with other plants
Power station Development Strategy
Timing
Business and Manufacturing control
Information security

2023/02/20 7
Process Philosophy
• Specifications on production rate, quality (main & intermediate products), plant
objectives. Process hierarchy (structure). Objectives of each major process stage. Process
factors that will affect plant control and operation design.
• Technology Summary
• How is product made? Raw materials & by-products? Effluents & Hazards? Technology risks.
• Plant capacity
• Product volume? Assumptions underlying numbers?
• Plant Hierarchy
• Operating units / areas. Complexity. Terminology, numbering & naming systems. Tasks,
objectives & measuring criteria for enumerating compliance per plant area.
• Development Procedures
• Investigation, development & change control. Human resources, outside contractors,
research, labs etc.
• Materials and Products Summary
• Raw material, intermediate product and product quality management and supply & storage
requirements and philosophies

2023/02/20 8
Operating Philosophy
• Guidelines for management of operability, productivity & product quality. Strategies used for
setting up & evaluating operating goals.
• Operating Goals
• Will plant run as integrated unit or separate loosely coupled sections? Setting production targets
for different units? Performance measurement? Can performance targets be related to plant
setpoints? Performance - quality trade-off.
• Operations Management
• How does management relate and communicate with operations staff. Delegation of responsibility
& authority? How is production scheduled ? How is schedule performance measured?
• Quality Management
• Relationship between quality & operating goals.
• Human resource philosophy
• Skills requirements, Operators (Shifts or not), Training philosophy, Organisational Structure,
Manual and Automation philosophies
• Environmental Philosophy
• Detail requirements for monitoring, recording and reporting, Effluent treatment and disposal.

2023/02/20 9
Automation Philosophy
• Closely related to operation philosophy. Vital to competitiveness. Document outlines
scope of automation work & determines budget. Enumerate perceived automation
benefits & requirements. Essential to achieve correct level of automation - balance
auto/manual.
• Automation Policy
• What will be automated and why? Is it feasible and sensible? Availability of skills and labour.
• Scope of Automation
• Is automation limited to running of plant units, the whole plant, the business? Which tasks
are to be automated?
• User (Human-Machine) Interface
• Where & how will humans intervene in automated plant.
• Equipment & Software Policies
• Basic rules for type of automation equipment & software. Constraining solution environment
saves plenty during implementation. Quality control & implementation standards for
automation software (+development).

2023/02/20 10
Maintenance Philosophies
• Identify maintenance requirements of plant and methodologies by which plant goals will
be achieved. Infrastructure required for plant & equipment-specific maintenance
strategies
• Availability Targets
• This broadly defines reliability, availability and maintainability goals for plant engineering
design.
• Maintenance Strategies
• Equipment specific maintenance strategies for predictive, preventative & corrective
maintenance. Outline of infrastructure requirements for each level of maintenance
• Logistics Support
• What tools are required for managing documentation, spares and equipment databases?
• Personnel
• Outline required skills, personnel structures & performance criteria.

2023/02/20 11
CO-OP 1 Summary
• Philosophy (vision)
• Business
• Process
• Operating
• Automation
• Maintenance
• Co-Op1  defines “scope of automation work”
• Effort now directed to refine automation requirements  plant sections

2023/02/20 12
Co-Op 2 - Conceptual Functional
Specification (CFS)
• CFS for automation in a specific area.
• Complete & agreed upon between client and automation provider before
implementation commences.
• Ensure that quality principles are followed throughout automation project.
• Specifications allow client and automation professional to control quality.
• Ensure correct functionality, adequately tested is delivered on time. (e.g. Ariane 5)
• Compile work breakdown structure for project control.
• Defines deliverable sections for which conceptual functional specifications will be
written (based on CoOp1 plant hierarchy)
• For successful automation of non process functions, other philosophy documents in
Co-Op1 must also be considered.

2023/02/20 13
Co-Op 2 - Conceptual Functional
Specification
• Plan to use standard modules and object abstraction if possible - e.g. buy
standard software.
• CFS becomes a specification for purchase inquiry processes and may need to be
tailored towards abilities of these standardised modules.
• Co-Op2 can become a library!

2023/02/20 14
Elements of a Co-Op2
1. Devices to be automated: List clearly defines scope of automation.

2. Functionality Overview: How the current plant section works. Process


objectives & functionality of automation.

3. Interfacing with other plant sections/systems:


• If possible, avoid interaction between systems by design - complexity, integrity,
reliability.
• Clearly identify & define remaining interdependencies.

2023/02/20 15
Elements of a Co-Op2 (cont.)
4. Definition of operating states: Define distinct operating regimes of plant. Forms
basis for rest of Co-Op2.
• Entry Requirements: Details what must occur to enter a specific state. Could include:
prerequisite previous state, certain process variable values, specific events etc.
• Functionality in this state: Exactly what plant section does while in this state. Detail
conditions monitored under which this state is exited.
• Failure Modes: A large part of automation! How are errors handled? Actions include:
Take section to fail-safe state, alarm generation with no automated intervention,
selective shutdown etc.

2023/02/20 16
Elements of a Co-Op2 (cont.)
5. State Diagram: State transition diagram provides overview of states and
transitions between them. Overview of proposed functionality of automated
system. (Must be kept up to date.)

6. Manual Actions: Manual actions remain (depending on extent of automation


specified) If these actions affect operation of automation, they need to be
documented in CFS. (E.g. opening & closing of manual isolation valves;
addition of chemical additives; manual mixing etc.)

2023/02/20 17
Example - Cooling Tower
"Eliminate routine repetitive tasks from the operator's workload by automation
such that he/she can concentrate on optimising plant performance"
From Distribution

NC52001 NC52002 NC52003 NC52004 NC52005

To Distribution
TI52002
2023/02/20 NC52006 18
Cooling Tower: 1. Devices to be
automated
• Five forced draft structured packing cells each with its own fan
(NC52001, NC52002, NC52003, NC52004, NC52005)
• Temperature sensor on outlet of cooling system (distribution header)
(TI52002)
• Note the implication is that the circulation pump NC52006 is outside the scope of
automation
• This document describes behaviour of cooling tower fans as a function of
temperature.

2023/02/20 19
Cooling Tower: 2. Functionality
overview
• The temperature of cooling water is to be kept between 20C and 28C. The
amount of cooling can be controlled by switching in and out cooling towers:
• If temperature of return cooling water decreases below 28C a cooling tower fan
is turned off. This process continues with a further fan being turned off for every
2C that temperature decreases until all fans are off at 20C. Should the
temperature go up again the fans are switched on again in order they were
switched off with a 1C dead-band.
• As normal operating condition is that plant runs with all fans running, it is likely
that a single fan will be switched off and then on again most of the time. To
prevent this from always being the same fan, rotate the first fan to be switched
off on every transition between the states “four fans running” and “all fans
running”. This will balance the wear and tear on the fans

2023/02/20 20
Cooling Tower: 3. Interaction
with other plant sections
• Essentially an independent plant section that must follow load to keep the plant
cooling water between 20C and 28C. Should the cooling water temperature fall
below 19C the refrigeration will experience trips due to glycol overcooling.
• Note that a wider knowledge of the process is essential for thorough definition of
interactions

2023/02/20 21
Cooling Tower
4. List of States All Fans

10 All fans running


T<28
20 Four fans running T>29
Shift
30 Three fans running register
4 Fans
40 Two fans running
50 One fan running T<26
60 No fans running T>27

3 Fans

T>25 T<24

2 Fans

T>23 T<22

5. State Diagram 1 Fan

T>21
T<20

•No Fans

2023/02/20 22
Cooling Tower: State description:
4.10 All fans running
• Entry Requirement:
• Cooling water distribution header temperature > 29C.
• Counter determining which fan will be first to turn off must have been incremented.
• Prerequisite information: None
• Function:
• The last non-running fan is switched on so that all five fans are commanded running.
• Before switching on the last fan, advance the buffer which determines the first fan to be
switched off. (If fan 1 was switched off last the first fan to be switched on the next
temperature dip will be fan 2.)
• This state is exited when the temperature drops below 28°C
• Failure modes:
• Should a fan not start/stop when commanded a command error is generated.
• The code however doesn't go on hold. If the excursion the exceeds 4°C from the point at
which action should have been taken, the next fan in the sequence acts.

2023/02/20 23
Cooling Tower: State description:
4.20 Four fans running
• Entry Requirement:
(Cooling water dist. header temperature (TI52002) > 27C and in 4.30)
OR (Cooling water dist. header temperature (TI52002) < 28C and in 4.10)
• Prerequisite information: None
• Function:
1. If entry is on temperature going lower, the first fan (determined from switching
order) is switched OFF.
2. If entry is from a rising temperature, the penultimate fan (determined by
switching order) is switched ON.
• Failure modes:
1. Should a fan not start/stop when commanded a command error is generated.
2. The code however does not go on hold. If the excursion the exceeds 4C from the
point at which action should have been taken, the next fan in the sequence acts.

2023/02/20 24
Cooling Tower: 6. Manual Actions
• To ensure proper operation of the cooling water system the following actions
must be taken:
• Ensure that the recirculation pump remains running (NC52006)
• Ensure that cooling water quality is managed properly by regular lab analysis and in
response dosing of anti-scalant and biocide chemicals.
• The cooling water must be purged monthly.

2023/02/20 25
Conclusions about Co-Op 2
• Example almost trivial but illustrates principle of specifying functionality & scope
of automation in unambiguous manner.
• Generating a Co-Op2 is a lot of work (cut ‘n paste), but is essential quality
assurance & contractual compliance tool for automation.
• Complete Conceptual Functional Specification for specified plant section
1. Devices to be automated:
2. Functionality Overview:
3. Interfacing with other plant sections/systems:
4. Definition of operating states:
1. Entry requirements
2. Functionality in this state
3. Failure modes
5. State Diagram:
6. Manual Actions:

2023/02/20 26
Co-Op3 - Detailed Functional
Specification (DFS)
• Final automation deliverable.
• Two phases:
• Detailed automation design
• “As-built” documentation used as a basis for maintenance & upgrading of the plant
• Cannot stress importance of good documentation to large scale projects.
• Documentation and change management is vitally important.

2023/02/20 27
Automation Methodology
• Design is top-down. Automation implementation is bottom-up. Automate lower
levels first & build up higher level functionality. Availability & reliability of higher
level functions < that of lower levels. Cannot optimise if controllers are not tuned.
Cannot tune controllers if instruments are unreliable.
• Automation projects usually require more than one programmer. (e.g. Star-Wars)
Standard methodologies ensure:
• Ease of multi-programmer implementation
• Structured modular testing
• Easy maintenance
• Automation must be reliable. Code crashes unacceptable. Quality management is
hence paramount. Software standards ... Mil. Spec. (tutorial).
• Specific automation methodology to be used must be contractually defined.

2023/02/20 28
Modular State Space Model for
Automation Design
• Modular approach to automation design recommended. Benefits:
• Module re-use. Object oriented design - devices automated are in object classes &
code is written to operate on object class. The code for a certain class needs to be
written once only.
• Code needs to be proved (debugged ) once only.
• Modules have clearly defined interfaces and can be connected easily

• The automation is implemented in 4 Co-ordination


distinct layers:
Unit Operations

Basic Operations

2023/02/20 Devices 29
Example: High Test Molasses …
Google this!
• Consider a system that meters a raw material (HTM) into a vessel.
• The automation of this would be classed as a basic operation.
• How is automation achieved using modular method?

2023/02/20 30
The Devices Layer
• System needs code to drive a conventional PID controller (an existing, defined
object in control system) in a robust manner. This requires that:
• The controller is active (inputs are coming in, output driven & control algorithm
being executed.)
• The controller is not locked out for maintenance (red-tagged)
• There is no safety interlock overriding the automation
• The controller is in program mode. Control over devices can only be under one
owner at a time. To achieve this a mode attribute is normally given to the device
object that defines whether the operator or the automation “owns” the device.

• Once subroutines like one below have been written for a device class, they can
simply be re-used. Once fully debugged checking requirements shift to higher
level modules.
2023/02/20 31
Honeywell CL Code
(not for exam purposes!)
Subroutine dr_pid(cmd :in number;
spvar :in number;
opvar :in number; )

If pid_exec=inactive then set pid_exec=active

If progmode=on and pid_redtag=off and pid_sd==off then


& set pid_ma=program

If pid_ma=operator or pid_im=on then exit

If cmd=PID_man then
& (set PID_mode=man; set PID_op=OPVAR)

END dr_pid
2023/02/20 32
The Basic Operations Layer
• Operation on system is broken into minimal increments - the states. A state must be
defined for every distinct operating condition.
• State Transition code
Nofeed
If State=Vessel_ready and Substate=Nofeed then
& set Substate=Feed

If State=Vessel_ready and Substate=Feed and feed


& target reached then
& set Substate=feed_complete Target m et

• A Single Device Controller (SDC) is then written to link state


feed _complete

transitions to devices. Function calls are made to drive each


device as a function of the current state.

2023/02/20 33
The Basic Operations Layer
--* Single Device Controller:

If state=Vessel_ready and Substate=Feed then


FIC_mode=auto
FIC_sp=23
else
FIC_mode=man
FIC_op=0

If ficxx.mode<>FIC_mode or
(FIC_mode=man and ficxx.op<>FIC_op) or
(FIC_mode=auto and ficxx.sp<>FIC_sp) then
call device level driver routine

2023/02/20 34
The Basic Operations Layer
• Coding Basic Operations in this manner has following advantages: It is possible
to implement the automation as two distinct sections of code which allows
testing and online modifications to be done quite easily
• software generated is easy to debug & can be thoroughly documented.
• coding workload can be spread over two coders per system
• methodology ties in with S88 batch system code generation.
• can also be applied to continuous plant. (Here basic operations are more complex
than in batch operations (running whole units becomes a basic operation).
• In a plant with mixed batch & continuous sections, a single software methodology
can be followed.

2023/02/20 35
Conclusions Co-Op3
• Lots of work & documentation.
• Once complete, implementation is very rapid & reliable.
• Implemented automation meets agreed specifications and rewrites should thus
be minimal.
• The documentation is almost complete before code is written. Useful for
commissioning & forms a basis upon which change can be tightly controlled.
• Software implemented as part of such a methodology can be maintained and is
of a high quality throughout.
• With a Co-Op methodology rigorously applied it should be possible to obtain
ISO9000 accreditation for automation code generation.

2023/02/20 36
ISO9000:2015
• ISO 9001:2015 specifies requirements for a quality management system when an
organization:
• needs to demonstrate its ability to consistently provide products and services that
meet customer and applicable statutory and regulatory requirements, and
• aims to enhance customer satisfaction through the effective application of the
system, including processes for improvement of the system and the assurance of
conformity to customer and applicable statutory and regulatory requirements.
• All the requirements of ISO 9001:2015 are generic and are intended to be
applicable to any organization, regardless of its type or size, or the products and
services it provides

2023/02/20 37

You might also like