System state information is often used to benchmark the reliability of a system. Therefore on a time scale it is estimated how long the system was productive, defective or in maintenance. To support this, a system should be able to publish its current state in a way enabling a client to do such estimation.

This standard follows the scheme of 6 basic system states defined by SEMI E10 standard (SEMI E10: Specification for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM) and Utilization). The following diagram shows how the total time of existence of a system is divided into different categories. From the left to the right the model gets more detailed.

Table 137 – E10 system states

E10

Total Time

Operations Time

Uptime

Manufacturing Time

Production

PRD

Standby

SBY

Engineering

ENG

Downtime

Scheduled Downtime

SDT

Unscheduled Downtime

UDT

Nonscheduled Time

NST

If the optional SystemState variable exists on the server, the vision system shall continuously map its internal state to one of the six generic states on the right. This current state shall be published in the SystemState variable in the interface.

The vision system is currently working on a job.

The vision system is ready to accept a command but is currently not executing a job. It could for example be waiting for a Start command or a user input.

The vision system is not working and not ready to accept a command because a user is currently working on the system. This could be for editing a recipe or changing the system configuration.

The vision system is not available for production and this was planned in advance. This could be for cleaning, maintenance or calibration works.

The vision system is not available for production due to failure and repair. This covers all kinds of error states that might occur during operation.

The vision system is not working because no production was scheduled. This also covers things like operator training on the system.

Example:

An application specific extension of the base states:

E10

vendor / application specific extension

PRD

Acquisition

ACQ CAM A

 

 

ACQ CAM B

 

Processing

SBY

Waiting for PREPARE

 

Waiting for START

ENG

Recipe Editing

 

Calibration

SDT

Maintenance

 

Cleaning

Optics A

 

 

Optics B

UDT

Software Related Error

 

Hardware Related Error

NST

Powered Off

 

Operator Training

If the system is in state “ACQ CAM A” the current path would be “PRD/Acquisition/ACQ CAM A

The tree-like E10 scheme may be extended to the right by getting more specific on the current state of action the system is performing. As in the original E10 scheme, at every time the system has to choose exactly one state (rightmost field of a branch) it is currently in. To be compatible to clients understanding only the basic E10 states the system has to give the “/” separated path running along the branch of that tree starting from the base E10 state to the current state.

The same scheme should be used to structure error states. Every error information carries such path information to enable generic clients without deeper application knowledge to get a basic understanding of the possible error cause. The following basic error paths shall be used. As above this model may be expanded to the right as needed.

Table 138 – Basic error paths

UDT

Software Related Error

 

Hardware Related Error

Computing Unit

 

 

Sensor Unit

 

 

Controller Unit

 

 

Lighting Unit

The system can only be in one specific state (leaf of the tree), although errors can occur in more than one leaf simultaneously. In this case the system still has to select exactly one system state to be published.

There are two different approaches possible:

  1. The system selects the most severe error and publishes its path as the current system state.
  2. The system truncates the path to the last element common for all active errors.

The system may select one approach fitting to the current application.

Example:

A system is in an Error State and there are currently two errors active. The system uses application specific extended error classes:

  • UDT/Hardware Related Error/ Sensor Unit/Camera A/Fan Fail
  • UDT/Hardware Related Error/Lighting Unit/LED A/Over Temperature

Possibility 1:

The system decides that an over temperature is the most severe error and publishes “UDT/Hardware Related Error/Lighting Unit/LED A/Over Temperature“ as its system state.

Possibility 2:

The system publishes the truncated path “UDT/Hardware Related Error” as its current system state.