Guide To Understanding SECS

User Manual:

Open the PDF directly: View PDF .
Page Count: 28

Download
Open PDF In Browser	View PDF

A Guide
to
Understanding
GEM - SECS - HSMS

March 24, 2004
Version 1.1

 Copyright Edge Integration 2004

Table of contents

Introduction........................................................................................................................ 3
Overview ............................................................................................................................. 3
SECS ................................................................................................................................... 3
SECS-II Message Protocol ....................................................................................... 4
Streams and Functions ................................................................................................ 4
Message Layout .......................................................................................................... 5
Data Items ................................................................................................................... 7
Layout Encoding ......................................................................................................... 7
Common SECS-II Messages ...................................................................................... 11
SECS-I
Block Transfer Protocol ......................................................................... 12
Handshake Sequence ................................................................................................ 12
Block Data ................................................................................................................ 14
Example of S1F1 / S1F2 .............................................................................................. 17
Typical SECS Protocol Parameters .......................................................................... 18
RS-232

Physical Link ........................................................................................... 19

Protocol Troubleshooting ........................................................................................... 20
T2 Timeout................................................................................................................ 20
T3 Timeout................................................................................................................ 20
Function 0 ................................................................................................................. 21
Stream 9’s ................................................................................................................. 21
Establishing Communications .................................................................................. 22
HSMS ............................................................................................................................... 23
HSMS Procedures ....................................................................................................... 23
Select ......................................................................................................................... 23
Deselect ..................................................................................................................... 24
Link Test ................................................................................................................... 24
Data ........................................................................................................................... 24
HSMS Message Format .............................................................................................. 25
Typical HSMS Protocol Parameters ......................................................................... 26
GEM ................................................................................................................................. 27
What’s it all about....................................................................................................... 27
GEM Compliance........................................................................................................ 27

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 3

Introduction
The intent of this guide is to help simplify some of the principles around interfacing with
semiconductor equipment and their communications standards. This is not intended to be a
substitute for the Standards themselves since this guide does not cover all details o
f the Standards . It only serves as general overview to aid in the support of applications
that use or deal with such interfaces.
The information presented in this guide is believed to be correct and accurate. Please send all
comments and questions to john@edgeintegration.com
The information presented within this guide may be used to your benefit, and may be
reproduced and distributed freely providing the copyright notice remains intact. No further
permissions are required.

Overview
This guide discusses some of the SEMI Standards that cover the interfacing to semiconductor
equipment. The reader should have as a minimum, a technical background and some knowledge
about semiconductor fabs and computer science.

SECS
This is a discussion of SECS (Semiconductor Equipment Communication Standard). SECS is
part of the SEMI Standards, E4 and E5, Equipment Automation /Software Volume. It was
developed in 1980 by Hewlett Packard. SECS is a point-to-point protocol via RS-232.
SECS is a layered protocol consisting of 3 levels: Message Protocol, Block Transfer Protocol, and the Physical
Link.
SECS-II Message Protocol
SECS-I

Block Transfer Protocol

RS-232

Physical Link

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

SECS-II

Page 4

Message Protocol
SECS-II Message Protocol
SECS-I

Block Transfer Protocol

RS-232

Physical Link

The Message Protocol is used to send SECS-II messages between the Host and Equipment. Each
SECS-II message contains a primary message and an optional secondary reply message. This is
also referred to as a transaction.
HOST

EQUIPMENT

Primary

Secondary

Primary – Is a SECS-II message initially sent by either the Host or Equipment.
Secondary – Is an optional SECS-II message send in response to a primary message.

Streams and Functions
SECS-II messages are referred to as Streams and Functions. Each message has a Stream value
(Sx) and a Function value (Fy). In the case of a Stream 1 Function 1, it is written as S1F1, and
spoken as “S1F1”. Streams are categories of messages while Functions are specific messages
within the category. The function value is always an odd number in a primary message, and one
greater, or even, in the associated secondary reply.

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

HOST

Page 5

EQUIPMENT

S1F1 (primary odd)

S1F2 (secondary even)

Stream
1
2
3
4
5
6
7
8
9
10
11
12
13

Catagory
Equipment Status
Equipment Control
Material Status
Material Control
Alarm Handling
Data Collection
Recipe Management
Control Program Transfer
System Errors
Terminal Services
(Not Used)
Wafer Mapping
Unformatted Data
Set Transfers

Some Streams and Functions are reserved while others are user defined.
Stream
Function Availability
0
0 to 255 Reserved
1 to 63
0 to 63 Reserved
64 to 127
0
Reserved
1 to 63 64 to 255 User defined
64 to 127 1 to 255 User defined
All function 0’s have a special meaning. They are sent as a reply to an aborted primary
message.

Message Layout
A SECS-II message contains a structure or layout. The layout defines the all data items
for the SECS-II message. The layout is that part of the message which follows the
Stream and Function notation.
Stream and Function
S2F41

message layout

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 6

Message Annotation
Providers of SECS interfaces typically provide an interface manual. This manual details
the applicable SECS messages and their layouts. It may also include a Data Item Dictionary
that defines the message items.
SECS-II messages can be annotated using several conventions. Two of the more
common conventions are show below:
SEMI Standard
S1,F1 Are You There Request
Description: ….
Structure: Header only

S,H<->E,reply

S1,F2 On Line Data
Description: …
Structure:
L,2
1.
2.

S,H<->E

S – single block
M – multi block

Defined in the Data Item Dictionary

SML (SECS Message Language) Format
S1F1 – Are You There
S1F1 W.

Message direction
H - Host
E - Equipment

H<->E

S1F2 – On-line Data
S1F2
H<-E

Defined in the Data Item Dictionary

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 7

Data Items
From above, SECS-II message layouts contain data items. Data items are defined by format
codes. All possible data items, along with their format codes, are listed in the following table.
The format code is defined by 6 bits only. This will become clearer later.
Note that the List data item is a data item used for grouping more data items. And Lists can
contain Lists.

Data Item Type
List
Binary
Boolean
ASCII
JIS-8
8-byte integer (signed)
1-byte integer (signed)
2-byte integer (signed)
4-byte integer (signed)
8-byte floating point
4-byte floating point
8-byte integer (unsigned)
2-byte integer (unsigned)
2-byte integer (unsigned)
4-byte integer (unsigned)

Format Code
000000
001000
001001
010000
010001
011000
011001
011010
011100
100000
100100
101000
101001
101010
101100

Layout Encoding
Before a SECS-II message can be sent, the layout must be encoded. Each data item in the
message layout is encoded and becomes part of the Data Structure. This is repeated until all the data
items in the layout are encoded. The Data Structure is subsequently sent via the SECS-I protocol.
Encoded Data Item 1 Encoded Data Item 2 Encoded Data Item 3 …

Encoded Data Item N

Data Structure

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 8

A data item is encoded as follows:
The first byte of the Encoded Data Item contains the data item’s format code and also defines
how many of the following bytes define the length of the data item. The format code is
contained within bits 2 to 7, and the number of length bytes is defined in bits 0 to 1.
Therefore, the number of length bytes to follow ranges from 0 to 3 bytes.
Byte 1
Bits - 7 6 5 4 3 2
Data Item Type

Bits - 1 0
Number of length bytes

The next 0, 1, 2, or 3 bytes define the length of the data. So for example, if the size of
the data is 1000 bytes, then 2 length bytes would be needed to represent 1000 (03 E8 Hex
or 00000011 11100100 Binary)
The following table shows the max number of data bytes that can be represented by the
number of length bytes.
Number of
length bytes
0
1
2
3

Max data size
Empty item
256 bytes
64 Kbytes
7.99 Mbytes

The next n bytes contain the data for the data item.

0, 1, 2, or 3 Bytes

Encoded Data Item

Byte 1

Data Item Type
(Bits 2 to 7)

Length Byte(s)

N Data bytes …

Number of length bytes
(Bits 0 and 1)

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 9

The following shows how an ASCII data item can be encoded. Depending upon how
many data bytes it contains, it may require zero, one, two, or three length bytes to
represent the total number of data bytes.
Format code

Number of length bytes

41 (01000001)

1 Byte

42 (01000010)

2 Bytes

43 (01000011)

3 Bytes

ASCII data

ASCII data (up to 256 bytes)

ASCII data (up to 64K bytes)

ASCII data (up to 7.99 Mbytes)

The following shows how an example SECS-II message layout is encoded. Note that
only the message layout is encoded, the stream and function are not encoded in this
example. All numeric values are in Hex, (ex: 52 = 01010010).
S2F41

01 - Item is type List
(with one length byte)
02 - List has 2 elements

41 – Item is type ASCII
(with one length byte)
05 – Item is 5 bytes (chars) long
53 54 41 52 54 – Spell “START”

01 – Item is type List
(one length byte)
00 – List has 0 elements

Multi-Block Messages
Due to the data size limitations in the SECS-I protocol, the encoded SECS-II message
(Data Structure) may not fit into one SECS-I transaction. Therefore the encoded SECS-II
message is divided into smaller blocks, and sent one block at a time. This is referred to
as multi-block messaging.

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 10

Each SECS-I message block is limited to 244 of encoded SECS-II messages bytes. The
maximum number of message bocks is 32,767, so the maximum SECS-II encoded
message size is 244 x 32,767 bytes long.
SECS-II Parameters - Are used to define some of the bounds while implementing the
Message Protocol. The following table shows the SECS-II parameters:
SECS-II Parameters
T3
T4

Reply Timeout
Inter-Block Timeout

T3 – This is the time period between sending a primary SECS-II message and receiving
the secondary reply.
T4 – This is the time period between receiving subsequent blocks in a multi-block
message.

HOST

EQUIPMENT

Primary (block 1)

Primary (block 2)

T3
T4
Primary (block 3)

Secondary

Interleaving Messages
This is when more than one transaction is being handled at a time. A transaction is the
sending of a primary message and the optional receiving a secondary reply. A
transaction is “opened” when it is waiting for its reply. Interleaving is the ability to have
more than one “opened” transaction. This allows for the sending of multiple primary
messages without first waiting for the secondary reply. Supporting this feature is not a
requirement of SECS-II.

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 11

Common SECS-II Messages
Here we list the more commonly used SECS-II messages.
The first set of messages are typically used at initialization when first connecting to the
equipment.
SECS-II
S1F1
S1F13
S2F15
S2F43
S2F33
S2F35
S2F37
S5F3

Description
Say hello to the equipment
Establish communications with the equipment
Set equipment constants
Turn off spooling
Create / Delete reports
Link reports to events
Enable / Disable events
Enable / Disable alarms

These message(s) are used for recipe selection, remote start, wafer selection etc
SECS-II Description
S2F41 Remote equipment control
These message(s) are used for data collection.

SECS-II
S6F3
S6F9
S6F11

Description
Older version of Event Reports
Older version of Event Reports
Event Reports

The S5F1 is used to handle equipment alarms.
And S9’s are sent by the equipment when it detects a previous message error.

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

SECS-I

Page 12

Block Transfer Protocol
SECS-II Message Protocol
SECS-I

Block Transfer Protocol

RS-232

Physical Link

The Block Transfer Protocol is used to establish the direction of communication and provide and
environment for passing message blocks. A primary or reply message may require multiple
Block Transfers (multi-block message.)

Handshake Sequence
The handshake sequence is the exchange of bytes between the Host and Equipment.
Handshake Codes – There are four handshake codes. These are used to control data
flow in the block transfer protocol. The following table shows the handshake codes:
Handshake Codes Hex Value
ENQ
05
Ready to Send
EOT
04
Ready to Receive
ACK
06
Correct Reception
NAK
15
Incorrect Reception
SECS-I Parameters – Are used to define some of the bounds while implementing the
block transfer protocol. The following table shows the SECS-I parameters:
SECS-I Parameters
T1
Inter-Character Timeout
T2
Protocol Timeout
RTY
Retry Limit
Master/Slave
Resolve contention
T1 – Is the time between receiving each character (after receiving the first character) in
the BLOCK DATA
T2 – Is the time between sending the ENQ and receiving the EOT

The following diagram shows the handshake codes during the bock transfer protocol. It
also shows the T1 and T2 timeouts and a possible NAK:

HOST
(SLAVE)

EQUIPMENT
(MASTER)

ENQ
T2

 Copyright Edge Integration 2004
EOT

A Guide to Understanding GEM – SECS – HSMS

Page 13

RTY – This defines the number of times to initiate the block transfer (start sending with
the ENQ.) Upon the receipt of a NAK (or other protocol error), the RTY value is adjusted and
the block transfer is again attempted.
Master/Slave – Is used to resolve contention. The host is slave and the equipment is the
master. Contention is when both the host and the equipment attempt to communicate at
the same time. The following shows how contention is resolved
HOST
(SLAVE

EQUIPMENT
(MASTER)

ENQ

EOT

BLOCK DATA
ACK

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 14

Block Data
The Block Data is the data portion of either a single-block or multi-block message. It contains a
Length Byte, N Data Bytes, and a two byte Checksum.
HOST

EQUIPMENT

ENQ

EOT
BLOCK DATA

ACK

Length Byte
(Len of N Data Bytes)

N Data Bytes
(10 – 254 bytes)

10 Byte Header

Checksum
(2 bytes)

Data Structure
(0 to 244 bytes)

Block Number

Encoded SECS-II message layout
(See the SECS-II section for a description)

Message ID

Device ID

System Bytes

Length Byte – Is the first byte sent in the Block Data. It is the number of bytes in the N Date
Bytes (10 Byte Header + Data Structure). The two byte Checksum is not included in this count The
value ranges from 10 to 254 bytes.
N Data Bytes – Is the data portion of the message block. It contains a 10 Byte Header, and
the Message Data. The size ranges from 10 bytes to 254 bytes. The minimum size of N Data
Bytes is 10 (contains only the 10 Byte Header), and the maximum is 254.
Message Data - Is the data portion of the message. It contains all or a portion (if a multiblock message) of the encoded SECS-II.

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 15

10 Byte Header
Each message contains a header. The header is used to describe the data contained within the
Block Data. It contains the Device ID, Message ID, Block Number, and System Bytes. Other important
indicators are also included.
Device ID – Bytes 1 and 2 of the header are the device ID. The left byte is the upper device
ID, and the right byte is the lower device ID. The left most bit of the left byte is the reverse bit
(R-bit). The R-bit determines the direction of the message.

lower device ID
R Bit
87654321

87654321

R-Bit Direction
0
Host to Equipment
1
Equipment to Host

upper device ID

Message ID – Bytes 3 and 4 of the header is the message ID. The left byte is the upper
message ID, and the right byte is the lower message ID. The left most bit of the left byte is the
Wait bit (W-bit). The W-Bit is used to indicate that the sender of the primary message is
expecting a reply.
The message ID indicates the SECS-II stream and function. The upper message ID is the
stream, and the lower message ID is the function.

lower message ID
W Bit
87654321

87654321

upper message ID
stream

Function

 Copyright Edge Integration 2004

W-Bit
0
1

Expected reply
No reply is expected
Reply is expected

A Guide to Understanding GEM – SECS – HSMS

Page 16

Block Number – Bytes 5 and 6 of the header is the block number. The left byte is the
upper block number, and the right byte is the lower block number. The left most bit of the left
byte is the end bit (E-bit). The E-bit indicates this is the last block of a message.
A multi-block message is used when the sent message requires more than one block.
Each block is number and sent in order. Since the receiver of the message does not know
how may blocks to expect, the E-bit indicates which block is the last, or if there are more
bocks to follow. The maximum number of blocks in a multi-block message is 32,767.
E-Bit Last block
lower block No
0
More blocks to follow
E Bit
1
This is the last block
87654321
87654321
upper block No

System Bytes – The last four bytes of the header are the system bytes. The left two bytes
are the source ID, and the right two bytes are the transaction ID. The source ID identifies the
sender of the message and is used for message routing. The transaction ID identifies the
message and is unique for each message sent. A primary message at its associated reply
have the same (matching) system bytes.

source ID

87654321

transaction ID

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 17

Example of S1F1 / S1F2
The following shows the bytes transferred while a sending primary message, and receiving a
secondary reply. This is not a multi-block message. The Host, send a S1F1 and the Equipment
sends a S1F2 reply.
HOST
(SLAVE)

EQUIPMENT
(MASTER)

EOT

ENQ

S1F1 (Header only)
05
04

06
S1F2

ACK
EOT

ENQ

05
04

ACK

S1F2

Length Byte

Device ID = 0
0A
00 00
81 01
80 01
40 5D 4A 9F
02 89

Wait bit set, S1F1
Last bock, block 1

System bytes

1C
00 00
01 02
80 01
40 5D 4A 9F
01 02
41 06
4D 61 72 6B 20 49
41 06
56 65 72 31 2E 31
06 4C

2 Element List
6 byte ASCII
“Mark I”
6 Byte ASCII
“Ver1.1”

Checksum
BLOCK DATA
BLOCK DATA

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 18

Typical SECS Protocol Parameters
Here is a summary set of the SECS-I / SECS-II Protocol Parameters along with some typical
values.
Parameter
Baud Rate
Device ID
T1
T2
T3
T4
RTY
M/S

Function
Typical value
Serial line speed
9600
Identifier assigned to equipment
0
Inter-Character Timeout
1 (second)
ENT / EOT Timeout
10 (seconds)
Reply Timeout
45 (seconds)
Inter-Block Timeout
45 (seconds)
Retry Limit
3
Master / Slave
Host-Slave
Equip - Master

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

RS-232

Page 19

Physical Link
SECS-II Message Protocol
SECS-I

Block Transfer Protocol

RS-232

Physical Link

This is the lowest protocol layer. It defines the physical interface at the equipment. It is based
on the RS-232-C standard. 25-pin type “D” connectors (or other) are used. The following are
the pins used for communication.

Pin RS-232-C Circuit
1
AA
2
BA
3
BB
7
AB
18
25

Description
Shield
Data from Equipment
Data to Equipment
Signal Ground
+12 to +15 volts (opt)
-12 to –15 volts (opt)

The equipment sends data on pin 2, and receives data on pin 3. It is therefore, called “Data
Terminal Equipment” (DTE, or Computer). If the other end (Host side) is “Data Communication
Equipment” (DCE) a straight through cable is used between the two.
Host
(DCE)

Equipment
(DTE)

Pin 1

Pin 2 RD

Pin 2 TD

Pin 3 TD

Pin 3 RD

Pin 7

However, if the other end (Host side) is also a DTE, then a null-modem connector or cable is
required. This effectively swaps pins 2 and 3.
Host
(DTE)

Equipment
(DTE)

Pin 1

Pin 2 TD

Pin 3 RD

Pin 7

 Copyright Edge Integration 2004

A Guide to Understanding GEM – SECS – HSMS

Page 20

Protocol Troubleshooting
This sections covers some of the more common error scenarios encountered when working with
the SECS protocol.

T2 Timeout
The following shows a T2 timeout scenario. The host is attempting to communicate with the
equipment but the equipment is off-line and not responding. This error condition could be
caused by a physical disconnect, or equipment being off-line.

HOST
(SLAVE)

EQUIPMENT
(MASTER)

ENQ
T2
ENQ
T2
ENQ
T2

T3 Timeout
The following shows a T3 timeout scenario. The host sends a primary message to the
equipment. The is done without any errors. However, the equipment fails to send the secondary
reply message. The error condition shows that the host and equipment are communicating, but
the equipment is not responding perhaps because communications have not yet been established.
HOST

EQUIPMENT

Primary (S1F1)
T3
?

A Guide to Understanding GEM – SECS – HSMS

Page 21

Function 0
Function 0 is reserved for all Streams to indicated a failed transaction. This secondary reply is
sent by the receiver, so the sender does not have to wait for a T3 timeout. In any case, it
indicates a failed transaction just like a T3 timeout.
HOST

EQUIPMENT

Primary (S1F1)

Secondary (S1F0)

Stream 9’s
Streams 9’s are sent by the equipment to host to indicating: either a message from the host
cannot be handled, or the equipment detected a timeout on a previously received message.
HOST

EQUIPMENT

Primary (S9Fy)

A Guide to Understanding GEM – SECS – HSMS

Page 22

Establishing Communications
Before SECS-II messages can be sent between host and equipment, communications must first
be “established”. This is done via a S1F13 (Establish Communications Request) message. This
should be the first message sent following an initial startup or after a long period of not
communicating.
Often times, the host and the equipment both initiate a S1F13, and unfortunately, both timeout
waiting for the reply. Doing this is not recommended.
HOST

EQUIPMENT

S1F13

T3
T3

It may be best to allow the equipment to send the S1F13 first. Then the host can send a S1F13
after replying to the equipment’s S1F13. Getting the equipment to send the S1F13 may take
some experimenting with the equipment. Sometimes taking the equipment in and out of remote
mode, or taking the equipment off-line then on-line, causes the equipment to send a S1F13.
HOST

EQUIPMENT

S1F13

S1F14

S1F13

S1F14

A Guide to Understanding GEM – SECS – HSMS

Page 23

HSMS
This is a discussion of the HSMS (High-Speed SECS Message Services). HSMS is based on the
SEMI E37 standard. It provides a means for sending SECS-II messages to the equipment at
greater speeds. HSMS is SECS-II over TCP/IP.

HSMS Procedures
HSMS procedures are the different types of messages passed between the host and the
equipment. Here is a summary of the procedures:

Procedure
Select
Deselect
Data
Link-test
Separate

Description
Establish a connection with the equipment
Break the HSMS connection
SECS messages between host and equipment
Determine if the host-equipment link is active
Terminate HSMS connections immediately

Select
The Select procedure is used to by the host to establish a connection with the equipment
HOST
(ACTIVE ENTITY)

EQUIPMENT
(PASSIVE ENTITY)

TCP/IP Connect

TCP/IP Accept

T7
Select.req
T6

Select.rsp

A Guide to Understanding GEM – SECS – HSMS

Page 24

Deselect
The Deselect is used by either the host or equipment to break the connection.

Deselect.req

Deselect.rsp

Link Test
The Link Test procedure can be sent by either the host or equipment to test if the link is active.
Linktest.req

Linktest.rsp

Data
The Data procedure is used to send and receive SECS-II messages between the host and
equipment

Primary Message

Reply Message

A Guide to Understanding GEM – SECS – HSMS

Page 25

HSMS Message Format
This is the format of a HSMS message. Each message is begins with a Message Length, then a
Message Header, followed by the Message Text.

Message Length
(4 Bytes)

Message Header
(10 Bytes)

Message Text
(0 to ~ 8 Mbytes)

Message Length – Is a four byte value that defines the length of the entire HSMS
message (Message Header + Message Text).
Message Header – Describes the HSMS message or procedure.
W-Bit + SECS Stream
SECS System Bytes
SECS Device ID

SType
SECS Function

Procedures
data

Device ID

System Bytes

select.req

FFFF

System Bytes

select.rsp

FFFF

System Bytes

deselect.req

FFFF

System Bytes

deselect.rsp

FFFF

System Bytes

linktest.req

FFFF

System Bytes

linktest.req

FFFF

System Bytes

separate.req

FFFF

System Bytes

Bytes

7 8 9 10

Select
Status

Message Text – Is the data portion of the HSMS message. It is only relevant for the Data
procedure. The data in the Message Text is the encoded SECS-II as described in the SECSII Message Protocol section.

A Guide to Understanding GEM – SECS – HSMS

Page 26

Typical HSMS Protocol Parameters
Here is a list of the HSMS Protocol Parameters and some typical values:
Parameter
SECS Device ID
Active or Passive

Function
Device ID
Client or Server

Typical Value
0
Host – Active (client)
Equip – Passive (server)
Passive Entity IP Address IP Address
192.9.200.1
Passive Entity TCP Port Port Number
5000
T3
Reply Timeout
30 (seconds)
T5
Connection Separation Timeout
10 (seconds)
T6
Control Transaction Timeout
10 (seconds)
T7
Not Selected Timeout
10 (seconds)
T8
Network Timeout
10 (seconds)

A Guide to Understanding GEM – SECS – HSMS

Page 27

GEM
This is a discussion of the GEM (Generic Model for Communications and Control of
Manufacturing Equipment) GEM is based on the SEMI E30 standard. It defines a common set
of equipment behavior and communications capabilities.

What’s it all about
Where SECS-II defines the messages and data items sent between the host and equipment, GEM
defines which SECS-II messages should be used and when. The GEM standard does not effect
nor apply to the behavior of the host. When a GEM message is sent or received by the
equipment, the equipment will behave in a predictable manor.
The below shows that GEM messages are a subset of SECS-II messages

SECS II Messages
GEM Messages

GEM Compliance
What is GEM Compliance?
The GEM standard contains two specifications:



Fundamental GEM Requirements
Additional GEM Capabilities

A Guide to Understanding GEM – SECS – HSMS

Page 28

The following table show the Fundamental GEM Requirements:
Requirement
State Models
Equipment Processing States
Host-Initiated S1F13/F14 Scenario
Event Notification
On-line Notification
Error Messages
Control (Operator-Initiated)
Documentation
Variable data items (as they apply)
SECS-II data item restrictions (as they apply)
Collection Events (as they apply)
Additional GEM Capabilities
Capability
Establish Communications
Event Notification
Dynamic Event Report Configuration
Variable Data Collection
Trace Date 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

To be GEM compliant, you must:



Meet the Fundamental GEM requirements
Where Additional GEM Capabilities are implemented, you must conform to the
Capability as GEM defines it. For example, you need not implement Remote Control to
be GEM compliant, but if you do, you need to implement it the GEM way.

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Author                          : Work
Create Date                     : 2015:11:27 16:15:34-05:00
Modify Date                     : 2019:02:28 22:35:20-08:00
Producer                        : Microsoft® Word 2013
Language                        : en-US
Tagged PDF                      : Yes
Description                     : 
Title                           : Guide to understanding SECS
Publisher                       : 
Subject                         : 
Creator                         : Work
Metadata Date                   : 2019:02:28 22:35:20.229767-08:00
Page Count                      : 28

EXIF Metadata provided by EXIF.tools

Guide To Understanding SECS

Navigation menu

Versions of this User Manual:

Views

Navigation