semi合集-English.pdf - 第2663页

SEMI E96-1101 © SEMI 1999 , 2001 3 3.2 Mapping to Alt ernate Distr ibuted Computin g Infrastructures 3.2.1 T he CIM Framew or k provides a specification for MES software compon e nts, specified in terms of gener- alized …

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)™

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.

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.

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.