semi合集-English.pdf - 第7723页
SEMI T12-0305 © SEMI 2004, 2005 2 5 Terminology 5.1 Definitions 5.1.1 Attachment — general term of Jig and Implem ent. 5.1.2 Implement — a ki nd of Attachment used to assemble /m aintain/im prove measurement or product i…
SEMI T12-0305 © SEMI 2004, 2005 1
SEMI T12-0305
SPECIFICATION FOR TRACING JIGS AND IMPLEMENTS
This specification was technically approved by the Global Traceability Committee and is the direct
responsibility of the Japanese Traceability Committee. Current edition approved by the Japanese Regional
Standards Committee on November 24, 2004. Initially available at www.semi.org January 2005; to be
published March 2005. Originally published in 2004; previously published July 2004.
1 Purpose
1.1 Semiconductor production equipment may use jigs and/or implements to produce semiconductor devices. Some
case such important conditions as quality of products and tool performance may depend on jigs or implements. This
difference often comes from such historical events as processing cycles, processing products, stocking environment.
To make sure correlation between the conditions and the events tracing jigs and implements is required.
1.2 Purpose of this document is to establish concept to trace jigs and/or implements used on equipment for
processing material and make sure required information, communications and services to realize the concept.
2 Scope
2.1 Scope of this specification includes management of required information on equipment. Because a specific
piece of jig may be used on other equipment, usually same type and/or same supplier, information transfer between
equipment and factory host computer is also in the scope of this specification.
2.2 Such physical issues mark position and mark readers are out of scope, for this specification treats just tracing
information, communication of it and logical management. The physical specification may be standardized
separately.
2.3 As long as management on this specification and above requirement is expected on an equipment, the
equipment is in the scope regardless of the type of process or type of equipment.
2.4 But if jigs and/or implements for certain type of equipment have been already traced or managed complying
with existing standard or along with some specification conventionally, they are out of scope of this specification.
But this specification can be applied even to such jigs and tools if user and/or suppliers want.
2.5 Because this specification describes just base functionalities to realize the traceability, applications of the
functionalities including checking or management of counterfeits are out of scope.
NOTICE: This standard does not purport to address safety issues, if any, associated with its use. It is the
responsibility of the users of this standard to establish appropriate safety and health practices and determine the
applicability of regulatory or other limitations prior to use.
3 Limitations
3.1 This specification defines and makes sure concept and information transfer basics. Specification about physical
ID marking on jigs and tools including readers/writers, and such application of this tracking as security and
operations are dependent to standard users. They are responsible for their application and related regal issues.
4 Referenced Standards
4.1 SEMI Standards
SEMI E5 — SEMI Equipment Communications Standard 2 Message Content (SECS-II)
SEMI E30 — Generic Model for Communications and Control of Manufacturing Equipment (GEM)
SEMI E39 — Object Service Standard: Concepts, Behavior, and Services
NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.
SEMI T12-0305 © SEMI 2004, 2005 2
5 Terminology
5.1 Definitions
5.1.1 Attachment — general term of Jig and Implement.
5.1.2 Implement — a kind of Attachment used to assemble/maintain/improve measurement or production
equipment.
5.1.3 Jig — a kind of Attachment used to support measurement or production for material on one or more
equipment.
6 Convention
6.1 This section defines the conventions followed by this document.
6.2 Object Conventions — This document conforms to the conventions for objects established by SEMI E39,
including object diagrams, object terminology, and re-quirements for standardized objects. Accordingly, notation is
based on Unified Modeling Language (UML).
6.2.1 Formal Name of an Object — The text capitalizes formal object name references. Similar to the way
capitalization is normally used when discussing entities. When describing something in the general (like cities)
lower case is used, but when a specific entity is of interest (New York City), then first letters are capitalized.
6.2.2 Components of Complex Attributes — The names of object attributes defined in tables are left-justified. The
individual elements of complex attributes are right-justified in order of appearance below the complex attribute.
6.3 State Model Conventions
6.3.1 This document uses the Harel state chart convention for describing dynamic operation of defined objects. The
outline of this convention is described in an attachment of SEMI E30. The official definition of this convention is
described in “State charts: A Visual Formalism for Complex Systems”
1
.
6.3.2 The Harel convention has not the concept of state models of “creation” and “extinction” for expressing a
temporary entity. The Secondent described in this document is such an entity, and a copy of the same state model is
used for an independent job newly created. In this document, a circle with a black circle inside is used for
expressing extinction of an entity. A filled black circle denotes the entry to the state model (the entity creation).
6.3.3 Transition tables are provided in conjunction with the state diagrams to explicitly describe the nature of each
state transition. A transition table contains columns for Transition number, Previous State, Trigger, New State,
Actions, and Comments. The “trigger” (column 3) for the transition occurs while in the “previous” state. The
“actions” (column 5) includes a combination of:
1. Actions taken upon exit of the previous state.
2. Actions taken upon entry of the new state.
3. Actions taken which are most closely associated with the transition.
4. No differentiation is made between these cases.
Num Previous State Trigger New State Actions Comments
6.4 Service Message Representation — Services are functions or methods that may be provided by either the
equipment or the host. A service message may be either a request message, which always requires a response, or a
notification message, that does not require a response.
1 D. Harel, “State charts: A Visual Formalism for Complex Systems”, Science of Computer Programming 8, 1987.
SEMI T12-0305 © SEMI 2004, 2005 3
6.4.1 Service Definition
6.4.1.1 A service definition table defines the specific set of messages for a given service resource, as shown in the
following table:
Message Service Name Type Description
6.4.1.2 Type can be either “N” = Notification or “R” = Request & Response.
6.4.1.3 Notification type messages are initiated by the service provider (e.g., the equipment) and the provider does
not expect to get a response from the service user. Request messages are initiated by a service user (e.g., the host).
Request messages ask for data or an activity from the provider. Request messages expect a specific response
message (no presumption on the message content).
6.4.2 Service Parameter Dictionary
6.4.2.1 A service parameter dictionary table defines the description, format and its possible value for parameters
used by services, as shown in the following table:
Parameter Name Description Format: Possible Value
6.4.2.2 A row is provided in the table for each parameter of a service.
6.4.3 Service Message Definition
6.4.3.1 A service message definition table defines the parameters used in a service, as shown in the following table:
Parameter Req/Ind Res/Cnf Comment
6.4.3.2 The columns labeled REQ/IND and RSP/CNF link the parameters to the direction of the message. The
message sent by the initiator is called the “Request”. The receiver terms this message the “Indication” or the
request. The receiver may then send a “Response” which the original sender terms the “Confirmation”.
6.4.3.3 The following codes appear in the REQ/IND and RSP/CNF columns and are used in the definition of the
parameters (eg., how each parameter is used in each direction):
M Mandatory Parameter — Must be given a valid value.
C Conditional Parameter — May be defined in some circumstances and undefined in others. Whether a value is
given may be completely optional or may depend on the value of the other parameter.
U User-Defined Parameter.
- The parameter is not used.
= (For response only.) Indicates that the value of this parameter in the response must match that in the primary (if
defined).
7 General Requirements
7.1 Identification Means — Equipment has to have any means to identify physical Jigs and/or Implements.
7.2 Communication Means — Each equipment and managing system has to have any electric communication
means to transact.