This book aims to facilitate and improve development work related to all documents and information required by functional safety standards.
Proof of Compliance (PoC) is important for the assessor and certification bodies when called up to confirm that the manufacturer has developed a software system according to the required safety standards. While PoC documents add functionality to the product neither for the developer nor for the customer, they do add confidence and trust to the product and ease certification, and as such are important for the product’s value. In spite of this added value, the documentation needed for PoC is often developed late in the project and in a haphazard manner.
This book aims at developers, assessors, certification bodies, and purchasers of safety instrumented systems and informs the reader about the most important PoC documents. A typical PoC documentation encompasses 50 to 200 documents, several of which are named in the safety standards (e.g., 82 documents in IEC 61508:2010 series, 101 documents in EN 5012X series and 106 work products in ISO 26262:2018 series). These documents also include further references, typically one to twenty of them, and the total number of pages developed by the manufacturer varies between 2000 and 10000 pages. The book provides guidance and examples what to include in the relevant plans and documents.
Author(s): Thor Myklebust, Tor Stålhane
Publisher: Springer
Year: 2022
Language: English
Pages: 292
City: Cham
Preface
Acknowledgment
Contents
Acronyms
Chapter 1: The Introduction
1.1 What Is This Book About?
1.2 Front Page of Documents
1.3 Reuse of Documents
1.4 Communication
1.4.1 Why Is Communication So Difficult
1.4.2 Communication in Agile Projects
1.5 Communication and Learning from Experience
1.6 Communication and the Guilds
1.7 Market Access and Certification
1.8 Prescriptive vs. Goal-Oriented Standards
1.8.1 Introduction
1.8.2 A Path to a Goal-Oriented Approach
1.8.3 The IMO 5-Tier Approach
1.8.4 The Need for a Safety Case
1.8.5 The Link to Safety Plan and the Safety Case
References
Chapter 2: Agile Practices
2.1 Overview
2.1.1 Practices Suitable Both for Traditional and Agile Processes
2.1.2 Practices Suitable in the First Safety Phases
2.1.2.1 Popular Practices Relevant for SCSW
2.2 More Detailed Information for Some of the Agile Practices
2.2.1 Acceptance Testing: A Development Practice
2.2.1.1 Information
2.2.1.2 Benefits
2.2.1.3 Safety Adaptations
2.2.2 Backlog, Backlog Splitting, and Backlog Refinement: Development and Planning Practice
2.2.2.1 Agile Definition
2.2.2.2 Benefits
2.2.2.3 Information and Safety Adaptations
2.2.3 Prioritized Work List: A Development Practice
2.2.3.1 Information
2.2.3.2 Benefits
2.2.3.3 Safety Adaptations
2.2.4 Daily Scrum Meeting (DSM) Including Four Questions: A Communication Practice
2.2.4.1 Information
2.2.4.2 Benefits
2.2.4.3 Safety Adaptations
2.2.5 Sprint Planning Meeting: A Planning Practice
2.2.5.1 Information
2.2.5.2 Benefits
2.2.5.3 Safety Adaptations
2.2.6 Time Boxing: A Development and Management Practice
2.2.6.1 Information
2.2.6.2 Benefits
2.2.6.3 Safety Adaptations
2.2.7 Incremental Development Including Iteration and Stepwise Integration: A Development Practice
2.2.7.1 Information
2.2.7.2 Benefits
2.2.7.3 Safety Adaptations
2.2.8 Shippable Code: A Development Practice
2.2.8.1 Information
2.2.8.2 Benefits
2.2.8.3 Safety Adaptations
2.2.9 Sprint Review: A Communication Practice
2.2.9.1 Information
2.2.9.2 Benefits
2.2.9.3 Safety Adaptations
2.2.10 Retrospective: A Communication Practice
2.2.10.1 Information
2.2.10.2 Benefits
2.2.10.3 Safety Adaptations
2.2.11 Definition of Ready: A Development Practice
2.2.11.1 Information
2.2.11.2 Vertical Slice and Horizontal Slice
2.2.11.3 Definition
2.2.11.4 Benefits
2.2.11.5 Context
2.2.11.6 Safety Adaptations
2.2.12 Definition of Done: A Development Practice
2.2.12.1 Information
2.2.12.2 Definition
2.2.12.3 Benefits
2.2.12.4 Context
2.2.12.5 Safety Adaptations
2.2.13 Behavior-Driven Development: A Development Practice
2.2.13.1 Information
2.2.13.2 Benefits
2.2.13.3 Safety Adaptations
2.2.13.4 Agile Practices: A Summary
2.3 Challenges and Agile Solutions
2.4 An Alternative View
2.5 Requirement Manager
2.6 Alongside Engineering
References
Chapter 3: POC in Agile Development and for SMEs
3.1 Agile and Kanban
3.2 Small SafeScrum Teams: Less Than Seven Persons
3.2.1 Introduction
3.3 What Is an Argument
3.4 POC for SMEs
3.4.1 Introduction
3.4.2 Quality and Safety Culture
3.4.3 Organization Requirements
3.4.4 Management Requirements
3.4.5 On Projects in SMEs
References
Chapter 4: Generic Documents
4.1 Document and Information Management Plan
4.1.1 Definitions
4.1.2 The Plan
4.2 On Living Documents
4.3 Change Impact Analysis Report
4.3.1 Introduction
4.3.2 Input Documents and Related Plans
4.3.3 Minor Safety Issues and Relevant Process
4.4 Code Baseline and Configuration Management
4.5 Safety Techniques and Measures: Software
4.5.1 Introduction
4.5.2 Requirements and Relevant Process
4.5.3 TandM and the Safety Life Cycle
References
Chapter 5: Plans and Functional Safety Management
5.1 Safety Plan
5.1.1 Safety and Agility
5.1.2 A Safety Plan and an Agile Safety Plan
5.1.3 Summary
5.2 Functional Safety Management (FSM)
5.2.1 Introduction
5.2.2 Safety Culture
5.2.3 Safety Plan Related Issues
5.3 Software Quality Assurance Plan (SQAP)
5.3.1 Introduction
5.3.2 Quality Standards: The Important Parts
5.3.2.1 Organizational Requirements
5.3.2.2 Quality Culture
5.3.3 Product Requirements
5.3.3.1 Review of System and Product Requirements
5.3.3.2 Customer Communication
5.3.4 Agile Development: Opportunities and Challenges
5.3.4.1 QA Role Task 1: Code Metrics
5.3.4.2 QA Role Task 2: Documentation and Code Coverage
5.3.4.3 QA Role Task 3: Test Coverage (Aka Code Coverage)
5.3.4.4 QA Role Task 4: Check Requirements-Task-Code Traceability
5.3.5 Toward a Quality System
5.3.5.1 Development
5.3.5.2 Implementation
5.3.5.3 Maintenance
References
Chapter 6: Safety Analysis Methods Applied to Software
6.1 Introduction
6.2 Summary of Safety Analysis Methods
6.3 Early Hazard Analysis: PHA, HazId, HazOp, and CHazOp
6.4 Generic, Domain-Specific Hazard Lists
6.4.1 Output
6.5 FMEA and FMEDA
6.6 Fault Tree Analysis
6.7 Common Mode and Common Cause Failures
6.7.1 Introduction
6.7.2 Definitions
6.7.3 Common Mode Analysis (CMA)
6.7.4 Common Cause Analysis
6.8 PoC for FMEA and IF-FMEA
6.9 Hazards and Sub-hazards
6.10 Risk Acceptance: GALE and ALARP
6.11 Dynamic Risk and Safety Analysis
6.11.1 Introduction
6.11.2 Dynamic Safety and Risk
6.11.3 Dynamic Safety Cases and DevOps
6.11.4 Two Approaches to Analyzing Emergent Risks
6.11.5 Morphological Analysis: GMA
References
Chapter 7: Safety and Risk Documents
7.1 Hazard Log
7.1.1 HL and Requirements in Safety Standards
7.1.1.1 Generic Safety Standard
7.1.1.2 Railway
7.1.1.3 Automotive
7.1.2 Input Documents and Related Plans
7.1.3 Recommended Process Approach
7.1.4 Topics 1-7: Generic Parts
7.2 Safety and DevOps
7.2.1 Introduction
7.2.2 DevOps vs. Maintenance
7.3 Safety Analysis Reports
7.3.1 Introduction
7.3.2 The Analysis Report
7.3.2.1 Safety Threats and How to Mitigate Them
7.3.2.2 Recommendations for Further Studies
7.3.2.3 How to Address Uncertainties
7.3.2.4 Recommendations for Mitigation of Uncertainties Related to Safety Threats
7.3.2.5 Points that Need to be Considered during Operation and Maintenance
7.3.2.6 The Persons Participating in the Analysis
7.3.2.7 A List of the Parts Analyzed
7.3.2.8 A List of the Information Used
7.4 Hazard and Risk Analysis Report
7.4.1 Introduction
7.4.2 What a Hazard and Risk Analysis Report Should Contain
7.4.2.1 A Description of the System
7.4.2.2 The System´s Scope and Boundaries
7.4.2.3 Assumptions
7.4.2.4 Methodology Used for Safety and Hazard Analysis
7.4.2.5 Stakeholders
7.4.2.6 Methods Used
7.4.2.7 Data Sources
7.4.2.8 Guidewords, Failure Modes, Etc.
7.4.2.9 Summary of Results and Recommended Actions
7.4.2.10 Limitations of the Analysis
7.4.2.11 Analysis Records
7.4.2.12 Any Other Information
References
Chapter 8: Software Documents
8.1 Tools Validation Plan
8.1.1 Scope, Purpose, and Introduction
8.1.2 Input Documents
8.1.3 Requirements and Tool Process
8.1.3.1 Requirements in Safety Standards
8.1.3.2 Proven in Use
8.2 Tool Process
8.3 Release Plan and Notes
8.3.1 Release Plan
8.3.2 Release Notes
8.4 Change Log
8.5 Architecture Documents
8.5.1 Software Architecture Specification
8.5.2 Application Architecture and Design
8.5.3 Architecture Standard: An Example
References
Chapter 9: Test, Analysis, and VandV
9.1 FAT/SAT/CAT Report
9.1.1 Introduction
9.1.2 Factory Acceptance Test (FAT)
9.1.3 Site Acceptance Test (SAT)
9.1.4 Customer Acceptance Test (CAT)
9.2 Overall Software Test Specification and the Use of Scripts
9.2.1 Test Specifications
9.2.2 Scripts
9.3 Software/Hardware Integration Test Specification
9.4 Software Quality Assurance Verification Report
9.5 Software Architecture and Design Verification Report
9.6 Software Requirements Verification Report
9.7 Overall Software Test Report
9.8 Software Validation Report
9.8.1 Verification vs. Validation
9.8.2 Special Problems Related to Self-Driving Vehicles
9.8.3 Relation to the Software Validation Plan
9.8.4 Techniques and Methods
9.8.5 Acceptance Criteria
9.8.6 Error Handling
9.8.7 Validation of AI-/ML-Based Systems
9.8.8 Data Considerations
References
Annex: Overview of Documents and Work Products Mentioned in Functional Safety Standards Including Weak Parts of Safety Standar...
A - Introduction
B - Relevant Documents Not Mentioned in the Main Safety Standards
C - Weak or Missing Parts in Safety Standards
D - Overview of Documents Mentioned in Safety Standards
Overview of IEC 61508:2010 Information/Documents
References
