semi合集-English.pdf - 第3582页

SEMI E139-0705 © SEMI 2005 6 6 Conventions 6.1 The following conventions are used in this document:  To highlight terms specific to RaP, a term appears in italics within the specification. Italicized terms include class…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 5
5 Terminology
5.1 SEMI Compilation of Terms
5.1.1 Definitions or descriptions of many of the terms used in this specification can be found in the SEMI
Compilation of Terms, available on the SEMI web site,
http://www.semi.org/; and in the OMG UML specification.
For terms related to object models, the definition from the OMG UML specification has precedence.
5.2 Abbreviations and Acronyms
5.2.1 FICS — Factory Information & Control System
5.2.2 PDE — Process Definition Element
5.2.3 RaP — Recipe and Parameter Management – this specification.
5.2.4 UML — Unified Modeling Language
5.3 Definitions
5.3.1 Checksum — a single unique value calculated from a sequence of data (a file, a string, etc.) that uniquely
identifies that data. It is sometimes called a “digital fingerprint” or a “message digest”. No two (different)
sequences of data are likely to have the same checksum. Therefore, a checksum can be used to check data integrity.
A typical method is to 1) calculate the checksum for a data sequence; 2) deliver that data sequence and its checksum
value to a separate entity; 3) the receiving entity recalculates the checksum value and compares it with the original
from the sender. If the checksums are the same, the receiver is assured that the data has not been modified or
corrupted.
5.3.2 Factory Information and Control System (FICS) — the software system that controls the operation of the
factory and its equipment. It may include such components commonly referred to as the MES, Station Controllers,
Recipe Managers, etc.
5.3.3 Module Parameter — settings that affect processing on an equipment module (typically a Process Module).
For a Process Module, the Module Parameters might represent temperatures, pressures, flow rates, etc. An
equipment recipe typically manipulates Module Parameters to accomplish its purpose.
5.3.4 PDE (Process Definition Element) — an executable specification of an activity or process on an equipment.
The recipe for a particular equipment activity may consist of multiple PDEs. A PDE is the smallest process
definition unit that can be individually managed with FICS participation or knowledge. Each PDE includes a
PDEheader and a PDEbody.
5.3.5 PDEbody — the executable portion of a Process Definition Element. The PDEbody is typically contained
within the PDE construct. In some cases, a PDEbody may exist as a separate entity, but it is always exclusively
related to its PDE.
5.3.6 PDEeditor — a software system that provides the ability to create, delete, and modify a PDE. A PDEeditor
may exist as a subsystem of an equipment or as a standalone system provided either by the manufacturer of the
equipment or a third party.
5.3.7
PDEheader — the descriptive portion of a Process Definition Element. The PDEheader is a collection of
information related to a PDEbody. This information is sufficient to manage and utilize the PDE without accessing
its PDEbody.
5.3.8 uuid — universally unique identifier. This 128-bit field (often represented as a 36-character string) is
calculated according to the standard ISO/IEC 11578:1996 – Remote Procedure Call (RPC). The field is guaranteed
to be unique over all space and time. The uniqueness holds even though the uuids are created independently by
separate entities.
5.3.9 Variable Parameter — a formally defined variable (setting) defined in the body of a recipe, permitting the
actual value to be supplied externally.
SEMI E139-0705 © SEMI 2005 6
6 Conventions
6.1 The following conventions are used in this document:
To highlight terms specific to RaP, a term appears in italics within the specification. Italicized terms include
class names, attributes, and services. Service names also end in (), for example “getPDE()”.
To prevent the definition of numerous message parameters named "XxxList," this document adopts the
convention of referring to the list as "list of Xxx". In this case, the definition and data type of the parameter will
be given (not the type of the list). The term "list" indicates a collection (or set) of zero or more items of the
same data type.
6.2 Object Modeling
6.2.1 Unified Modeling Language (UML)
6.2.1.1 This specification uses UML notation for all class diagrams and for any object diagrams provided as
examples. No other types of object modeling diagrams are used in this specification.
6.2.2 Class Diagrams
6.2.2.1 UML class diagrams have clearly defined meaning and are a part of this specification. Detail contained in
these diagrams is not necessarily repeated in the text.
6.2.3 Name of a Class
6.2.3.1 The text capitalizes class names. Class attributes and services begin with lowercase letters.
6.2.4 Abstract and Concrete Classes
6.2.4.1 Each class is specified as Abstract or Concrete. Abstract classes are not directly implemented (that is, there
are no instances). All classes defined as concrete may be directly implemented. In UML class diagrams, abstract
class names are shown in italics.
6.2.5 Class Attribute Definition
6.2.5.1 The attributes of a class are defined in table format as illustrated by Table 1 below. Note that the “+” sign in
front of attributes in UML class diagrams indicates “public” attributes. All attributes defined in this specification
are public, therefore the “+” sign is omitted.
Table 1 Attribute Table Format
Attribute Name Definition Access Reqd Form
RO or
RW
Y or
N
See list below.
6.2.5.1.1 Access — Attributes may be settable (ReadWrite or RW) or not settable (ReadOnly or RO) through an
interface to the service provider.
4
6.2.5.1.2 Reqd — Is this attribute required? Y – Yes, or N – No.
6.2.5.1.3 Form — Defines the data type of the attribute. Data types in this specification are high-level definitions
and should be mapped to the data types of a specific technology as appropriate. In this specification, these data
types are also used for the parameters of message services.
Binary — A sequence of bytes that may have any value. Binary values are sometimes called “unformatted”
because their structure is not apparent.
Boolean — Takes the value of “true” or “false”.
Enumeration — A format that allows a specified list of possible values. In this document, these values are
represented as text strings, but may be implemented differently (e.g. as integers that correspond to the named
values).
4 The attribute table is a common format used by multiple standards. Note that all attributes defined by RaP are ReadOnly (RO).
SEMI E139-0705 © SEMI 2005 7
Error — The Error type is a structure that contains information about an error that has occurred. The form of
the structure is implementation dependent and shall be defined by each sub-specification of RaP that describes
messaging using a specific technology (for example SECS-II or XML/SOAP).
Integer — A numeric value. Integers are always whole numbers. The form and number of bytes is left to the
implementation definition.
Real — A numeric value that may represent any whole or fractional number. The form and number of bytes is
left to the implementation definition.
String — A text string. Limitations on length are left to the implementation technology unless otherwise
specified in this document. Strings are recommended to be implemented as UTF-8.
Checksum — A checksum value calculated on a specific stream of data using a specific method of calculation.
Time — Representation of the date and time of the occurrence of interest. The structure and form of items of
this type is left to the implementation.
UUID — Universally unique identifier created according to the ISO specification referenced in ¶4.2 and
represented as ASCII characters. Note that this type is represented by all-caps “UUID” to differentiate it from
the “uuid” ISO standard string definition that defines the content of an attribute of type “UUID”.
Any — The format may be any of the others listed in this section. Format is determined by the implementation.
list of xxx — An item that can hold multiple instances of a specified type (where xxx is the data type).
6.2.6 Association Documentation
6.2.6.1 Associations are documented using the form of Table 2. Only Navigable Associations for the class of
interest are included in the table. See ¶6.2.7 for explanation of Navigable Associations.
6.2.6.2 For each association, the table lists the Type, Description, Associated Class, Role, and Cardinality
Type — The type of association. The possible values include Composition, Aggregation, and Association. See
the UML standard in ¶4.3 for an explanation of these types of association.
Description — Text describing the association.
Associated Class — The name of the class connected by this association.
Role — The role name of the associated class in the association taken from the UML diagram. Composition
associations are not given roles in this document, since it usually implies containment of the aggregated objects.
Cardinality — How many of the associated class may be associated with this class – documented in UML form.
Table 2 Navigable Associations for Class xxx
Type Description Associated Class Role Cardinality
6.2.7 Association Navigability
6.2.7.1 UML associations include the concept of “Navigability”. When an association is navigable, the association
may be traversed to reach the class instance at the opposite end of the association (target object).
6.2.7.2 By default, an association is navigable in both directions. If an arrowhead is shown on one end of an
association, then navigability exists only in that direction.
6.2.7.3 From any object, it must be possible to obtain a reference to the target objects of any of its navigable
associations. For any navigable association defined in this document, this is required of the implementer. The
method of referencing the target objects is implementation dependent and is not specified in this document.