The "Technician" role have extended workflow functionality in Operator Interface, allowing users in this role to resolve issues or handle abnormal situations on site. This article is meant as a guide for technicians to understand the extended functionality, common issues that might arise, and how to identify and resolve them to ensure a stable production environment.
Suspending/resuming and cancelling workflows
When a unit needs to be tested during repair, or in circumstances when issues with the workflow has occurred, a technician can resolve these type of situations by controlling the state of the workflow by using the Suspend, Resume and Cancel functions.
Screen capture from Operator Interface during workflow execution. Buttons are located in top right corner below the unit header.
- Suspend: Possible to run tests on ATE without using any validation and constraints from the workflow (the workflow must be resumed afterwards). When the unit is under repair and the "Identify UUT Report" step in the repair wizard has been completed, the workflow is suspended and resumed when the UUR report has been submitted.
- Cancel: When a workflow instance was created by mistake on a finalized unit. This can occur when a unit is scanned in Operator Interface, and the application is configured with Start Page = Execute Workflow and Workflow Auto Initialize = On. A technician should cancel the workflow.
- Cancel: When an "Internal Workflow Error" has occurred. If the error is recurring, the instance cannot recover. A new instance must be created, but a technician must cancel the unrecoverable instance first (Cancel deletes the instance).
Forcing units through processes
A technician have the privilege to force a unit through any process in a workflow. This privilege is only meant to be used in scenarios when issues has prevented the workflow to execute as normal.
- The test sequence completed normally (in TestStand for instance), but the workflow was not able log if the test process started or ended because of a workflow error. If the test passed (check if a passed UUT report is found for this unit/process), a technician should force the unit to the next process in the workflow. This is acheived by pressing "Passed" in the Execute Workflow function.
- When a test has been run several times with a result of only Error or Terminated, and the maximum test errors limit has been reached, the workflow usually sends the unit to Repair. A result of Error or Terminated does not neccessarily indicate a component failure, and a technician could force the workflow to skip the repair process when this occur.
The below view lets technicians set the result manually on automated tests by clicking "Passed" or "Failed". Maximum test count is always measured against a variable (set in the workflow definition) which defines how many times a test can fail before the unit is sent to repair.
When a test has failed as many times as allowed, a technician can skip the repair process if the test failed with status Error or Terminated.
Setting the phase of a unit
Unit phase is set through the Unit Info function. This function should only be used when the current phase of a unit is incorrect. The current process of the unit may also be set, but does not directly affect the workflow in any way.
- When a workflow instance was created by mistake on a finalized unit, causing the unit phase to be set to "Under Production" or similar. A technician should cancel the workflow and set the unit phase back to "Finalized". An easy way to identify if this is the cause
- Verify that a workflow instance exist through the Execute Workflow function
- Verify that the unit was finalized earlier through the Unit History report in Operator Interface
- The unit phase is incorrect. A common cause could be a data replication conflict, typically when unit information have been updated both locally and on the parent server since the last replication. This could generate a conflict since the replication agent could be undetermined on which update to submit as the winner.