semi合集-English.pdf - 第1779页
SEMI E42-0704 © SEMI 1995, 2004 48 Agents interact with one another collaboratively and/or hierarchically, through th e service resources that they provide, to perform wo rk in the factory. 7.2 RMS Resources — The servi …
SEMI E42-0704 © SEMI 1995, 2004 47
7 Agents
This section describes the agent and resources as they are used in Recipe Management. The concept of agent is
introduced to cover the different types of RMS implementations and to provide a context for the other specific
object types introduced in RMS.
7.1 Definitions — A resource is an owned entity that has an active role in factory operations. A factory has many
different kinds of resources. Some resources, such as valves, may be primarily physical. A software application is a
type of resource not generally considered as physical. The factory itself is a resource for the corporation.
An agent is a system in a factory — a type of resource that includes both hardware and software components, at
least some of which are also resources. Intelligent equipment that provides recipe namespace capability, for
example, would be an agent with a recipe namespace resource, as well as a computer platform, operating system,
and electro-mechanical components, some or all of which represent other types of resources. An agent may be a
component of another agent, and it may also contain other agents as components. For example, a cluster module is a
component of a cluster and may itself contain intelligent subsystems as components.
Agents may, in some cases, share certain resources with other agents. An example is a docking station that connects
two clusters.
Services defined by RMS may be provided at various levels within the factory. The generic term agent may be
applied at any of these levels as appropriate. Typical agents that use and provide Recipe Management services
include equipment, clusters, cluster modules, cells, and independent recipe namespace servers
9
. The term agent
applies equally well to each of these.
A service resource is a set of services within a particular area of specialization. Service resources of interest to
RMS are the recipe namespace resource, the recipe execution resource, and the Object Services Resource. The
service resource object, illustrated in Figure 7.1, allows a group of message services defined by a service standard
(such as RMS) to be represented by a single object, one of the subtypes of the service resource. However, this
concept is introduced for clarification only. The service resource object is not a standardized object.
Figure 7.1
Examples of Service Resource Subtypes
An agent is introduced as a standardized object that provides one or more service resources. Figure 7.1 shows an
example of an agent composed of different service resources. Also, an agent may supervise subordinate agents or
be supervised by a superior agent, each of which in turn will possess their own service resources.
9 A recipe namespace server is an agent whose primary function is to provide recipe namespace capabilities.
SEMI E42-0704 © SEMI 1995, 2004 48
Agents interact with one another collaboratively and/or
hierarchically, through the service resources that they
provide, to perform work in the factory.
7.2 RMS Resources — The service resources defined
by RMS are the recipe namespace resource and the
recipe execution resource.
A recipe namespace resource consists of the set of
message services defined in Section 12, corresponding
to the namespace operations defined in Sections 8 and
9. All services required for operations designated as
required are fundamental and shall be provided for an
RMS-compliant recipe namespace resource.
A recipe execution resource consists of the set of
messages defined in Section 14 corresponding to the
recipe executor operations defined in Section 11. All
services required for operations designated as required
are fundamental and shall be provided for an RMS-
compliant recipe execution resource.
7.3 Agent Attributes — Table 7.1 defines the public
attributes of agents that are required for recipe
management.
Table 7.1 Agent Attribute Definition
Attribute
Name
Definition
Access
Reqt
Form
ObjType Agent object
type.
RO Y Text:
“Agent”
ObjID The agent's
name, assigned
by an
authorized
user.
RO Y Text.
8 Recipe Management Operations
There are two important kinds of operations involving
recipes within a namespace. Those that change a
recipe's attributes or body are called recipe
management operations. Those that affect the set of
recipe identifiers within a namespace are part of recipe
namespace management operations. A few operations
qualify as both recipe management and namespace
management and are discussed in their different aspects
under both topics.
A third type of operation is informational only and
requires reading but not changing recipe attributes.
Operations of this type that require knowledge of the
attributes of the namespace or of more than one recipe
are discussed in Section 9.
This section describes recipe management operations.
Requests for recipe operations are always directed to
the namespace where the recipe is stored. Recipe
management operations are delegated by the namespace
manager to the namespace segment, which is
considered as the recipe manager. This is invisible for
a centralized namespace and explicit for a distributed
recipe namespace.
Operations may be invoked by the operator or through
namespace services defined in Section 12. In many
cases, service scenarios consist of a single message
request from the service user and a corresponding
response from the namespace manager. This case is
illustrated in Section 12.2, Figure 12.1. Operations
requiring additional messages are discussed in Section
8.2.
The service user is responsible for proper authorization
of the user prior to requesting an operation that is
restricted to authorized users
through RMS services.
8.1 Recipe Lifecycle — A typical production recipe
goes through various stages in its development within a
namespace. These stages are shown below in a typical
order through their associated operations. The attributes
concerning the body are provided by the initiator of the
operation.
create — The create operation enters a recipe body
into the namespace.
Editing is expected, but not required, to be performed
outside the namespace. Where provided by the
manager, the same requirements concerning creating or
updating a recipe are to be followed.
update — A recipe is updated when a body (typically,
a modification of the original body) is entered into the
namespace to replace the body of an existing recipe that
is not write-protected. The attributes concerning the
body are provided by the initiator of the operation.
verify — The verify operation is used to build a recipe.
Checks for semantic correctness may also be performed
at this time but are not required. The recipe body is read
and checked for syntactical correctness, and all external
references and variable parameter definitions are
collected. The verification operation may be delegated
to a recipe executor, which returns the required
information.
write-protect — At some point during its development,
an authorized user needs to be able to prevent the
accidental deletion or modification of a recipe and
requests to have it be write-protected. A write-
protected (read-only) recipe may not be updated,
renamed, deleted, unlinked, or relinked.
link — The link operation is used to signify that the
recipe is ready for execution. If the recipe has external
references, linking also builds a linked recipe set by
collecting the external references and variable
parameter definitions and saving them for quick access
SEMI E42-0704 © SEMI 1995, 2004 49
in the main recipe's attributes. Linking resolves all
identifiers explicitly for recipes that are within the
namespace.
unlink — At times it may be desirable to undo the link
operation. The unlink operation clears those attributes
set by the last link operation. A write-protected recipe
may not be unlinked.
approve — The factory uses the recipe's approval level
to indicate the level of its authorization. For example,
approval levels of 1, 2, and 3 may indicate “write-
protected,” “authorized for engineering,” and
“authorized for production,” respectively.
modify variable parameters — The variable
parameter definitions of a linked recipe may be
adjusted for a specific executing agent to achieve the
desired result. For example, a generic parameter for
time may be incremented repeatedly for a specific
furnace until it goes out of range, which indicates that it
needs to be cleaned. If the recipe did not previously
have an agent-specific dataset for this agent, this
operation causes one to be created.
certify — An authorized user (typically by the process
engineer who developed the recipe) assigns it a
certification-level to indicate that it achieves the
desired result on a specific executing agent. The factory
may require certain certification levels for production.
de-certify — the certification level of the recipe is reset
to zero.
unprotect — Before a recipe can be updated, deleted,
renamed, re-linked, or unlinked, the recipe must be
unprotected.
delete — Deleting a recipe causes it to be removed
from the namespace.
8.2 Description of Operations — Operations that
require additional messages are of two types:
operations that may be performed on more than one
recipe (such as certify recipe) and operations that may
require interactions with a recipe executor to complete
(verify recipe). The scenario for verify recipe is shown
in Section 9.4.7.
The remaining operations that require additional
messages are invoked with the namespace service
RMNAction, where multiple recipes are specified for
the operation. Operations such as these may require
more time to complete. The initial response to the
message service request only indicates the intent to
perform the operation. In this case, the scenario is
illustrated by Figure 8.1 and Figure 12.2, Section 12.2.
The namespace manager performs the operation for
each recipe, in the order specified, and upon the
completion of each operation, sends the notification
message RMNComplete with the results for that
operation. (See Sections 12.15 and 12.17 for additional
details.)
Figure 8.1
Message Flow with Completion Notification
Recipe management operations are categorized into
three types: recipe origination, recipe building, and
recipe authorization.
Recipe origination includes those operations that
create or modify an entire recipe. Recipe building
includes the verification, link, unlink, and modify
variable parameter operations. Recipe authorization
includes the write-protect, unprotect, approve, and
certify operations.
Except for those operations that only provide
information, recipe management operations change the
state of the recipe. Section 8.3 contains the complete
state model, and a table of transitions is given in Table
3.1. Substates of this model are provided for illustration
in sections defining the operations that affect these
substates.
8.2.1 General Requirements — The generic length and
timestamp attributes AttrLength
and AttrChgTime shall
be updated whenever any other generic attribute
changes value.
An agent-specific dataset for a specific agent exists
only when a non-required attribute is given a non-
default value, such as whenever a recipe is certified for
a given agent. If the non-required attributes are all
cleared, the agent-specific dataset is removed and no
longer exists. Otherwise, the agent-specific length and
timestamp attributes for an agent-specific dataset shall
be updated whenever one of its attributes changes
value.
8.2.2 Recipe Origination — A recipe may be originated
by the create recipe operation and by the copy recipe
operation. The copy recipe operation creates a duplicate
of an original recipe and assigns it a new identifier. All