SIL Documentation should be realistic, objective and integrated
I am part of the certification team that has been responsible for the certification of HIPPS and other systems according to IEC 61511 during the past two years. Last month, we had a review meeting in Dubai with a delegation of client engineers for a whole week. The documentation subject to verification included among others the Safety Requirements Specification, functional safety plan, verification plan, configuration management procedure, etc. The meeting went very well and the documents were in very good shape.
Over the last two years Risknowlogy, our certification partner, and us have successfully completed various SIL verification and certification projects in Iran. All projects included the preparation, verification and assessment of the above documents. Needless to say, every project is unique and poses its own challenges; And lessons.
Documentation lessons learned from HIPPS certification projects
Documentation plays such an important role in a SIL project that I want to share with you the lessons learned from the last five projects.
‘’Documents are only useful when they are realistic, objective and integrated’’
I was trying to generalize on the magic formula of success in SIL projects… ! In fact, beyond the technical content of our last month 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 after all?). Here they are, in my opinion:
First of all, documentation must be a realistic depiction of a project if you want the documents 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
Second of all, documents must be objective. Take the example of an SRS, why do we write it? Is it only because IEC 61511 wants us to? No, it is the technical basis for our SIS. All SIL related documents must be objective because
- with a clear objective, writing a document becomes a lot easier, and
- objective documents become a useful tool to guide you rather than a useless extra task that you just have to complete.
Consider the FAT procedure as another example. The objective of the FAT procedure is to document the tests to perform on the SIFs in the workshop that verify that the SIS is build according to the SRS. You need to think about the fact that a test must resemble a real world situation and thus be a useful situation, right? The FAT tests should simulate process variables, or need to stimulate (what do you mean?) the software blocks. How do you do that? Simply write it down for each test and you are done. For example, how do you simulate a function bypass or trigger a deviation to replicate the real situation of a maintenance override and process upset, respectively? The reward is that a well-thought-of FAT Procedure minimizes surprises at the time of the real FAT and speeds up your tasks.
Last but not least, documents must be integrated. You have to address and document interfaces between tasks, subsystems, requirements, specifications, etc., and the dynamic of the project. Therefore, documents cannot be standalone pieces of information. You have to check various documents back and forth and through comparison.
So, what is good about realistic, objective and integrated documents? The bottom line is that if you prepare your documents like that, you make sure you have addressed all the important factors affecting your project. It improves the quality 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 and not just for the record!
Contact Us
Are you interested in SIL certification of HIPPS systems, or do you want to know more about the documentation involved then feel free to contact us.
