Last Friday I highlighted thoughts from Emerson process safety expert, Len Laskowski in the post, Executing IEC 61511 Process Safety Projects. He shared more than I could fit in a single post, so today’s post will share the balance.
One of the points made by the authors of the article, IEC 61511 Implementation – The Execution Challenge, was:
The information required to fully define and document a SIF may entail 40 or more unique data items. The source and detail required to document each item must be defined clearly. The effort to gather, track and review this data can be significant. For a large project, the work includes migrating and recording large amounts of data that may be provided in different formats, at different times and by different disciplines and organizations, so some companies develop in-house SRS database tools to improve productivity, reduce errors and track SIF development and approval status.
Len agreed with the challenge of managing this amount of data items required for many safety instrumented functions (SIFs). The cause-and-effect matrices may provide 25 to 30 data items. Other decisions about test frequencies and coverage factors lead to additional data items. Given this large volume of data per SIF, having a database to manage the development and approval status is critical. The authors ask:
A common scope question is what are the project requirements for documenting protective instrumented functions (PIF) that are not required by the LOPA [layer of protection analysis]/PHA [process hazard analysis]. Are PIFs documented in the SRS? Do the SIF analysis and verification steps apply to PIFs? Will the SRS differentiate between SIFs and PIFs?
Len cautioned against using tools such as Intergraph’s SmartPlant Instrumentation (INtools) that manage your basic process control system (BPCS) I/O as the place to manage your process safety management (PSM) database. A typical plant may have 3000 I/O under control by the BPCS and 300 I/O under control of the safety instrumented system (SIS). Local, state, and federal regulations require a well-documented management of change process for any process safety-related changes.
Mixing your BPCS I/O into this change process is asking for trouble. Process manufacturers need the flexibility to make changes to the BPCS to operate and optimize their processes in an efficient manner. Programs such as INtools may be okay for developing initial I/O lists, making instrument specs, and other parts of the design process, but not for long-term documentation and management of change.
Instead, Len recommended a simple spreadsheet for the SIS I/O, which is much easier to control and requires no special training. It contains the SIS database settings, cause and effect matrix settings including engineering units, pre-trip, and trip levels. Often the control of this PSM database is by a different group within the plant than the group that manages the BPCS.
Len’s closing thoughts for process manufacturer’s new to the IEC 61511 process is to focus on the critical shutdown streams in their process. In most processes, there are a few really important streams to close down to take the process to a safe state. The rest are secondary effects to the key streams. Once the key streams are designed and approved, the rest can be done. This often helps to simplify the safety requirements specification (SRS) and make the ongoing support through the safety lifecycle more manageable.
Having strong, experienced technical leaders on the front-end help minimize problems as the process safety project progresses. Although this front-end work may seem time consuming and expensive, Len shared the old safety saying, “If you think safety is expensive, try an accident!”