functional safety handbook

Functionalsafety handbook

©A

BB

Lim

ited

2008

Functional safety handbook - v10 11/6/08 3:29 pm

2

CONTENTS

1.0 Introduction Page 3

2.0 Background Page 4

3.0 Putting the basics in place Page 6

4.0 Defining the boundaries Page 8

5.0 Specifying competency requirements Page 11

6.0 Benchmarking current practice Page 13

7.0 Selecting the certification body Page 14

8.0 Developing the safety lifecycle model and Page 15functional safety management system

9.0 Executing the certification process 6

10.0 Training courses Page 28

11.0 Establishing Supporting activities Page 29

12.0 Managing channel partners and third-party integrators Page 29

13.0 Final Comments and Conclusions Page 30

Appendices Page 31-33

References Page 34

About the author Page 35

For more information, contact Stuart Nunns, UK Safety Lead Competency Centre [email protected]

Functional safety handbook - v10 11/6/08 3:29 pm Page 2

3

The demands of the safety critical systemsmarket are becoming ever more exacting, withinternational standards being increasingly usedto demonstrate compliance with legalrequirements and the increasing need to justifythat the required functional safety has beenachieved. This is not surprising given theincreasing dependence on such systems toachieve the specified tolerable risk targets. Withincreasing contractual rigour and the potentialfor litigation should something go wrong,organizations need to demonstrate that their functional safety capability is seen as best in class.

Of particular importance in this context is theeffectiveness of the competence managementarrangements to ensure that those within theorganization having responsibility for functionalsafety are competent to undertake those duties.In order to meet these increasing demands,safety suppliers and integrators are increasingly

embarking on more formalized regimes,including certification programmes, to ensure their safety applications are implemented in accordance with IEC61508 [1]and IEC61511 [2].

The author has worked with a number oforganizations seeking certification. ThisFunctional Safety Handbook provides a casestudy illustrating how a major automationsystem supplier (the organization), with worldwide systems integration businesses (theintegrators) undertook the challenge to achievethird-party accredited certification for itsfunctional safety management system (FSMS)against the requirements of IEC 61508 and IEC 61511.

The generic methodology described andcomprising the procedures and processes toachieve certification have been developed byABB Ltd.

1.0 INTRODUCTION


4

2.0 BACKGROUND

Statistics relating to the performance of largeorganizations are published internationally andincidents, especially those causing injury ordeath, make headline news. Recent inquiriesinto major incidents provide further support ofthe increasing importance of internationalstandards (IEC 61508 and IEC 61511) wheresuch standards have been used as abenchmark of what constitutes acceptablegood practice [3] [4]. Many managementincentives are based on the safety performanceof their operation. In order to compete or evensurvive, industry continually strives to improveperformance and profitability while maintainingand improving safety. In today’s world there aresignificant costs on an organization if they arenot acting in a socially responsible manner.Such costs include direct financial costs arisingfrom the incident itself, from legal costs andfines in the event of being found guilty ofbreaking the law, damages paid to injuredparties caused by negligence and reputationdamage which can have far reachingimplications on the business. The result is thatsafety and profitability are inextricably linked.

In summary, there are strong regulatory andsocial demands for businesses to demonstratethey have exercised their duty of care byproviding a safe, reliable operation with fulldocumentation and decision traceability.

2.1 Safety technologies are changing rapidlyIn line with all control system technologies,safety systems are undergoing a revolution.Increasing reliance for process protection isbeing placed on networked ‘smart’ equipment,integrated control and safety solutions, reusablesafety components and subsystems withautomated configuration tools. The applicationof such technology has, potentially, significanteconomic and safety benefits, but to release itspotential, it is vital that such technology isapplied by the adoption of current goodpractice and this means the adoption ofrelevant standards such as IEC 61508 and IEC61511. These standards represent current good

practice and demand that attention be paid toall safety lifecycle activities within an effectivefunctional safety management system.

2.2 Safety standards are also changingThe publication of the international safetystandards IEC 61508 and IEC 61511 for theprocess sector are setting global benchmarksas “good practices” in functional safety. SafetyRegulators and the legal professions world wideare embracing these standards and using themto make judgements as to whether acceptedgood practice has been applied if negligence issuspected. Ignore them at your peril!

2.3 GlobalizationThe safety-related market is truly global andincreasingly based on international standards.Although companies throughout the supplychain are establishing the capability to ensurecompliance with the relevant internationalstandards there are currently differences in theway IEC 61508 and IEC 61511 are beingimplemented. These differences lead to a lack of cohesion in the supply chain andincrease the likelihood of contractual andproject disruption. The interface between thesupply chain and the end user organization cansometimes be less than ideal as end userorganizations have been subjected to right-sizing, downsizing, restructuring and changes of ownership which makes it a challenge forthem to retain core competencies in anenvironment of rapid change.

2.4 Organizational and personalcompetenceProven competence at a company, departmentand individual level is increasingly seen asnecessary to meet contractual and regulatoryrequirements. But which competency scheme ismost appropriate and who should it apply to?

2.5 What do the standards say aboutcompetency and functional safety?The following clauses relate to IEC 61508 and IEC 61511 in respect of the “Managementof functional safety”. In the case study, the


5

organization had to develop a functional safety management system (FSMS), centrally, in compliance with these clauses as anessential pre-requisite to achieving accredited certification.

The relevant clauses in these standards are:1. IEC 61508 – Part 1 – clause 6.2.1 states

“Those organizations or individuals that haveoverall responsibility for one or more phasesof the overall E/E/PES or software safetylifecycle shall, in respect of those phases forwhich they have overall responsibility, specifyall management and technical activities thatare necessary to ensure that the E/E/PESsafety-related systems achieve and maintainthe required functional safety”.

2. IEC 61511 – Part 1 – clause 5.2.2.2 states“Persons, departments or organizationsinvolved in safety life-cycle activities shall becompetent to carry out the activities for whichthey are accountable”

Striving to achieve recognition for organizationaland individual functional safety capabilities hadto be seen as both a positive and essentialrequirement for the business as a whole. Also,in the light of many inaccurate and disputedclaims (so-called ‘claims to fame’) relating tocompliance of safety-related products in themarketplace it was necessary for theorganization to establish an objective andirrefutable means of demonstrating complianceand competence. The organization could notafford to ignore the requirements IEC 61508and IEC 61511 standards and those of itscustomers who increasingly specify them as a functional safety benchmark and acontractual requirement.

The additional benefits to the business ofachieving certification included:• Limiting the company’s exposure to

potential liabilities• Demonstrating due diligence• Implementing repeatable and cost effective

safety management systems (procedures,techniques, tools etc)

• Reducing unnecessary and costly pre-contract discussions and evidence gathering(which actually benefits both the organizationand its clients)

• Winning work cost effectively • Limiting effort (and cost) in developing so-

called bespoke project safety procedures• Gaining a competitive advantage and as a

result securing more business


6

3.0 PUTTING THE BASICS IN PLACE

The ‘Strategic Competency Principles’ arebased on a multi-tiered approach todemonstrating functional safety capability, seeFigure 1 below. At the highest level theorganization had to demonstrate compliance togood practice by the adoption of internationalstandards IEC 61508 and IEC 61511. A keypart of this demonstration was the strategic aimof achieving third party accredited certification.An essential element of this was theorganization’s competence framework.

The second level relates to individualcompetence and the requirement to achieveexternal recognition of an individual’s functionalsafety capability. This recognition complementsthe organization’s competence framework. Atthe lowest level is the specific requirement to becompetent to implement and deliver a specificsafety product, package or service.

Figure 1

In the case study, the senior management ofthe organization responded to the strategicobjectives by establishing an internal CompanySafety Authority (CSA). The CSA was chargedwith the responsibility of ensuring that safetyapplications were implemented in accordancewith IEC61508 and IEC61511.

The CSA was tasked with developing a set ofcore principles for functional safety and aprogram of work to achieve accreditedcertification for the organization as a whole.These core principles endorsed by seniormanagement are collectively referred to as‘Strategic Competency Principles’. They defineminimum requirements designed to reflect acommon purpose, shared beliefs and valuesand a commitment to (functional) safety withinall the relevant businesses.


7

There are four strategic competency principles:a) Benchmark current practice

Undertake and document a ‘gapassessment’ of each of the organizationsintegrator companies’ functional safetymanagement system against IEC 61508 andIEC61511 to establish the scope of the task.(See section 6)

b) Implement safety standardsFollowing the ‘gap assessment’, specify andimplement a program of work to achieveaccredited certification for each of theorganization’s integrator companies’functional safety management systems.

Whilst the organization’s integratorcompanies are seeking accreditedcertification, they shall produce safety planscovering all their related safety activities.

c) Establish individual Competency The organization’s Safety Engineers shallprogress to certified functional safetyengineer status through the TUV RheinlandFunctional Safety Program.

The organization’s Lead Engineers andnominated Safety Engineers working on asafety project shall have attended all therelevant safety system training courses priorto working on a safety project

d) Manage Third Party Integrators and Channel PartnersAll Third Party companies invited to carry outsafety-related activities on behalf of theorganization’s integrator companies shall beassessed and approved by the CSA.

This assessment and approval shall beachieved through a gap assessment, project functional safety assessmentsundertaken by the CSA and project auditsundertaken by the integrator. All Third PartyIntegrators shall have in place a functionalsafety management system compliant withIEC 61508 and IEC 61511.

The key tenets of these Strategic CompetencyPrinciples are:

• To use Certified Products• To employ Competent (Certified) persons• To implement safety systems through the

certified organization


8

4.0 DEFINING THE BOUNDARIES

In the case study, prior to the gap assessment acore set of prerequisites had to be agreed forthe organization. These not only provided aclear understanding of the organization’s safety-related systems supply chain responsibilities butalso mapped the organization’s genericfunctional safety management system againstIEC 61508 Part 1 clause 6 and IEC 61511 Part1 clause 5 (Management of Functional Safety).

This core set of prerequisites are defined below: • The subsystem used for systems

implementation (logic solver and associated I/O modules) is third-partycertified in accordance with the requirements of IEC61508

• Safety integrity data (PFD, systematiccapability and hardware fault tolerance) exists for all devices

• Safety integrity data for the logic solver isclearly defined in the Safety Manual providedby the supplier of the logic solver

• Reliability data necessary for the integrator to perform their task is provided by supplychain manufacturers to the integrator and is readily available

• Hardware element design (e.g. Analog Inputmodule, Analog Output module) is notundertaken but hardware is configured intooverall hardware architecture by developmentof subsystems

• Software is Limited Variability Language (LVL).This is defined in IEC61131-3 [5] andincludes ladder diagram, functional blockdiagrams, sequential function chart andstructured text

• Libraries are available with certified orapproved function blocks

• Special (approved) configuration tools are available as part of the logic solver environment

• Development tool support confirms that thedownloaded run-time application software isidentical to the source application software

• Application software development isfacilitated by the use of existing function blocks

• Integration involves the downloading andcompilation of the configuration data andapplication software on the target platform

• Approved libraries and function blocks areprotected from unauthorized modification

• Hardware consists of SIS logic solver,cabinets with appropriate termination panelsfor connecting the process signal to the logicsolver I/O modules. Power supplies andpower distribution for the logic solver andfield devices are also normally included

• A certified application development packageis used to configure the SIS logic solver, I/Oand communication hardware

• Coding standards are available for each61131-3 language used, including anyspecific limitations or restrictions

• The development environment provides version and configurationmanagement facilities

• Process Hazard and Risk Assessment hasbeen performed to ensure systematicdevelopment of a Safety RequirementsSpecification and this has been provided as a key deliverable from the EndUser/Engineering Procurement andConstruction (EPC) organization

With respect to the last bullet point, there aresignificant variations in the quality and contents ofthe Safety Requirements Specification (SRS)within the industry. The fundamentalrequirements are for a clear specification of thesafety functions and target safety integrity foreach safety function. This information is critical tothe integrator, as it enables the integrator to notonly provide a detailed and constructive proposalto any bid document, but also, if successful, toengineer a solution which meets the safetyfunctions and target safety integrity required.

Guidance is provided in IEC 61508 Part 2clause 7.2.3 regarding the content of the SafetyRequirements Specification. This isstrengthened, for the process industry, in IEC61511 part 1 clause 10.3.1. In the absence ofan SRS at the bid and proposal phase, theintegrator established a set of processes to


9

facilitate a dialog with the client in order to complete, for the bid and proposal phasepurposes, the checklist in Table 1. However, this was not a substitute for the delivery of an adequate SRS by the client which would be necessary subsequent to the bid and proposal phase.

There are significant benefits to the partiesinvolved in needing the SRS (the party havingresponsibility for developing the SRS and theparty requiring the SRS in order to undertakethe integration process) engaging in a dialog atan early stage. Early dialog facilitates theconcept of partnership working and can be ofadvantage to both parties.

This core set of pre-requisites was also arequirement for defining the certificationscope and applied area of each integrators’certification. The certification scope covered:• IEC 61508 E/E/PE safety related System

Integration and IEC 61511 SIS Integration• Applicable phases – IEC 61508 Phase 9 &

IEC 61511 Phase 4• Specifically:

• Management of Functional Safety• Documentation• Functional Safety Assessments

Table 1 Requirements to be addressed

A description of all the safety instrumented functions necessary to achieve the required functional safety

Identification of requirements of common cause failures

Definition of the safe state of the process for each identified safety instrumented function

Definition of any individually occurring safe process states which, when occurring concurrently, create aseparate hazard (for example, overload of emergency storage, multiple relief to flare system)

Assumed sources of demand and demand rate on the safety instrumented function

Requirement for proof-test intervals

Response time requirements for the SIS to bring the process to a safe state

Safety integrity level and mode of operation (demand/continuous) for each safety instrumented function

Description of SIS process measurements and their trip points

Description of SIS process output actions and the criteria for successful operation, for example,requirements for tight shut-off valves

Functional relationship between process inputs and outputs, including logic, mathematical functions andany required permissives

Requirements for manual shutdown

Requirements relating to energize or de-energize to trip

Requirements for resetting the SIS after a shutdown

Maximum allowable spurious trip rate

Failure modes and desired response of the SIS (for example, alarms, automatic shutdown)

Any specific requirements related to the procedures for starting up and restarting the SIS

All interfaces between the SIS and any other system (including the BPCS and operators)


10

4.0 DEFINING THE BOUNDARIES

At the outset of the certification program it wasnecessary to analyze the two relevant standards(IEC 61508 and IEC 61511) to identifydifferences in interpretation and terminology forthose clauses affecting the scope of supply;such as levels of independence for FunctionalSafety Assessments, Techniques andMeasures, Site Acceptance Test (SAT),Verification and Validation.

In addition, this analysis was required as theorganization only provides logic solversubsystems and IEC 61511 tends to focus onthe complete SIS. As the organization had arequirement for its certification scope to includeboth IEC 61508 and IEC 61511 it had to reachan agreement with its certification body oninterpretation of the standards in specific areas.This resulted in a memorandum ofunderstanding providing interpretation andclarification. For example:

• IEC 61511, Part 1, clause 15.1.1 states thatSIS Validation is also referred to as Site

Acceptance Test (SAT) which is undertakenon the complete SIS. However in the contextof the integrator, Site Acceptance Test (SAT)is an activity performed by the integrator onthe customer’s site, following FactoryAcceptance Test (FAT) on the logic solver(and not the complete SIS) and after deliveryof the logic solver to site

• IEC 61511, Part 1, 15.2.2, software validationcan be interpreted as applying to the SIS. Inthe context of the integrator softwarevalidation is included in the FactoryAcceptance Test (FAT) on the logic solveritself, and not the complete SIS which is outof the scope of supply

• IEC 61511, Part 1, Clause 13.1 refers toFactory Acceptance Test (FAT) and statesthat Factory Acceptance Test (FAT) issometimes referred to as integration test andpart of validation. In the context of theintegrator’s Factory Acceptance Test (FAT)this is a separate activity from integration testand is undertaken on the logic solver itself


11

There is an increasing trend in the marketplacefor client organizations to demand formalevidence of the competency of those providersof safety-related products and services. Many of these requirements are colloquiallyreferred to as ‘one liners’ (for example ‘musthave competent people’ or ‘must have certifiedengineers’), and it is clear in many cases thatthe originators of such statements do not fullyunderstand the requirement or how to respondto questions relating to what is exactly meant by such statements.

In any well-run organization, staff are required tobe competent to perform the tasks assigned tothem. Organizations dealing with safety-relatedsystems increasingly find that their customersneed assurance that the organization’spersonnel can be shown to meet the necessarystandards of competency. This includes thedesigners and implementers of such systems.Professionals, with responsibility for designand/or supervision, will also, for example, beexpected to have a detailed working knowledgeof all relevant legislation, codes of acceptedgood practice which affect their work, togetherwith knowledge of working practices in similarestablishments and awareness of currentdevelopments in their field.

Against this background the case studycompany established processes for bothorganizational and individual competence. Theability to demonstrate that the organization hadcompetent functional safety staff called for theestablishment of a functional safety competencescheme. This competence scheme was basedon four attributes:

1. Knowledge2. Experience3. Training4. Qualifications

One of the objectives of the CSA was set toestablish a group of functional safetypractitioners within the organization.

Strategic Competency Principle (c) (see section3) addresses training (attribute 3) in functionalsafety and specific safety platforms. The CSAchose a respected third party specialist as theprovider of training leading to TUV certifiedfunctional safety engineer status.

The other three attributes above on which thecompetence of persons was based, namelyknowledge, experience and qualifications, wereaddressed through the development andintroduction of a Competence ManagementSystem (CMS).

The CMS introduced a further level ofcompetence specific to functional safety, overand above that required by the company’s ISO9001 QMS. The CMS was based on the UKIEE/BCS “Competency Criteria for Safety-related System Practitioners” [6].

The key requirement was for all personnelhaving responsibilities for specified tasks on asafety-related project to have their training,knowledge, experience and qualificationsassessed in relation to the particular tasks forwhich they were responsible.

Although IEC61508 does not make a directcorrelation with the required level of rigourand competence, the following factors weretaken into consideration:• The consequences in the event of failure of

the Electrical/Electronic/ProgrammableElectronic (E/E/PE) safety related system; thegreater the consequence, the more rigorousthe specification and assessment ofcompetence.

• The safety integrity levels of theElectrical/Electronic/Programmable Electronic(E/E/PE) safety related system; the higher thesafety integrity levels, the more rigorous thespecification assessment of competence.

• The novelty of design procedures orapplication; the newer or more untried thedesigns, design procedures or application,the more rigorous the specification andassessment of competence should be.

5.0 SPECIFYING COMPETENCY REQUIREMENTS


12

5.0 SPECIFYING COMPETENCY REQUIREMENTS

• Previous experience and its relevance to thespecific duties to be performed and thetechnology being employed. The greater therequired competence levels, the closer the fitshould be between competencies developedfrom previous experience and those requiredfor the specific duties to be undertaken.

A competence database, in existence at theorganization, and used to record the technicalcapabilities of personnel was used as the basisfor personnel selection. That is, the responsibleProject Manager consults the database whenassigning resources to a safety-related project,to ensure that candidates have the necessaryexperience and qualifications appropriate to theapplication area and technology, as well asknowledge of the legal and safety regulatoryframework. The classification of the level ofcompetence achieved, with respect to specificcompetence, is as follows:

Level 1:Has experience of the system safety platform inan implementation capacity and / or hasattended appropriate training courses. This isthe minimum level required for the relevantactivities of the implementers and testers of thesystem.

Level 2:Has experience and training to the level ofspecifying/designing solutions for the systems platform. This is the minimum levelrequired for the relevant activities of thedesigners of the system.

Level 3:A recognised expert in his/her application of thesystems platform, demonstrated throughappropriate combination of experience,application and training. This is the minimumlevel required for the relevant activities of thereviewers of the system.

A set of supplementary guidelines assists those undertaking the assessment of anindividual in order to produce an assessmentprofile and the level of competence achieved.This information was subsequently recorded inthe competence database.

The supplementary guidelines cover suchareas as:• Engineering knowledge appropriate to the

industry domain• Safety system knowledge applicable to the

application and technology• Principles of Functional Safety Assurance• Specifying, witnessing & performing tests• Transposing safety requirements to design• Analysing design and code (in terms of

software and hardware architecture andincluding various forms of definition notation)

Completion of the assessment of competencenot only facilitates the mapping of theindividual’s competence to the specific projecttasks and activities they are required to performbut also identifies those areas where mentoringand supervision is required and any additionaltraining necessary.


13

Strategic Competency Principle a) (see Section3) called for a gap assessment to be performedof the functional safety management systemagainst the requirements of IEC 61508 and IEC61511 for each of the organization’s integratorsinvolved in functional safety activities. In order toundertake this task, a gap assessmentmethodology, based on the CASS (ConformityAssessment of Safety Systems) [7] scheme wasused. The CASS assessment templates weredeveloped to align with clause 6 of IEC 61508Part 1 and clause 5 of IEC 61511 Part 1.

IEC 61511 rather than IEC 61508 was used todevelop the detailed gap assessmentmethodology, simply because its terminologywas more readily understood and relevant to thecase study organization that operatespredominantly in the process sector. The gapassessment methodology was aligned to thosephases of IEC 61511 and mapped across to thecore set of pre-requisites of the organization (seeSection 3. 2 – Defining the boundaries), namely:

• Phase 4 SIS Design & Engineering• Phase 9 Verification

• Phase 10 Management of functional safety and functional safetyassessment and auditing

• Phase 11 Safety life-cycle structure and planning

A gap assessment module was developedspecifically for each of the above phases.

For each gap assessment module, and forcompleteness, all relevant clauses of bothstandards were reviewed and a series of gapassessment tables developed to include:

• Targets of Evaluation (TOE) i.e.) evidence expected

• Summary of the clause• Sub clause reference identifier• Supplementary assessor guidance

(Assessor prompt list)• Assessor findings

An example is provided in table 2 below.

As a result of performing the gap assessmentcommon areas for improvement were identified,which in turn helped to prioritize the laterdevelopment of the functional safetymanagement system.

6.0 BENCHMARKING CURRENT PRACTICE

Purpose of TOE

To define proceduresfor ensuring thatapplicable partiesinvolved in any of theoverall, E/E/PES orsoftware safety lifecycleactivities are competentto carry out theactivities for which theyare accountable; inparticular, the followingshould be specified:the training of staff indiagnosing andrepairing faults and insystem testing,the training ofoperations staff, theretraining of staff atperiodic intervals;

IEC 61508 Clauses/tables1/6.2.1 h)

Figs 2,3,4 and1/Table 1 asframework.

Assessment prompt list

• There is evidence that thefunctional safety tasks tobe done have beenassigned – thecompetency required forthe task and a gap analysisbetween the competenciesof the individual allocatedto the task have beenundertaken.

• There is evidence of alogical process thatdocuments who isresponsible for deciding why an individualhas been allocated to thetask.

• This element will beexplored in greater detailwithin the overallcompetency assessmentTOES (Annexe C)

IEC 61511 Clauses/purpose

5.2.2.2Persons, departments or organisationsinvolved in safety lifecycle activities shallbe competent to carry out the activitiesfor which they are accountable.• What evidence is available

demonstrating this• Does it take into account, specific

technology, safety engineering,regulations, management andleadership skills, consequences, SIL,complexity, novelty

• Knowledge – how do you show this• Training – generally records in place

(part of ISO9001)• Experience – traditionally

poorly recorded• How are these assessed /

recorded / updated • How are the competency

needs identified• How is the ‘gap’ between needs

and skills assessed / bridged

Target ofEvaluationCompetenceassessmentprocess

Table 2 Example Gap AssessmentTarget of Evaluation


14

7.0 SELECTING THE CERTIFICATION BODY

The organization chose to achieve accreditedthird-party certification as its ultimate goal.Accredited certification provides transparency,credibility, international recognition, objectivityand independent scrutiny.

A short list of accredited certification bodieswas drawn up by the Company Safety Authority(CSA) and invited to participate in a pre-qualification exercise to provide information todemonstrate their capability and competency.

The information requested included:

• Appropriate evidence of operation as anaccredited certification body including- national accreditation bodies to which

accredited- scope and date of accreditation- details of applicable standards and

certificates relevant to the accreditation

• Pedigree, including a description of theexperience, capability and competence of thecertification body and its auditors to performthese specific third-party assessments(functional safety management as opposedto product assessment)

• Global presence of the certification bodyincluding countries in which they operate

• Whether dependent on agencies in specificcountries and if so their details

• Reciprocal arrangements including:- Memoranda of Understanding (MOR)- Mutual Recognition Arrangements (MRA)

• CVs of assessors

• List of organizations including those that havebeen assessed, their scope of assessmentand contact details within the organization

• Description of:- the assessment methodology- the assessment process- guidance notes for the assessed

organization

• Typical work program (including labor costs)for a third party functional safety assessment,including man-days effort

• Any current limitations envisaged inundertaking the third party assessmentprogram

• Company accounts for the last accounting period

• Organizational structure

It was then necessary to establish an impartialand independent panel representing theorganization to review the responses resulting inthe selection of a global third-party accreditedcertification organization. In the case study thiswas the Company Safety Authority (CSA).


15

8.0 DEVELOPING THE SAFETY LIFECYCLE MODEL ANDFUNCTIONAL SAFETY MANAGEMENT SYSTEM

Figure 2: The Safety Lifecycle Model (see Appendix, page 32 for full version)

This was the most significant activityundertaken. It followed the gap assessment andentailed defining a comprehensive safetylifecycle model mapping the relevant phases ofIEC 61508 [1] and IEC 61511 [2] in respect ofthe core set of pre-requisites described insection 4 – ‘Defining the boundaries’. Thissafety lifecycle model was supported byprocedures, framework documents (basicdefault information for a safety project to becustomized to meet any specific project

variations) and skeletons (a template consistingof all necessary headers to be completed).

The development of this safety lifecycle modelhad in addition to make full use of the existingquality management processes andprocedures. Figure 2 below details the model.

An explanation of the deliverables specified in the model is provided below in sections 8.1 to 8.5.


16


8.1 Design Documentation

8.1.1 Functional Design SpecificationThe Functional Design Specification (FDS) is thekey design document produced by theintegrator. It is also the key, controllingdocument for the system design and containsall the rationale as to why the design has takenthe specified approach. It takes the client’sSafety Requirement Specification (SRS) as inputdata, and develops them through the FDS,detailing the platform to be used, system layout(often in the form of a system block diagram),interfaces, and functional and operationaldesign considerations. The FDS, onceapproved, confirms the basis of design andtraceability of the ensuing design to the client’srequirements. It also sets up the rollout of theHardware Design and Software DesignSpecifications. The FDS provides the keyacceptance criteria for the system FactoryAcceptance Testing (FAT), and is used by theintegrator to measure the success of the projectfrom the results of FAT.

8.1.2 Module Design SpecificationThis is the lowest level of detailed designdocument produced on the project. The primaryfunction of the Module Design Specification is toshow clear design intent, to communicate thatdesign in a clear fashion, and to allow forapproval before its implementation. The ModuleDesign Specification defines in detail the inputs,outputs and functionality for the operation of aparticular software module in pseudo code orstructured English. It will also define all variablesused (global or local), other modules called, theresult and error conditions, parameters passedand interfaces/relationships with other modulesor systems.

The second function of the document is toenable any trained programmer to code to theprogramming language and standards definedin the document and in accordance with therelevant project programming standards. Theapproach to the Module Design Specification isof particular importance where there is more

than one programmer on the project teamproducing modules that affect the overallfunctionality of the system.

Examples of modules are as follows:• Generic analog input module• Generic digital output module• Cause and effect mimic• Firewater pump logic• Evacuation criteria

8.1.3 Boundary DiagramThe purpose of the Boundary Diagram is tographically identify which components form partof the Sensor, Logic Solver and Final Element,and is of use as a reference point for the SILverification report.

Boundary Diagrams are an optional requirementand only need be produced if they are arequirement / necessity of the project.

8.2 Verification documentation

8.2.1 Test Plan The Test Plan defines the verification process forthe System. This includes an outline of the testsand test criteria, test environment and testphase prerequisites necessary to verify andvalidate the system against the appropriatereference documents and standards.

Refer to the Review and ConfigurationManagement Procedure in respect of theverification activities which encompassdocumentation and code reviews.

8.2.2 Module Test SpecificationOnce a software module has been coded, andreviewed, it is subjected to formal testingdefined by the Module Test Specification. Asmany module test specifications can beproduced as necessary.

The functionality of each module will be verifiedby the use of this document and the approvedModule Design Specification specific to themodule under test.


17

8.2.3 Integrated Test SpecificationThe Integrated Test Specification is used todemonstrate that each application softwaremodule produced integrates correctly with othersoftware modules and interfaces correctly withthe system target hardware and systemfirmware, all being an integral part of thedeliverable system. Testing will include bothfunctional safety and non-safety aspects of thesystem to verify that the system performs itsintended functions and does not performunintended functions.

8.2.4 Factory Acceptance TestSpecificationThe Factory Acceptance Test Specification isused to demonstrate to the client that eachapplication software module producedintegrates correctly with other softwaremodules, and interfaces correctly with thesystem target hardware and system firmware,all being an integral part of the deliverablesystem. Testing will include both functionalsafety and non-safety aspects of the system, to verify that the system performs its intended functions and does not performunintended functions.

8.2.5 Site Acceptance Test SpecificationThe Site Acceptance Test Specification is usedto demonstrate to the client that the entiresystem, including all networks, function correctlyafter re-assembly and installation on site. Inaddition the SAT verifies that the softwareloaded is that which was demonstrated at theFAT stage, this is achieved by functionallytesting specific elements of the control system,previously verified at the FAT.

8.2.6 SIL Achievement ReportThe purpose of the SIL Achievement Report isto demonstrate that the system meets thesystematic and hardware fault tolerancesrequired by the SIL specified by the SafetyRequirements Specification. The SILAchievement Report provides the quantitativeevidence in the form of PFD and architecturalconstraints (a combination of Hardware Fault

Tolerance (HFT) and Safe Failure Fraction (SFF)).

8.2.7 Module Failure Modes AnalysisThe purpose of the Module Failure ModesAnalysis is to provide a report of the hardwarefailure modes performed on the System.

This analysis attempts to discover and analyzeall potential failure modes of the hardware sub-system, the effects these failures have on thesystem, and what measures have beenengineered to correct and or mitigate thefailures or effects on the system.

The analysis supports the Reliability andAvailability calculations in the SIL VerificationReport, in providing evidence that the ESDsystem conforms to the availability requirementof the SIL, as identified in the SafetyRequirement Specification.

Note that the Failure Modes Analysis is anoptional requirement and should only beproduced if they are a requirement/necessity ofthe project.

8.3 Safety Lifecycle Structure and PlanningDocumentation

8.3.1 Safety Lifecycle Management PlanThe purpose of this document is todemonstrate how the integrator intends tomanage the realization sections of the safetylifecycle of the project and defines how the usermanages the subsequent operational andmaintenance parts. This is in order to show itsalignment with the recommendations laid out inIEC 61508 and IEC 61511.

Compliance with this safety lifecyclemanagement plan, and thus conformance withthe recommendations of IEC61508 andIEC61511, is demonstrated by means ofassessment (Functional Safety Audits) andverification (Module, Integrated and FactoryAcceptance Testing) of the outputs from eachphase of the safety lifecycle model.


18


8.3.2 Software Configuration Production LogThe purpose of the software configurationproduction log is to modularize and categorizethe software elements, for example, genericloop types, graphics, and logic. The productionlog is then used to track the progress of eachmodule as it goes through design, build andstage stages, according to the safety lifecyclemodel.

8.3.3 Techniques and MeasuresSpecificationThe purpose of this document is to define thetechniques and measures, and whereapplicable supporting tools, necessary to alignwith the requirements of IEC61508, Part 2(Annexes A and B) and Part 3 (Annexes A andB) for each phase of the E/E/PE and SoftwareSafety Lifecycles. In order to demonstratecompliance to the requirements of IEC 61508 itwas necessary for the organization to specifythose techniques and measures used in orderto avoid and control systematic faults, see IEC61508 Part 2, clause 7.4.2.2.

Technique/measure See IEC SIL1 SIL2 SIL3 SIL4 SIS61508-7

Functional testing B.5.1 HR HR HR HR Ymandatory mandatory mandatory mandatory

Project Management B.1.1 HR HR HR HR YLow Low Medium High

Documentation B.1.2 HR HR HR HR YLow Low Medium High

Black box testing B.5.2 R R R R YLow Low Medium High

Field experience B.5.4 R R R R NLow Low Medium High

Statistical testing B.5.3 - - R R NLow Low Medium High

Techniques and Methods

In-house ‘Process Navigator’

Safety Lifecycle Management Plan

Test Plan

Module Test Specification

Integrated Test Specification

Factory Acceptance TestSpecification

ISO9001

‘Process Navigator’


‘Process Navigator’


Validation and Test Plan

All techniques marked “R” in the grey shaded group are replaceable, but at least one of these is required.For the verification of this safety lifecycle phase, at least one of the techniques or measures shaded grey in this table or listed in table B.5 shall be used.NOTE 1 For the meaning of the entries under each safety integrity level, see the text preceding this table.NOTE 2 The measures in this table can be used to varying effectiveness according to table B.6, which gives examples for low and high

effectiveness. The effort required for medium effectiveness lies somewhere between that specified for low and for high effectiveness.NOTE 3 The overview of techniques and measures associated with this table is in annex B of IEC 61508-7. Relevant sub-clauses are

referenced in the second column.

Table 3 - Recommendations to avoid faults and failures during E/E/PES integration


19

In the case study, this was an extensiveexercise. The tables of Techniques andMeasures within IEC 61508 cover the completeE/E/PES and Software Safety Lifecycles. Thefirst step was to identify only those tablesassociated with the integrator’s core set of pre-requisites (see section 3.2 above) related to IEC61508 Phase 9 and IEC 61511 Phase 4. Havingidentified the sub-set of tables the decision wasmade to benchmark the assessment of theorganization against the requirements for SIL 3.The aim of the certification would be to providethe third party evidence that the integrator haddemonstrated, for the logic solvers within the

scope of the certification, a functional safetycapability of SIL 3. In respect to the techniquesand measures used, the Highly Recommended‘HR’ option was selected and then tablespopulated with:• cross references to organization procedures• certificates of compliance• use of certified logic solvers

Examples are shown in Tables 3 and 4 below

A ‘Y’ in the SIS column within the table againsta specific technique identifies the technique asbeing selected for the project.

Technique/measure See IEC SIL1 SIL2 SIL3 SIL4 SIS61508-7

1 Suitable programming C.4.6 HR HR HR HR Ylanguage

2 Strongly typed C.4.1 HR HR HR HR Yprogramming language

3 Language subset C.4.2 - - HR HR Y

4a Certified tools C.4.3 R HR HR HR Y

4b Tools: increased confidence C.4.4 HR HR HR HR Yfrom use

5a Certified translator C.4.3 R HR HR HR N

5b Translator: increased C.4.4 HR HR HR HR Yconfidence from use

6 Library of trusted/verified C.4.5 R HR HR HR Ysoftware modules and components

Techniques and Methods

Certified Control Language, with asubset of function blocks is certifiedfor use, constrained by certifiedlogic solver

Certified Control Language

Certified function blocks are utilized,constrained by certified logic solver


Certified Control Language is acomponent of certified logic solver.Safe subset dictated by the safetymanual and certified logic solver

Certified Control Language, with asubset of function blocks is certifiedfor use. Safe subset dictated by the safety manual and certified logic solver


Not used for LVL

Certified Control Language has >5years proven in use

Only certified function blocks, ormodules constructed from theseblocks, are utilized in this application.Refer to the Safety Manual

* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/measures areindicated by a letter following the number. Only one of the alternate or equivalent techniques/measures has to be satisfied.

Table 4 – Software design and development: support tools and programming language


20


8.3.4 Operator ManualThe Operator Manual is developed from theFDS and the Module Design Specifications andis written to ensure that plant personnel areprovided with all relevant information on theoperation of the System.

8.3.5 Maintenance ManualThe Maintenance Manual is developed from theFDS and the Module Test Specification and iswritten to ensure that plant personnel areprovided with all relevant information on themaintenance of the System.

The Maintenance Manual makes reference to,and use of, the standard integrator DocumentReference Set. This is a collated set ofindividual, standard instruction booklets (IBs) forthe company’s generic Safety system (in thecase of the case study 800xA HI) (whichincludes the safety manual), covering bothhardware and software.

The Maintenance Manual indicates, whereapplicable, the verification tests that the usermust undertake to proof test the Logic Solver.This includes, but is not limited to, the action tobe taken when abnormal conditions areindicated by the system (either via LED on themodule, or software diagnostic).

The Maintenance Manual provides informationto the end user to enable them to ensurefunctional safety performance is maintained.

8.4 Management of Functional SafetyDocumentation8.4.1 Query/Change ProcedureThe Query/Change Procedure providesguidance in the use of project queries, anddefines the impact assessment form to be usedto assess each change or variation to the SafetyInstrumented System.

8.4.2 Review and ConfigurationManagement ProcedureThe Review and Configuration ManagementProcedure ensures that, through review and

assessment, application software code andsupporting documentation is produced to beconsistent, maintainable, of acceptable quality,satisfying user requirements, and is safe.

8.4.3 Project Competency AssessmentProcedure The purpose of the Project CompetencyAssessment Procedure is to provide a formalmeans of assessing personnel involved in anySafety Lifecycle Electric / Electronic /Programmable Electronic Systems (E/E/PES)and software activities, to ensure that theypossess the necessary experience, knowledge,training and qualifications to carry out theactivities for which they are accountable and,where necessary, to identify any additionaltraining requirements.

8.4.4 Functional Safety Audit ProcedureThe purpose of the Functional Safety AuditProcedure is to provide additional guidance tothe project auditors in order to verify correctimplementation.

8.4.5 Functional Safety Assessment (FSA)Functional Safety Assessments are undertakenin accordance with the requirements of IEC61508 Part 1 Clause 8.

In the case study, the CSA acted as the'Independent Department' in performingfunctional safety assessments of the integrator’ssafety-related projects in accordance with therequirements of IEC 61508 Part 1, Table 5 forSafety Integrity Level (SIL) 3. An assessor drawnfrom the CSA plans, schedules and executesthese functional safety assessments inaccordance with a CSA procedure (‘FunctionalSafety Assessment Process’).

Acting as an Independent Department forundertaking FSAs enables the CSA to performa similar role for other business units within theorganization planning for future accreditedcertification.


21

The FSA should provide, amongst otherthings, confidence that the following havebeen achieved:• The safety instrumented system logic solver

is designed, constructed, verified and testedin accordance with the safety functionaldesign specification; any differences havebeen identified and resolved

• The safety instrumented system logic solvervalidation planning is appropriate and thevalidation activities have been completed

• Project design change procedures are inplace and have been properly applied

• SIL capability achieves the SIL targetrequirements

• Regulations, mandatory standards and anystated codes of practice have been met

• Where development and production tools areused they shall be included in the FSA

• Adequate and complete documentation isprovided

At least one Functional Safety Assessment(FSA) is performed during the project’s safetylifecycle. The FSA is split into three phases:• Preliminary FSA – trigger point completion of

Safety Lifecycle Management Plan• Design FSA – trigger point completion of

Functional Design Specification• Final FSA – trigger point completion of

Factory Acceptance Test

Additional FSAs may be required dependingon criteria such as:• Duration of project• Number of safety systems implemented

within the project• Safety regulatory requirements• Degree of complexity

Each phase of the FSA is supported bychecklists drawn directly from IEC 61508 anddesigned to assist the assessment team inensuring that the FSA is conducted inaccordance with the requirements of thestandard.

Table 5 (see page 22) provides an example of achecklist to be used during the final FSA. Thewhite cells are the clauses from the standardsetting out the objectives to be achievedwhereby compliance will be measured andfindings recorded. The blue cells are the clausesfrom the standard setting out the requirementsto meet the objectives.


22


Item Clause RecommendationAccept (A); Reject (R);

Qualified Acceptance (QA); Not Applicable (NA)

1 IEC 61508-1 Clause 5Documentation

1.1 IEC 61508-1 Clause 5.2Requirements

Objectives & Requirements

5.1 Objectives5.1.1 The first objective of the requirements of this clause is to

specify the necessary information to be documented in orderthat all phases of the overall, E/E/PES and software safetylifecycles can be effectively performed.

5.1.2 The second objective of the requirements of this clause is tospecify the necessary information to be documented in orderthat the management of functional safety (see clause 6),verification (see 7.18) and the functional safety assessment(see clause 8) activities can be effectively performed.

Assessor Note: In respect of the Preliminary FSA this will seekevidence that the key deliverables are identified within the SLMP andthe SLMP has itself undergone formal review and approval. During the Design and Final FSA the results of the functional safetyaudits will be reviewed.

5.2.1 The documentation shall contain sufficient information, foreach phase of the overall, E/E/PES and software safetylifecycles completed, necessary for effective performance ofsubsequent phases and verification activities.

5.2.2 The documentation shall contain sufficient informationrequired for the management of functional safety (clause 6).

5.2.3 The documentation shall contain sufficient informationrequired for the implementation of a functional safetyassessment, together with the information and results derivedfrom any functional safety assessment.

5.2.4 Unless justified in the functional safety planning or specified inthe application sector standard, the information to bedocumented shall be as stated in the various clauses of thisstandard.

5.2.5 The availability of documentation shall be sufficient for theduties to be performed in respect of the clauses of thisstandard.

5.2.6 The documentation shall be– accurate and concise;– be easy to understand by those persons having to make

use of it;– suit the purpose for which it is intended;– be accessible and maintainable.

5.2.7 The documentation or set of information shall have titles ornames indicating the scope of the contents, and some formof index arrangement so as to allow ready access to theinformation required in this standard.

5.2.8 The documentation structure may take account of companyprocedures and the working practices of specific applicationsectors.

5.2.9 The documents or set of information shall have a revisionindex (version numbers) to make it possible to identifydifferent versions of the document.

5.2.10 The documents or set of information shall be so structured asto make it possible to search for relevant information. It shallbe possible to identify the latest revision (version) of adocument or set of information.

5.2.11 All relevant documents shall be revised, amended, reviewed,approved and be under the control of an appropriatedocument control scheme.

Table 5 Example of a Final FSA checklist


23

Table 6 Safety Project Activity Plan

8.5 Safety Project Activity PlansThe project safety lifecycle model, as definedabove, is further supported by a detailed ActivityPlan, which specifies for each stage of theproject, its inputs, outputs and reviewresponsibilities. The intention is that eachintegrator will populate the business processmodel reference and activity references with

Further clarification of some of the cells is provided on the following page

local procedures. An extract of the Activity Planis provided in Table 6 below.Although Activity Plan activities are in theirrespective logic sequence, this does notconstitute the actual order in which activitiesmay be completed. Therefore reference shouldbe made to each specific safety projectschedule.

ActivityNumber

1.12

1.13

1.14

1.15

BusinessProcessModelreference

Activity

Preparation,Submission,Review andup-date ofCompetencyAssessmentProcedure

Assessment ofSafety TeamMembers

Preparation,Submission,Review andup-date ofQuery/ChangeProcedure

Preparation,Submission,Review andup-date ofReview andConfigurationManagementProcedure

Activityrelatedprocedure ordocument

Safety LifecycleManagementPlan

Review andConfigurationManagementProcedure

ProjectCompetencyAssessmentProcedure





Acceptancecriteria

Conformity toABB qualitysystemrequirements

Conformity toSafety LifecycleManagementPlan



Primeresponsibilityfor activity

SIS LeadEngineerProjectManagerIndependentVerificationBody

ProjectManagerIndependentVerificationBody

SIS LeadEngineerProjectManager

IndependentVerificationBody

SIS LeadEngineerProjectManager

IndependentVerificationBody

Activitydeliverable

ClientApprovedProjectCompetencyAssessmentProcedure

CompletedSafety TeamMemberAssessmentForms

ClientApprovedQuery/ChangeProcedure

ClientApprovedReview andConfigurationManagementProcedure

Inspection schedule

ABB Client VB

H A R

H R R

A A R

A A R


24


Verification Body (VB) Verification is only applicable to those activitieswithin the Quality Plan that relate to the design,hardware build, software configuration,functional test and validation of safety-relatedsystems, that is Phase 9, Realization, of theSafety Lifecycle recommended by IEC61508and IEC61511, and Phase 4, SIS design andengineering within IEC61511.

The field marked ‘VB’ is used to indicate (anddemonstrate to the client or Verification Body(VB)) that each applicable activity has beenformally assessed and verified in terms ofmeeting the required Safety Integrity Level (SIL),for the particular item of safety-relatedequipment, to which the activity relates.

The Verification Body will be a person that hasthe required competency, skills andindependence from the project to undertake theassessment of the particular activity. In line withthe recommendations of IEC61511,Independence is defined as follows:

Independent Person – a competent person whois separate and distinct from the activities whichtake place during the specific phase of thesafety lifecycle and does not have directresponsibility for those activities

Inspection Schedule CodesThe inspection / documentation schedulecodes listed in the Activity Plan are defined as follows:

H: Hold PointThis is an inspection or test that is consideredvital to the quality and integrity of the equipmentand services being supplied.

A hold point cannot be passed unless thespecified acceptance criteria have been met(unless a concession is raised and approved).Where a hold point is also specified by theclient, the point cannot be passed withoutwritten authorization from the client.

W: Witness PointThis is an inspection or test that may be asimportant as a hold point (and must be notifiedto the client), but which can be responsiblycarried out after the point has been passed.

Witness points may be attended by the client,but authorization from the client is not requiredto allow work to proceed beyond that point(following expiry of the seven days notice).

M: Monitor PointThis is a point in the programme of work wherea check may be made to verify that a specifiedaction has taken place, and that the correctdocumentation records exist. Such checks canbe retrospectively made.

A: Approval Point(documentation and/or records)Approval points are those which requiredocumentation and/or records to be reviewedand approved by the integrator and the client,and beyond which work cannot proceed untilthe appropriate approval is given.

R: Review PointReview points are where design reviews and /or walkthroughs are to be performed for thespecified activity or activities that requireverification.

Review points may be attended by the client,but authorization from the client is not requiredto allow work to proceed beyond that point(following expiry of the seven days notice).

Full adherence to the safety lifecycle modelrequired the development of a set of supportingprocedures, framework documents andskeletons defined below. Tables 7, 8, 9 and 10provide titles for all of these additionaldocuments including those specific to theintegrator’s QMS.


25

Table 7 QMS Document list

• New Supplier Assessment• Contract Review and Order Processing• Internal Kick-off Meeting Preparation• Quality Plan/Safety Plan• Query Management Process• Configuration Management• Competency and Training Work Practice• Complete Functional Description• Software Production• Complete Test Specification• Module Test• Integrated Test• Factory Acceptance Test• Management System Audits• Bid and Proposal Guideline• Safety Requirements Checklist• Product Alert Handling• Management System Review

Table 8 Supplementary FSMS Document list

• Functional Safety Management System Overview

• Functional Safety Policy (UK-SEC)• Project Competency Assessment• Project Competency Assessment Form• Review and Configuration Management

Document Review Form• Code Review Form• Project Query Handling Supplementary

Instruction & Guideline• Query Change Impact Analysis Form• Functional Safety Audit & Assessment

Procedure• Safety Lifecycle Management Plan• Software Production Log• Techniques and Tools• Verification and Test Plan• SIL Verification Report

Table 9 Supplementary FSMS specificSkeletons Document list –

• Functional Design Specification• Software Design Specification• Module Test Specification• Integrated Test Specification• Factory Acceptance Test Specification• Site Acceptance Test Specification• Operator Manual• Maintenance Manual• FMEA• Boundary Diagrams

Table 10 FSMS Framework Documents –

• Safety Lifecycle Management Plan• Software Production Log• Techniques and Tools• Verification and Test Plan• SIL Verification Report


26

9.0 EXECUTING THE CERTIFICATION PROCESS

A generic certification process model isnecessary for the integrators to identify rolesand responsibilities of all parties. It is also usedas the basis for the CSA Assessor to providesupport and consultancy to each integrator inorder to assist them to achieve certification. The model shown below was used during thecase study.

9.1 Training in Functional SafetyManagement and Recommended Lifecycle ProceduresThe purpose of this training module is topresent the recommended safety lifecyclemodel, FSMS procedures and specificexamples to the integrator such that they havea clear understanding of the intent and purpose

REMOTE & SITE

Training in Functional Safety

Managment & Recommended

LifecycleProceduresdd

Perform gapAssessment

Gap AssessmentReport

ProduceImplementation

Program

Appoint ProjectManager

Champion

DevelopStandards

Template and Procedures

Identify PilotProject

Pilot Project Implementation

Certification BodyAudit

REMOTE & SITE

Advise on LocalModel

Development & Deviations

2

REMOTE

Issue CompletedChecklists to

Certification Body

6

CSARecommended

Functional SafetyProcedures

CSARecommendedLifecycle Model

Functional SafetyManagment

System

SITE

Certification BodyAssessment & Awareness &

Checklist Completioneee4

Certification BodyAudit Report

Corrective ActionProgram

REMOTE

XXXXX XXXCertification Body

Agree Programand PlaceContract 3

SITE

Training in SLAchievement &

Functional SafetyAssessment

5

SITE

Pre-Certification Body Audit

8

Certification BodyGap Assessment

and Reviewat FSMS


and Reviewat FSMS

Certification BodyPre-Audit

SITE

Perform Functional Safety

Assessment

7

1

Certification

Str

ateg

icC

omp

lace

ncy

Prin

cip

le‘A

’

Str

ateg

icC

omp

lace

ncy

Prin

cip

le‘B

’

CSA Activity

Local Organisation Activity

Certification Body Activity

UK CSA Call off Activity

Key

Figure 3: The Certification Process (see Appendix, page 31 for larger version)


27

of the FSMS and its implementation within theirorganization. This allows the integrator todevelop their local procedures based on aworking model. It will also cover the certificationprocess and alignment to IEC 61508 and IEC61511. (See section 10 below for a descriptionof the training modules).

At the conclusion of the training module, theintegrator is presented with a copy of thetraining material, the recommended safetylifecycle model, and the suite of genericprocedures. (See section 3.8).

9.2 Advise on development / deviations forintegrators’ use of proceduresThe CSA provides advice to the integrator onthe implementation of the FSMS, developmentof their own FSMS procedures and answerstechnical queries on procedures, templates andother documents.

The integrator then has the option of makingalterations to the generic suite of FSMSprocedures to align with existing requirementsand local business systems. The CSA willprovide advice on the impact of thesedeviations on the FSMS and the recommendedcertification process.

9.3 Liaison with the Certifying AuthorityThe CSA directly liaises with the certificationbody to agree a formal program of work andplace a contract on behalf of the organizationfor the agreed scope of work. The scope andprogram is confirmed and agreed with theorganization prior to order placement.

9.4 Certification Body AssessmentAwareness and Checklist CompletionThe purpose of this training module is toprovide the organization with an overview of the certification body’s own detailedcertification process.

Following on from the training module, the CSAand the integrator prepare the certificationbody’s compliance checklists (including any

deviations), which are required as part of thecertification process.

Once completed, the CSA will issue thechecklists to the certification body LeadAssessor for review. At the same time, theorganization will issue its FSMS procedures tothe certification body. In parallel, the integratoridentifies a pilot project or projects todemonstrate that the safety lifecycle and FSMS is being implemented in its entirety. The pilot project(s) will be audited by thecertification body.

9.5 Training in SIL Achievement andFunctional Safety AssessmentThe purpose of this training module is toprovide the integrator with a detailedunderstanding of the methodology adopted inorder to prepare a SIL Achievement Report fora safety project. This will include several workedexamples, and prepare the safety engineers forthe pilot project implementation.

The training module will also address the scopeand purpose of Functional Safety Assessmentsand Audits, and commence development of aplan of the assessment activity for the pilotproject (see section 10, page 28).

9.6 Perform Functional Safety AssessmentAs part of the CSA’s responsibilities, a functional safety assessment is performed on the pilot project.

9.7 Pre-Certification Body AuditIn order to ensure the success of thecertification site audit, the CSA will perform apre-audit to identify any potential risks oromissions from the FSMS and/or the pilotproject. This gives the integrator the opportunityto correct these deficiencies before the officialcertification audit, hence ensuring that thecertification audit results in a successfuloutcome.


28

10.0 TRAINING COURSES

Technical training was an essential part of theimplementation program and the competencymanagement system for the organization.Training is one of the four attributes ofcompetence (see Section 5). Two technicaltraining courses were developed by the CSAsuitable for delivery to business units working tothe core set of the pre-requisites earlier defined(see Section 4).

In the case study, these technical trainingcourses were delivered to the organization witha period of six weeks separating them. Thecontents of these courses are set out below:

10.1 Functional Safety Management &recommended lifecycle procedures A two day course consisting of thefollowing topics:• The certification process • Overview of IEC 61508 and IEC 61511• Functional Safety Management and

links to QMS• Safety lifecycle planning and management –

the safety lifecycle model, inputs, outputs,deliverables

• Requirements and design• Overview of SIL Achievement• Verification & Validation• Functional safety audit and functional

safety assessment• Course exercises

10.2 SIL achievement & Functional Safety Assessment A 1.5 day course consisting of the following topics:• Safety function and safety integrity

requirements• Design essentials of IEC 61508, hardware

safety integrity and systematic safety integrity• SIL compliance to IEC 61508• SIL achievement procedure, worked example

and exercise• Functional safety assessments in the context

of SIL achievement


29

11.0 ESTABLISHING SUPPORTING ACTIVITIES

Prior to and during the case study, there wasalready in place a large internal companynetwork of safety practitioners with differentsafety objectives and operational safetystandards.

Other internal businesses had developed futureplans for certification.

Consequently it was essential to establish, at anearly stage in the process, a common repositoryfor information exchange.

This was achieved in the form of a SafetyDatabase containing the following information:

• Third-party certificates of safety products• Lists of certified functional safety engineers

and functional safety technology engineers• Improvement themes• Technical papers and articles• Latest FSMS procedures• External functional safety standards• Sales and technical product material• Case study progress and program updates

12.0 MANAGING CHANNEL PARTNERS AND THIRD-PARTY INTEGRATORS

The same rigorous approach to functionalsafety had to apply to any third-party integratorsbeing used by any of the company’s integrators.This ensured the safety and quality of the third-party integrator. A program of work wasrequired to perform a gap assessment on third-party integrators and to subsequently work withthem to ensure that they developed a compliantfunctional safety management system,preferably in line with that of the main systemvendor. This process has been seen to benefitthe third-parties in that they can also achievecertification and capitalize on the achievementin the safety market place.


30

13.0 FINAL COMMENTS AND CONCLUSIONS

The international safety market is undergoingmany changes driven by technology, standards,legislation and incidents. Those organizationsworking in this demanding and highlycompetitive arena seek to differentiatethemselves, secure market advantage anddemonstrate competence and due diligence.Many organizations see accredited certificationof the organization as a positive step forward.

Accredited certification for an organization is asignificant undertaking. It requires managementcommitment at the highest level in addition to acomprehensive work program involving not onlythat part of the organization selected forcertification, but other groups within theorganization itself.

The case study described above providesdetails relating to implementation of anorganization’s generic processes,methodologies and procedures and then howthese were applied to a specific safetyintegration group within the organization. Itoutlines a step-wise approach covering:

• Strategy• Benchmarking and gap assessment• Developing the functional safety management

system• Selecting the certification body• Implementing the functional safety

management system• Rolling out the certification process

Successful implementation of a certificationprogram provided advantages to theorganization, not least:• Limiting the company’s exposure to

potential liabilities• Demonstrating due diligence• Implementing repeatable and cost effective

safety management systems (procedures,techniques, tools etc)

• Reducing unnecessary and costly pre-contract discussions and evidence gathering– actually benefiting both the organizationand its clients

• Winning work cost effectively • Limiting effort (and cost) in developing so-

called bespoke project safety procedures• Gaining competitive advantage and as a

result securing more business

The author hopes that the information providedin this chapter will benefit other organizationsand individuals with an interest in functionalsafety management and certification.


REMOTE & SITE

Training in Functional Safety

Managment & Recommended

LifecycleProceduresdd

Perform gapAssessment

Gap AssessmentReport

ProduceImplementation

Program

Appoint ProjectManager

Champion

DevelopStandards

Template and Procedures

Identify PilotProject

Pilot Project Implementation

Certification BodyAudit

REMOTE & SITE

Advise on LocalModel

Development & Deviations

2

REMOTE

Issue CompletedChecklists to

Certification Body

6

CSARecommended

Functional SafetyProcedures

CSARecommendedLifecycle Model

Functional SafetyManagment

System

SITE

Certification BodyAssessment & Awareness &

Checklist Completioneee4

Certification BodyAudit Report

Corrective ActionProgram

REMOTE

XXXXX XXXCertification Body

Agree Programand PlaceContract 3

SITE

Training in SLAchievement &

Functional SafetyAssessment

5

SITE

Pre-Certification Body Audit

8


and Reviewat FSMS


and Reviewat FSMS

Certification BodyPre-Audit

SITE

Perform Functional Safety

Assessment

7

1

Certification

Str

ateg

icC

omp

lace

ncy

Prin

cip

le‘A

’

Str

ateg

icC

omp

lace

ncy

Prin

cip

le‘B

’

CSA Activity

Local Organisation Activity

Certification Body Activity

UK CSA Call off Activity

Key

31

APPENDICES

Figure 3: The Certification Process (referred from page 26)


32

APPENDICES

Figure 2: The Safety Lifecycle Model (referred from page 15)


33

APPENDICES


34

REFERENCES

[1] IEC 61508 – Functional safety of electronic/electrical/programmable electronic safety-related systems

[2] IEC 61511 – Functional safety – Safety instrumented systems for the process sector

[3] “Recommendations on the design and operation of fuel storage sites”; Buncefield MajorIncident Investigation Board:http://www.buncefieldinvestigation.gov.uk/reports/recommendations.pdf

[4] “The Report Of The BP U.S. Refineries Independent Safety Review Panel” (concerning theTexas City incident). http://www.csb.gov/completed_investigations/docs/Baker_panel_report.pdf

[5] IEC 61131 – Programmable Controllers

[6] Safety, Competency & Commitment - Competency Guidelines for Safety-Related SystemPractitioners 1999 (ISBN 0 85296 787 X)

[7 ] CASS – Conformity Assessment of Safety-related Systems certification scheme - FunctionalSafety Capability Assessment (FSCA)


35

ABOUT THE AUTHOR

Stuart Nunns has thirty-sixyears’ experience inautomation and safetywithin the oil & gas,chemical, steel andelectricity generation sectors and is a Principal

Consultant within the Safety Lead CompetencyCentre of ABB's Process Automation Division.Nunns is a member of ABB's Safety SteeringTeam, responsible for identifying and managingthe development of functional safety productsand services, mapping the total safety lifecycle.He is currently leading a global work programwithin ABB to establish TUV certified SafetyExecution Centres.

Nunns is a TUV Functional Safety Expert andmember of the IET Functional SafetyProfessional Network Executive Group and the InstMC’s Safety Panel. He has written and presented papers and led internationalsafety-related systems workshops. He wasproject manager of both the CUIG (Framework IV) European safety group and the F/W V SIPI61508 EC Framework V projectdeveloping guiding principals for theimplementation of IEC 61508.

Within the UK he was the instigator and projectmanager of the CASS (conformity assessmentof safety systems to IEC 61508) scheme andserved as a Director of CASS Ltd.

Stuart R Nunns CEng, BSc, FIET, FInstMC - Principal Safety Consultant ABB Ltd


ABB LimitedHoward RoadEaton SoconSt NeotsCambridgeshirePE19 8EUTel: 01480 475321Fax: 01480 217948www.abb.com

© Copyright 2008 ABB. All rights reserved.Specifications subject to change without notice.

Func

tiona

lsaf

ety

hand

book

/Jun

e08
