Functional Safety Management
An important part of management is planning ahead. This is not just important for meeting deadlines, but also ensuring the correct resources are in place and that the required activities will actually happen in practice.
Many companies extract a copy of the safety life-cycle directly from IEC 61511 and list that as their chosen life-cycle for a project. This is a flawed approach as it does not have the required level of detail for real-life projects.
Just copying the IEC 61511 life-cycle from the standard is an over-simplified and flawed approach to planning
A central element of the SIS safety life-cycle is a functional safety management (FSM) system. A good FSM system will ensure that each person responsible for completing and signing off functional safety activities is competent in the part of the lifecycle they are responsible for. It will provide effective policies, planning and procedures to control lifecycle activities.
IEC 61511 edition 2 now requires competence of individuals to be actively managed in a competence management system (CMS). The CMS for functional safety may be just a part of overall competence management, and need not be separated. The CMS should set the competence standard for each safety lifecycle role. It should include the role context, tasks, and attributes that the ideal candidate must fulfill to deliver what is required. The levels of required attainment for each task and attribute should be clearly specified. A competent assessor should be assigned to verify the individual against the required standard in each role.
People are critical to the achievement of functional safety. It is highly recommended to develop or hire a functional safety technical leader with the requisite experience, knowledge and qualifications. Once this is in place, the FS leader and relevant discipline experts can assess the competence of others for different lifecycle steps.
Companies responsible for delivering services and products also require competence assessment and management. Achieving this for every phase of the life-cycle and all potential suppliers of good and service is not trivial. To recognise the difficulty around external supplier competence, suppliers are required to have their own quality management system . If a supplier make any functional safety claims (e.g. a claimed SIL capability for a product) then they are additionally required to have a functional safety management system in place (IEC 61511-1 clause 220.127.116.11).
Functional safety assessment
See the chapter on conformance.
Functional safety audit
See the chapter on conformance.
Document and configuration management
Documentation is a key aspect of the functional safety standards. Some have even said that "if it isn't documented, then it didn't happen". This is certainly very true when it comes to functional safety assessment and audit. Without good documentation, there is very little an assessor or auditor can do except conclude non-compliance.
The need for SIS documentation has now been made normative in IEC 61511 edition 2. It is now a shall, not should requirement to describe the installation, have it accurate and up to date, easy to understand and fit for purpose. In addition to these requirements, all SIS documentation must show traceability back to the hazard and risk analysis phase. This means demonstrating a clear link from each SIF in an SIS back to each hazard, other protection layers, and the risk gap each SIF is designed to fill.
There are some very simple, yet effective, things that can be done to manage documentation:
- Use a document management system, or better still, a dedicated safety life-cycle database.
- Ensure all documents have a unique reference and date, a table of contents, numbering and a traceable revision history.
- When changes are made to any document, include the reason for the change in the document history and make sure a new revision is issued.
- Ensure each document is reviewed by someone competent (independent of the document author) and includes a sign-off by an authorised signatory.
These things sound very simple, but it is surprising how many organisations fall short of some of these simple to implement aspects.
By the very nature of having different suppliers and system elements, all Safety Instrumented Systems have a unique configuration of hardware and often include firmware and software. IEC 61511 requires every piece of the SIS to be uniquely identified. There are several reasons for this, including knowing when any required replacement is an exact like-for-like, controlling restore of any software or settings that are lost, as well as providing traceability for failures during the system lifetime.
When looking at a typical programmable SIS, the following parts will need careful registration in the configuration management environment:
- Non-intelligent sensors: model, serial number;
- Intelligent sensors: model, serial number, firmware version, configuration settings;
- Logic solver input modules: model, serial number and firmware version;
- Logic solver controllers / CPU's : model, serial number, firmware version, application program version, CRC (or other unique software identifier);
- Logic solver output modules: model, serial number and firmware version;
- Non-intelligent final elements: model, serial number;
- Intelligent final elements: model, serial number, firmware version, configuration settings;
- Utility tools: intelligent sensor or final element configuration tools;
- Utility software: SIS logic solver configuration tool, compiler, HMI software and HMI application version.
Many organisations outsource things like application programming to others, so managing the safe backup and storage of software is something that needs careful control.