How-to Create a Temporary Correction
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 document provides an overview of the handling of TCs. It describes the high-level process applied, the roles involved, and their responsibilities.
This document points several times to the Product Issue Database (PID), which isn’t available completely for all products yet. It’s intended that all products will be part of the PID in the near future. As long as a product isn’t part of the PID, the product-related workflows are accepted.
Note: This description is not applicable for safety-related corrections (certified corrections).
Intended for
- Product managers, product owners, L4 coordinators, and L3 Support.
Activities
TC request
A request for a TC is usually initiated by a customer support case. The TC can also be requested by divisions or within R&D for severe or urgent issues. A request must include motivation and no viable workaround should be available. The handling of field communications (product bulletin, product alert, etc.) isn’t handled by the TC process description. For details related to field communication, see 3BUL980146 Writing and Publishing Field Communication.
The TC requests are accepted by following the defined life cycle policies for the different system families, see System 800xA Life Cycle Policy as reference. Note that the policy may differ depending on which system the TC is requested for. The customer must also have an active ABB Care Automation Software Maintenance agreement.
An issue related to a TC request must always be associated with a Product Issue Number (PIN), and corresponding bug(s) in Azure DevOps (ADO).
The TC request will be evaluated in the respective change control board (CCB), as described in TC approval. Approval for an existing TC is made by the product owner or L4 coordinator, see TC delivery for more information on TC distribution.
The L4 coordinator is responsible for driving the request to a decision and communicating it to the person requesting the TC, normally the support case caller.
Evaluation workflow:
TC approval
The L3 or L4 coordinator is responsible to carry the customer's voice:
- Confirms that a TC is the only viable solution, no acceptable workaround exists, etc.
- Understanding the customer's problem
- Expected delivery dates from the customer
The product owner is responsible to collect the technical impact:
- Estimated time to fix, verify and deliver (man-hours).
- Risk.
- Severity.
Product management is responsible for making the decision, including motivation and consequences for the customer if the request is rejected. The possibility of escalation by other roles (e.g. sales, support, etc.) is possible at any time.
TC planning
The product owner is responsible for delivering a TC within the release date which will be defined after TC planning is finished.
The planning step in the TC process shall ensure that all prerequisites are fulfilled so that the execution and delivery can be done smoothly.
The product owner is responsible for completing this step, in collaboration with the L4 coordinator.
The rough procedure is as follows:
Confirm that the version in which the TC is requested is the correct customer system version
Check with L4/L3 for which customer the TC shall be created and which version (= target version) is installed there.
Define timing and resources and get commitment from all involved parties
Take the data from the previous step (time estimation, risk, severity, etc.) and define the next steps. The product owner is responsible for creating an epic in ADO for the TC. There are two options for the planning:
- The development and test of this TC fit into the available time set of the current increment for the developers/configuration manager / tester or the severity/criticality of the bug is so low that a solution is sufficient for an upcoming increment.
- Inform the L4 coordinator, release owner, and product manager / product line manager.
- Inform the L4 coordinator, release owner, and product manager / product line manager.
- The severity/criticality is high, we cannot wait, and the available resources are planned/blocked by other tasks. Replanning the current increment is necessary.
- The product owner is responsible to get in touch with the product manager, L4 coordinator, release owner, and head of development to create a proposal on how to handle this TC. Clarify:
- Needed resources (developer, tester, configuration manager, etc.).
- Impact on the budget (additional resources, external resources, etc.).
- Impact on ongoing and planned work items.
- Get approval from management/SteCo.
- The product owner is responsible to get in touch with the product manager, L4 coordinator, release owner, and head of development to create a proposal on how to handle this TC. Clarify:
TC execution
When a TC has been approved and planned it’s time to start the work on producing the TC.
The product owner is responsible for the TC execution but can delegate to e.g. the release owner or L4 coordinator.
As a first step of the execution, a TC checklist must be created. The checklist is available in the List of Document Templates for L4 & Maintenance.
When the checklist has been created a test plan must be defined.
When the test plan ready it’s time to start the TC development, following the software development process. This is followed by the build process for the TC, described in the configuration management process.
When a build is ready the related bugs shall be validated, and the planned test cases are executed and documented (e.g. in the TC checklist or in a test record). The tests have to follow the test process.
All output from a TC must be stored in the document management system (DMS). All concerned PINs and the TC (release version) must be added, prepared, and published in the PID.
The mandatory deliverables for a TC project are:
- Software package (following applicable CM rules described in reference).
- A list of bug corrections included in the TC (will be included in the TC checklist).
- A record of all tests executed to secure the quality of the TC (can be documented in the TC checklist, otherwise a reference to the test record).
- TC checklist.
- Release notes.
TC delivery
Place the TC in a shared area for ABB internal access, e.g., OneDrive or DMS, for TC distribution.
A TC delivery must include:
- Customer authorization letter.
- Release notes.
- Software package.
The L4 Coordinator register the TC delivery in the PID. (For products not yet using the PID, the L4 coordinator maintains an Excel spreadsheet that documents the TC delivery.)
The following information is mandatory/optional when registering a TC delivery:
| Delivery information | Mandatory/Optional |
|---|---|
| Product | Mandatory |
| TC release | Mandatory |
| System ID | Mandatory* |
| Delivery date | Mandatory |
| Support case number | Optional* |
| Customer/site | Optional |
| Recipient (Delivered to) | Optional |
| Comments | Optional |
The TC will be delivered by the L4 coordinator from R&D to the internal ABB customer. The distribution to the end customer is product specific and is typically managed by the L2 or L3 support levels.