The key to delivering safety

When it comes to any hazardous process, safety instrumented systems (SIS) are a key tool by which a company can seek to lessen the risks that can lead to personnel injury, damage to equipment or the environment, as well as disrupt or even halt production. Such incidents can cause untold damage to the financial health or reputation of a company.

A key document at the heart of implementing safety driven systems is the Safety Requirement Specification (SRS) as it provides a foundation on which to base and build all aspects of the safety protection levels in the system.

When it comes to implementing an SIS, the SRS is a central element in the IEC 61511 safety lifecycle. It captures all of the safety requirements from the analysis phase of the lifecycle, forms the basis for the realisation phase and is the key document against which the validation of the SIS is performed. Therefore, it seems inconceivable for the SRS to be incomplete or missing in SIS projects. However, this is all too often the case on projects where safety is a critical aspect.

A complex system

One of the many challenges faced when complying with the requirements of functional safety standards (such as IEC 61511) is the organisational complexity of a typical project. The concept of the safety lifecycle is relatively straightforward, but it involves activities which often span multiple organisations – each with their own approach to functional safety management.

Stakeholders on a typical project may include the end customer, engineering contractor, DCS hardware vendor and ESD system vendor and, potentially, separate systems integrators. Allocating activities, capturing requirements and integrating functional safety management systems across such potentially complex structural relationships can be challenging.

By taking a joined up approach to both control and safety, it is possible to simplify a little by streamlining the interface between engineering of regulatory control and safety. However, there is still much ambiguity over particular roles and responsibilities.

Roles and responsibilities

At the top level, the question of ‘who does what?’ can be addressed by the creation of, and adherence to, a project safety plan. Annex C of the EEMUA 222 guide to the application of IEC 61511 gives an example of a project safety plan, in which all the overall safety lifecycle activities are identified with responsibilities and target dates clearly assigned.

There are three key phases in the safety lifecycle approach – analysis, realisation and operation. In the analysis phase, it is decided how much additional risk reduction is required. Process hazards are identified, along with their initiating causes, and they are quantified in terms of likelihood and consequence. Existing layers of protection are taken into account and requirements for additional safety instrumented functions (SIFs) are determined. The risk reduction requirement for each SIF is specified by assigning a safety integrity level (SIL). These SIL classification activities often involve many techniques and their various outputs need to be documented. The SRS is the key document for capturing all information relating to the SIF requirements.

It is the role of the integrator to then take the SRS, produce the detailed equipment specification, engineer both project hardware and application software, and build and test the required SIS against the SRS requirements.

On occasions, the step by step approach advocated in the IEC 61511 standard is not mirrored in reality and the realisation phase can commence before the SRS has been finalised. This can have a negative impact on the project with the SIS designers potentially over engineering safety functions to compensate for ambiguity in the requirements and the possibility of increases in SIL when the SRS is finally frozen.

Other pitfalls arise when instead of being a separate stand alone document, the basis for the SRS is merged with other system requirements in a user requirement specification and/or functional design specification. Whilst it is certainly possible to merge the SRS requirements into other functional requirements, this can also lead to a lack of clarity regarding safety functions, which is clearly undesirable.

Worse still is the case where there is no SRS. The consequences of such a scenario are apparent when considering the example of the replacement of an obsolete system. The original system was most likely documented in a ‘cause and effect’ diagram and it may be that this is seen by some organisations as sufficient to form the basis of design for a replacement system. Whilst the cause and effect may well document the logic associated with the relevant SIFs, the first challenge is that the C&E diagram will almost certainly contain extraneous information from a functional safety perspective, and so identifying the actual SIF is not always straightforward.

Conclusion

By having a SRS produced as the output to the analysis phase, a sound basis for SIF design, SIL verification and ultimately SIS validation is available. By generating the SRS in a timely fashion during the analysis phase and before the commencement of engineering and detailed SIS design, it will help ensure that there is a clear dividing line between safety functions and regulatory control and that SIFs are engineered appropriately to meet clearly defined requirements.

It is clear that the safety plan and the SRS are key documents in executing a project in accordance with IEC 61511. It defines each safety function and provides the basis for design and validation of the safety instrumented system. It also captures the requirements for ongoing testing of the system.

The SRS plays a vital role in ensuring the safety of the plant during installation and is also a key resource for ongoing maintenance and change management issues. Its critical importance should not be overlooked.