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.