something from the past , 2000 , could be proved upon

1. CONTROL SYSTEMS EXECUTION PLAN - PRELIM
Table of Contents
1. General
1.1. Intent of Document
1.2. Definitions
2. Administrative Plan
2.1. Roles and Responsibilities
2.2. Standard Design Documents
2.3. Deviation Procedure
2.4. Standard Terms and Abbreviations
3. Control and Issue of Controlled Documents
3.1. Mechanics of Issue
3.2. Format and Numbering
3.3. Internal Reviews and Checking
3.4. Issue for Client Approval
3.5. Client Review/comments/approval
3.6. Resolve Client Comments
3.7. Client Sign-off
3.8. Accumulate Changes
3.8.1. General Specifications
3.8.2. Software Specifications
3.9. Re-issues
4. Change Control and Documentation
4.1. General
4.2. Change Control Procedures
4.2.1. Level 1 Changes
4.2.2. Level 2 Changes
4.2.3. Level 3 Changes
4.2.4. Level 4 Changes
4.3. Marking of Changes
4.3.1. Text-based Documents
4.3.2. Drawings
4.4. Document Filing
4.4.1. Original Documents
4.4.2. Master and File Copies
4.4.3. Review Copies and Check Copies
4.4.4. Document Index
4.4.5. Final Disposition
4.5. Distribution
5. Design Development Plan
5.1. Work Procedures and Documents
5.2. Document Descriptions
5.2.1. Requirements
5.2.2. Preliminary Design
5.2.3. Detail Design
5.2.4. Implementation
1. GENERAL
1.1. Intent of Document
This document describes how the control system hardware, software, and instrumentation will be designed, implemented and tested.
It is meant to supplement the “Project Procedures Manual”. This plan becomes effective when approved by the project manager.
A master copy of the approved plan will be maintained as a controlled document through the life of the project.
1.2. Definitions
Controlled Documents - Drawings, specifications, and other documents whose issues and revisions are strictly controlled, logged
a and accounted for. The review/approval activities are identified by the Quality Matrix in Specification “Control Systems Quality
Plan "
Approved - A document is considered approved when the approval authority has signed the document and the signed copy is in
EPCM's possession
Basis of Design - The design inputs.
Design Products - The result of applying a design method to identified design inputs to produce, within the limits imposed by the
acceptance criteria, a design output.

2. Acceptance Criteria - Specified boundaries or limits placed on the design; Codes, Standards, and Practices.
Tasks - Individual instructions or actions that are followed to generate a specific result, document or group of documents.
Activity - A sequence of related tasks which produce a specific result or set of results.
Work Process - A sequence or collection of activities performed to a particular procedure.
Design Inputs - Those criteria, parameters or design requirements upon which the detailed design is based; the specific basis for
the design.
Design Outputs - The product of the design process; the deliverables ; those documents which uniquely define what is to be built,
operated or devised.
Design Review - The design review process includes verification that the design output meets the design input. Results of design
reviews are documented.
Quality - Conformance to prescribed requirements.
Verification - The act of reviewing, checking, and documenting whether processes, actions or documents conform to specified
requirements.
Documents - Documents are used to record the results of the design process. They may be products of design or may be Standard
Design Documents adapted for use in the project. For simplification, some individually controlled documents may become part of a
larger composite document, which when referenced, refers to all of its constituent documents.
Practices - Rules, procedures, or guidelines which apply to all control system development work and not necessarily to the generation
of a document or group of documents.
System Software - System software provides basic operating instructions for the computer and controls functions such as resource
allocation, scheduling, input-output functions and data management. An example of system software is the operating system such as
MS-DOS or UNIX. Generally, system software is supplied with the computer and is independent of the specific application.
Configurable Software - Configurable Software is a program which allows the user to define a number of conditions such as
operating parameters, reporting parameters and alarm conditions. The user does not change the configurable program code itself but
can change the modifiable parameters to satisfy the requirements of the application. Examples of configurable software are Lotus
1-2-3 and dBaseIII. If the program code is configurable software is altered for the application, the code is considered to be
application software.
Applications Software - Applications software is code which is written or modified for the specific application, When a configurable
program is used, the parameters and operations which are specified by means of the configurable software comprise the Application
Program.
Structural Testing - Structural testing of software is the detailed examination of the internal structure of the code.
It includes low-level and high-level review of the code, analysis of all important logic paths and inspection for “dead” code,
A listing of the source code must be available to perform structural testing, and other program documentation such as a logic diagram,
a description of their program structure, a definition of all variables and a specification of all inputs and outputs may be very helpful
in performing a structural testing.
Functional Testing - Functional testing of software, sometimes called “black box” testing, evaluates the outputs of a program
compared to the expected output values for a range of input values. Functional testing does not require the program source code to
be available, but the source code can be very helpful in designing the tests to be performed. Functional testing requires a comprehensive
system specification which describes all functions of the system in sufficient detail to define the test required to assure proper
performance of the system.
Software Design Specification - These include:
Sequence of Operations
Phase Logic Descriptions
General Design Specifications - These include:
System Design Specifications
Instrumentation Specifications
Package Equipment Specifications
2. ADMINISTRATIVE PLAN
2.1. Roles and Responsibilities
Certain roles and responsibilities are defined by Specification “Control Systems Quality Plan”. In addition key members of the
project design team will have defined roles and responsibilities describing their part in project execution. The control systems lead
engineer may assign roles and responsibilities to other members of their design team. All such assignment will be documented in
the project files.
2.2. Standard Design Documents
Standard design documents are derived from either existing standards or archives. These documents are made part of this plan
by inclusion as appendices.
Standard Documents may be any of the following:
Technical Practices
Standard Specifications
Standard Details
Standard Reports

3. Standard Forms
2.3. Deviation Procedure
Deviations from “this specification” or from documents made a part of it by reference or attachment, are allowed provided they are
approved and recorded in accordance with the procedure listed below.
The initiator (engineer, designer, technician, or client representative) who detects the need for a procedure deviation generates a written
communication to the project lead control systems engineer which contains the following information:
Descriptions of the deviation and new procedure.
The reason for the deviation.
The scope of the deviation (e.g., one issue of a specific document, a specification for a class of instruments, a time period, for the
duration of the project, etc.)
The initiator signs and dates the communication and delivers it to the project lead control systems engineer. The lead control
systems engineer evaluates the request to determine if the modified procedure meets the intent of “this specification”, if it is workable,
and if it will not adversely affect other design efforts. If the modified procedure meets these requirements, the discipline lead approves
the deviation, assigns a Deviation Number in the Deviation Log and forwards a copy of the communication to the designated client
representative.
The client representative reviews the appropriate modified procedure, signs it or rejects it, and returns it to the lead control systems
engineer.
The lead control systems engineer distributes the communication and files the original as an Appendix to “this document”.
The affected portions of the procedure are marked with the revision number assigned to the deviation according to the method required
required “this specification”.
2.4. Standard Terms and Abbreviations
Industry standard terms and abbreviations shall be used where applicable.
3. CONTROL AND ISSUE OF CONTROLLED DOCUMENTS
Control systems generated documents may include specifications, procedures, drawings, reports, sketches, listings, applications
software programs, and other groups of information that issued through document control.
3.1. Mechanics of Issue (guideline)( develop specifically for this project )
The sequence of activities in issuing any document are is as follows:
1. Select Document Format and Number
2. Develop Document
3. Internally Review/Check Document (Rev. ?)
4. Interdepartmental Review, comment, and/or approval
5. Resolve internal Comments If necessary re-issue Rev. A for internal review
6. Issue for Client Approval (Rev. ?)
7. Client Review, comment, and/or approval
8. Resolve client comments, if necessary re-issue (Rev. ?) for client approval
9. Client Sign-off
10. Issue Approved for Design/Construction (Rev. ?)
11. Accumulate Changes on software documents during the coding phase
12. Issue for Off Site Testing ( Rev. ?) (Software documents only)
13. Accumulate changes on software documents during the testing phase
14. Issue for Installation ( Rev. ? ) (Software documents only)
15. Issue for Validation (Rev. ?) (as built for Software documents only)
A specification cover sheet showing revision history must be attached to each text-based document. Drawings shall have a drawing
revision and title block as specified in the “Project Procedures Manual”.
3.2. Format and Numbering
Documents shall be numbered per the numbering scheme defined in the “Project Procedures Manual”. General Specifications may
be treated as instrument specifications for numbering purposes. Standard specifications (e.g. narrative specification), reports, and
listings should follow the requirements of the project. The control systems lead engineer will maintain a log of all document numbers
used or assigned for use on the project. Minor revisions are indicated by a 1.1, .. etc
3.3. Internal Reviews and Checking (Rev. ?)
The level of checking and review shall be per the Specification 675.270.70415 “Control System Checking” .
3.4. Issue for Client Approval (Rev. ?)
Those documents which require client approval are listed in the Quality Matrix in Specification “Control Systems Quality Plan”.
After internal review and checking, those documents will be revised and upgraded to Issue for Approval. The lead control systems
systems engineer and the project manager now sign the original cover sheet, initial the revision table on the original cover sheet, and
forward the documents to the document control who will issue them to the Client.
A revision may be skipped if there are minimal or no changes from previous revisions, with Clients approval.
Documents will not be used for PROCUREMENT purposes without Client approval.
3.5. Client Review/comments/approval

4. The client will singularize all comments and resolve all internal differences and return to marked up copy to EPCM document control
by the due date. All document not returned by the due date or notification that they will be delayed, the documents will be considered
accepted as issued.
3.6. Resolve Client Comments
The Client may approve the documents without comments, approve them with comments, or comment without approval. If the
document is return approved, all client comments will be resolved (if any) and the document will be re-issued (Rev.?) Approved
for Design/Construction. If the document is returned without approval all client comments will be resolved and the document
re-issued (Rev. ?) for Client Review. This process will continue until the document is approved.
3.7. Client Sign-off
The Approved for Design or Construction original is signed and initialed by the authorizing Client representative. Document control
will distribute the document and retain the original with the signed cover sheet per project procedures.
3.8. Accumulate Changes
For all document issues of controlled documents (Rev. ?) and higher for Instrument and narrative specs and (Rev. ?) and higher for
software specs) two copies of the document are kept. The first copy (file copy) is normally kept by Technical Document Control. The
second copy (master copy) will be kept by the control systems lead engineer. Each copy is marked on the front page with its designation.
No comments or marks are made on the file copy. All markup will be done on the “Master Copy” and signed and dated.
3.8.1. General Specifications
Per the constraints of the change control requirements of this execution plan, the master copy is marked to show changes necessitated
necessitated by items such as mistakes, conflicts, supplier input, client comments, and construction restraints. All changes, including
such items as loop tuning parameters, will be recorded signed and dated in a Change Log kept with the Master Set of documents (e.g.
the Master Specification book) or with the individual master copies. The master copy is used for design reference. As predecessor
documents are modified, the master copy of successor documents are checked and marked accordingly.
3.8.2. Software Specifications
Accumulate changes resulting from further design development and from off site testing. The change log is not used for this set of
software design changes. These changes are considered development changes and not keep recorded in the change log unless they
effect the Functional Requirements.
3.9. Re-issues
When sufficient changes have been accumulated, as judged by the lead control systems engineer, or a re-issue is required according
to the change control procedure listed in this specification, the document is revised and re-issued. For re-issues of the document the
following steps are followed:
Refer to the master copy and make and mark the revisions.
Update revision data in revision block.
Document is initialed by lead control systems engineer, project manager, and authorizing Client representative.
document control distributes the document and files the original.
The old master is marked void and filed, the old file copies are discarded, and new master and file copies take their place.
4. CHANGE CONTROL AND DOCUMENTATION
4.1. General
The project lead control systems engineer is responsible for control of all Control System documents. To ensure that only valid,
up-to-date, documents are used, the guidelines listed below will be strictly followed.
Documents shall be re-issued only upon authorization by the lead control systems engineer.
Only the latest master copy of documents shall be used for design reference. Changes to the master copy will be recognized only
when properly justified, dated, and signed.
4.2. Change Control Procedures
All changes to documents after (Rev ? ) for instrument and narrative specs and (Rev ?) for software design specs will be strictly
controlled according to the procedure listed below.
The initiator of the change fills out the following sections of the Change Request / Record form included as Attachment 1 of this practice.
Change Description
Reason for Change
Change Level
First line of Related Documents Table
Requested by: and Date
The change level is selected according to the following guidelines:
Level 1 : These are cosmetic changes that will impact one document only
Level 2: These changes will affect Control Systems successor documents.
Level 3: These changes will affect Control Systems and other disciplines' documents.
Level 4: These documents will change the process.
Each level of change is handled differently from this point as listed below.
4.2.1. Level 1 Changes
The initiator gets lead control systems engineer approval on the Change Request / Record form.
The initiator marks the appropriate master copy.

5. The initiator fills in the following fields on the Change Request / Record form
Revised Name/Date in Related Documents Table
Form Completed and Date
The initiator files the Change Request / Record form.
4.2.2. Level 2 Changes
The initiator fills out one line in the Related Documents table for each document that may be affected by the proposed change.
The initiator gets lead control systems engineer approval on the Change Request / Record form.
The initiator checks and marks the appropriate master copies.
The initiator fills in the following fields on the Change Request / Record form for each document listed:
Revised Name/Date in Related Documents Table
Form Completed and Date
The initiator files the Change Request / Record form.
4.2.3. Level 3 Changes
The initiator fills out one line in the Related Documents table for each document that may be affected by the proposed change.
The initiator gets lead control systems engineer approval on the Change Request / Record form.
The initiator checks and marks the appropriate master copies.
The initiator fills in the following fields on the Change Request / Record form for each document listed:
Revised Name/Date in Related Documents Table
Form Completed and Date
The initiator files the Change Request / Record form.
The modified documents are revised and re-issued as soon as possible per the issuing procedure.
4.2.4. Level 4 Changes
The initiator fills out one line in the Related Documents table for each document that may be affected by the proposed change.
The initiator gets lead control systems engineer approval on the Change Request / Record form. The lead control systems engineer
proceeds to get project manager and client representative approvals.
The initiator checks and marks the appropriate master copies.
The initiator fills in the following fields on the Change Request / Record form for each document listed.
Revised Name/Date in Related Documents Table
Form Completed and Date
The initiator files the Change Request / Record form.
The modified documents are revised and re-issued as soon as possible per the issuing procedure.
4.3. Marking of Changes
Once change control has been instituted for a given document, the following procedure for making changes will be followed.
4.3.1. Text-based Documents
A revision mark, will indicate places in the document where additions and or deletions have been made. Revision marks will only indicate
changes from the pervious version. However, hard copies of all revisions will be kept.
4.3.2. Drawings
A revision mark, consisting of the revision number of the drawing enclosed in a triangle, will be placed adjacent to area affected by
the revision. The changed area is circled with a cloud where the cloud border runs through the revision triangle.
For the next issue of the drawing, the cloud and triangle are removed. The revision narrative (i.e., include vendor information) is retained
throughout the life of the drawing.
4.4. Document Filing
Detailed filing procedures are contained within the “Project Procedure Manual”.
4.4.1. Original Documents
The original documents will be retained in the project files by document control.
4.4.2. Master and File Copies
A file and master copy each issue of each document will be retained in the discipline files.
4.4.3. Review Copies and Check Copies
All check copies and review copies shall be maintained in discipline files and will be placed in storage at the end of the project in
accordance with the appropriate records retention schedule.
4.4.4. Document Index
The document control will maintain an index of all documents issued, with a record showing the revision number, date of issue, and
approval status of each document.
4.4.5. Final Disposition
At the end of the project, custody of the control system files will be transferred to document control for disposition.
4.5. Distribution
Distribution will be made by document control according to the document distribution matrix contained within the “Project Procedures
Manual”. Additional distribution can be made as requested by the initiator, lead control systems engineer, or project manager.
5. DESIGN DEVELOPMENT PLAN

6. 5.1. Work Procedures and Documents
Standard Work Procedures and Documents which are referenced as appendices will apply.
5.2. Document Descriptions
5.2.1. Requirements
5.2.1.1. Scope/Budget/Schedule
Includes the Scope of Services, Scope of Facilities, Budget, Control Level Schedule, and Staffing Plan. The Project Requirements
Checklist is a required Input to the Scope, budget and schedule.
5.2.1.2. Control System Design Criteria Checklist
Uses a checklist format to clarify and define the control system scope of work for the project. It covers the quantity, type, and format
of deliverables, work to be performed by MIPAC, work not to be performed by MIPAC, etc. It is used to gather and document
client and project specific details of the instrument design and installation
5.2.1.3. Control Systems Execution Plan
Control Systems Execution Plan together with the “Project Procedures Manual” and applicable internal EPCM practices, governs
how control systems design will be executed.
5.2.1.4. Global Functional Requirements
Functional Requirements specification is intended to conceptually define the requirements of the process control system. It briefly
covers the areas listed below.
Control Philosophy - Project Description, References, Objectives of Control System, Definitions, Conceptual Automation
System Architecture, Level of Automation Required, and Area Specific Philosophies.
Functional Requirements - Batch Control, Operator Interface Requirements, Security, Data Archiving, Logging, and Reporting,
Alarming, Recipe Management, and Production Scheduling.
Performance Requirements - Expandability, Responsiveness, and Redundancy.
Hardware Requirements Overview - System Hardware Requirements, and Third Party Control System Hardware Requirements.
Required Standards - Control Systems Execution Plan, Design Standards, and Testing and Staging Plan.
Hardware architecture including interfaces between levels, Operator Interface Terminal Locations, vendor-supplied controls and
interfaces, printers, highway connections, etc. It is not specific to any hardware manufacturer.
5.2.1.5. Control System Specification
Control System Specification includes hardware specifications, I/O estimates by area, application software needs, commercial terms
and conditions, bid evaluations and recommendations, and the resultant purchase agreements.
5.2.2. Preliminary Design
5.2.2.1. Selected Instrumentation Vendors
List lists the vendors selected to furnish each kind of instrument planned for the job. It represents assigned sole source suppliers
or vendors selected through a competitive bid process.
5.2.2.2. System Design Standards
System Design Standards will specify in detail how software will be developed. It will cover procedural as well as aesthetic concerns.
It will cover in detail the topics listed below.
General - Intent of Document, Objectives, and References and Related Specifications.
Development Methodology - Process Narratives, Sequence of Operations, Logic Definition Diagrams, Batch Control Logic,
and Control Block Configuration.
Documentation - Guidelines and Format
Primitives and Subroutines - Control Block Primitives and Common Subroutines.
Programming Practices - Style, Variable, Program, and Routine Naming, Inline Commenting, and Program and Routine Template.
Appendices - Alarming Methodology, Subroutine Descriptions, Control Block Diagrams and Descriptions, Program Template,
Subroutine Template, Sequence of Operations Format, and Logic Definition Diagram Format and Usage.
5.2.2.3. Operator Interface Design Standards
Operator Interface Design Standards defines how all operator interface graphics are to be developed. This will ensure that all interfaces
are uniform in look and feel and use identical escape and command sequences. It will cover in detail the topics listed below.
General - Scope of this Document, References, Graphics System Objectives, Quality, and Visual Design.
Overview - Menuing and Hierarchy, Page Template, Function Keys, and Exiting.
Messaging - Informational Messages, Feedback Messages, Error Messages, Help Messages, and Scrolling.
Symbols and Graphics - Lines, Graphic Symbols, Tagging, Dynamic Symbols, Colors, and Text.
Data Entry - Input Fields, Input Validation, and Input Errors.
Abbreviations - List of allowed standard abbreviations.
5.2.2.4. Control System Process I/O List
Control System Process I/O List will link the instrument tag numbers to the physical connection addresses and logical addresses.
DCS Tag
Instrument Tag
I/O Point Tag
Physical Wire Location

7. Service description
5.2.2.5. Inter-Processor Communications
Inter-Processor Communications will be developed for each serial or highway interface between the DCS and third party systems.
5.2.3. Detail Design
5.2.3.1. Process Narratives
Will be developed by the client and/or the process discipline for process-oriented modules of equipment. They will describe sequencing
requirements, failure actions, critical parameters, etc.
5.2.3.2. System Stage and Test Requirements
System Stage and Test Requirements will specify all testing to be performed. It will not include actual test specifications but it
will describe how they must be developed. It will cover who is to write and review test specifications, perform and record tests, review
test results, and how discrepancies are to be handled. It will cover in detail the topics listed below.
General - Objectives and Definitions.
Staging Plan - Home Office, Package Equipment Vendor Shop, Factory, and Jobsite.
Testing Overview - Test Record keeping, Home Office, Package Equipment Vendor Shop, Factory, and Jobsite.
Home Office Testing - Testing Matrix, Module Testing, System Testing, and Acceptance Testing.
Package Equipment Testing - Responsibilities and Guidelines
Factory Testing - Responsibilities and Guidelines
Jobsite Testing - Objectives, I/O Checks, Loop Checks, etc.
Appendices - Sample Module Test Specification Table of Contents and Structured Basis Testing Methodology.
5.2.3.3. Hardware and Software Architecture
Drawing or sketch will be specific to the vendor(s) selected and will include part numbers, equipment numbers, communications adopters,
cabling requirements, etc.
5.2.3.4. Unit Functional Requirements (XXX>000)
The Unit Functional Requirements will define the details of how each Unit is to function as well as defines the functional requirements
and operation of the system. It will consist of documents specifying the operation of each process/software sequence.
5.2.3.5. Unit Sequence of Operations where XXX is a sequential number matching the number for the Unit Functional Requirements
for this Unit.
Sequence of Operations Specifications will define the software in pseudo code and primitives (phases) detail each unit operation.
Sequence of operations specifications may contain multiple phases or single phase definition.
The Overall Sequence of Operations will specify the following:
Overall Batch Processing and Coordination
Continuous Control Logic Specs
Batch control Logic Specs
5.2.3.6. Master Phases
Define in pseudo code the function of each of the Primitive Sequence of Operations used in the Units. These Primitive will be kept in
alphabetical order. They will referred to as Phases.
5.2.3.7. Screen Sketches
Will be developed only for those applications where the screens are not based on the P&IDs. The sketches will include the static
background as well as embedded dynamic elements.
5.2.3.8. Master Specification Book
Master Specification Book will be a hardcopy of the latest issued revision of all instrument specifications. It will also be used to record
approved revisions to specifications prior to those revisions being added to the design database. A hardcopy of all issued specifications
will also be filed in this book "behind" the current revision of each specification.
5.2.3.9. Instrument Vendor Documentation
Includes catalog cut sheets, certified dimensional drawings, installation and calibration manuals, etc. for instruments purchased for the job.
5.2.3.10. Inline Dimension Book
Includes reports, sketches, and certified data that define the dimensions of instruments that are installed inline. It may be expanded to
include dimensional information on all instrument connections.
5.2.3.11. Instrument Installation Details
Physical installation details for instruments. They will consist of standard EPCM/MIPAC details with minor modifications as required for
this project.
5.2.3.12. Instrument “Loop Drawings”
Are schematic/symbolic representation of all physical interconnections between an instrumentation sensing device, the receiving device
and/or output controlling device, and final control element. Loop Reports are non-graphical loop drawings. Loop documentation will be
produced according to a form and format approved by the Client and based on EPCM/MIPAC Standard Documents.
5.2.3.13. “Vendor Documentation”
Includes cut sheets, certified data, installation instructions, application instructions, etc. for instruments, systems and other materials
specified by EPCM/MIPAC
5.2.4. Implementation
5.2.4.1. “Instrument Index”

8. Is a database that includes information on instruments including specification data, drawing references, process data, I/O addresses,
procurement data, etc. Information is