semi合集-English.pdf - 第1754页

SEMI E42-0704 © SEMI 1995, 2004 23 3.2.5.1 Descriptors — Two types of mandatory attributes of particul ar importance are the timestamp and length attributes. These are provided fo r the body , for each agent-specific dat…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 22
Text strings are restricted to the character set defined
above to represent the low and high limits of the domain
and shall convert to a numeric value within that
domain.
3.2.4.2.2 Non-Numeric Parameters A non-numeric
parameter is any parameter other than a numeric
parameter, including parameters whose domains are
sets of discrete numbers that cannot be represented by a
single mathematical interval, and strings that represent
names. Non-numeric values may or may not place
restrictions on the replacement value. A parameter that
contains the name of a wafer map, for example, cannot
be easily restricted by a general rule
7
, whereas a
parameter that contains a string identifying
thermocouple type can be restricted to one of a defined,
unordered set of valid strings. Restrictions for non-
numeric parameters might also consist of, or include,
logical expressions that shall evaluate to TRUE before a
value may be used.
If a recipe language has been defined for the
corresponding class of recipes, the syntax for the
restriction is taken directly from the formal definition
of that parameter within the body of a source form
recipe (and therefore conforms to the specification for
that recipe language). Otherwise, the restriction is
expressed in a syntax defined by the recipe executor's
supplier specifically for parameter attributes.
For example, the parameter for a furnace recipe may
specify which set of PID values should be used, where
sets A-F exist on the equipment. The automatic
restriction on the value for such a parameter, as
specified by the recipe executor's supplier, might be
"{A,B,C,D,E,F}" with the default for the value
specified as the character "C" with a format type of
"ASCII string of length 1".
In another example, a restriction might be that the value
be taken from the enumerated set
“{cassette, lot , batch }”.
3.2.4.2.3 Agent-Specific Parameters In order to
"tune" a recipe so that it produces the same result on all
recipe executors of the same type, it may be necessary
to provide a different initial value for the parameter or
a different parameter restriction for individual
executing agents. A special editing facility may be
provided by the recipe manager to allow the original
value and/or restriction of a parameter to be modified
for a specific executing agent.
7 Typically, the validity of parameters which are unrestricted names
can only be established at run-time.
NOTE: Agent-specific parameter definitions replace
the corresponding original definitions in the recipe that
is downloaded to the recipe executor. At run-time, they
are superseded by parameter values specified for the
recipe executor's select operation.
3.2.5 Attributes The name of an attribute is a text
string required to be unique for its object. The names of
the attributes defined in this document are reserved for
their standard use.
Identification attributes are those used to identify the
object in OSS. These attributes are available through
OSS, but in RMS, services are handled separately from
the other attributes and are not transferred in parameters
for "recipe attributes".
Attributes other than identification attributes and
mandatory attributes discussed below always have a
defined default value. Attributes with a default value
not otherwise specified are considered to have a null
value corresponding to their form as their default value.
The null value for a text string is a zero-length string.
The null value for a numeric form is zero. The null
value for a boolean form is FALSE. The null value for
an empty list or structure is an empty (zero-length) list.
The manner of representing null values is left to the
protocol.
An attribute is cleared or reset by setting its value to
the default value.
Mandatory attributes are attributes that are required to
always have a non-default value.
Certain attributes are required, including all mandatory
attributes. A required attribute is one that shall be
supported with a non-default value. For example, the
BodyFormat
attribute is required. This means that
object form recipes (for which BodyFormat
has a non-
default value) shall be supported by a namespace.
Any attribute defined in this standard shall only be
modified according to the rules specified for that
attribute.
Attributes of the managed recipe and the execution
recipe may be accessed through Object Services.
However, only certain of the attributes may be set
through Object Services.
For purposes of OSS, all attributes defined in RMS
shall be recognized. That is, a response to a GetAttr
service request that references any attribute of an object
defined in RMS for that object shall not return an
"invalid attribute" error. If the attribute is not supported
by the application, then it shall show the value of that
attribute as having the null value appropriate for its
form, and it shall deny attempts to set its value through
the SetAttr service.
SEMI E42-0704 © SEMI 1995, 2004 23
3.2.5.1 Descriptors Two types of mandatory
attributes of particular importance are the timestamp
and length attributes. These are provided for the body,
for each agent-specific dataset, and for the set of
attributes of the recipe object itself, including the
timestamp and length attributes of the body.
A descriptor contains the length and timestamp
attributes (in that order) of one or more of the aspects of
a recipe: its attributes, its body, or an agent-specific
dataset. Descriptors are used to compare two recipes
stored in different namespaces or in a namespace and in
the recipe execution area of a recipe executor.
NOTE: Provision of a real-time clock or other device
capable of counting time in centiseconds greatly
improves the value of the timestamps for this
comparison.
3.3 Full and Minimal Recipe Models — Figure 3.5
contains an object model for the managed and
execution recipes supporting all of the standard
attributes defined in RMS. Non-identifier attributes are
shown in alphabetical order. Many of these attributes
are not required for minimal applications. Minimal
models for the managed and execution recipes are
shown in Sections 3.4.2.3 and 3.5.2, respectively.
Figure 3.5
Full Recipe Object Model
SEMI E42-0704 © SEMI 1995, 2004 24
3.4 Managed Recipes — This section defines the
managed recipe and its attributes.
3.4.1 Generic Attributes — For clarity, the attributes of
the managed recipe are sometimes called generic
attributes to distinguish them from agent-specific
attributes or attributes of the execution recipe.
Attributes that are not specifically defined in this
standard may be defined by an application or by the
user. Attributes that are defined by a namespace or by a
recipe executor for its own use shall be changed only
by rules specified and documented by the originator of
the attribute.
To prevent conflict between non-standard attribute
names and names which may become standard in the
future, non-standard attribute names shall start with the
prefix "UD_" (the two characters "U" and "D" followed
by the underline character). It is the responsibility of the
originator to provide unique attribute names. When
using other RMS services, non-standard attributes shall
follow all standard attributes.
It is desirable that a method be provided for the user to
define new attributes.
3.4.1.1 Timestamp Attributes — Timestamp
information (date and time of the last change) is
important to recipe management. Timestamp attributes
are maintained by the recipe namespace and may not be
changed otherwise.
A timestamp attribute shall always contain the date and
time that the particular aspect of the recipe was last
changed. This attribute is a text string of the form
"yyyymmddhhmmsscc" for the year yyyy, the month
mm, the day dd, the hour hh, the minutes mm, the
seconds ss, and the centiseconds cc.
The timestamp of the body is called EditTime
and is set
when a recipe is first created and updated whenever the
body is modified in any way.
Because a recipe's attributes may be changed without
changing the body, both the recipe's generic attributes
and each set of agent-specific attributes themselves
each have a timestamp attribute. For the generic
attributes, the timestamp attribute is called
AttrChgTime
. The set of agent-specific attributes (of an
agent-specific dataset) has its own timestamp attribute,
called AgentSpec_ChgTime
.
3.4.1.2 Length Attributes There are three length
attributes, one which contains the length of body, one
that contains the length of the generic attributes, and
one that contains the length of the agent-specific
attributes. Length attributes are calculated without
regard to either protocol overhead or storage overhead,
such as proprietary formats used for internal storage
that may change from one implementation to another.
This preserves the length across different conventions
used for recipe storage and different communications
protocol.
The length attribute of the body, BodyLength
, contains
the length of the body in bytes. The length of the body
is calculated as the number of bytes it will require when
transferred, excluding any overhead, such as that which
might be required for protocol format information.
The length of an individual
attribute is calculated as the
sum of the lengths of the attribute name and the
attribute value.
The length of a set
of attributes shall be calculated as
the sum of the lengths of the individual attributes that
are set to a non-default value at the time the calculation
is performed, including the length attribute itself. All
attributes set to their default value, at the time the
length is calculated, are excluded from the calculation.
This is because only the attributes with a non-default
value are transferred when a recipe is moved into or out
of a namespace. It also results in a more significant
change to value of the length attribute when an attribute
is set to a non-default value.
3.4.1.3 Descriptors The descriptors of the managed
recipe are the body descriptor (BodyLength
and
EditTime
), the generic attribute descriptor
(AttrLength
and AttrChgTime), and the agent-specific
descriptor (AgentSpec
_AttrLength and
AgentSpec
_ChgTime). The recipe descriptor for a
managed recipe consists of the attribute descriptor, the
body descriptor (in that order), followed by descriptors
of any existing agent-specific datasets.
3.4.2 Managed Recipe Object Attribute Definitions —
This section provides the formal definitions for the
recipe's generic attributes. For Object Services, a recipe
is considered as the owner of its components, any
agent-specific datasets. The body may not be accessed
through Object Services.
Attributes in Tables 3.1 and 3.2 are presented in the
following order:
identification attributes, including object type and
identifier, appearing above the heavy line in Tables
3.1 and 3.2,
mandatory attributes and the other required
attributes, in the order in which they are to appear
when a recipe is transferred,
optional attributes in alphabetical order, and
non-standard attributes, which are transferred last.