159 / 1143
Paper 2: Why embrace the concept of the Safety Requirements Specification?
Institute of Measurement and Control – Functional Safety 2016
7
One point must be accepted. Whilst some SRS content might be referenced to
other documentation, the SRS itself is an additional document. Making any
attempt to consolidate the SRS into a list of existing design documents and
specifications entirely misses the point. The standard requests that the SIS
requirements should be expressed and structured in such a way that they are:
- clear, precise, verifiable, maintainable and feasible; and
- written to aid comprehension by those who are likely to utilize the
information at any phase of the life cycle
The paradigm shift
There are two changes which together could lead to a new approach and new
appreciation of the benefits that an SRS can deliver. First is
ownership
. If the
design and integration of an SIS can be completed without an SRS, then it is
unlikely it will get the required focus or deliver the benefits required. As the duty
holder is the major beneficiary of the document, then it is logical that the duty
holder take ownership in stating expectations, controlling content and
managing the evolution of the SRS from the earliest stages of the project. Let’s
not forget, it is an expectation of Functional Safety Planning. Second is
identity
. If you walk round the average process unit, it is virtually impossible to
determine which devices are safety-related and which are not. Good
engineering practice requires us to impose strict controls on our safety assets
and ensure they are secure against any unauthorised intervention. This is
referred to as Configuration Management in IEC61511. With an increasing
emphasis placed on the threats possible due to poor cyber security, the SRS is
an opportunity not only to specify the functional safety requirement but also
how other objectives like system security, access control, configuration
management and control of specific reference documents. The SRS is unique
to SIS and can contain the requirements which will lead it to being identifiable,
manageable and secure.
Define SIS expectations
The SRS is an exercise in consolidation of information contained in many
documents as well as in the heads of those responsible for designing and
specifying what will become the SIS. The analysis phase of a new project or a
replacement system is a complex combination of process design and hazard
and risk assessment in parallel with the definition of the entire automation
solution. IEC 61511 expects the entire life cycle to have a functional safety
plan. Planning for the SRS will help you consider how to get the most out of this
activity. Defining roles and responsibilities is necessary to ensure that the
activity is completed as you wish with the right people involved. The SRS
requires an owner but also team input as a single individual cannot have all of
the skills and knowledge to produce a complete concise and usable SRS. In
our experience finding an individual with overall responsibility for the SRS from
within the project can result in a document biased by the needs of their day-to-
day responsibilities. In addition, this lack of independence may result in key
questions not being asked as people rarely question their previous decisions,
assumptions or opinions. The option of an independent person with broad
experience is worth considering. The actual content and format of your SRS is
flexible but to meet the objectives stated above it should focus on safety-related