semi合集-English.pdf - 第2662页
SEMI E96-1101 © SEMI 1999 , 2001 2 • Event Specificatio n — Establishes the deliver y mechanism, identification conventions, and data structures f o r reportin g the occu rrence of antici- pated state chang es to CIM Fra…
SEMI E96-1101 © SEMI 1999, 20011
SEMI E96-1101
GUIDE FOR CIM FRAMEWORK TECHNICAL ARCHITECTURE
This guide 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
European Regional Standards Committee on June 11, 2001, and by the North American Regional Standards
Committee on July 19, 2001. Initially available at www.semi.org August 2001; to be published November
2001. Originally published February 2000. This document replaces PR5-0699 in its entirety.
1 Purpose
1.1 This guide describes technical architecture choices
that enable application components to cooperate in a
Computer Integrated Manufacturing (CIM) environ-
ment and reduce the effort required to integrate those
components into a working solution. The CIM Frame-
work technical architecture guide builds on publicly
available specifications for distributed object comput-
ing. It defines manufacturing production systems
requirements for the technical infrastructure needed for
improved component interoperability, substitutability,
and extensibility. It provides guidance for specifying
components and addresses options for using an under-
lying distributed object communication infrastructure.
1.2 This guide provides guidance for the technical
foundation of the SEMI Computer Integrated Manufact-
uring (CIM) Framework standards. It discusses a com-
ponent-based architecture using object-oriented and
framework technology that helps implementers achieve
component interoperability and substitutability, applica-
tion extensibility, and reuse. It establishes the role of
distributed object communications infrastructure in pro-
viding necessary support for the framework technology.
Specification methods for mapping a CIM Framework
specification to alternative infrastructure technologies
are also addressed by this technical architecture. How-
ever, these mappings are not intended to be prescrip-
tive. Further work may be required to define additional
mappings to emerging technologies. Many implement-
ation issues that should be resolved for a particular
software implementation are outside the scope of this
guide.
1.3 Adhering to this guide for technical architecture
alone does not provide interoperability between appli-
cations. While the technical architecture provides a
foundation for interoperability, it is limited by the
following factors:
• Multiple infrastructure implementation choices are
possible, and interoperability across these environ-
ments is not guaranteed.
• The technical architecture intentionally limits its
scope to only the most fundamental infrastructure
requirements, leaving additional technical issues
for future guide upgrades or for implementers’
discretion.
• Conformance to a specification for CIM Frame-
work Domain Architecture is also required for
interoperability of domain components.
• More complete semantics (including behavioral
constraints and collaboration patterns) for compo-
nents are needed to ensure consistent interactions
among components developed by separate
suppliers.
1.4 A guide for technical architecture is a necessary,
but not a sufficient, basis to achieve the goals of the
CIM Framework specifications. It does not mandate
specific solutions to address the identified technical
requirements because there are multiple implementation
choices that meet these requirements. Rather, the tech-
nical architecture identifies those crucial technical
requirements that should be considered by both CIM
software suppliers and consumers. The proposed stan-
dard identifies the technical capabilities implement-
ations should provide, but leaves the implementation
options open. It is the responsibility of suppliers to
provide and explain an implementation of each
capability, and the responsibility of consumers to assess
particular implementations for use in their factories.
1.5 This guide provides guidance on the technical
tradeoffs for services provided by the distributed
computing infrastructure for the purpose of supporting
and enabling the domain specifications of CIM Frame-
work components. These areas are:
• Distributed Object Communication — Provides the
basic services to enable implementations
supporting the CIM Framework interfaces to trans-
parently locate other, possibly distributed imple-
mentations and exchange messages requesting
standard CIM Framework operations. Interface
Definition Language provides a formal specifica-
tion of the CIM Framework interfaces that can be
automatically transformed into conformant imple-
mentations ready for integration and interoperation.
• Exception Declarations — Identify the form and
structure of return messages that inform requestors
that a requested operation resulted in an
anticipated, but abnormal outcome.
SEMI E96-1101 © SEMI 1999, 2001 2
• Event Specification — Establishes the delivery
mechanism, identification conventions, and data
structures for reporting the occurrence of antici-
pated state changes to CIM Framework objects.
• Distributed Transactions — Define mechanisms
needed to coordinate the start, completion or
rollback of units-of-work that cross CIM
Framework component boundaries.
• Component Manager Support — Identifies the
component-level operations needed to create,
locate, or remove instances of objects (and manage
collections of those objects) that support the CIM
Framework specified interfaces.
2 Scope
2.1 Intended Audience
2.1.1 This document is intended for developers of
components and applications, and integrators of MES
systems that adhere to the CIM Framework speci-
fications. It is also intended for system architects who
contribute to the evolution of the CIM Framework
architecture and guides based on implementation exper-
ience. A guide for technical architecture is focused on
the software technologies that support the architectural
goals for the CIM Framework rather than on the manu-
facturing domain concepts that the CIM Framework
encompasses. The technical architecture perspective
complements SEMI E81.
2.2 Architectural Issues Not Covered
2.2.1 A number of architectural issues are not covered
within this document because they are beyond the scope
of the CIM Framework standards and are not expected
to come within the scope of the standards as they are
revised. They are itemized here because a product
architecture layered on the CIM Framework Technical
Architecture should address these additional
architecture issues. In these cases, other more general
specifications emerging in the infrastructure technology
areas are expected to provide these needed standards.
The CIM Framework domain specifications do not
require specific conformance in these areas to support
component specifications.
2.2.2 Persistence
2.2.2.1 Persistence refers to the ability of an object to
maintain a nonvolatile copy of its current state such that
the object could recreate the state during a future
initialization. There are various operations for object
persistence, and problems can occur if objects with
cross-references do not coordinate their persistence
strategies and mechanisms. The CIM Framework
excludes persistence as an implementation mechanism.
2.2.3 System Performance
2.2.3.1 System performance is highly dependent on the
selection of hardware and software platforms for
system execution. Tests should be performed to verify
adequate system performance and scalability for the
anticipated operating environment. Performance tuning
mechanisms or measurement tools are excluded from
the CIM Framework specifications as an implement-
ation dependent mechanism.
2.2.4 Data Replication
2.2.4.1 Data replication is a technique used to provide
additional fault tolerance or improve system perform-
ance in certain situations. The CIM Framework
excludes specification of replication strategies as an
implementation dependent mechanism.
2.2.5 Change Management
2.2.5.1 Change management is the ability to introduce
and control changes to the system configuration. The
CIM Framework encompasses change management in
the domain context of document control, but the CIM
Framework excludes the broader treatment of change
management for the MES software configuration itself.
2.2.6 Externalization
2.2.6.1 Externalization can be used to provide a form
of persistence or to transfer object state between dis-
joint implementations. The ability of an object to exter-
nalize its data and state supports recovery of data and
state for objects that terminated from memory. The
CIM Framework excludes externalization as an
implementation dependent mechanism.
2.3 This standard does not purport to address safety
issues, if any, associated with its use. It is the responsi-
bility of the users of this standard to establish appro-
priate safety and health practices and determine the
applicability of regulatory limitations prior to use.
3 Limitations
3.1 The CIM Framework should continue to evolve to
meet the needs of a competitive and vital industry. The
content of this framework represents a significant
amount of real development experience from a number
of commercial software suppliers and their customers.
These specifications reflect the product architectures of
those companies, as well as the requirements of their
customers. This evolution process should continue as
more products based on the CIM Framework are
developed.
3.1.1 This guide acknowledges the following
deficiencies that should be addressed in future
revisions. These deficiencies are identified in the
following sections.
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.