semi合集-English.pdf - 第2664页
SEMI E96-1101 © SEMI 1999 , 2001 4 3.5.2 Internatio nalization are intended to be addressed in future rev isions of th is guide. 3.6 Ob ject Properties 3.6.1 Obj ect properties ref ers to a technique that allows addition…
SEMI E96-1101 © SEMI 1999, 20013
3.2 Mapping to Alternate Distributed Computing
Infrastructures
3.2.1 The CIM Framework provides a specification for
MES software components, specified in terms of gener-
alized manufacturing production systems requirements,
that may be implemented using a variety of technical
infrastructure foundations. While the intent of this
guide is to provide both rigor in specification and flexi-
bility to make infrastructure implementation choices,
these goals often conflict. The use of mapping tech-
niques complicates the task of integrating applications
across technology boundaries.
3.2.2 While it is anticipated that a conformant imple-
mentation using either CORBA
®1
or the Microsoft
®2
Distributed Component Object Model (DCOM) is feasi-
ble by mapping the specifications to the implementa-
tion, it is recognized that cross-infrastructure
integration is significantly more difficult (for example,
merging transaction models). The mapping described
here offers more diverse implementation choices, but it
does not guarantee that all of those chosen technologies
easily work together in a single heterogeneous
implementation.
3.2.3 Although the DCOM mapping provides a
straightforward transform from the OMG
Interface
Definition Language (IDL)™
3
specifications for static
invocation, the Microsoft OLE Automation interfaces
may be required for dynamic invocation. There appears
to be greater risk in being able to successfully map the
CIM Framework to the OLE Automation interfaces.
The requirement for dynamic invocation should be
evaluated with this in mind.
3.2.4 Another issue with DCOM mapping concerns
exceptions. DCOM returns exceptions using its return
value HRESULT. Many CIM Framework operations
already use return values and would not be able to
return a HRESULT without restructuring the return
mechanism for the operation results.
3.2.5 Finally, there has not yet been a detailed analysis
of the CIM Framework interfaces to verify that they can
be successfully mapped using the CORBA
Interworking Architecture.
4
This is especially true of
the OLE Automation mapping resolution.
1 CORBA is a registered trademark of Object Management Group,
Inc. in the United States and other countries.
2 Microsoft is a registered trademark of Microsoft Corporation, Inc.
in the United States and other countries.
3 OMG Interface Definition Language (IDL) is a trademark of Object
Management Group, Inc. in the United States and other countries.
4 Object Management Group. The Common Object Request Broker:
Architecture and Specification, Revision 2.2, Object Management
Group, 492 Old Connecticut Path, Framingham, MA: Object
Management Group, 1998.
3.3 Business Rules
3.3.1 The management of factory objects requires the
use of a set of business rules; that is, procedures repre-
senting common business practices that should be
applied under a given set of circumstances in response
to some factory event. For instance, “Do not assign a
process job to a machine which is scheduled for main-
tenance within 24 hours.” Factory systems implement-
ations typically specify business rules as event-driven
ECA (event-condition-action) or ECAA (event-
condition-action-alternative action) rules. For example:
• event –– request to edit a process specification;
• condition –– invalid user access privilege;
• action –– deny access;
• (alternative action –– deny access and report
breach of security).
3.3.2 Business rules can also be embodied in the
sequencing logic of sequential process definitions. In
this case the business rules define the criteria for
making sequencing decisions that effect the flow of
work through the factory.
3.3.3 Business rules are intended to be addressed in
future revisions of this guide.
3.4 Security and Access Control
3.4.1 The management of sensitive information
regarding business processes and product specifications
requires that MES implementations (especially
distributed systems) provide some level of security and
access control services. Typically, such services:
• identify and authenticate any factory object seeking
sensitive information,
• permit access to information or operations based
upon identity and privilege,
• provide security-related audit trails,
• provide secure communications (not susceptible to
being intercepted nor malicious or inadvertent
modification), and
• administer an enterprise’s security policy.
3.4.2 Security and access control is intended to be
addressed in future revisions of this guide.
3.5 Internationalization
3.5.1 Specifications that deal with issues related to
internationalization are emerging from several sources,
including the OMG. This guide should encompass the
need and ability to incorporate internationalization
features into the CIM Framework specifications.
SEMI E96-1101 © SEMI 1999, 2001 4
3.5.2 Internationalization are intended to be addressed
in future revisions of this guide.
3.6 Object Properties
3.6.1 Object properties refers to a technique that allows
additional attributes (data) to be dynamically associated
with an object without changing the interfaces of the
objects to which the properties are attached. This can be
used as a convenient dynamic extensibility mechanism
that may be considered in future CIM Framework
specifications.
3.6.2 Object properties are intended to be addressed in
future revisions of this guide.
3.7 Object Collections and Queries
3.7.1 Object collections and queries allow flexible
access to aggregate data for a group of objects. This
capability may be a candidate to replace the limited
operations for collections found in the component
manager interface.
3.7.2 Object collections and queries are intended to be
addressed in future revisions of this guide.
4 Referenced Standard
4.1 SEMI Standard
SEMI E81 — Provisional Specification for CIM
Framework Domain Architecture
NOTE 1: As listed or revised, all documents cited shall be the
latest publications of adopted standards.
5 Terminology
5.1 Abbreviations and Acronyms
5.1.1 ACID — Atomicity Consistency Isolation
Durability
5.1.2 CIM — Computer Integrated Manufacturing
5.1.3 ECA — Event-Condition-Action (rule)
5.1.4 ECAA — Event-Condition-Action-Alternative
Action (rule)
5.1.5 ENS — Event Notification System
5.1.6 ERP — Enterprise Resource Planning
5.1.7 GUI — Graphical User Interface
5.1.8 MES — Manufacturing Execution System
5.1.9 ODL — Object Definition Language
5.1.10 OMA — Object Management Architecture
5.1.11 OTS — Object Transaction Service
5.2 Definitions
5.2.1 application — 1. one or more programs
consisting of a collection of interoperating objects
which provide domain specific functionality to an end
user or other applications. 2. functionality provided by
one or more programs consisting of a collection of
interoperating objects.
5.2.2 application interface — the interface provided by
an application or application program.
5.2.3 application object — an object implementing an
application interface.
5.2.4 architecture — the structure of the components
of a program/system, their interrelationships, and
principles and guidelines governing their design and
evolution over time.
5.2.5 attribute — an identifiable association between
an object and a value. An attribute may have functions
to set and retrieve its value.
5.2.6 behavior — the effects of performing a requested
service, including its results (e.g., changes in the state
of an object).
5.2.7 binding — a specific choice of platform
technologies and other implementation-specific criteria.
5.2.8 class — the shared common structure and
common behavior of a set of object implementations.
5.2.9 client — an object that uses the services of
another object by sending messages to it or referencing
its state.
5.2.10 collection — an object containing references to
(collections of) other objects with services for
managing them and providing access to them as a
related group of objects.
5.2.11 component — a reusable package of
encapsulated objects and/or other components with
well-specified, published interfaces. The component is
the element of standardization and substitutability for
the CIM Framework.
5.2.12 Computer Integrated Manufacturing — an
approach that leverages the information handling
capability of computers to manage manufacturing
information and support or automate the execution of
manufacturing operations.
5.2.13 conformance — adherence to a standard or
specification in the implementation of a product,
process, or service.
5.2.14 conformance requirement — identification in
the specification of behavior and/or capabilities
required by an implementation for it to conform to that
specification.
SEMI E96-1101 © SEMI 1999, 20015
5.2.15 conforming implementation — an
implementation that satisfies all relevant specified
conformance requirements.
5.2.16 event — an asynchronous message denoting the
occurrence of some incident of importance. For
example, state change or new object created.
5.2.17 event channel — the intermediate object that
forwards published events to interested subscribers.
5.2.18 exception — an infrastructure mechanism used
to notify a calling client of an operation that an unusual
condition occurred in carrying out the operation.
5.2.19 extensibility — the ability to extend or
specialize existing components and add new object
classes or components while preserving architectural
integrity and component conformance to standards.
5.2.20 framework — a collection of classes or
components that provide a set of interoperable services
and functionality for a particular domain.
5.2.21 implementation — the internal view of a class,
object or module, including any non-public behavior.
The specific code and functionality that implements an
interface.
5.2.22 implementation conformance statement — a
statement made by the supplier of an implementation or
system claiming to conform to one or more
specifications and stating which capabilities have been
implemented. It specifically includes the relevant
optional capabilities and limits.
5.2.23 infrastructure — the services, facilities, and
communications mechanisms that support the collabor-
ation between and lifecycle of distributed objects.
5.2.24 inheritance — the ability to derive new classes,
types or interfaces from existing classes, types or
interfaces. For example, a derived class (“subclass”)
inherits the instance variables and methods of the base
class (“superclass”) and may add new instance
variables and methods. In the CIM Framework,
inheritance applies to interfaces and their specification
of operations rather than implementations of classes.
5.2.25 instance — a software entity that has state,
behavior and identity. The terms instance and object are
interchangeable. An object is an instance of an interface
if it provides the operations, signatures, and semantics
specified by that interface. An object is an instance of
an implementation if its behavior is provided by that
implementation.
5.2.26 interface — the external view of a class, object,
or module that emphasizes its abstraction while hiding
its structure and internal behavior. An interface
definition ideally includes the semantics of attributes
and operations.
5.2.27 interoperability — the ability for two
applications or the parts of an application to cooperate.
In the CIM Framework, interoperability requires that
application components be able to support specified
relationships, share data, invoke each others’ behavior
(operations), return exceptions, and exchange events.
5.2.28 lifecycle — the life of an object, including
creation, deletion, copy, and equivalence.
5.2.29 message in object oriented systems a
message is the means by which a client object invokes
the behavior specified by an operation of a server
object.
5.2.30 message bus — a software infrastructure that
provides distributed communication between objects in
component implementations. It can refer to an Object
Request Broker, Microsoft DCOM, Java Remote
Method Invocation or other infrastructure for conveying
messages between objects.
5.2.31 name-value pair — a data structure that
associates a name with an arbitrary value, typically
used as an extensibility mechanism for conveying
information by name-based retrieval.
5.2.32 namespace — a namespace is a bounded
collection of names with a constraint to ensure that each
name is unique within the collection.
5.2.33 object — a software entity that has state,
behavior, and identity. The terms instance and object
are interchangeable. An object is an instance of an
interface if it provides the operations, signatures, and
semantics specified by that interface. An object is an
instance of an implementation if its behavior is
provided by that implementation.
5.2.34 object services — interfaces for general services
that are likely to be used in any program based on
distributed objects.
5.2.35 operation — an operation is a specification en-
tity, identified by an operation identifier, that denotes a
service that can be requested. An operation has a sig-
nature that describes the legitimate values of request
parameters and returned results, including any
exceptions.
5.2.36 persistent object — an object that can survive
the process or thread that created it.
5.2.37 productive entity productive entity is an
abstraction of a physical unit, which is involved in any
way in a production process (e.g. production or
supporting equipment). A productive entity has its own