Application Functional Safety IEC 61511
Introduction Functional safety must be an integral part of the project execution if we shall succeed to make safe application program We can t test and audit safety into a project Safety must be built in never bolted on! If we shall succeeded with this in a lager scale we must have competent people and procedure in place Introduction
Introduction Which safety lifecycle phases in IEC 61511 is applicable for an application program development? Typical verification activities? How can a safety project organization look like? How to ensure that the competency in the project is sufficient? What is the difference between FS Audit and FSA?
IEC 61511 Safety Lifecycle Phases Activities Responsibilities End user / operator Analysis phase 1-2 Identify hazards, specify requirements Design & Installation Commissio ning Phase 3-5 Configure to requirements Engineering / Equipment Supplier Operation phase 6-8 Operate, maintain & modify End user / operator Phase 9-11, responsible - ALL
Safety Life Cycle The Application Program development must comply to the following phases in the safety lifecycle: Phase 4 Design and engineering Phase 9 Verification Phase 10 FSM, FS Audit and FSA Phase 11 Planning The Design and engineering phase 4 is divided into the following sub phases 4.1 Design basis 4.2 Basic design 4.3 Detailed design 4.4 Fabrication 4.5 Test & Validation Safety Life Cycle
Workflow Project Management Workflow
11 - Planning Plan all safety activities Required input and out from each phase High level of safety activities in application program development Scope with regards to the safety life cycle Verification activities Test and validation Test strategy Job description 11 - Planning
11 - Planning Who is responsible for what RACI Matrix Project organization Needed competency Safety requirerments tracking Test specifications Configuration Management Validation and Assessment planning 11 - Planning
10 FSM and 11 Planning Safety Assessor 10 FSM and 11 Planning
10 FSM Why is competency important? The application program developer is responsible for the safety of the delivered application program This responsibility can't be limited by contract or transferred to contractual partners As a result of this, the application developer must secure their own competency to take care of their responsibility Every project need to possess necessary competence 10 FSM
10 FSM How do we secure necessary competency in each project? Competency Assessment What is competency Assessment? What is the required competency What is the possessed competency Necessary measures to close the gap 10 FSM
10 FSM Who need to be competency assessed? A competency assessment is required for any member of the project s team undertaking any of the following activities: Functional safety management (including the project manager) Hardware and software design Hardware build Software coding Quality control activities (including testing and hardware inspection) 10 FSM
9 - Verification Verification activities Document review Basic design review Detailed design review Code review Testing For more consistency during verification is checklists used 9 - Verification
4.1 Design basis Application program integrators is responsible to check the received input documentations Is the needed input received? Is it enough input to create a safe application program? Analyze the Safety Requirements method used for consistent verification is check lists 4.1 Design basis
4.2 - Basic design Write Function description Function design specification Safety Analysis Report How to fulfill the safety requirements Any deviation from the safety requirements is highlighted here Any assumption where safety requirements is missing is highlighted here Any new typical solutions is designed during basic design 4.2 - Basic design
4.3 - Detailed design Detailed design System design Choose topology HW design SIL achievement PFD calculation SW design - Programming manual Detailed design specification 4.3 - Detailed design
4.4 Fabrication Fabrication phase System setup and configuration HW build Application programming Final documentation 4.4 Fabrication
4.5 Test and Validation Internal Acceptance Test HW inspection HW module test SW module test Control logic and functional test Integration test Factory Acceptance Test Safety validation 4.5 Test and Validation
10 FSM Functional Safety Audit and Functional Safety Assessment What is the difference FS Audit: Has the project established and followed relevant procedures? FS Assessment: Is the project delivery safe? This is done by judgment of the project activities and deliverables The assessment can also judge the requirements, will these requirements make a safe product 10 FSM
10 FSM FS Audit is mandatory activity Can be performed by a quality manager Has the project established: A FSM organization? Necessary procedures and documentations 10 FSM
10 FSM Functional Safety Assessment is a mandatory activity Must be lead by a independent senior person The assessment team need technical knowledge Scope to judge that the deliverables form the project is safe The assessment team can also put question to the requirements in the project 10 FSM
Conclusion Developing safety application program is much more than just writing the application program Management is an important part of a safety project Safety must be an integral part of the project In large scale this can only be achieved through high degree of competency When necessary ABB can guide suppliers and customer in what is required to make safe application programs Conclusion
More time left? What is LVL? Conclusion
LVL - Limited Varability Language Defined in IEC 61511 Type of programming language IEC 61131 programming languages like Function Block Diagram Ladder Diagram Sequential Functional Chart Common for them Graphical programming interface Conclusion
What does use of LVL men in practice LVL application program much simpler than C++ program Do not have to use all the methods and techniques in IEC 61508-3 Which methods and techniques to use when developing a LVL application program is not well defined in IEC 61511 Conclusion