The purpose of this handbook is to describe how to perform quality assurance during a safety project in addition to the Quality Management System. Other documents with "Safety Handbook" in the title belong to this Safety Handbook. Although existing as separate documents they are functionally integrated parts and as such are linked in the Safety Handbook. Those documents are:
For the development of a non-SIL classified function with a recommended safety integrity level of SIL 1 during development, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.
For the development of a non-SIL classified library, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.
For the development of a function with a required safety integrity level SIL 1, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.
For the development of a function with a required safety integrity level SIL 2, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.
For the development of a function with a required safety integrity level SIL 3, this document lists measures for avoiding systematic failures during PHASE 1 up to PHASE 7.
---
The purpose of this document is to provide an overview of the safety-related artifacts that need to be created during the development of a safety product in addition to the artifacts required for related non-safety development.
The purpose of this document is to provide an overview of the documents referenced in the Safety Handbook that are used for the development of functionally safe products within PCP R&D.
The objective of this guideline is to describe the procedure of how to perform HAZOP analyses for Electrical/Electronic/Programmable (E/E/PE) safety-related systems, explain the reasons for performing a HAZOP, give an overview of the process, and explain the terminology and concept. The HAZOP is a recommended technique in IEC 61508.
A product issue is a uniquely identified problem impacting a product, requiring clear communication with various stakeholders. It must be documented with accurate information and version details and managed in parallel with bug management and product releases.
An existing Azure DevOps (ADO) project - on-premises or in the cloud - may differ from the current standard PCP work item templates due to historical reasons or tailoring. This guide lists the steps and tools to adopt standard work item templates in an existing ADO project with existing data.
This guide focuses on describing the practical change of the work item, starting from a process change request received, to the completion of a pull request updating the template.
This guideline aims to describe how to conduct internal Functional Safety Management (FSM) audits in ABB PCP R&D, as well as how to monitor and handle external FSM audits conducted by the Independent Safety Assessor (ISA) for ABB PCP R&D.
Mechanics includes all parts that are not electrical, such as housings, baseplates, and labels. All mechanics are created in a CAD tool.
This guide describes how to add a software supplier in Decision Focus.
In emergency situations, software corrections may be required in a short time frame to solve a critical issue on the customer site. This type of emergency correction will be handled as a temporary correction (TC).
This guide takes you through the steps to initiate a change on the PCP R&D Processes website by creating a process change request (PCR). It also includes information on how the process teams handle submitted PCRs and updates to the R&D processes.
This guide describes how to add 3rd-party software to Decision Focus.
This page describes how to add software use in Decision Focus.
The purpose of this guide is to provide hands-on support to the roles involved in setting up a test plan and test suites in Azure DevOps (ADO), demonstrating the product's test coverage.
This guide describes how to use Markdown to document technical information using the Azure DevOps (ADO) wiki. The Markdown files can be reviewed, approved, and baselined with the code. The code and technical documentation can be restored from the same baseline when a released product needs to be updated.
This guide provides hands-on support for the roles involved in executing test cases and reviewing test results.
Introduction
A bug can exist in multiple releases, and such bugs can be challenging to track and fix. This guide describes how to manage them.
During the development of a release, if a bug is found but the CCB decides to fix it in a later version, the bug is deferred. After the official release, it will then be a known bug in the product or system.
This guide describes the steps to handle 3rd-party software that has reached end-of-life (EOL) and "Operational risks" identified by Black Duck for OSS.
A work item of type "Bug" can be used to suggest an enhancement, something that is not a real defect, but an idea for improvement. This guide describes how to handle enhancements as bugs.
This guide describes the measures and activities to handle non-conformities for equipment intended for explosive atmospheres.
Some minor hardware changes to products can be implemented without setting up a project. This guide describes the steps involved and the checklists that shall be used.
This guide describes the process for handling software vulnerabilities in products within PCP R&D. It includes instructions on everything from recording a description of a reported issue to documenting and communicating its remediation.
This guide describes how to determine if a malware suspicion is correct or false and how to handle both scenarios. It also includes information about how malware is detected in ABB software.
This document describes steps to be taken when vulnerabilities are detected for any type of 3rd-party components like OSS, runtime cost, development cost- free runtime, components used in development and testing of our products.
When starting a new project there are several tasks to be performed to ensure that tools and systems are well set up when M0/G0, M1/G1, and M2/G2 are reached.
A bug is an unexpected problem in the software or hardware which can be reported for any issue in a product by e.g. product managers, product owners, test engineers, or customers (via L3 or L4 Support).
This guide describes how to manage documents related to functional safety certifications. It also includes information on how to manage continuous updates of such documents under Details.
Various certifications are applied for in the development of products. This guide covers the ten activities of the general certification flow, and includes specific information regarding marine certifications, certifications for hazardous areas, certification affecting manufacturers, and the order of certification applications.
This guide describes the routines for stopping and restarting the manufacturing, delivery and/or ordering of products within PCP.
This guide describes the approach for mapping the lifecycle components derived from the technology product releases, to the branded products (800xA, Symphony Plus, etc.). It also covers how to gather the data and share relevant ECCN-related information with the product classification team.
Binary composition analysis is a method used to examine the components inside binary files to detect and manage security risks. This guide describes how to perform such analysis with Black Duck Binary Analysis (BDBA).
This guide describes how to import and export “Software” and “Software Use” lists in Decision Focus.
The purpose of configuration auditing is to objectively assess the integrity of a product, both from a functional and physical perspective.
This guide describes the activities to perform explosion protection (Ex) audits within the PCP organization.
This guide describes the activities to perform explosion protection (Ex) training within the PCP organization.
This guide describes the activities to perform explosion protection (Ex) audits at external manufacturing services (EMS).
Threat modeling is the process of analyzing various business and technical requirements of a system identifying the potential threats, the mitigations of these threats, and documenting the vulnerabilities these threats have on the system.
Defining a team in Azure DevOps (ADO) allows the use of planning and visualization features, for example, the team backlog, sprints, capacity planning, boards, and team dashboard.
The ABB Cyber Security Assessment Tool Importer is an internal utility tool used to import the security requirements from various assessment spreadsheets into Azure DevOps (ADO) as security work items.
This guide describes how to handle epics in streams. It includes examples of epic descriptions and information about the epic definition, grooming, and change management.
This guide describes how to handle features in streams. It includes examples of feature descriptions and information about the feature definition, grooming, and change management.
The purpose of this guide is to provide hands-on support to the roles involved in defining the system architecture influenced by requirements, captured in the system epics, epics, and features.
This guide describes how to handle system requirements and system epics. It includes descriptions and information about the system requirement / system epic definition, workflow, grooming, and change management.
Safety tool selection strategy
For a new epic, feature, or user story, there may be a need to write new test cases or modify existing test cases. The purpose of this guide is to provide hands-on support to the roles involved in writing, updating, or reviewing test cases of a product.
This code review guideline is written for those in the Control organization working with Git and includes the functional safety related aspects to adhere to. The guideline is directed to both source code level as well as feature level.