semi合集-English.pdf - 第2742页

SEMI E98-1102 © SEMI 2000, 2002 7 6.4.3 Service Message Definition 6.4.3.1 A service message definition table defines the paramete rs used in a service, as shown in the following table: Parameter Req/Ind Res/Cnf Comment …

100%1 / 7923
SEMI E98-1102 © SEMI 2000, 2002 6
6.2.3 Names of OBEM Objects — The names of abstract object types start with the word “Abstract” and are not
intended to be directly implemented. All other objects defined in OBEM are concrete types that may be directly
implemented.
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”
3
.
6.3.2 The Harel convention has not the concept of state models of “creation” and “extinction” for expressing a
temporary entity. The “job” 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.
6.3.3.1 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.
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.
3 D. Harel, “State charts: A Visual Formalism for Complex Systems”, Science of Computer Programming 8,
1987.
SEMI E98-1102 © SEMI 2000, 2002 7
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).
6.5 OBEM Standard Structure
6.5.1 The remaining part of this document is organized as follows:
6.5.1.1 Section 7 contains background information to provide a context for the Object-Based Equipment Model.
6.5.1.2 Sections 8 provides an overview of two major views of the equipment: the functional view and the internal
composition view.
6.5.1.3 Section 9 introduces the OBEM object model: the interface inheritance hierarchy and the rules of
aggregation that together form the foundation of the OBEM model of equipment.
6.5.1.4 Section 11 defines the requirements for the component objects within the equipment interface hierarchy: and
other related objects of significance not defined elsewhere.
6.5.1.5 Section 12 defines the message services used in OBEM that are not defined in other standards.
6.5.1.6 Section 13 defines the services that are required of the user (factory system, remote access, and operator).
6.5.1.7 Section 14 specifies the minimum requirements and optional capabilities for compliance to the OBEM
standard.
6.5.1.8 Section 15 provides scenarios showing typical message flows during operation.
6.5.2 Additional sections are provided as related information: examples and additional material that are not part of
the standard itself. These include models for linked litho, 300 mm equipment, the relationship of OBEM and the
CIM Framework, and representations of date and time.
7 Background
7.1 Both modern manufacturing processes and modern manufacturing equipment are increasingly complex. A
single installation of equipment may have hundreds or thousands of sensors and actuators. In order to manage this
complexity, better methods of referencing the internal components of equipment are needed. Use of the object
paradigm provides a means for the equipment to describe its internal composition to the factory in a natural way.
7.2 Definition of standardized objects allows the factory to be specific about its requirements and its need for
information.
SEMI E98-1102 © SEMI 2000, 2002 8
7.3 Computer Manufacturing Integration Business
Goals
7.3.1 The intent of this section is to provide a context
for, and insight into, those requirements of industries
such as semiconductor and flat panel display (FPD)
manufacturing businesses that affect the object-based
equipment model.
7.3.2 The primary purpose of computer integrated
manufacturing (CIM) technologies is to improve
factory productivity.
4
Other inter-related secondary
CIM business goals are listed below.
• Maximize product yields (line/mechanical yield).
• Maximize device yields (electrical/functional
yield).
• Maximize total factory product substrate
throughput.
• Increase individual equipment product substrate
throughput.
• Reduce product variability.
• Reduce process variability.
• Optimize ability to center processes in a “sweet
spot”.
• Reduce the use of non-product substrates.
• Reduced time to utilization for equipment (i.e., the
time to install, qualify, characterize and ramp
production).
• Increase the usability, accuracy, and reliability of
data used for metrics.
• These business goals can be met by addressing
certain concrete objectives, which are listed below.
7.4 OBEM Functional Objectives
7.4.1 OBEM will standardize specific functional
capabilities to be implemented on semiconductor/FPD
and other manufacturing equipment, providing a
hierarchical view of equipment for effective factory
integration.
7.4.2 The OBEM functional objectives are as follows:
• Manage material into and through the equipment.
• Manage the association of the process instructions
with the material.
4 For a more detailed discussion and list, see the Guidance and
Guideline documents at
http://www.sematech.org/public/docubase/abstract/tech-30.htm
• Report data associated with the equipment, the
process, and the material.
• Facilitate equipment performance monitoring.
7.4.3 These OBEM functional objectives, individually
and collectively, can be shown to directly address the
overall business goals:
7.4.4 The Object Based Model objective directly
affects the ability to implement most of the other
objectives, especially in the case of highly modular
equipment.
7.4.5 Equipment performance monitoring has the effect
of improving product variability, device yield and can
reduce the need for non-product test substrates. It can
also provide a means of targeting a specific process
window to improve device characteristics such as
speed.
7.4.6 Management of the association of process
instructions with the material can reduce scrap due to
misprocessing, thus improving product yield. The
material management objectives impact on the
throughput of individual equipment and the total
factory throughput.
7.5 Relevant Factory Environment — Equipment must
support a variety of different factory environments.
This is necessary because factory business practices and
factory configurations vary not only from company to
company but also from one facility within a company to
another. Items will be added to this section as their
relevance becomes apparent.
7.5.1 Material Handling Systems — Material may be
loaded and unloaded manually by a fab technician or it
may be loaded and unloaded using semi-automated and
automated transport systems. Types of systems
include:
• Automated Guided Vehicles (AGV),
• Personal Guided Vehicles (PGV),
• Overhead Transport Systems (OTS), including
Overhead Hoist Transport (OHT), and
• Fixed Arm Robots.
7.5.2 Containers — Containers may be open (e.g.,
cassettes) or closed (pods, including reticle pods). Pods
may be bottom-opening (SMIF), with a removable
cassette, or front-opening (FIMS), which may have
either a removable cassette or an integrated (non-
removable) cassette (FOUP).
7.5.3 Factory Interface — The equipment must be able
to support different levels of automation, including: