Fault Tracing Outside PCP Using a Debug Release

During L4 fault tracing it may be required to send a debug release outside of PCP. This has to be handled with care as it isn't a formally released software.

A debug release can be needed for different reasons, for example, when:

• Additional diagnostics are required for further fault tracing.
• It's difficult to verify a correction internally, for instance, related to heap corruption. Such verifications are often under time pressure and require quick feedback.

This guide provides two lists of prerequisites that should be met before sending out a debug release.

Intended for

• Product owners, L4 coordinators, L4 engineers, software engineers, and L3 support.

Prerequisites

Prepare the receiver

Fulfill the below tasks to ensure that the recipient understands the unique conditions associated with a debug release.

ID	Description	Status
1	Does the recipient understand that the software is a debug release?
2	Has the recipient confirmed their agreement to install the debug release software on their system?
3	Does the recipient understand that the software will not be maintained and must be removed after fault tracing/verification has ended?
4	Does the recipient understand that ABB has made no commitments to include the software changes in future releases unless explicitly agreed?
5	Is it clear to the recipient that ABB does not offer any liability with the debug release?

Quality assurance within R&D

Fulfill the below tasks to ensure that the debug release meets its quality criteria.

ID	Description	Status
1	Have you ensured that you have informed and obtained agreement from the certification body before delivering any debug version to the customer for certified products (at least for Safety)?
2	Are the code changes stored in Azure DevOps to be traceable, such as in a shelveset or branch, and associated with the bug work item if applicable?
3	Was the software made on an official build machine?
4	Were all necessary configuration management activities, including release signing, conducted on the official build machine for the software?
5	Does the software have a unique version identification?
6	If possible, is the software indicating that it is a debug version?
7	Is the software quality assured to a sufficient level through testing, code review, and other measures?
8	Has the software been scanned with antivirus programs and documented?
9	Are detailed installation instructions with any specific care that needs to be taken provided to the recipient?
10	Export control: (contact the trade compliance officer if any of the following questions are answered with a yes or if you have any doubts) - Has any new functionality been added (e.g., new, or major improved features, major change of performance/capacity, new operating environment)? - Have any changes to integrated US-origin 3rd-party software or USABB software items been made? - Have any changes to redistributed US-origin 3rd-party software or USABB software items been made? - Have any changes been made related to encryption?