IEEE TRANSACTIONS ON SEMICONDUCJ'OR MANUFACTURING, VOL. 7, NO. 2, MAY 1994
`
`l07
`
`The MMST Computer-Integrated Manufacturing
`System Framework
`
`John McGehee, Member, IEEE, John Hebley, and Jack Mahaffey
`
`Abstract-Computer-Integrated Manufacturing (CIM) is the
`harmonious connection, integration, and interoperation of au(cid:173)
`tomation equipment within a manufacturing facility. In a semi(cid:173)
`conductor wafer fab, this includes integration of the process(cid:173)
`ing equipment with all of the supporting systems for product
`and process specification, production planning and scheduling,
`and material handling and tracking. Traditionally, CIM sys(cid:173)
`tems have been characterized as monolithic mainframe-based
`systems and/or inflexible islands of automation with limited inter(cid:173)
`operability. Today's manufacturing demands fully integrated
`dynamic systems which directly support the concepts of lean,
`flexible and agile manufacturing to high quality standards. These
`requirements drove the design of a new CIM system which was
`developed for the Microelectronics Manufacturing Science and
`Technology (MMST) program. This paper provides an overview
`of the MMST CIM system framework which is based on open
`distributed system and object technologies. The CIM system
`was demonstrated in a 1000 wafer pilot production run in
`1993 which achieved world record cycle time, and is now being
`commercialized as part of the WORKS™ product family from
`Texas Instruments.
`
`I. INTRODUCTION
`
`SEMICONDUCTOR wafer fabrication is a very complex
`
`and capital-intensive manufacturing process [ l ]. A modern
`wafer fab, costing several hundred million dollars to construct,
`contains several hundred machines and personnel running
`three shifts per day, seven days per week to produce tens
`of thousands of wafers per month. Production of each wafer
`requires several hundred process steps, each of which must
`be carried out in a hostile, near particle free enivornment to
`exacting tolerances.
`Complexity and cost continue to increase with each new
`generation of semiconductor product. Approximately five
`years of process and equipment development are required
`to achieve reasonable quality and yield for next generation
`devices [2]. Each generation requires more process steps with
`tighter tolerances, and smaller geometrics on larger dies.
`Compounding the increasing complexity of semiconductor
`process and equipment technologies is a massive shift in
`manufacturing strategy brought about by global competitive
`pressures [3]. Semiconductor companies are being forced to
`move from high volume production of commodity parts to low
`
`Manuscript received August I, 1993; revised November 10, 1993 and
`December 22, 1993. This work was supported in part by the Air Force
`Wright Paterson Laboratory and the DARPA Microelectronics Technology
`office under Contract F336 I 5-88-C-5448.
`The authors are with the Information Technology Group, Texas Instruments,
`Inc., P.O. Bo, 655012, MS 3635, Dallas, TX 75265 USA.
`IEEE LofMNumber 9216487.
`is a registered trademark of Texas Instruments, Inc.
`WORKS
`
`volume, flexible and leaner production of application-specific
`parts. Pressure to reduce cost is leading to a re-thinking and
`in several cases a re-engineering of virtually every aspect of
`semiconductor manufacturing.
`Computer-Integrated Manufacturing (CIM) offers the great(cid:173)
`est hope for dealing with this increasing complexity. Un(cid:173)
`fortunately, CIM systems of today fall far short of meeting
`the challenge. Typically implemented as either monolithic
`mainframe-based systems or distributed isolated islands of au(cid:173)
`tomation, traditional CIM systems suffer numerous problems:
`• limited flexibility due to a lack of design for change;
`• nonintegrated due to lack of a common system architec(cid:173)
`ture and design model;
`• limited functionality because a single supplier carmot
`provide full functionality or because multiple suppliers
`carmot provide applications that can be integrated;
`• high development costs and poor quality due to a lack of
`reusability and to the use of poor or outdated development
`methodologies, processes, and tools;
`• high maintenance cost due to designs and implementa(cid:173)
`tions which are difficult to understand, modify and extend;
`• high procurement, installation, and support costs due to
`the use of outdated architecture and hardware delivery
`technologies;
`• difficult to use due to the use of nonintuitive text oriented
`user interfaces.
`Clearly a new, revolutionary approach to semiconductor man(cid:173)
`ufacturing is required to cost effectively meet the integrated
`circuit needs of semiconductor manufacturers and their com(cid:173)
`mercial and military customers. This was the conclusion drawn
`by TI and the DoD when the ideas for the MMST research
`and development program were conceived. A contract for
`this program, sponsored by the Defense Advanced Research
`Projects Agency (DARPA) and the Air Force Wright Paterson
`Laboratory was awarded to TI in October of 1988.
`The objectives for the MMST program are covered in
`[4] and summarized in Table I. Achieving these objectives
`required significant innovations in all aspects of wafer man(cid:173)
`ufacturing, including new rapid thermal processes, in situ
`sensors, modular processing equipment, and development of a
`next generation CIM system architecture which could exploit
`the capabilities of these new technologies while addressing the
`deficiencies of current CIM technology. This paper provides
`an overview of the MMST CIM system framework which is
`based on open distributed systems and object technologies.
`Additional background on the CIM system can be found in
`[5] and [6].
`
`0894---0507/94$04.00 © 1994 IEEE
`
`Authorized licensed use limited to: University of Texas at Austin. Downloaded on June 20,2020 at 18:46:18 UTC from IEEE Xplore. Restrictions apply.
`
`Applied Materials, Inc. Ex. 1013
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 1 of 10
`
`

`

`108
`
`IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING. VOL. 7. NO. 2. MAY 1994
`
`Factory cost > $500M
`Silicon only
`
`TABLE I
`COMPARISON OF MMST AND CONVENTIONAL PROCESSING
`MMST Technology
`Current Technology
`Modular, 100-1000 wafer/month
`Large, fixed 20,000 wafer capacity
`capacity
`Factory costs $30-50M
`Generic manufacturing (HgCdTe,
`GaAs)
`Class I 000 cleanroom
`Liquid free processing
`Single wafer processing
`Real-lime process control
`5-15 day cycle time
`Modular vacuum processing
`equipment
`
`Class I cleanroom
`30% of processes use liquids
`25-50 wafer batches
`Batch sampling
`1-3 month cycle time
`Mixed equipment configurations
`
`II. MMST CIM SYSTEM REQUIREMENTS
`The requirements for the MMST CIM system were derived
`through an analysis process which was based upon the ob(cid:173)
`jectives for the MMST program as a whole. Essentially, the
`CIM system was required to integrate and automate the wafer
`manufacturing process both horizontally (i.e., order entry
`through finished wafer output) and vertically (i.e., production
`planning through embedded machine control). Specifically, the
`following functions were to be provided:
`1) planning of factory operation from order entry through
`wafer production;
`2) scheduling of factory resources to meet the production
`plan;
`3) modeling and simulation of factory operation;
`4) generation and maintenance of process and product
`specifications and recipes;
`5) tracking of work-in-progress (WIP);
`6) monitoring of factory performance;
`7) machine monitoring, control and diagnosis;
`8) process monitoring, control and diagnosis.
`In addition to these general functional requirements, a number
`of additional MMST requirements were derived from the
`principal objectives of reduced cost and cycle time with
`higher flexibility and quality. These requirements are shown in
`Table II and together they formed the basis of the subsequent
`CIM system architecture analysis, design, and implementation
`phases. The following sections provide an overview of the
`architecture, including the fundamental principles, application
`partitioning, system services, and development of a generic
`framework for semiconductor manufacturing.
`
`III. CIM SYSTEM FOUNDATION
`
`As discussed in the prior sections, the vision for the MMST
`factory of the future was driven by the principle objectives
`of flexibility, reduced cycle time, improved quality, and low
`cost. At the outset of the program, it was recognized that the
`CIM system if properly designed could have significant impact
`on each of these objectives. Flexibility could be enhanced
`by designing a CIM system which supports single wafer as
`well as to batch processing. Cycle time could be reduced by a
`CIM system with a bottleneck resource-regulated scheduling
`strategy which reduces WIP. Quality could be improved
`with CIM system support for automatic material identification
`
`· 1
`
`Cycle Time
`
`TABLE II
`MMST CIM SYSTEMS REQUIREMENTS AS DERIVED FROM FACTORY OBJECTIVES
`MMST Factory Objective Derived CIM System Requirements
`- pilot wafer elimination
`- WIP reduction/tracking
`- dynamic look-ahead scheduling of bottleneck
`resources
`- capacity based planning
`- factory simulation/modeling
`- workload balancing
`- resource-regulated material release
`- high performance application software
`- distributedUnix workstation-based
`implementation
`- incrementaVmodular expansion
`- support for automation
`- paperless operation
`- increased application development productivity
`- decreased application maintenance
`- JIT planning/scheduling
`- cost modeling/tracking
`
`Cost
`
`Flexibility
`
`Quality
`
`- single wafer processing
`- incremental/modular expansion
`- scaleable application software
`- machine independent process recipes
`- integrated applications
`- dynamic system extension/evolution
`- distributed client-seIVer architecture
`- automatic configuration/application binding
`
`- process control/diagnosis
`- process recipe management/upload/download
`- automated material idcnlification
`- process data collection/analysis
`- faclory/machine performance monitoring
`- preventive maintenance tracking/scheduling
`-SQC
`- high quality application software
`- effects-to-settings translation
`
`and recipe download to eliminate operational errors, and
`embedded process control which can keep each process in
`tune. System purchase, operation, and maintenance costs could
`be significantly reduced with appropriate choices for CIM
`system technology . Finally, and perhaps most importantly, all
`of these objectives could be facilitated with the highest quality
`of software engineering.
`Traditionally, CIM system software has been characterized
`as expensive to develop, inflexible, and difficult to maintain
`or extend, all of which are characteristic of what is often
`referred to as the "software crisis" [7]. Fortunately, a new
`paradigm has emerged which specifically addresses each of
`these problems and provides a significant lift in overcoming
`them. The paradigm is based on object technology , and it
`represents a revolutionary new approach to all phases of soft(cid:173)
`ware development from analysis and design, to implementation
`and operation. A detailed description of the object-oriented
`approach can be found in [8]. In a nutshell, it is based on four
`fundamental principles.
`1) The object abstraction consisting of both data and proce(cid:173)
`dures (called methods) which enables software entities to
`model the real world, making them more understandable
`and stable over time.
`
`Authorized licensed use limited to: University of Texas at Austin. Downloaded on June 20,2020 at 18:46:18 UTC from IEEE Xplore. Restrictions apply.
`
`Applied Materials, Inc. Ex. 1013
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 2 of 10
`
`

`

`McGEHEE et al.: THE MMST COMPUTER INTEGRATED MANUFACTURING SYSTEM FRAMEWORK
`
`109
`
`2) Encapsulation of data and behavior into objects which
`enables them to be changed without affecting the clients
`of those objects.
`3) Inheritance (of data and behavior) and composition
`which facilitate the creation of reusable software com(cid:173)
`ponents.
`4) Dynamically bound polymorphic behavior which en(cid:173)
`ables the construction of applications, tools, and frame(cid:173)
`works which can accommodate a wide variety of object
`types without type specific code.
`Together these principles provide a powerful new foundation
`for software engineering in general and system architecture in
`particular. The MMST design team adopted the object-oriented
`approach whole-heartedly as the foundation upon which to
`base the CIM system architecture. The CIM system was
`developed using object-oriented analysis, design, and rapid
`prototyping methodologies, and is implemented in an object(cid:173)
`oriented environment and programming language (Smalltalk).
`Each CIM application is comprised of a set of objects with
`well defined services and graphical object-oriented direct ma(cid:173)
`nipulation user interfaces. Further, the fundamental principles
`and attendant advantages of the paradigm at the object level
`have been exploited at the subsystem level as well, through
`use of an object-oriented framework design concept which is
`discussed in a section VI.
`
`IV. CIM SYSTEM ARCHITECTURAL PRINCIPLES
`In addition to its object-oriented foundation, the CIM system
`architecture was based on a number of other fundamental
`principles. These principles were a direct reflection of the
`vision of the system architects and were used to set the
`overall architectural direction and to tradeoff alternatives in
`architectural design. The most important of these principles
`are discussed in the following paragraphs:
`Distributed Object-Oriented Peer-to-Peer Architecture: The
`architecture is fundamentally object-oriented for reasons men(cid:173)
`tioned earlier. Applications are distributed to the point of
`most need, and their services are available to distributed
`clients. Distributed applications enhance performance and fault
`tolerance, and facilitate incremental flexible expansion.
`Fully Integrated Dynamically-Bound Applications: Each ap(cid:173)
`plication is comprised of objects with well known services.
`External applications needing those services deal directly with
`the objects that provide them, enhancing performance and
`fault tolerance. For example, an application needing to know
`the status of a particular machine sends a message to the
`corresponding machine object.
`Additionally, applications are dynamically bound to the
`greatest extent possible. A client object doesn't bind with a
`server object until the point in run time when the service
`is needed. For example, when a wafer is ready for the next
`process step, the scheduler considers all machines capable of
`performing that step at that instant, including any that may
`have just been brought on line. Dynamic binding makes the
`system more resilient and adaptive to instantaneous changes
`in factory status or configuration.
`
`Intelligent Proactive Pull-Oriented Object Model: Objects
`are given as much intelligence as is practical and take on
`proactive role in improving the state of their domain. For
`example, machines will actively seek work when they are
`idle. They also know their preventive maintenance (PM)
`requirements and will request PM services when due. This
`pull-oriented object model also serves to enhance the operation
`of the factory. Material is not released into the factory until
`there are resources available to process it, reducing work-in(cid:173)
`progress (WIP) and decreasing cycle time.
`Event-driven Object Interaction: Objects are automatically
`notified whenever an aspect of interest of an object of interest
`changes. This eliminates the need for polling for object status,
`reducing CPU overhead and increasing system responsiveness.
`Furthermore, the objects to be notified are dynamically bound
`and are transparent to the object which has changed.
`Universal Object Communication With Transparent Object
`Location: Any object in the system can communicate with
`any other object without knowledge of or regard for (short
`of transport delay) its location. Restrictions are applied for
`certain objects for safety or security reasons and to protect
`encapsulation. Location transparency reduces application code
`volume and complexity and facilitates portability.
`Object Purity First; Compromise Only Where Essential
`Maintaining object purity throughout the system is essential if
`all the benefits of the paradigm are to be realized. Exceptions
`introduce limitations which destroy the simplicity, power, and
`ease of use.
`Once a pure object design is completed, analysis of that
`design will indicate if the paradigm must be violated, usually
`either for capacity or performance reasons.
`Graphical Direct Object Manipulation/Navigation U/F Par(cid:173)
`adigm: User interfaces are object-oriented and users interact
`with the system following the paradigm of direct object
`manipulation. That is, objects on the screen should represent
`familiar real-world objects with which a user interacts by
`addressing (pointing at) them and selecting what he wants
`them to do. In addition, he can navigate from an object to any
`other object that it references. For example, it is possible to
`navigate from the factory object to any object in the factory
`or from a machine object to any object within the machine.
`Generic High-Level Abstractions: Every limb in the object
`class inheritance hierarchy is rooted in a series of rich ab(cid:173)
`stractions that are generic across application domains. For
`example, while leaf nodes on the limb might be specific
`to Semiconductor Manufacturing, root nodes are applicable
`to manufacturing within any industry. This enables the CIM
`framework to be used in alternative manufacturing domains.
`Any Application/Screen From Any Workstation: An appli(cid:173)
`cation can be executed on any node in the system and
`have its user interface either locally or remotely located. For
`example, it is possible to execute the Planner application
`on one workstation with its user interface on another. This
`promotes flexibility by separating locality of use from locality
`of execution.
`Any Platform/Operating System/Network: Applications are
`portable to the greatest extent possible to enable transparent
`exploitation of advances in computer hardware and system
`
`1 --
`
`Authorized licensed use limited to: University of Texas at Austin. Downloaded on June 20,2020 at 18:46:18 UTC from IEEE Xplore. Restrictions apply.
`
`Applied Materials, Inc. Ex. 1013
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 3 of 10
`
`

`

`110
`
`IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING, VOL. 7, NO. 2, MAY 1994
`
`Logical (Class) Architecture
`
`Physical (Object Instance) Architecture
`
`, Document
`
`ProcessSpec
`
`DISTRIBUTED WORKSTATIONS
`
`• Factory Planning
`• Factory SchedJWng
`· Factory Sirrulation/Modeling
`- Factory Performance Monttoring
`- Spec GenerationtManagement
`- Production Planning
`- WIP Tracking
`
`localAr&aNetwolk
`
`(Pliml
`~
`
`MODULAR PROCESSING
`EQUIPMENT
`
`- Machine/Process Control
`- Machine/Process Diagnostics
`· Equipment Pe<formance Monrtoring
`- Recipe Download
`- Intra-machine Scheduling
`- PM Schedufi,vTracking
`-SOC
`- Data/Event Collection/logging
`
`7
`/
`I Advanced '
`·
`Varuum
`Processor /
`
`Fig. I. Object-oriented system architecture.
`
`software. To a large extent, this feature is facilitated by the
`chosen environment (Smalltalk).
`Standards Where Appropriate: Adoption of appropriate in(cid:173)
`dustry standards simplifies the requirements, reduces devel(cid:173)
`opment time and effort, facilitates portability, and enhances
`resale. Several standards were adopted at the outset (e.g.,
`UNIX™, X Windows™, Motif™, Ethernet™, TCP/IP, Sock(cid:173)
`ets, SECS, SEMI GEM) and several others are being tracked
`for possible future incorporation (e.g., several OSF and OMG
`standards).
`
`V. CIM SYSTEM ARCHITECfURE OVERVIEW
`The architecture of a distributed object-oriented system
`is multidimensional. Examples of the two most important
`dimensions, the logical and the physical, are shown in Fig. I.
`The logical architecture is represented by the object class
`inheritance hierarchy. At the top of this hierarchy lie the most
`abstract and generic classes (e.g., Document, Plan, Resource,
`Material). These abstractions are reusable across domains. For
`example, Document contains the data (e.g., revision number)
`
`UNIX™ is a regiSlered trademark of AT&T.
`X Windows TM is a registered trademark of the Massachusetts Institute of
`Technology.
`Motif™ is a registered trademark of the Open Software Foundation.
`Ethernet™ is a registered trademark of the Xerox Corporation.
`
`and behavior (e.g., print) required for all types of documents
`within an Enterprise. At the bottom of the class hierarchy
`lie the most concrete and specialized classes (e.g., Process
`Aow Spec, Wafer Start Plan, Cluster Tool and Wafer). These
`abstractions, generally only applicable to semiconductor man(cid:173)
`ufacturing, inherit the data and behavior of all of their super(cid:173)
`classes and specialize them, either through adding data and
`behavior, or by overriding that which is inherited.
`The physical architecture is represented by the object in(cid:173)
`stance hierarchy as shown on the right hand side of Figure I.
`Objects (instances of leaf node classes in the logical hierarchy)
`are grouped by many "using" or "containing" relationships
`and distributed to the various compute nodes throughout the
`factory. For example, a Machine (object) contains many other
`objects (e.g., Chambers, Valves, Robots, Pumps). These are
`instantiated on the various computers within the machine, such
`as the host user interface computer and one or more embedded
`process control computers.
`Each instantiated object (e.g., Robot) has a set of responsi(cid:173)
`bilities (e.g., material movement) and provides a set of services
`(e.g., moveMaterial) to other "qualified" objects within the
`system. Other objects may be involved in providing the
`service (e.g., the Robot must collaborate with both the source
`and destination objects for material handoff). Inter-object
`messaging is used for all object interaction, and parameters
`associated with these messages, both passed and returned, are
`also objects.
`
`Authorized licensed use limited to: University of Texas at Austin. Downloaded on June 20,2020 at 18:46:18 UTC from IEEE Xplore. Restrictions apply.
`
`Applied Materials, Inc. Ex. 1013
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 4 of 10
`
`

`

`McGEHEE et al.: THE MMST COMPUTER INTEGRATED MANUFACTURING SYSTEM FRAMEWORK
`
`Ill
`
`/
`
`/
`/
`
`Simulator
`Disc Event SIM Framework
`Experiment Design
`SIM Data APT/Analysis V
`
`I
`
`I
`
`/
`
`/
`/
`
`Planner
`Order Entry
`Plan Creation
`Wor1< Release
`Incremental Planning
`What-tt Planning
`Strategy Management I/
`/
`
`FaciOfY Confiouration/Status
`Material Start Plan
`Machine Status
`
`Material Specs
`
`r
`V
`5...., .. .....,,., V
`Step Editor
`Sequence Editor
`Flow Editor
`CM Control
`Validation
`Equip Hierarchy V
`
`/
`
`Factory
`Factory Framewor1<
`F ab Config/Startup/Shutdown
`Operations Management
`WIP Tracking
`F ab Performance
`
`/
`/
`
`V
`
`+
`
`Material Movement
`Commands
`I
`/ '
`Scheduler
`Machine Loading
`Machine Setup
`Lot Release Control
`Lot Movement Control IV
`
`/
`I/
`
`~
`
`I.
`
`Machine
`Schedule
`
`/
`
`Svstem Sen/Ices
`ObjectBase
`Remote Objeci Comm
`ISIS
`Generic Data/Info Mngt
`User Interface Builder
`Bulletin Board
`Alanming/Logging
`Reporting
`
`/
`/
`
`IV
`
`/
`
`/
`V
`
`/
`
`/
`T
`Process Control /
`Effects Xlation
`Process Data Collection
`Settings
`Data Analysis
`Model Tuning
`Diagnosis
`
`,/
`
`GEM
`Machine Control Core
`Material Transfer
`Machine Scheduling
`Wafer Data Collection
`Performance Monitor
`PM Management
`Remote Machine Monitor
`3rd Party Equip Adapters /
`/
`~hlne Control
`AVP Specialization
`Endpoinl Detection
`MFC Calibration
`Machine Maintenance
`Smart Sensor 1/F
`Multi-Zone Controller
`
`1.....-
`
`Fig. 2. MMST CIM system applications.
`
`A. CIM System Services/Application Environment
`The services provided by the CIM system have been parti(cid:173)
`tioned into 8 major applications as shown in Fig. 2:
`• Factory Manager,
`Factory Planner,
`• Factory Scheduler,
`• Factory Simulator,
`• Spec Manager,
`• Generic Equipment Model,
`• Machine Control,
`• Process Control.
`Each application typically contains several subapplications,
`any one of which can be executed as a separate UNIX process
`on any node in the system. Applications interact with each
`other via messages between their well known objects. For
`example, if the Scheduler needs to know the status of a
`
`particular machine, it sends a message to the instance of the
`GEM Machine object of interest. A brief overview of each
`application is provided in the following paragraphs. Refer to
`subsequent papers in this issue for more detailed information.
`Factory Manager: The Factory Manager is logically the
`highest level application in the CIM system. It contains many
`factory level abstractions (e.g., Factory, Area, Material, User,
`Material Transporter) that serve to tie all the applications
`together (e.g., it is possible to navigate to any object in the
`factory from the Factory object itself). The Factory Manager
`provides services for starting up and shutting down the factory
`and for coordinating the activities of operations management
`personnel while the factory is running. Fab performance mon(cid:173)
`itoring (e.g., throughput, cycle time) and work-in-progress
`(WIP) tracking facilities are also provided.
`Factory Planner: The Factory Planner is the focal point
`for the acceptance of factory orders and the generation of
`
`L
`
`- ---·- 7 -
`
`Authorized licensed use limited to: University of Texas at Austin. Downloaded on June 20,2020 at 18:46:18 UTC from IEEE Xplore. Restrictions apply.
`
`Applied Materials, Inc. Ex. 1013
`Applied v. Ocean, IPR Patent No. 6,836,691
`Page 5 of 10
`
`

`

`112
`
`IEEE TRANSACTIONS ON SEMICONDUCTOR MANUFACTURING. VOL. 7. NO. 2. MAY 1994
`
`a production plan that identifies which wafers are to be
`produced by the fab during each time period. The Planner
`works hand-in-hand with the Factory Scheduler, with the
`Scheduler being responsible for driving the factory to meet the
`delivery commitments as specified by the Planner. The Planner
`and the Scheduler collaborate to control material release into
`the factory, with the Scheduler controlling when material is
`released (based on WIP levels, bottleneck loading, etc.) and
`the Planner controlling what material is released. Both are
`driven by a configurable production strategy based on a set of
`user definable goals (e.g., minimize cycle time) which enables
`the operation of each fab to be "tuned" to meet its particular
`objectives.
`Unlike prior-generation planning systems, the Planner in(cid:173)
`crementally and dynamically updates the plan based upon a
`capacity model and changes in either order or factory status or
`planning-personnel direction. A fresh plan showing expected
`delivery dates with confidence factors is always available. The
`Planner also can also be used to do "what-if' planning to
`evaluate the effects of either changes to the plan or to the
`factory resources (e.g., the effect of adding a new machine).
`The Planner can then be used with the Factory Simulator to
`verify the plan via simulated production.
`Factory Scheduler: The scheduling of production opera(cid:173)
`tion within the fab is controlled by the Factory Scheduler.
`The Scheduler decides when material is to be processed by
`each machine and directs the factory resources (people and
`machines) to effect those decisions. Scheduling decisions are
`based upon the aforementioned production strategy, the real(cid:173)
`time factory status, machine performance history and a set of
`heuristic rules. Machine failures and preventive maintenance
`actions are accommodated.
`Factory Simulator: The Factory Simulator provides the
`mechanisms required to conduct discrete-event simulations of
`factory operation. Simulations are controlled by user defined
`experiments that specify the factory configuration to be sim(cid:173)
`ulated and any starting and terminating conditions. Real as
`well as hypothetical factories can be simulated at multiple
`levels of resolution (e.g., factory, machine, mechanism, sen(cid:173)
`sor/actuator). Standard CIM user interface builder (UlB) and
`reporting tools can be used to monitor simulation progress,
`and analyze and report simulation results.
`Specification Manager: A computer-aided process engi(cid:173)
`neering (CAPE) environment is provided for generation and
`management of the various CIM system specifications. The
`Specification Manager includes editors for entering and modi(cid:173)
`fying new process steps, sequences, and flows and an engineer(cid:173)
`ing change notice (ECN) management system for controlling
`revisions, effectivity, signoff, and activation. The system sup(cid:173)
`ports the generation of machine-independent, effects level [9]
`process specs that are readable and directly executable by the
`new class of MMST-compliant machines. Other capabilities
`provided include support for spec libraries, process step hi(cid:173)
`erarchies with inheritance, spec validation and all electronic
`(paperless) operation.
`· Generic Equipment Model:The Generic Equipment Model
`(GEM) provides an object-oriented model for the new gen(cid:173)
`eration of architecturally compliant machines. GEM models
`
`all aspects of common machine operation, including material
`transfer, intramachine scheduling, material processing, data
`collection, performance monitoring, and preventive mainte(cid:173)
`nance. Compliant machines implement GEM directly, spe(cid:173)
`cializing where required. For noncompliant machines, GEM
`provides a generic adapter, parts of which can be mapped
`into whatever machine connection capabilities exist (e.g., the
`SECS-II SEMI Equipment Communications Standard).
`Machine Control: Machine Control is principally responsi(cid:173)
`ble for controlling the sequencing and settings of the various
`machine resources in response to external commands for pro(cid:173)
`cessing. Any specialization of GEM required for a specific type
`(vendor/model) or instance of a machine is also provided by
`Machine Control. This can include such things as specialized
`sensors, calibration procedures, maintenance instructions and
`programs for controlling unique machine operations.
`Process Control: Responsibility for ensuring consistency
`and quality of processing for a specific machine is provided
`by Process Control. Fundamentally, this is the translation of
`the desired effects, as specified by the machine-independent
`process spec, into the actual machine settings as needed
`by machine control or GEM, to realize those effects. The
`actual translation is based upon a model of the process
`which is tuned over time to compensate for drift in machine
`characteristics. Process diagnosis is also provided to detect and
`isolate machine failures and out-of-tolerance conditions.
`
`B. C/M System Applications
`A rich object-oriented application environment was de(cid:173)
`veloped to facilitate delivery of the CIM applications. In
`addition to the traditional platform specific services such as the
`operating system, database, communication and user interface
`facilities, a higher-level set of generic system services as
`well as platform service extensions are provided. As shown
`in Fig. 3, these new services can be viewed as additional
`layers on top of the platform specific services. They include
`persistent object storage (Object Base), distributed object
`communications, user interface building/execution services
`and facilities for collecting, logging, alarming and reporting
`on system data and events.
`These services and their associated APis provide a very
`rich and highly portable, platform independent environment
`for the deployment of distributed Smalltalk applications. A
`brief overview of these services is provided in the following
`paragraphs:
`Operating System: For the initial deployment of MMST,
`most of the platforms ran the UNIX operating system. Ap(cid:173)
`plications were shielded from differences between the vendor
`supplied versions of UNIX by the Smalltalk virtual machine
`(VM) which translates operating system specific services into
`Smalltalk generic services. Deployment under other operating
`systems (e.g., OS/2™, Windows™ , and MacOS™) can be
`supported without change to application code.
`
`is a registered trademark of International Business Machine