Upload
emerson-process-management
View
5.045
Download
5
Embed Size (px)
DESCRIPTION
Presented by Ed Marszal, president of global consulting and engineering firm, Kenexis, at 2010 Emerson Exchange in San Antonio, Texas.
Citation preview
Best Practices in SIS Documentation
Ed Marszal, President, Kenexis
Presenters
Ed Marszal
Gary Hawkins
Introduction
Safety Instrumented System Design per “ISA S84”* is becoming a common practice
Poor documentation is being generated due to “safety case” mentality
Current practices ignore audience of documents and “good practices” for specifications in general
* ANSI /ISA 84.00.01-2004 (IEC 61511-Mod)
FEED Phase SIS Documents
List of Safety Instrumented Functions (SIF) Grouping of Instrumented Protective Functions (IPF)
– Group by equipment or process• Compressors• Reactors
• Fired Heaters
P&ID representation of SIF Logic description
– cause and effect tables– Boolean logic diagrams– Narrative (“plain English” description of operation)
Testing procedures (with documentation of results)
Preliminary Design Steps
SIF List should be precursor to SIL selection HAZOP/LOPA without knowledge of typical SIF leads
to errors HAZOP is a final check on a good design, not a
design task Typical SIF based on experience, standards, codes,
and judgment
Instrumented Protective Function Groups
Group instruments together that are functionally related
Typically based around major equipment– Compressors– Fired Heaters– Reactors
Typically contains multiple SIF Also can contain non-SIF instruments and logic
Typical Plant Groupings
IPF Grouping for Separator
V-101
PT101B
PV101B
PT101D
LT101A
LT
101B
PI101C
PIC101B
H
L
A
D
PT101C
PV101A
PIC101A
PT
101A
USC101
USC101
LG101A
LG101B
H
H
L
Detail “A”
Detail “A”
Advantages of IPF Grouping
Compact information with minimal duplication Facilitates programming – programmer shielded for
single instruments in multiple SIF Facilitates design and I/O counting Facilitates test plan development and testing
P&ID representation
Symbology for SIS, specifically tag naming in inconsistent (I, X, UC, USC)
Use of “S” is technically correct, but leads to more confusion (PSV is always a relief valve??)
Use of typicals to minimize clutter
Typical SIS I/O Details
Detail “A” - SIS Inputs
XIXXX
XTXXX
HAXXX
XAHHLLXXX
XAHLXXX
HSXXX
XDAXXX
USCXXX Indicator
Bypass Switch
Trip Alarm
Pre-Alarm
Bypass Alarm
Deviation Alarm
Safety Requirements Specs
Specifications (emphasis on ‘s’) Limit information to what is required for audience (SIL
not required on C&E or P&ID) Use “general requirements” statements for common
features such as bypassing Refer to other documents for non-critical information
Typical Bypass Note
1.1 Bypass / Override SIS Logic Solver
Each of the functional groups that are described in this Safety Requirements Specification shall require a shutdown bypass function for maintenance and testing. The bypass functionality described in this note shall not be used for normal operations. I f a bypass is required for normal operations such as start-up, a dedicated hard-wired bypass facility shall be provided. The SIS shall be configured so that bypasses are implemented using a two-step process that includes activation of a unit-specific “bypass enable” switch and activation of an input-specific BPCS bypass soft switch. Only when both of these items are activated shall the input be bypassed. When an input is placed in “bypass”, the SIS logic solver shall hold the input in the non-trip state, regardless of the status of the bypassed input.
Reference External Documents
Conclusions
Room for improvement in SIS documentation practices
Consider the audience for the documents Use good engineering practice Minimize data duplication Leads to shorter preparation time and fewer errors
Business Results Achieved
Decreased implementation time and cost– Compact documentation is easier to prepare and more
accurate– Use of standard modules instead of custom development– Minimal clarification and rework
Decreased ongoing maintenance effort and cost– Updates only occur in one document– Likelihood of inconsistent data in multiple documents
decreased
Safer processes– Lower probability of systematic errors in system resulting
from poor documentation
Summary
SIS design can be made safer and more cost effective through documentation method improvements
Specification preparation time can be reduced by as much as 50%*
Please fill out comment cards and e-mail any feed back you have to the authors
Questions?!?
Where To Get More Information
ISA Bookstore – Safety Integrity Level Selection Kenexis Web Site
– HTTP://www.kenexis.com/resources
Emerson SIS Lifecycle Workbook– At Delta V SIS Booth during EGUE– Contact Emerson After EGUE