semi合集-English.pdf - 第3019页
SEMI E121-0305 © SEMI 2003, 2005 15 document.) In addition, all tags h ave an ending tag or are themselves self-ending ( <slide>..</s lide> or <slide/> ). In addition, in a well-formed document, all tag…
SEMI E121-0305 © SEMI 2003, 2005 14
R1-2.30 RDF Schema — A standard for specifying consistency rules (for example, price must be greater than zero,
discount must be less than 15%) that apply to the specifications contained in an RDF.
R1-2.31 Root — The outermost element in an XML document. The element that contains all other elements.
R1-2.32 SAX — “Simple API for XML”. An event-driven interface in which the parser invokes one of several
methods supplied by the caller when a “parsing event” occurs. “Events” include recognizing an XML tag, finding an
error, encountering a reference to an external entity, or processing a schema specification.
R1-2.33 Schema — A database-inspired method for specifying constraints on XML documents using an XML-
based language. Schemas address deficiencies in DTDs, such as the inability to put constraints on the kinds of data
that can occur in a particular field (for example, all numeric). Since schemas are founded on XML, they are
hierarchical, so it is easier to create an unambiguous specification, and possible to determine the scope over which a
comment is meant to apply.
R1-2.34 SGML — Standard Generalized Markup Language. The parent of both HTML and XML. However, while
HTML shares SGML’s propensity for embedding presentation information in the markup, XML is a standard that
allows information content to be totally separated from the mechanisms for rendering/displaying that content.
R1-2.35 Tag — A piece of text that describes a unit of data, or element, in XML. The tag is distinguishable as
markup, as opposed to data, because it is surrounded by angle brackets (< and >). For example, the element
<name>My Name</name> has the start tag <name>, the end tag </name>, which enclose the data “My Name”.
To treat such markup syntax as data, you use an entity reference or a CDATA section.
R1-2.36 Unicode — A standard defined by the Unicode Consortium that uses a 16-bit “code page” which maps
digits to characters in languages around the world. Because 16 bits covers 32,768 codes, Unicode is large enough to
include all the world’s languages, with the exception of ideographic languages that have a different character for
every concept, like Chinese. For more info, see http://www.unicode.org/.
R1-2.37 Unparsed Entity — A general entity that contains something other than XML. By its nature, then, an
unparsed entity contains binary data.
R1-2.38 URI — A “Universal Resource Identifier”. A URI is either a URL or a URN. (URLs and URNs are
concrete entities that actually exist. A “URI” is an abstract superclass -- it’s a name we can use when we know we
are dealing with either an URL or an URN, and we don’t care which.
R1-2.39 URL — Universal Resource Locator. A pointer to a specific location (address) on the Web that is unique in
the entire world. The first part of the URL defines the type of address. For example, http:/ identifies a Web location.
The ftp:/ prefix identifies a downloadable file. Other prefixes include file:/ (a file on the local disk system) and
mailto:/ (an email address).
R1-2.40 URN — Universal Resource Name. A unique identifier that identifies an entity, but doesn’t tell where it is
located. That lets the system look it up to see if a local copy exists before going out to find it on the Web. It also
allows the web location to change, while still allowing the object to be found.
R1-2.41 Valid — A valid XML document, in addition to being well formed, conforms to all the constraints imposed
by a schema. In other words, it does not contain any tags that are not permitted by the schemas, and the order of the
tags conforms to the or schema’s specifications.
R1-2.42 Validating Parser — A validating parser is a parser that ensures that an XML document is valid, as well as
well formed. See also: parser.
R1-2.43 w3c — The World Wide Web Consortium. The international body that governs Internet standards.
R1-2.44 Warning — A SAX parser warning is generated when the document’s schema contains duplicate
definitions, and similar situations that are not necessarily an error, but which the document author might like to
know about, since they could be. See also: fatal error, error.
R1-2.45 Well-formed — A well-formed XML document is syntactically correct. It does not have any angle brackets
that are not part of tags. (The entity references < and > are used to embed angle brackets in an XML
SEMI E121-0305 © SEMI 2003, 2005 15
document.) In addition, all tags have an ending tag or are themselves self-ending (<slide>..</slide> or <slide/>). In
addition, in a well-formed document, all tags are fully nested. They never overlap, so this arrangement would
produce an error: <slide><image>..</slide></image>. Knowing that a document is well formed makes it possible
to process it. A well-formed document may not be valid however. To determine that, you need a validating parser
and a schema.
R1-2.46 XHTML — An XML look alike for HTML defined by one of several XHTML schemas. To use XHTML
for everything would of course defeat the purpose of XML, since the idea of XML is to identify information content,
not just tell how to display it. XHTML makes the conversion from HTML to XML, though. You can also reference
it in a schema, which allows you to say, for example, that the text in an element can contain <em> and <b> tags,
rather than being limited to plain text.
R1-2.47 XLink — The part of the XLL specification that is concerned with specifying links between documents.
R1-2.48 XLL — The XML Link Language specification, consisting of XLink and XPointer.
R1-2.49 XML — Extensible Markup Language, which allows you to define the tags (markup) that you need to
identify the data and text in XML documents.
R1-2.50 XML Schema — The w3c schema specification for XML documents.
R1-2.51 XPath — See XSL.
R1-2.52 Xpointer — The part of the XLL specification that is concerned with identifying sections of documents so
that they can referenced in links or included in other documents.
R1-2.53 XSL — Extensible Stylesheet Language. An important standard that achieves several goals. XSL lets you:
a) Specify an addressing mechanism, so you can identify the parts of an XML file that a transformation applies
to (XPath).
b) Specify tag conversions, so you convert XML data into different formats. (XSLT).
c) Specify display characteristics, such page sizes, margins, and font heights and widths, as well as the flow
objects on each page. Information fills in one area of a page and then automatically flows to the next object
when that area fills up. That allows you to wrap text around pictures, for example, or to continue a
newsletter article on a different page. (XML-FO)
R1-2.54 XSL-FO — See XSL.
R1-2.55 XSLT — See XSL.
NOTICE: SEMI makes no warranties or representations as to the suitability of the standard set forth herein for any
particular application. The determination of the suitability of the standard is solely the responsibility of the user.
Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant
literature respecting any materials or equipment mentioned herein. These standards are subject to change without
notice.
By publication of this standard, SEMI takes no position respecting the validity of any patent rights or copyrights
asserted in connection with any item mentioned in this standard. Users of this standard are expressly advised that
determination of any such patent rights or copyrights, and the risk of infringement of such rights, are entirely their
own responsibility.
Copyright by SEMI® (Semiconductor Equipment and Materials
International), 3081 Zanker Road, San Jose, CA 95134. Reproduction of
the contents in whole or in part is forbidden without express written
consent of SEMI.
SEMI E122-0703 © SEMI 2003 1
SEMI E122-0703
STANDARD FOR TESTER EQUIPMENT SPECIFIC EQUIPMENT
MODEL (TSEM)
This standard was technically approved by the Global Information and Control Committee and is the direct
responsibility of the North American Information and Control Committee. Current edition approved by the
North American Regional Standards Committee on November 22, 2002. Initially available at www.semi.org
January 2003; to be published March 2003.
NOTICE: The designation of SEMI E122 was updated
during the 0703 publishing cycle to reflect the addition
of SEMI E122.1.
NOTICE: This standard replaces SEMI E30.3, which
has been removed from publication as of the March
2003 (0303) publication cycle.
1 Purpose
1.1 This document establishes a Specific Equipment
Model for testing equipment (TSEM). The TSEM
consists of equipment characteristics and behaviors that
apply to this class of equipment. These characteristics
and behaviors are required to be implemented. The
intent of this document is to facilitate the integration of
testing equipment into an automated semiconductor
factory. This document accomplishes this by defining
an operational model for testing equipment as viewed
by a factory automation controller. This definition
provides a standard host interface and equipment
operational behavior.
2 Scope
2.1 The document defines the view of the equipment
through the host communications link but does not
define the internal operation of the equipment. It
includes a specific processing state model as the basis
for the behavior of all equipment of this class.
2.2 This document expands testing equipment
requirements and capabilities in the areas of the
processing state model, collection events, alarm
documentation, remote commands, variable items, and
process program management.
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 Communications
3.1.1 It is required that any TSEM-compliant
equipment follow the Communications State Model in
SEMI E30. In addition TSEM-compliant equipment
shall support the High-Speed Messaging Service (SEMI
E37) Communication Standard sending messages over
TCP/IP to maximize the amount of data available for
monitoring from this class of equipment. This
specification deals only with the behavior of the tester
in communicating with the host application
3.2 Virtual Tester
3.2.1 Section 7 of this document describes the concept
of the Virtual Tester. The requirements described in
this document must be fully implemented on each
virtual tester, independent of any other virtual tester.
For the purposes of this document, it can be assumed
that the term “tester” refers to the virtual tester as
defined in Section 7. Any references to the physical
tester will be explicitly noted.
4 Referenced Standards
4.1 SEMI Standards
SEMI E30 — Generic Model for Communications and
Control of Manufacturing Equipment (GEM)
SEMI E37 — High-Speed SECS Message Services
(HSMS) Generic Services
SEMI E37.1 — High-Speed SECS Message Services
Single Selected-Session Mode (HSMS-SS)
NOTICE: Unless otherwise indicated, all documents
cited shall be the latest published versions.
5 Terminology
5.1 Definitions
5.1.1 calibration fixture — any electromechanical
fixture required to perform system calibration. The
calibration fixture may consist of multiple components
with different part and serial numbers.
5.1.2 class — classes represent the most coarse view of
the test results. At a minimum, there should be two
classes defined for each process program: one class
representing good units and another class representing
failed units.