Ed Marszal, president of global consulting and engineering firm, Kenexis, shared his expertise in safety instrumented systems and projects in an Emerson Exchange presentation, Best Practices in SIS Documentation. Emerson’s Desmond Lee, a member of the process safety systems team for the Asia-Pacific region, was kind enough to send me his notes from Ed’s presentation as background for this post.
Ed noted that poor documentation is often generated due to a “safety case” mentality. What he means by this is that the safety requirements specification (SRS) will often be a compilation of all of the supporting information that is used to form the basis for the specifications, including the process information, hazard information, hazard frequencies, and hazard consequences. It is not necessary to document the HAZOP and process design in the SRS. Instead, the SRS should be based on this information, but provide the key functional and integrity requirements for each safety instrumented function (SIF).
Ed pointed out that current practices ignore the audience of documents and “good practices” for specifications in general. It’s important to understand the audience and to follow good document management practices when developing the SRS and other SIS documentation. As an integral part of a good safety management system, information should be limited to what is required for the relevant safety roles to perform their planned activities.
Safety requirement specifications are more than a single document. They are a collection of specifications for each SIF and the documents should be limited to include only what’s required to properly implement the SIF. A problem arises when engineers attempt to list all of the requirements per the IEC 61511 global safety standard, clause by clause, separately for each SIF. A good SRS should not repeat the same requirement in different places. Anything that is generic should be written down once and then referenced. “General requirements” statements should be used for common features, such as bypassing requirements, and the SRS should reference other documents for any non-critical information. The SRS should not contain procedures and detailed designs, as these are separate documents that result from the design of the system.
Ed recommended that the SIFs be grouped together based on their functional relationships, typically based on major equipment such as compressors, heaters, reactors, separators, etc. Groupings include multiple SIFs and can contain non-SIF instrumentation and logic. The advantage of this grouping approach is to minimize duplication and keep the documentation more compact. 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% if you use groupings, minimizing duplication across SIFs.
From a safety logic development perspective, this helps avoid single instruments in multiple SIFs, facilitates design and I/O counting, and simplifies test plan development and testing. Ed shared an example of a high-pressure separator with SIFs associated with high levels, low levels, and high pressure. These SIFs appear in the high-pressure separator’s cause and effect matrix (CEM) and only here. Safety instrumented systems that provide CEM safety function blocks, such as DeltaV SIS, let the SIS programmer directly input these without reduction and reassembly with function block diagrams.
Following this path reduces preparation time, errors, ongoing maintenance, and other general document management considerations–all of which contribute to safer operations through reduced complexity. This provides a lower probability of systematic errors that result from poor documentation.
If you have a safety project in your future and want to get the SIS documentation as useful as possible for the intended recipients, take a look at this presentation along with other shared experiences in the safety category (RSS feed) of this blog.
Update: I’ve now embedded Ed’s presentation into the post and linked to its home in SlideShare.
