155 / 1145
Paper 2: Why embrace the concept of the Safety Requirements Specification?
Institute of Measurement and Control – Functional Safety 2016
3
Automation design.
Overlapping the process design the overall automation system is
developed. In order for each element of the automation solution to be procured, each
must have an individual specification to capture all requirements. For the SIS, each
element including field equipment and control room equipment will have its own
specification. The logic solver being described by its physical requirements,
connectivity, capacity and configuration normally based on cause and effect diagrams.
From now we are dealing with devices rather than SIFs and a SIS. Individual
specifications are unlikely to be questioned.
System integration and test.
Each manufacturer follows the requested specification.
For more complex elements such as the logic solver the specification is often
developed with the automation designer in order to clarify specific elements of the
configuration. Decisions are made outside of the multi‐disciplined team who specified
the solution. Systems are tested with varying levels of component integration and
normally against the latest revision of design documentation.
Site integration
. The bringing together of all elements of the automation system on‐
site including installation, commissioning and testing is often chaotic with many
different disciplines working in parallel. Due to the nature of this activity a detailed
plan is difficult to prepare and can be even more difficult to stick to give the
constantly changing situation and resources.
Operate and maintain.
As operating experiences gained procedures carried out by
individuals often evolve and are not necessarily reflected back into the
documentation. Maintenance and proof testing practices vary considerably in their
degree of rigour and the recording of activities and results.
Modify and enhance.
Over time numerous changes will be made. These may either be
minor changes with no assumed impact or major enhancements. In each case the
original design intent may not be clear to those assessing the risk of the change as
knowledge of the original design becomes more distant and people move on.
Individuals may have wider responsibilities and may call on third parties expecting
them to have the knowledge required.
During all the above phases it is possible that commercial goals may come into
conflict with the number one priority of safety. Individuals and functions work
under time pressure and productivity is measured in various ways. Between
each phase and within each phase are interfaces between individuals and
disciplines. Each interface is also a source of error. Like the Chinese whisper,
errors can be compounded giving a believable but erroneous result. Our
industry is full of talented engineers and technicians but often their reaction to
the concept of personal or collective failure ranges from denial to fingers
pointed elsewhere. A well written SRS encourages the contributors and
consumers to have a wider understanding of exactly why each part of an SIS is
designed as it is. Knowledge outside the boundaries of an individual’s discipline
will lessen the potential for unnoticed error at interfaces.
The Safety Lifecycle. Controlling systematic error
In most industrialised Countries, the IEC 61511 standard is recognised as
defining good engineering practice for the implementation of Safety
Instrumented Systems. IEC 61511 sets out a number of key concepts, one of