SRS and other reasons how functional safety projects can shine…

2017-12-15

Documenting Functional Safety of Instrumented Systems

Farshad Nourai
NEXO: technology, risk, performance

We sat with a delegation of client engineers the whole last week in Dubai reviewing, assessing or verifying their HIPPS system design and functional safety documentation, i.e., SRS, functional safety plan, verification plan, configuration management procedure, etc. The meeting went very well and the documents were in very good shape.

Our partner Risknowlogy and us have successfully completed 5 functional safety verification and certification projects in Iran in the past two years, all of which included preparation of documents like SRS and others mentioned above. Needless to say, every project is unique and poses its own challenges; And lessons.

‘’Documents are only useful when they are realistic, objective and integrated’’

So, I was trying to generalize on the magic formula of success in such projects… !

In fact, beyond the technical content of our last week meetings, I was trying to see the big picture and extract the anatomy of efficient project documentation from the functional safety management point of view in order to best support the practical side of the project (or, are they separate worlds at all?). Here they are, in my opinion:

1. Documentation shall be a REALISTIC depiction of a project if it is going to support you. Key terms here are: ‘Timely’ (documents are to be prepared according to project milestones to be useful in subsequent stages, too), ‘Accurate’ (there is no point in only capturing the overall picture; go into useful, relevant details), ‘Specific’ (each project is different: different clients, different wish lists, different environments and therefore, different requirements), and ‘Compliant’ (IEC gives a list of requirements that shall be patiently followed in documents and not all of them are technical, a large part of it is about managing the project: Your Project –address them one at a time).

2. Documents shall be OBJECTIVE: take the example of an SRS, why do we write it after all? Is it only because IEC 61511 wants us to? Documents shall be objective because (a) with a clear objective, writing a document becomes a lot easier, and (b) objective documents become a useful tool to guide you rather than a useless extra task that you just have to complete. As another example, consider a FAT procedure. The objective of a FAT Procedure is to document the tests to perform on the SIS in the workshop. You need to think about the fact that a test shall resemble a real world condition as far as possible, right? So, you have to simulate the process variable, or need to stimulate the software blocks. How do you do that? Simply write it down for each test and you are done. The reward is that a well-thought-of FAT Procedure minimizes surprises at the time of the real FAT and speeds up your tasks.

3. Documents shall be INTEGRATED (you have to address and document interfaces between tasks, subsystems, requirements, specifications, etc., and the dynamic of the project. Therefore, you have to check various documents back and forth and through comparison).

So, what is good about it all? The bottom line is that if you prepare your documents like that, you will make sure you have addressed all the important factors affecting your project. So, it means you have improved the quality management of the project, hence its results, as well as your knowledge and experience. Further, there are very good chances you can identify areas where you have missing information, or data. Sometimes you realize you have to coordinate some items with other parties involved, like your client, and that saves you time and money by avoiding delays, rework, liabilities, etc.

Documents are important, because they are tools that can protect you against project risks. Take charge of preparing them well!