21st Century Semiconductor Manufacturing Capabilities (continued)


Previous Next     Page 4 of 8

Application of OM&S Technology

The following are examples of how OM&S technology can be applied:

More detailed discussions of applications of operational modeling may be found in Court Hilton's paper entitled "Manufacturing Operations System Design and Analysis" and Karl Kempf's paper "Improving Throughput Across the Factory Life-Cycle" also appearing in this Q4'98 issue of the Intel Technology Journal.

Note that all of the above examples are specific applications; they do something for someone who has a specific issue to resolve. As such, they are highly beneficial. But the real payoff comes when all these applications are linked through some integrated, hierarchical model. The benefits of such a model can be imagined by comparing it to Microsoft Windows*. In Microsoft Windows, each application (Word*, Excel*, PowerPoint*, etc.) is individually very useful, but the ability to share textual and image objects between applications greatly enhances the whole. The total Windows environment is more than just the sum of its parts.

So part of the evolving OM&S effort is aimed at defining a modeling hierarchy, and establishing the links and infrastructure between modeling elements, to make the entire modeling environment much more than the sum of the individual components. This is schematically illustrated in Figure 4, where the NOW environment shows individual models, distributed through the manufacturing enterprise, and the FUTURE scenario shows an evenly distributed, linked hierarchy of models.

Figure 4: Modeling hierarchy

Figure 4: Modeling hierarchy

The scope of operational modeling is very broad, as illustrated in Figure 5. For convenience, the operational environment has been divided into three roughly equal domains: those dealing directly with product (the PHYSICAL DOMAIN), those dealing with the data and information associated both with the product and with the factory itself (the INFORMATION DOMAIN), and those dealing with background and support issues (the INFRASTRUCTURE DOMAIN). Each of these domains is itself sub-categorized, as shown in Figure 5.

Figure 5: Model scope

Figure 5: Model scope

Each sub-category is made up of sub-sub-categories, and so on, until one reaches the lowest level of the model hierarchy. Hence, each topic can have applications, roadmaps, goals, interfaces, etc.; the question is, how many of these topics have common elements and should actually be integrated with one another. This integration is both lateral, meaning across equivalent levels of hierarchy, as well as being up and down the chain of model hierarchy. It raises interesting philosophical questions about model integration, as well as deep practical questions of how one may make modeling capabilities more cost-effective and efficient.


* Other brands and names are the property of their respective owners.


Previous Next     Page 4 of 8