JAN-FEB 2018

Issue link:

Contents of this Issue


Page 24 of 53

SYSTEM INTEGRATION INTECH JANUARY/FEBRUARY 2018 25 squabbles. They also bring experience from dozens of projects—more than the range of experience possible for some - one working for one company or plant. n ABOUT THE AUTHORS Lee Swindler, PMP, is a program manager at MAVERICK Technologies and has 30 years of automation industry experience. He is a TÜV Certified Functional Safety Engineer. Ron Carlton, a consultant for MAVER- ICK Technologies with 30 years of petro- chemical industry experience, is respon- sible for work processes and philosophy development in alarm management. Rick Slaugenhaupt (richard.slaugen-, a consultant for MAVERICK Technologies, has more than 34 years of industrial controls experience. View the online version at RESOURCES "From managing to optimizing alarms" "A standard grows up: The evolution of ISA's standard on alarm management (ISA-18.2)" "ISA alarm management standard packs a punch" "When Good Alarms Go Bad" "Get a life (cycle)! Connecting Alarm Management and Safety Instrumented Systems" Instrumented-Systems "Alarm Management and ISA18 – A Journey, not a Destination" Safety Alarms: At the Intersection of IEC 61511 and ISA-18.2 Workshop Texas A&M 69th Instrumentation Symposium for the Process Industries G ood documentation practices facili- tate the management of projects as they progress from initial specifications to final system implementation. Good documentation is critical; often differ - ent aspects of a project are handled at different times and by different resource groups. The potential for missed, forgot - ten, or misinterpreted verbal communi- cation is great. In all the documents discussed, it is important to note the ra tionale for the decisions. Many deci- sions are compromises, and it is impor- tant to capture their justification. Selected documentation topics relevant to this article include functional require - ments (FRs), system design, formal change control, alarm philosophy/rationalization, and system testing/commissioning. Functional requirements: A validated system requires FRs documentation, and it is a best practice for all systems. This document is the complete list of proj - ect, system, infrastructure, and product requirements from the various project stakeholders. It is used to help select system vendors and in driving system design and testing. System design: The design part of a project is driven by functional require - ments and must be documented. It usu- ally includes a multitude of documents, all the way down to detailed piping and instrumentation drawings. Design shows, for example, whether a separate SIS is in - cluded, LOPA information, interfaces with other plant computers, and where alarms will be generated. Formal change control: Almost all ma jor plant projects experience signifi - cant changes as the project progresses (e.g., a failure modes and effects analysis often results in significant plant or system redesign to reduce unacceptable risks from the original design). It is important for an organization to have a manage- ment of change procedure to drive activi- ties associated with, for example, plant design changes, including the require- ment to update relevant documentation. This enables late project activities, such as alarm rationalization, to draw on "up- to- date" design and other documents in de termining what alarms to implement and what their attributes should be. Alarm philosophy/rationalization: The requirements of alarm management are described in the national standard ANSI/ ISA-18.2. This includes the need for an alarm philosophy document—which, in turn, describes the requirements for the various alarm management life-cycle ac- tivities, including rationalization. Alarm rationalization can be a daunting task with several attributes needing specifica- tion for sometimes many thousands of plant alarms. Many of these attribute val- ues can best be determined with the help of documents from previously completed project activities, such as functional speci- fications, system design, and documenta- tion generated as part of change control. System testing/commissioning: Testing is largely driven by functional require- ments (i.e., the primary purpose of testing is to show that FRs have been met). Test- ing includes verification that alarms work as intended, which requires that alarms are implemented in accordance with the results of alarm rationalization, which, in turn, depends on the results of previ- ous project activities. For example, ANSI/ ISA-18.2 notes that plants can designate some classes of alarms as "highly man - aged," because they have special admin - istrative (e.g., reporting) requirements. Any alarms designated as "highly man - aged" will typically be determined from documentation of previously completed project activities like HAZOP reviews. Good documentation practices By Joe Alford, InTech Editorial Advisory Board Member

Articles in this issue

Links on this page

Archives of this issue

view archives of InTech - JAN-FEB 2018