A useful tool for safety systems implementation
14 September 2010
A key document at the heart of implementing safety-driven systems is the Safety Requirement Specification, or SRS. This provides a sound foundation on which to base and build all aspects of the safety protection levels in any given system. For this week’s newsletter leader, I have invited Ian Curtis from Siemens Industry Automation to describe how the SRS can be an essential step in helping to satisfy international safety standards such as IEC 61511 - and to spell out the consequences for plant and machine operators should the SRS be incomplete or even missing from safety-related project work.
When it comes to implementing Safety Instrumented Systems (SIS) the safety Requirement Specification (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. 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 deemed critical.
Complying with the requirements of functional safety standards (such as IEC 61511) poses a number of challenges, not least being the sheer organisational complexity of a typical project. The concept of the safety lifecycle is relatively straightforward, but it involves activities that 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 - with maybe also an external safety consultant. Allocating activities, capturing requirements and integrating functional safety management systems across such potentially complex structural relationships can be a daunting task, especially for those organisations with limited experience of working with the IEC 61511 standard. By taking a joined-up approach to both control and safety, it is possible to simplify things a little by streamlining the interface between the engineering of regulatory control and safety, but there is still much ambiguity over particular roles and responsibilities.
At the top-most 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 (HAZOP, LOPA, Risk Graph, et al) and their various outputs need to be documented. The SRS is the key document for capturing all information relating to the SIF requirements. IEC61511-1 Clause 10.3 helpfully pinpoints the information that is required to be included in the SRS as the basis for overall safety instrumented system design.
It is the role of the integrator to then take the SRS, produce the detailed equipment specification (functional design specification), engineer both project hardware and application software, and build and test the required SIS against the SRS requirements.
On occasion, 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 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. A lack of clarity regarding SIS requirements can also impact safety by blurring what should be a clear separation between control and safety.
Other pitfalls arise when, instead of being a separate standalone 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. Functional separation is one of the tools used to help achieve safety integrity and it makes sense to apply it to documentation. The SRS needs to be a separate, readily identifiable document.
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’ (C&E) 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 C&E diagram may well document the logic associated with the relevant SIFs, the first challenge is that it will almost certainly contain extraneous information from a functional safety perspective and so identifying the actual SIF is not always straightforward.
In addition, there is much more to a safety instrumented function than just the logic and a SIL; for example, details regarding proof testing and process safety time. A system integrator may be put in the invidious position of having either to insist on a SRS from the client, or working with the client to explain the need, and help them to develop an acceptable SRS with which to work. This is not an ideal situation and increases the potential for cost overrun and impact on delivery time if this activity was not originally planned for.
With SRS produced as the output to the analysis phase as a sound basis for SIF design, SIL verification and ultimately SIS validation is available. These are all key factors in demonstrating compliance with the IEC 61511 international safety standard by which companies seek to demonstrate they are achieving best practise in functional safety and, ultimately, meeting their obligations in law.
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; all of which helps to improve safety and help reduce cost.
In conclusion, it is clear that the Safety plan and the SRS are key documents to executing a project in accordance with IEC 61511. The project safety plan defines roles and responsibilities for each lifecycle activity and helps ensure nothing gets overlooked. The SRS defines each safety function and provides the basis for design and validation of the SIS. It also captures the requirements for subsequent system testing.
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.
My thanks to Ian for this explanation. If you are charged with responsibilities for ensuring system safety and wish to learn more about the SRS and its role in safety system design and validation visit www.siemens.co.uk/automation
Les Hunt
Editor
Contact Details and Archive...