SEMI E30-1000：通用通信与控制模型标准（GEM）概述

需积分: 10 9 浏览量更新于2024-07-15 收藏 685KB PDF 举报

SEMI E30-1000通用通信与控制模型（GEM）是一份由半导体工业协会(SEMI)在1992年和2000年发布的技术标准，主要针对制造业设备的通信与控制。该模型由全球信息与控制委员会（Global Information & Control Committee）批准，并由北美信息与控制委员会负责，经过了1992年至2000年间多次修订，于2000年7月14日和8月28日分别获得北美区域标准委员会的认可。最初的版本于2000年8月在SEMI官方网站上发布，计划于同年10月正式出版。该文档的核心内容包括以下几个部分： 1. **介绍**：概述了标准的历史发展，包括修订历史，明确GEM的适用范围，即制造设备的通信与控制。同时，定义了GEM的目的，如提供统一的框架和术语，以便于设备制造商、系统集成商和用户之间的沟通。 - **GEM的范围**：通过图1.1展示，GEM适用于所有类型的制造设备，无论其复杂程度如何，都应遵循此模型进行设计和实现。 - **GEM组件概述**：图1.2展示了GEM模型的主要组成部分，包括通信模块和控制模块，这些模块共同确保设备间的协调工作。 1. **定义**：文档详细列出了与GEM相关的专业术语，以确保所有参与者对词汇的理解一致。 2. **状态模型**： - **状态模型方法**：介绍了构建设备状态模型的基本原理和步骤，强调了模型在设计中的关键作用。 - **通信状态模型**：通过图3.0和图3.2.1展示了设备通信过程中的状态变化，以及对应的表3.2，提供了状态转换表格，便于理解设备在不同通信阶段的行为。 - **控制状态模型**：类似于通信模型，控制状态模型展示了设备控制流程的状态和转变，见图3.3和表3.3，强调了控制逻辑的重要性。 3. **设备处理状态**：图3.4和表3.4展示了设备在执行特定任务时的不同处理状态，这有助于优化设备的工作流程和响应时间。 SEMI E30-1000通用通信与控制模型为制造业设备的设计和通信提供了一个标准化框架，通过定义清晰的状态模型，促进了设备间的信息交换和控制操作的统一性，从而提升整个生产线的效率和可维护性。遵循这个模型，制造商和用户可以确保设备在不同环节上的兼容性和互操作性。

SEMI E30-1000 © SEMI 1992, 200015

Table 3.3 CONTROL State Transition Table

# Current State Trigger New State Action Comments

1 (Undefined) Entry into

CONTROL state

(system

initialization).

CONTROL

(Substate

conditional on

configuration).

None Equipment may be configured to

default to ON-LINE or OFF-LINE .

(See NOTE 1.)

2 (Undefined) Entry into OFF-

LINE state.

OFF-LINE

(Substate

conditional on

configuration.)

None Equipment may be configured to

default to any substate of OFF-LINE.

3 EQUIPMENT

OFF-LINE

Operator actuates

ON-LINE switch.

ATTEMPT ON-

LINE

None Note that an S1,F1 is sent whenever

ATTEMPT ON-LINE is activated.

4 ATTEMPT ON-

LINE

S1,F0. New state

conditional on

configuration.

None This may be due to a communication

failure (See NOTE 2), reply timeout, or

receipt of S1,F0. Configuration may be

set to EQUIPMENT OFF-LINE or

HOST OFF-LINE.

5 ATTEMPT ON-

LINE

Equipment

receives expected

S1,F2 message

from the host.

ON-LINE None Host is notified of transition to ON-

LINE at transition 7.

6 ON-LINE Operator actuates

OFF-LINE switch.

EQUIPMENT

OFF-LINE

None “Equipment OFF-LINE” event occurs.

(See NOTE 3.) Event reply will be

discarded while OFF-LINE is active.

7 (Undefined) Entry to ON-LINE

state.

ON-LINE

(Substate

conditional on

REMOTE/LOCAL

switch setting.)

None “Control State LOCAL” or “Control

State REMOTE” event occurs. Event

reported based on actual ON-LINE

substate activated.

8 LOCAL Operator sets front

panel switch to

REMOTE.

REMOTE None “Control State REMOTE” event

occurs.

9 REMOTE Operator sets front

panel switch to

LOCAL.

LOCAL None “Control State LOCAL” event occurs.

10 ON-LINE Equipment accepts

“Set OFF-LINE”

message from host

(S1,F15).

HOST OFF-LINE None “Equipment OFF-LINE” event occurs.

11 HOST OFF-LINE Equipment accepts

host request to go

ON-LINE

(S1,F17).

ON-LINE None Host is notified to transition to ON-

LINE at transition 7.

12 HOST OFF-LINE Operator actuates

OFF-LINE switch.

EQUIPMENT

OFF-LINE

None “Equipment OFF-LINE” event occurs.

NOTE 1: The configuration mentioned for transitions 1 and 2 should be a single setting. This would provide the user with a choice of entering

the EQUIPMENT OFF-LINE, ATTEMPT ON-LINE, HOST OFF-LINE, or ON-LINE states.

NOTE 2: Communication failures are protocol specific. Refer to the appropriate protocol standard (e.g., SEMI E4 or SEMI E37) for a protocol-

specific definition of communication failure.

NOTE 3: Any host initiated transaction open at the equipment must be completed. This may happen either by sending the appropriate reply to

the host prior to sending the event message or by sending an Sx,F0 message following the event message (i.e., after the transaction).

SEMI E30-1000 © SEMI 1992, 2000 16

3.4 Equipment Processing States — The behavior of

the equipment in the performance of its intended

function must be documented. This processing state

model is highly dependent on the equipment process,

technology, and style. However, there are expected to

be common aspects to these models.

The Processing State Diagram, Figure 3.4, is provided

as an example of an implementation model. This model

demonstrates the expected nature of the processing state

model documentation. There is no requirement that

these specific states be implemented.

The equipment must generate collection events for each

processing state transition, as well as provide status

variables (ProcessState, PreviousProcessState) whose

values are the current processing state and the previous

processing state.

In referring to the Processing State Diagram, note that

the initialization state INIT is not an actual processing

state. It is shown here simply to indicate that the IDLE

processing state is entered upon completion of

equipment system initialization. On the following pages

detailed descriptions are provided for the equipment

processing states and state transitions (numbered) as

shown in the diagram.

3.4.1 Description of Equipment Processing States

IDLE

In this state the equipment is awaiting instructions.

PROCESSING ACTIVE

This state is the parent of all substates where the context

of process program execution exists.

PROCESS

This state is the parent of those substates that refer to

the active preparation and execution of a process

program.

SETUP

In this state all external conditions necessary for process

execution are satisfied, such as ensuring material is

present at the equipment, input/output ports are in the

proper state, parameters such as temperature and

pressure values are within limits, etc. If all setup

operations are already complete, then this becomes a

fall through state and a transition to the next state takes

place.

READY

In this state the equipment is ready for process

execution and is awaiting a START command from the

operator or the host.

EXECUTING

Executing is the state in which the equipment is

executing a process program automatically and can

continue to do so without external intervention.

PAUSE

In this state processing is suspended and the equipment

is awaiting a command.

Each state transition is defined in the following table.

Note that all transitions in this table should be

considered collection events.

Figure 3.4

Processing State Diagram

SEMI E30-1000 © SEMI 1992, 200017

Table 3.4 Processing State Transition Table

# Current State Trigger New State Action Comments

1 INIT Equipment initialization

complete.

IDLE None None

2 IDLE Commit has been made to set

up.

SETUP None None

3 SETUP All setup activity has

completed and the equipment

is ready to receive a START

command.

READY This activity is

equipment-

specific.

None

4 READY Equipment has received a

START command from the

host or operator console.

EXECUTING This activity is

equipment-

specific.

None

5 EXECUTING The processing task has been

completed.

IDLE None None

6 PROCESSING

ACTIVE

Equipment has received a

STOP command from host or

operator console.

IDLE None None

7 PROCESSING

ACTIVE

Equipment has received an

ABORT command from host

or operator console.

IDLE This activity is

equipment-

specific.

None

8 PROCESS The equipment decides to

PAUSE due to a condition

such as alarm.

PAUSE This activity is

equipment-

specific.

For this type of

problem, an

operator assist is

usually required.

9 PROCESS Equipment has received a

PAUSE command from host

or operator console.

PAUSE This activity is

equipment-

specific.

None

10 PAUSE Equipment has received a

RESUME command from

host or operator console.

PROCESS

substate

This activity is

equipment-

specific.

None

4 Equipment Capabilities and Scenarios

This section describes the details of the capabilities

required by GEM and provides scenarios for their use.

Capabilities are operations performed by semiconductor

manufacturing equipment. These operations are initiated

through the communications interface using SECS-II

messages. A scenario is a group of SECS-II messages

arranged in a sequence to perform a capability. Other

information may be included with the scenario for

clarity. For each capability, the reader is provided with

a statement of purpose, pertinent definitions, a detailed

description, requirements, and scenarios.

The following capabilities are discussed:

Establish Communications

Event Notification

Dynamic Event Report Configuration

Variable Data Collection

Trace Data Collection

Limits Monitoring

Status Data Collection

On-line Identification

Alarm Management

Remote Control

Equipment Constants

Process Program Management

Material Movement

Equipment Terminal Services

Error Messages

Clock

Spooling

Control

4.1 Establish Communications — The Establish

Communications capability provides a means of

formally establishing communications following system

initialization or any loss of communications between

communicating partners, and thus of notifying the

communication partner that a period of non-

communication has occurred.

4.1.1 Purpose — Communications between host and

equipment are formally established through use of the

Establish Communications Request/Establish

Communications Acknowledge transaction.

The use of S1,F1/F2 for this purpose is ambiguous since

the transaction can be used for other purposes and may

occur at any time.

The S1,F13/F14 transaction, used in conjunction with

the Communications State Model, provides a means for

equipment to notify the host, or the host to notify the

equipment, that there has been a period of inability to

communicate. The successful completion of this

transaction also signals a possible need for

synchronization activities between host and equipment.

4.1.2 Definitions

COMMACK — Acknowledge code returned in the

Establish Communications Acknowledge message. See

the SEMI E5 Standard for a full definition of this data

item.

EstablishCommunicationsTimeout — An equipment

constant used to initialize the interval between attempts

to re-send an Establish Communications Request. This

value specifies the number of seconds for the interval.

See the SEMI E5 Standard for a full definition of this

variable data item.

4.1.3 Description — There are potential problems

when one side of the communications link fails and the

other side does not detect it. From the point of view of

the host, a loss of communications has many possible

causes. In some cases, host-controlled settings on the

equipment may need to be reset. In other cases, the

equipment may have continued an automatic processing

sequence during the period of no communication and

may have changed states. The definition of a formal

protocol for establishing communications alerts the host

to the need to synchronize itself with the equipment’s

current status.

Equipment shall consider communications as formally

established whenever either of the following conditions

have been satisfied:

— Communications Request has been sent to the host

and an Establish Communications Acknowledge

has been received within the transaction timeout

period and with an acknowledge code of Accept, or

— Communications Request has been received from

the host, and an Establish Communications

Acknowledge response has been successfully sent

with an acknowledge code of Accept.

When the equipment sends an Establish

Communications Request to the host, this notifies the

host of the possible need to synchronize itself with the

equipment.

When the equipment is attempting to establish

communications, an Establish Communications Request

shall be sent periodically until communications have

been formally established as described above. The

interval between attempts must be user-configurable and

begins as soon as a connection transaction failure is

detected (see Section 3.2).

Attempting to establish communications is not a low-

level connectivity issue, but rather a logical application

issue used by either party to notify its partner that the

host may need to perform synchronization activities

with the equipment.

4.1.4 Requirements

— Equipment must support the Communication State

Model (see Section 3.2).

— Equipment must provide the EstablishCommunica-

tionsTimeout equipment constant described above.

14 Satisfaction of either of these conditions will result in a transition

to the COMMUNICATING substrate. See Section 3.2 for further

detail.

剩余88页未读，继续阅读

wwkwangwenkai

粉丝: 142
资源: 8

SEMI E30-1000：通用通信与控制模型标准（GEM）概述

SEMI E30&E30.1&E30.5

E30gem译文对照.7z

SEMI E87 -0301

SEMI E30-1000 GENERIC MODEL FOR COMMUNICATIONS AND CONTROL.docx

SEMI E30 - 0299.pdf

SEMI E30-0200标准：半导体制造设备通讯与控制通用模型

SEMI E30.pdf

SEMI E30.zip

semi标准合集.pdf

SEMIE30-0200_GEM.pdf

最新资源