Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Best Practices in SIS Documentation

on

  • 4,974 views

Presented by Ed Marszal, president of global consulting and engineering firm, Kenexis, at 2010 Emerson Exchange in San Antonio, Texas.

Presented by Ed Marszal, president of global consulting and engineering firm, Kenexis, at 2010 Emerson Exchange in San Antonio, Texas.

Statistics

Views

Total Views
4,974
Slideshare-icon Views on SlideShare
3,853
Embed Views
1,121

Actions

Likes
0
Downloads
178
Comments
0

4 Embeds 1,121

http://www.emersonprocessxperts.com 1105
http://static.slidesharecdn.com 11
http://webcache.googleusercontent.com 3
http://translate.googleusercontent.com 2

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Ed to provide Kenexis logo.
  • Notes: First bullet: added “more complete” name for what we commonly refer to as “ISA S84” or even “S84” for short. Second and third bullets: Ed explains what is meant by “safety case” mentality. That following S84 point by point is the root cause of poor SRS documents resulting in a large document that is difficult for the user of the document – those involved in designing and building the SIS. Maybe include an example of a “bloated” bad document versus the more user friendly format. Phone book versus People magazine…. Or better analogy.
  • Ed – Is the second bullet on a wish list of the right way to do things, whereas the others are more common place? Maybe reorganize with the typical on top and wish list at the end. Ed to incorporate verbal narrative of how DeltaV is well suited to IPF’s, not necessary to have huge monolithic safety logic solver (as they are cumbersome, more difficult to maintain or implement changes over the years), etc. Added sub-bullets to Logic description – not that this is implying a choice of one of the three but the best results are had when all three are present. Not all nuances can be captured in the cause and effect table (like reset actions), logic diagrams are bullet proof (if done correctly), but the plain English narrative makes it easy for someone not waist deep in the logic to understand what is supposed to happen (operators and managers…)
  • First bullet: I agree that the functions should be identified first before the discussion on severity and frequency of a failure on demand. Second bullet: Can you cite an example of an error in the process hazard analysis (PHA) due to ignorance of the SIF? I’m not clear on this as I thought that the “true” hazard analysis is done on a process in the absence of protective instrumented functions. Or is the point being that someone that knows how to build safety systems be present in the PHA? Third bullet: I like it - but kind of reverses the common man’s thinking (me too). Chicken and egg thing here? Does one do a generic PHA as part of the process design to identify the SIF’s, then do a HAZOP (trademark) on the final process including the SIS design? Fourth bullet: You seem to be implying that experienced engineers can do the required process design work, with SIS, before the formal HAZOP. This makes sense but I’m sure it will be a comment that will stimulate some discussion – if someone interrupts, agree with their point and say that we’ll discuss this as the first question in the Q&A period – we’ll have a better chance of staying on time.
  • Ed – Add examples

Best Practices in SIS Documentation Best Practices in SIS Documentation Presentation Transcript

  • 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
  • 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
  • Safety Requirements Specs
    • Specification s (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
  • 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