Professional Documents
Culture Documents
How to achieve compliance with IEC 62304 for medical device software development
Standards Landscape
Key elements of IEC 62304
Recommendation
Conclusion
Processes
Activities
Tasks
Standards Landscape
Quality management system RISK MANAGEMENT Software safety classification Software development PROCESS Software development planning Software requirements analysis Software ARCHITECTURAL design Software detailed design
Coding Phase
Configuration Management
Planning Process
Unit/Integration Testing
Output: S/W Verification Cases and Procedures (SVCP) and Results (SVR)
Traceability SC to SDD
Coding
Output: Source and Object Code
Code Review
Output: Source Code Review and Analysis Data
Customer Needs
Develop Concept
Product Definition
Requirements Capture & Analysis Reporting, Version & Change Mgmt Systems Analysis & Design
System Acceptance
Up)
Complements Functional Risk Management (Top
SW Design Module Integration & Test
Down)
Risk Management applied recursively throughout product lifecycle Documentation various tools, safety assurance 8 cases
Risk Management File
Implementation & Unit Test Best Practices
Hazards Failures
Design RCMs Requirements
Requirements
System Acceptance
SW Design
Best Practices
10
The software safety classes shall initially be assigned based on severity as follows: Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible
11
Unless
Higher classification applies unless there is a documented rationale in a Risk Management file to justify lower safety class for software items
12
SOFTWARE SYSTEM
SOFTWARE ITEMS
13
Risk is a product of severity and probability of occurrence Software Risk Management Process: - identify software items that could contribute to a hazardous situation - identify causes of contribution to a hazardous situation - define risk control measures - verify risk control measures
Document traceability: Hazardous situation to software item to specific software cause to risk control measure to verification of risk control measure
14
Fault Tree Analysis determines what combinations of conditions or events are necessary for a hazard condition to occur
Fault Tree Analysis allows the developer to identify, control and lower the risk to an acceptable level
This is critical in the IEC 62304 standard
16
The key to safe systems is to analyze the system and to identify the conditions and events that can lead to hazards
Fault Tree Analysis (FTA) determines what logical combination of events and conditions lead to faults
By adding ANDing-redundancy, architectural redundancy can be added
17
Recommendations
Document updated software development process showing compliance with IEC 62304
Mapping chart should now have 100% coverage of IEC 62304 clauses within your processes
18
Risk Analysis
Qualification of requirements
Must have, want to have, nice to have, source, product version etc.
Traceability
Multiple levels required due to the complexity of the systems
Change Control
Who made a change, when the change was made, why the change was made, and analysis of the impact.
PowerPoint
Excel Outlook
Spreadsheet
DOORS
MS-Project
Spreadsheet
Tool Integrations*
FrameMaker RIF (XML)
Risk Analysis
Qualification of requirements
Must have, want to have, nice to have, source, product version etc.
Traceability
Multiple levels required due to the complexity of the systems
Change Control
Who made a change, when the change was made, why the change was made, and analysis of the impact.
Spell check
Context
Requirements
OLE
DOORS views
Change bars and link indicators; instant traceability
DOORS views
Attribute columns in a spreadsheet-like view
29
Risk Analysis
Qualification of requirements
Must have, want to have, nice to have, source, product version etc.
Traceability
Multiple levels required due to the complexity of the systems
Change Control
Who made a change, when the change was made, why the change was made, and analysis of the impact.
Requirements Specifications
1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design Identify impacted elements due to a change in another element 1.1. and development activities 1. Capture design and related informationand define responsibility for implementation. 1. Capture design and related information Traceability Reports: consistency with driving design elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data Impact Reports: other design elements affected information sources The plans shall 1.2. Reference external information sources identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external Links to impacted design elements in, input to 1.3. Reference external documentation the design and development process. 1.3. Reference external documentation
Test Cases
1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1. Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3. Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4. Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6. Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1. Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines
1.1.1. Create backward traces to design elements within and across any organizational
2.
3.
4.
5.
6.
The plans Store design and related information shall be reviewed as design and development evolves. 2. Store design and related information procedure The plans shall be updated as elements 2.1. Identify and tag design information as unique design design and development evolves. 2.1. Identify and tag design information as unique design elements Traceability Reports: Procedure Attribute The 2.2. Organize design elements plans shall be approved as design and development evolves. 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Traceability Reports: MilestoneOrganize by inter-relationships 2.2.2. Organize by inter-relationships Design Input 2.2.2. Attribute 2.1. Each 2.3. Ensure all design elements are availablemanufacturer shall establish procedures to ensure that the design requirements relating to backward traces to design elements within and are available 2.3. Ensure all design elements across Design Control 1.1.3. Create a device are appropriate and address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Design Control Guidance Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements and patient. 2.3.2. Store design elements and their historical values 2.3.2. Store design elements and their historical values Traceability Reports: Linked design elements 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the 1.1.4.of the user needs Create forward impacts to design elements within and across any organizational Manage all user needs 3. Manage all user needs and procedure 3.1. Identify the source of the user need patient. 3.1. Identify the source of the user need 2.3. 3.2. Identify all user types (groups) The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure Identify all user types (groups) 3.2. Attribute 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 3.3. Identify the customer and 1.1.5. Create forward impacts to design elements within(s) across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Impact Reports: Milestone State the intended use of the product (family) 3.5. State the intended use of the 2.6. The design input requirements shall be documented by a designated individual(s). product (family) 3.5. Attribute 2.7. each user input 3.6. Capture the acceptance criteria forThe designneed requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and acrosseach user need 3.6. Capture the acceptance criteria for Design Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements 4. Manage design input Impact Reports: Linked design elements requirements shall 4.1. Identify the source of the requirement be documented. 4.1. Identify the source of the 1.2. Associate changed design elements with related elements requirement 2.10. 4.2. Identify the associated user need Questions. 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of with affected design element(s) Link Change Design Object 4.3. Capture requirement description and attributes 4.3. Capture requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. Capture acceptance criteria Traceability Links and Reports from affected design element(s) 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. Assign responsibility for each Impact Links and Reports from affected design element(s)requirement 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects with following Attributes: 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity 5.3. Document the results of every user need acceptance test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2. Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Change Design Object Traceability Link on Procedure Attribute Manage change 6. Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain on Procedure element changes Change Design Object Impacts Link history of design Attribute 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history 1.2.3. Provide associations within and across any project milestone available 2.10.3.14. reliability 6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational procedure on Milestone Attribute Change Design Object Traceability Link history within and across any project milestone 2.10.3.15. statutory and 6.1.3. Maintain history within and across any project milestone regulatory requirements 6.1.3. Maintain 2.10.3.16. voluntary Guidance Change Design Object Impacts Link on Milestone Attribute any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control standards Elements 6.1.4. Maintain history within and across 2.10.3.17. 6.2. Capture frequency and nature of element changes manufacturing processes 6.2. Capture frequency Control of element Elements 1.2.4. Provide associations within and across Design and natureGuidance changes 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide to traced change Change Design Object Traceability Linkrationale for design elements 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made 2.10.3.20. design history files (DHFs) Change Design Object Impacts Link to linked design elementschange 6.2.3. Identify approval authority for the change 6.2.3. Identify approval authority for the 2.10.4. For the specific design covered, how were the design input requirementsMange the change process 1.3. identified? 6.2.4. Capture date, time, and signature of approving authority 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For another element 6.3. Identify impacted elements due to a change in the specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in another element Design adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone
Initial user needs should be decomposed to detailed requirements, then to design specification, tests, etc.
Traceability view
User Needs
1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy?
Requirements
1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design Identify impacted elements due to a change in another element 1.1. and development activities 1. Capture design and related informationand define responsibility for implementation. 1. Capture design and related information Traceability Reports: consistency with driving design elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that Impact Reports: other design elements affected information sources provide, or result 1.2. Reference external information sources 1.2. Reference external Links to impacted design elements in, input to 1.3. Reference external documentation the design and development process. 1.3. Reference external documentation
1.1.1.Create backward traces to design elements within and across any organizational
The plans 2. Store design and related information shall be reviewed as design and development evolves. 2. Store design and related information procedure The plans shall be updated as elements 2.1. Identify and tag design information as unique design design and development evolves. 2.1. Identify and tag design information as unique design elements Traceability Reports: Procedure Attribute The 2.2. Organize design elements plans shall be approved as design and development evolves. 2.2. Organize design elements 1.1.2.Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Traceability Reports: MilestoneOrganize by inter-relationships 2.2.2. Organize by inter-relationships Design Input 2.2.2. Attribute 2.1. Each 2.3. Ensure all design elements are availablemanufacturer shall establish procedures to ensure that the design requirements relating to backward traces to design elements within and are available 2.3. Ensure all design elements across Design Control 1.1.3.Create a device are appropriate Element 2.3.1. Store design elements by Design Control Guidance and address the intended use of the device, including the needs of the user Elements 2.3.1. Store design elements by Design Control Guidance Element Guidance and patient. 2.3.2. Store design elements and their historical values 2.3.2. Store design elements and their historical values Traceability Reports: Linked design elements 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the 1.1.4.of the user needs Create forward impacts3.to design elements within and across any organizational 3. Manage all user needs Manage all user needs and procedure 3.1. Identify the source of the user need patient. 3.1. Identify the source of the user need 2.3. 3.2. Identify all user types (groups) The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure Identify all user types (groups) 3.2. Attribute 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. Create forward impacts to design elements within(s) across any project milestone 3.3. Identify the customer and 1.1.5. 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Impact Reports: Milestone State the intended use of the product (family) 3.5. State the intended use of the 2.6. The design input requirements shall be documented by a designated individual(s). product (family) 3.5. Attribute 2.7. each user input 3.6. Capture the acceptance criteria forThe designneed requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and acrosseach user need 3.6. Capture the acceptance criteria for Design Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements 4. Manage design input Impact Reports: Linked design elements requirements shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the 1.2. Associate changed design elements with related elements requirement 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of with affected design description Link Change Design Object 4.3. Capture requirementelement(s) and attributes 4.3. Capture requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. Capture acceptance criteria Traceability Links and Reports from affected design element(s) 2.10.2. 4.5. Assign responsibility for each requirementFrom what sources are design inputs sought? 4.5. Assign responsibility for each Impact Links and Reports from affected design element(s)requirement 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1.Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects with following Attributes: 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety 5. Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity 5.3. Document the results of every user need acceptance test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2.Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Change Design Object Traceability Link on Procedure Attribute 6. Manage change 6. Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain on Procedure element changes Change Design Object Impacts Link history of design Attribute 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history 1.2.3.Provide associations within and across any project milestone available 2.10.3.14. reliability 6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational procedure Change Design Object Traceability Link on Milestone Attribute project milestone 2.10.3.15. statutory and 6.1.3. Maintain history within and across any project milestone regulatory requirements 6.1.3. Maintain history within and across any 2.10.3.16. voluntary standards Elements Change Design Object Impacts Link on Milestone Attribute any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control Guidance 6.1.4. Maintain history within and across 2.10.3.17. manufacturing processes 6.2. Capture frequency and nature of element changes 6.2. across Design Control of element Elements 1.2.4.Provide associations within andCapture frequency and natureGuidance changes 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide to traced change Change Design Object Traceability Linkrationale fordesign elements 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made 2.10.3.20. Change Design Object Impacts Link to linked design elementschange 6.2.3. Identify approval authority for the change design history files (DHFs) 6.2.3. Identify approval authority for the 2.10.4. For the specific design 1.3. identified? 6.2.4. Capture date, time, and signature of approving authority covered, how were the design input requirementsMange the change process 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For another element 6.3. Identify impacted elements due to a change in the specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in another element Design adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone
Traceability Explorer
Risk Analysis
Qualification of requirements
Must have, want to have, nice to have, source, product version etc.
Traceability
Multiple levels required due to the complexity of the systems
Change Control
Who made a change, when the change was made, why the change was made, and analysis of the impact.
Suspect Links
Suspect links are visible directly in the document as indicators or as a full description
Previous Baseline
Change History
2011 IBM Corporation
Baseline Compare
Manage Change for Good Manufacturing Practice (GMP) Establish an integrated change process across the lifecycle
Capture customer requests & market driven enhancements Manage Portfolio & Product Priorities
Execute Tests
Testing Eco-system
Configuration Management
Integrate Suppliers
2011 IBM Corporation
Risk Analysis
Qualification of requirements
Must have, want to have, nice to have, source, product version etc.
Traceability
Multiple levels required due to the complexity of the systems
Change Control
Who made a change, when the change was made, why the change was made, and analysis of the impact.
Electronic Signature
Accountability
Audit capability Quality procedures Verification of intent Documented consensus and decision making Conformance with FDA 21 CFR part 11
Provides full accountability without external tools
2011 IBM Corporation
Flexible output
Customer Needs
Develop Concept
Product Definition
Spans the entire systems and software lifecycle Integrates complex systems, embedded software and IT to create innovative products Achieves end-to-end traceability
Requirements Capture & Analysis Reporting, Version & Change Mgmt Systems Analysis & Design
System Acceptance
SW Design
46
Powered by
47
48
Learn more at: IBM Rational software IBM Rational Software Delivery Platform Process and portfolio management Change and release management Quality management Architecture management
Rational trial downloads Leading Innovation Web site developerWorks Rational IBM Rational TV IBM Business Partners IBM Rational Case Studies
Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBMs sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
Back-up
Safety-Related Concepts
Accident is a loss of some kind, such as injury, death, or equipment damage Risk is a combination of the likelihood of an accident and its severity: risk = p(a) * s(a) A Hazard is a set of conditions and/or events that leads to an accident.
Hazards are predictable and therefore controllable A safety-relevant system contains two kinds of hazards Intrinsic hazards - due to the inherent job and operational environment of the system Technology hazards - due to the addition of specific technological solutions
A safety control measure is an action or mechanism to improve the safety of the system by either
Reducing the severity of the accident Reducing the likelihood of the accident
A fault is the nonperformance of a system or component and may be either random or systematic Fault Tree Analysis determines what combinations of conditions or events are necessary for a hazard condition to occur
Allows the developer to lower the risk of a Safety violation, critical for IEC 62304
51
Safety Metamodel
52
53
54
55
56