Many companies today are striving for sustainable safe manufacturing. The challenge to successfully achieving this goal is to understand how to optimize profitability while still fully meeting process safety management (PSM) obligations — i.e., preventing and controlling incidents with the potential to release hazardous materials or energy that could harm people, property and the environment. As part of the broader PSM task, an organization must identify necessary protective layers and implement functional safety (FS) lifecycle management.
Dedicated automation systems serve as an important protective layer in a process operation. Processing visibility provided by integrated control and safety automation underpins successful delivery of both FS and business sustainability.
Managing FS is an increasingly complex challenge and involves specifying safety requirements and then ensuring those requirements are successfully incorporated into design and engineering solutions from your supply chain partners.
Defining what is required to deliver an optimized safety instrumented system (SIS) within process industry projects, whether new builds, major upgrades or expansions, can be incredibly complicated. Therefore, the asset owner or engineering-procurement-construction (EPC) company must ask three essential questions:
1. Do we spend enough time and effort on our systems to ensure FS requirements are correctly specified and documented?
2. Do we have competent people assigned and available over the entire supply chain to undertake and deliver these requirements?
3. Can we demonstrate compliance against industry good-practice expectations?
If a safety system is over-specified, it is likely to cost more upfront and, because of the extra complexity, will require more attention and maintenance once commissioned. Over-specification pushes up running costs over the lifetime of the plant. However, under-specification can pose much more serious consequences because the safety system may well be inadequate and unable to provide the correct level of risk reduction — potentially resulting in a failure on demand.
Safety Requirements Specification
The second edition of the IEC 61508 functional safety standard  gives higher priority to defining a suitable, dedicated safety requirements specification (SRS) for each project. It introduces a formal phase (Phase 9) between the conclusion of the hazard analysis stage of a project and specifying particular SIS requirements leading into the design and engineering phase. The same focus on requirements specification also appears within the recently revised and enhanced process-industries-sector standard IEC 61511  — in particular, the 29 pieces of minimum information as identified within Clause 10.3.
Ultimately, the SRS is intended to bring together all the information necessary to ensure the required SIS provides the right level of performance and risk reduction without being overly complex or expensive.
During a typical project front-end-engineering-design study, the outline SIS requirements are based on a preliminary automation philosophy document. This usually is confirmed in principle before any detailed hazardous scenario is defined, risk assessed and an eventual target safety integrity level (SIL) established. This also is even prior to considering the functionality aspects needed to successfully design, engineer, operate and maintain an SIS.
At this stage in the project, work on the safety requirements typically begins, as do discussions with possible supply chain partners. Decisions are made early in the process regarding SIS requirements. They are not usually based on a full technical clarification process, i.e., one that focuses on the potential hazards that may be present at the site and details needed to provide adequate risk reduction. Therefore, it is impossible to confirm in any great detail whether the selected technology requirements exhibit the necessary safety integrity and safety functions. Nevertheless, the specific technology chosen usually centers around the need for one or more SIL-rated-capable logic solvers.
For larger projects, the SIS usually forms a very small part of the broader automation scope of supply in terms of the cost and resources applied to a typical new-build project. However, what often is missed completely at this stage of the decision-making process is the modest effort that the responsible process engineering and instrumentation teams can and should apply to get the SIS correct. The resultant lack of robustness frequently develops into an SRS seeded with too many assumptions and potential gaps that the automation partner is expected to bridge during the future detailed design and engineering lifecycle phases.
An owner/operator should always remember the SIS usually is the last line of defense against the occurrence of an incident.
Consider this analogy: Do you actually have a robust, well-built steel bridge to your functional design and engineering requirements? Or, in reality, is it a wobbly rope bridge missing many foot planks, potentially leading to an incident when put into use?