A Framework for Building Intelligent Manufacturing

2 downloads 0 Views 264KB Size Report
rules, and object-oriented programming paradigms in a single application. ... mastering more complex tools, as well as higher initial investments. ..... Page 11 ...... "Artificial Intelligence in Education", IOS Press, Amsterdam / OHM Ohmsha, ...
IEEE Transactions on Systems, Man, and Cybernetics, Part C - Applications and Reviews, Vol.29, No.3, August 1999, pp. 402-419.

A Framework for Building Intelligent Manufacturing Systems 9ODGDQ 'HYHGåLü DQG 'DQLMHOD 5DGRYLü

Abstract--The paper describes a systematic approach to design and development of software for intelligent manufacturing systems. The approach is based on a multilevel, general object-oriented model of intelligent systems. Current methods and software design and development tools for intelligent manufacturing systems either stress particular components of intelligence (e.g., high-level domain expertise, or learning capabilities, or fuzziness of decisions), or their domain dependence (e.g., monitoring and control systems, or CAPP systems). It is usually difficult to make extensions of such methods and tools, nor is it easy to reuse their components in developing intelligent manufacturing systems. Considerable efforts are being dedicated to the development of interoperable software components, distributed object environments, and flexible and scalable applications to overcome some of these problems. The approach described in this paper starts with a well-founded software engineering principle, making clear distinction between generic, low-level intelligent software components, and domain-dependent, high-level components of an intelligent manufacturing system. It is extensible and adjustable. It also suggests some steps towards design of future software development tools for intelligent manufacturing systems. Several intelligent systems have been developed using the approach. One of these systems, in the cement-manufacturing domain, is briefly overviewed in the paper, illustrating how the approach is used in practice. Finally, some informal discussion on the performance and complexity of the approach is presented. Index Terms-- Intelligent Manufacturing Systems, Object-Oriented Systems, Software Components, Hierarchical Modeling.

I. INTRODUCTION Intelligent Manufacturing Systems (IMSs) contain software components using such techniques as expert systems, fuzzy logic, neural networks, and machine learning. The number, the kind, and the complexity of intelligent components of an IMS can vary a lot from one system to another, and the components themselves can be combined in many ways, depending on the application. When designing and developing a particular IMS, engineers often face problems like: • selection of the right software development tools; • choosing between existing but not-quite-appropriate solutions, and developing completely new ones; • extending or adapting some techniques, thus making them capable of handling specific problems of the particular system; • testing the prototype system and defining conditions for performance analysis. A systematic approach to completing all such tasks is necessary in order to handle the complexity of the design and development process. We have made a first step towards developing such an systematic approach, based on the general objectoriented software engineering paradigm. The results obtained are: a) an informal description of a reference model for IMS components; b) an object-oriented model of software design for IMSs; 9ODGDQ 'HYHGåLü 8QLYHUVLW\ RI %HOJUDGH )21  6FKRRO RI %XVLQHVV $GPLQLVWUDWLRQ 'HSDUWPHQW RI

Information Systems, POB 770, Jove Ilica 154, 11000 Belgrade, Yugoslavia. Email: [email protected] 'DQLMHOD 5DGRYLü 8QLYHUVLW\ RI .UDJXMHYDF 7HFKQLFDO )DFXOW\ ýDþDN 6YHWRJ 6DYH   ýDþDN

Yugoslavia. Email: [email protected] 1

c) a practical framework for the implementation of the model. These results are presented in the paper. Throughout the paper, several important and well-known concepts are used from both object-oriented software engineering and manufacturing systems design. They are defined in Appendix A. The paper is organized as follows. First the problem we have been trying to solve is defined explicitly, and relevant previous work is briefly analyzed. Then our proposed solution is described in detail, from its theoretical background and assumptions, to practical design decisions and the current implementation. The proposed solution is analyzed in comparison to other solutions, and an application example is presented. A discussion that follows the example and the analysis notes some facts from our experience in using the proposed solution in practical applications. The concluding Section summarizes the results and responds to the questions put forth in the problem statement. It also points out some directions for future research. Appendices A and B define important concepts and show several design details of our object-oriented model of intelligent systems and IMSs. II. PROBLEM STATEMENT This paper describes the process of IMS design and development from the software engineering perspective. In particular, the objective of the paper is to answer the following questions: 1. What are the levels of abstraction that should be considered when designing an IMS? 2. What are the sets of generic concepts that should be considered at each level of abstraction? 3. What kinds of software development tools are associated with each level of abstraction? 4. What are the strategies that should be used for extensions and upgrades of the software development tools? III. PREVIOUS WORK Since our main concern in this paper is object-oriented software for IMS design and development, this Section briefly overviews and discusses some related issues that have had major influence on our work. The issues are: • the concept of the manufacturing process; • relevant existing software architectures and frameworks; • most important current efforts in the areas of object-oriented intelligent systems, object-oriented manufacturing systems in general, and IMS in particular; • standardization efforts in these areas. A. Modeling and Representation of Manufacturing Processes Since processes and process information are fundamental to manufacturing, a number of software applications attempt to capture the essence of the manufacturing process [Schlenoff et al., 1996]. They include various graphical and simulation tools, as well as tools for analysis, and/or control of manufacturing processes. However, there is still no a definite consensus on a common, formal method for representing processes, in spite of the fact that several research groups have been working on such representations. There is also no common method for representing the kinds of manufacturing processes. For example, the Manufacturing Domain Task Force of the Object Management Group (OMG Mfg DTF) distinguishes among seven distinct kinds of processes: marketing and product support, product design, production planning, production operations, distribution and logistics, business management and quality management [OMG, 1996]. For OMG Mfg DTF there are two main manufacturing application classes: ERP (Enterprise Resource Planing) and MES (Manufacturing Execution Systems). Only the latter (MES) are relevant for the rest of this paper, and they cover: production allocation and status, data collection and acquisition, quality management, process management, maintenance management, supervisory systems, and statistical control. On the other hand, SEMATECH's CIM Application Framework focuses on processes like factory operations, equipment integration, and material management and movement [Doscher and Hodges, 1997], [SEMATECH, 1997]. The work of the Gartner Group, Inc. is similar. Manufacturing process modeling is also being done within the National Institute of Standards and Technology (NIST). NIST's generic approach involves several steps: identifying critical parameters that define product quality, identifying factors affecting these critical parameters; and establishing relationships between the factors and the parameters [Schlenoff et al., 1996]. B. Software Architectures and Frameworks - General An important class of object-oriented general software architectures is the layered architecture [Batory and O'Malley, 1992]. Layers are sets of classes on the same level of abstraction. One extension of the concept of layered software architecture, particularly relevant for our work, is the orthogonal architecture [Rajlich 2

and Silva, 1996]. In the orthogonal architecture, classes (objects) are organized into layers and threads. Threads consist of classes implementing the same functionality, related to each other by the using relationship [Booch, 1994]. Threads are "vertical", in the sense that their classes belong to different layers. Layers are "horizontal", and there is no using relationship among the classes in the same layer. Hence modifications within a thread do not affect other threads. Layers and threads together form a grid. By the position of a class in the architecture, it is easy to understand what level of abstraction and what functionality it implements. The architecture itself is highly reusable, since it is shared by all programs in a certain domain which have the same layers, but may have different threads. Most important current trends in the area of distributed computing include component-based software [Adler, 1995], integration of diverse object-based and other applications within distributed heterogeneous environments (e.g., [Vinoski, 1997]), and design of multi-agent, distributed, collaborative, virtual development environments (e.g., [Lockheed Martin, 1997]). Component-based software systems are designed from application elements constructed independently by different developers, using different languages, tools, and computing platforms [Adler, 1995]. Such a design process is based on the assembly of pretested, reusable, interoperable, independent software components. Interoperability and integration of such components within distributed heterogeneous environments is provided by designing components with standard communication interfaces, infrastructures, and architectures, such as CORBA [Pope, 1997], [Vinoski, 1997]. Communication of such compliant components with non-compliant, legacy code and systems is provided through wrappers, which implement mechanisms for launching the non-compliant applications and translation of different representations of data, which is passed between them. An example of multi-agent virtual development environments is the Simulation-Based Design (SBD) environment [Lockheed Martin, 1997], that supports concurrent engineering throughout the product/process lifecycle by enabling the development of virtual prototypes of products and processes. SBD components include high level agents that support product and process representation, collaboration and design process assembly and activation, visualization and interaction with product data, and integration of external applications. C. Software Architectures and Frameworks for Development of Manufacturing Systems Important software architectures and frameworks in the area of manufacturing, and particularly MES systems, include OMG Mfg DTF's architecture [OMG, 1996], SEMATECH's CIM Application Framework [SEMATECH, 1997], and NIST's Reference model architecture for Control Systems (RCS architecture) [Albus, 1992], [Huang et al., 1995]. OMG's Mfg DTF has proposed a high-level architecture for objectoriented manufacturing systems that ensures consistency and support of manufacturing domain requirements with existing and future OMG specifications [OMG, 1996]. The architecture has three distinct parts: • System Architecture, corresponding to the platform-specific infrastructure elements (e.g. operating system) as well as the Object Request Broker and other parts of CORBA-specific infrastructure (see Appendix A); • Application Framework, corresponding to the "domain interfaces", as defined by the OMG's OMA (see Appendix A); and • Application Architecture, corresponding to the "application interfaces", also specified in the OMA. APPLI-BUS, a distributed object-based middleware conforming to this architecture, is designed to ease the development and integration of manufacturing applications in a distributed heterogeneous environment [Pope, 1997]. Another CORBA-compliant, component-based middleware product for enterprise computing is IBM's Component Broker [Ferguson, 1997]. Its elements include a runtime environment, application builder, and class libraries, frameworks, and pre-implemented components. All of the objects in this architecture are divided into several categories (Application Objects, Business Objects, Composed Business Objects, and State Objects). Objects from "higher-level" categories are dynamically built from "lower-level" objects at run-time. Similar to OMG Mfg DTF's architecture, SEMATECH's CIM Application Framework is based on components that comprise patterns of class behavior that perform invisible units of work in the factory [Doscher and Hodges, 1997]. In a recent joint project between NIST and SEMATECH, the CIM framework is based on CORBA, in an attempt to ease the adoption, use, standardization, testing, and certification of the framework [Kemmerer and Fowler, 1997]. NIST's RCS reference model architecture for intelligent control systems is based on a generic intelligent machine system model [Albus, 1992]. The central idea of that model is that each intelligent machine can be functionally decomposed into a hierarchy of layered blocks. The hierarchy has a regular and recursive structure, and the blocks represent issues like sensory processing, world modeling, interaction with an operator, behavior generation, and value judgement. The levels in the hierarchy are defined by spatial and temporal decomposition of goals and tasks in a manufacturing environment (see [Albus, 1992] for details). 3

D. Object-Oriented and Component-Based Intelligent Systems - General A substantial portion of research in the area of intelligent systems in recent years is done around the concepts of ontologies and knowledge sharing [Chen et al., 1998], [Gruber, 1993a], [Gruber, 1993b], [Mizoguchi and Ikeda, 1996], [Neches et al., 1991]. An ontology defines the basic terms and relations comprising the vocabulary of a topic area, as well as the rules for combining terms and relations to define extensions to the vocabulary. An early example of ontology from the manufacturing domain is the MKS generic model (ontology) of manufacturing operations [Pan et al., 1989]. Ontologies make possible to define an infrastructure for integrating intelligent systems at the knowledge level, independent of particular implementations, thus enabling knowledge sharing [Neches et al., 1991]. Together with various reasoning modules and common knowledge representation techniques, ontologies can be used as the basis for development of libraries of shareable and reusable knowledge modules (which take the form of software components). The work on ontologies, supported by DARPA (Defense Advanced Research Projects Agency), has initiated several well-known projects in the area of intelligent systems. Knowledge Interchange Format (KIF) is a language (an "interlingua"), a form of predicate calculus, by which knowledge can be moved from one declarative system to another [Genesereth et al., 1990], [Ginsberg, 1991]. Generic Frame Protocol (GFP) makes possible to write applications which are portable over variety of frame representation systems and knowledge bases [Karp et al., 1995]. GFP is based on generic knowledge-base functions of frame representation systems. It also has a simple translation layer between these functions and existing functional interfaces of specific systems. The translation is done by a library of object-oriented methods. The associated Generic Knowledge Base Editor (GKB-Editor) allows the user to graphically browse and edit knowledge bases across multiple frame representation systems in a uniform manner. Finally, KQML is a high-level language (a protocol) that enables communication and run-time interoperability between intelligent agents (systems), essentially by specifying wrappers that define messages communicated between the agents [Finin et al., 1994]. Loom and its successor PowerLoom are the systems that provide a language and environment for constructing intelligent applications [MacGregor, 1994], [MacGregor and Burstein, 1991]. Declarative knowledge in Loom/PowerLoom consists of definitions, rules, facts, and default rules. Using objectoriented technologies, declarative knowledge is compiled into a network that efficiently supports on-line deductive query processing. The users of Loom/Power Loom can utilize logic programming, production rules, and object-oriented programming paradigms in a single application. The built-in logic-based pattern matcher drives a production rule facility and a pattern-directed method dispatching facility that supports the definition of object-oriented methods. PowerLoom uses a fully expressive, logic-based representation language (a variant of KIF). The Parka system is a frame-based AI language/tool that can handle extremely large size applications [Evett et al., 1994]. The knowledge base can be defined with class, subclass, and property links used to encode ontologies. Efficiency in handling large knowledge bases is achieved through massive parallelism and use of DBMS technologies. In the latest version, called Parka-DB, the system also supports data mining. As a part of work on the DARPA-supported program called Intelligent Integration of Information Technology (I3), the I3 Services Framework has been defined. The framework specifies key I3 services, which can be used to design and integrate I3 components into large-scale intelligent applications. Internally, the framework is organized as a layered set of services. The Information Services layer at the base of the framework provides a protocol abstraction for information request, update, and subscription. The middle layers are those of Repository Services and Mediation Services, and higher level services include Object, Ontology, Domain Model, User Profile, and other intelligent services. There are also Integration Services, which integrate objects from multiple information sources in domain-dependent ways. Components performing all these services provide a base level of information processing and interaction with a client component. E. Object-Oriented Manufacturing Systems and Intelligent Manufacturing Systems Typical for object-oriented manufacturing systems based on the current technology is a CORBA-based manufacturing environment developed at Sandia National Laboratories for Sandia's Agile Manufacturing Testbed (SAMT) [Whiteside et al., 1997]. Each physical object like lathe, milling machine, or robot arm, has a corresponding CORBA-compliant software object in this environment. Interface functions of these objects provide operations for material processing, material movement, status monitoring, and other tasks. Integration of this testbed management system with process planning, integrated design, and inventory control systems is currently under investigation. Software for IMSs is usually developed using one of the following approaches. In the first one, some integrated design and development tools are applied in the development process. An example is the work 4

of Cho, Lee and Ahn [Cho et al., 1991]. They have used a combination of AutoCAD, CLIPS and dBase environments to develop an integrated process planning and monitoring IMS for turning operation. In the second approach, parts of the IMS are developed first (using some other, simple, lower-level tools), and then they are integrated more or less "manually" into the final software product. An example of the second approach is the intelligent diagnostic system for fabric inspection processing described by Tsai, Lin and Lin [Tsai et al., 1995]. The system is implemented in Prolog, as a rule-based expert system. Apart from standard modules (knowledge base, inference engine, and user interface), the system also has a fuzzy reasoning module developed in Turbo C. The fuzzy reasoning module works with fuzzy linguistic variables, while clauses of the rules in the knowledge base have a more crisp and more classical form (object-attribute-value-certainty factor). In fact, the system handles uncertainty in two ways - by means of certainty factors and by means of fuzzy reasoning. Both these approaches have advantages and disadvantages. The first approach requires additional time for mastering more complex tools, as well as higher initial investments. However, once the tools are mastered, the development of the corresponding system takes less time and it is comparatively easy to extend the entire IMS (but only within the framework provided by the tools used for the initial development). The second approach reduces the costs of tools and requires less training of the design and development staff, but the system development and integration takes longer. Although the developers using this approach have much more control over the software being developed, it is usually tightly coupled with the particular application and must be retailored in order to be used in other applications. The approach closest to the one we propose in this paper is described by Huang et al. [Huang et al., 1995], but it is bound to intelligent automation and control applications. They have proposed a framework for modeling complex automation systems using multiple dimensions. The framework facilitates open and scalable system architectures and efficient processing of system intelligence. Modeling intelligent systems within this framework is supported by NIST's RCS reference model architecture [Albus, 1992]. F. Standardization Efforts Due to the variety of approaches and frameworks in the area of manufacturing software systems, the question of standardization has become extremely important. One of the most relevant standards so far is the STEP standard (STandard for the Exchange of Product model data), developed by the International Standards Organization (ISO). It supports definition of a product and all the relationships it includes, in a way that is independent of software and hardware system characteristics. STEP specifies how information about a product can be exchanged among various applications, which support different aspects of the product development process. OMG Mfg DTF has begun its work on standardizing manufacturing software components of various granularity. Once their standards are completed, they will address data structures, specific interfaces to software components, and functional behavior of components. However, OMG Mfg DTF has recently noted that "These components tend to evolve very rapidly... It is difficult to standardize software components and their interfaces within a domain, and it is arguably not even desirable at the industry level" [OMG, 1997]. The work in this direction at NIST includes representations of constraints for virtual assembly, product data management application interface protocol, manufacturing plant layout representations, manufacturing resource data representations, integration of manufacturing process planning functions, shop floor status representations, and support for a wider adoption of the STEP standard [Kemmerer and Fowler, 1997]. G. Discussion of Previous Work Compared to the issues like process modeling, component interfaces, distributed environments, and interoperability, the issue of intelligence in manufacturing software systems has received relatively little attention. It is particularly the case with groups and agencies working on manufacturing processes, software architectures and frameworks, and components for manufacturing systems. IMSs are addressed explicitly and extensively only in NIST's projects, and just partially and implicitly in DARPA-supported efforts, OMG Mfg DTF's initiatives and SEMATECH's framework. On the other hand, many IMSs have been developed independently to handle specific manufacturing tasks. However, they have not come out of common frameworks and approaches suggested by the above agencies and task forces; they typically have their own representational approach. Benefits that can be gained from a representation, which is common to IMSs for process planning, production scheduling, part type and tool selection, workflow management, and other IMS applications, are not studied thoroughly in these individual systems. Another fact typical for individual IMS development is neglecting the possibility that during the system maintenance and extension additional analysis or design artifacts may be needed to represent other aspects of the system [O'Leary et al., 1997], [OMG, 1996]. Likewise, a change of manufacturing equipment and devices, or a change in requirements that leads to a new functionality and application objects, may result in 5

additional work for the developer. In this sense, it would be very useful for the IMS developer if modifications and additions to the existing system could be handled efficiently, without the need to redevelop a large portion of the system. Changes of equipment and requirements would cause little effort if generic intelligent software components were available to the developer. Such components should represent generic manufacturing processes and equipment. Preferably, these should be heterogeneous commercial off-the-shelf (COTS) components. Without the availability of such components, the constant increase in the number and variety of data types used in the IMS, and the complexity of their physical representation become an extremely hard burden for the system designer. IV. PROPOSED APPROACH The focus of this Section is on the space of components over which IMSs should be developed. We believe that an appropriate and approximate definition of such a space could be the basis for a classification scheme of IMS components. Such a classification scheme and a corresponding software architecture for building IMSs are proposed here. They are considered within in a wider context of an object-oriented model of intelligent systems. We did not try to develop the best possible scheme and architecture. Our goal has been to develop a practical framework for building IMSs, based on a scheme and a model that focus on object-oriented intelligent systems in general, and on manufacturing in particular. The purpose of the scheme and the model is to put up an initial taxonomy of components to be used in building IMSs in multiple manufacturing domains, as well as to make a distinction between intelligent components which are common to multiple domains and those that are domain-specific. We have tried to incorporate most of the advantages of the other approaches, frameworks, architectures, and techniques described in the previous Section. A. Key ideas Like several other approaches, our approach starts from a well-founded software engineering basis, the one of object-oriented and component-based software analysis and design [Adler, 1995], [Booch, 1994]. In the other approaches, the main goal is often to specify object classes with well-defined access methods to allow better cooperation between separate applications or modules (e.g., [OMG, 1997] and [Whiteside et al., 1997]). Although that is an extremely important issue, we are primarily concerned with a hierarchy of such classes. Such a hierarchy enables us to make a clear distinction between generic, low-level intelligent software components, and domain-dependent, high-level components describing conceptual and functional hierarchies of an IMS as a whole. Moreover, it is a good starting point for defining a reusable software architecture that can be shared by multiple IMSs, in different manufacturing domains. The approach further explores the idea of using generic forms of knowledge and knowledge decomposition and management, in a way analogous to that of the RCS reference model architecture for intelligent systems [Albus, 1992]. Our approach is based on the concepts of foundation class libraries for objectoriented software development and software components. Foundation class libraries are similar to components in the sense that they provide pretested and reusable classes for building applications in a specific domain [Booch, 1994]. However, they don't provide interoperability and platform-independence as most components do, since they don't have wrappers and standard interfaces. Encapsulation of components is very hard - strictly those functions that are exposed to interfaces are accessible. Components are autonomous - they always perform complete functions, on minimal interfaces [Pope, 1997]. Foundation class libraries have much steeper learning curves and require more development efforts than components [OMG, 1996]. On the other hand, foundation class libraries are excellent tools for building applications on a preselected hardware when some further derivation from generic classes is expected as a design requirement. In our research and implementations, we have concentrated more on foundation class libraries than on components. The reason is that our initial work has been more traditionally oriented: the major effort has been put into software development and programming. Component-based plug-and-play design and development has not been initially a major issue because in order to build more sophisticated applications, we had to develop generic classes first. However, foundation class libraries provide a good basis for building appropriate software components by transforming class and method definitions into fully interoperable software components (once the component specifications are agreed upon). In particular, such foundation class libraries should contain a large variety of classes describing both simple and complex parts of IMSs, yet none of these classes should be too detailed to cover just a single application. Under the assumption that the appropriate software components are not available yet, the developer of an IMS is supposed to use the foundation class libraries in such a way that the classes actually required are easily derived starting from the classes provided in the libraries. Consequently, the resulting software would remain completely under the developer's control and would be tuned for the particular application. Simultaneously, the development time would be significantly reduced for two reasons: 6

a)

the classes required would not be developed from scratch; most such classes can be designed in a few steps, using slightly more general and more abstract classes from the foundation class libraries and specifying additional attributes and method procedures and functions as needed; b) there is no need to invest in a complex integrated development tool and train the development staff to use it; ordinary software engineering skills and object-oriented design and development practice, combined with the experience of manufacturing design specialists should be quite sufficient for most projects based on this approach. Our approach also takes into account one particular fact stressed in the activities of OMG Mfg DTF, SEMATECH and NIST, and considers it in the context of IMSs as target applications. The fact is that general patterns of dependencies might exist between different IMS application domains, and that common components could be developed for use by IMSs in quite different domains. Another important point in this approach is the one already mentioned in the introduction: as the approach is supported by a well-developed software engineering paradigm, it can be a good basis for development of a more general, formal theory of IMS design. It is beyond the scope of this paper, but we only briefly mention here that one starting point for development of such a theory might be the concept of ontologies. B. Levels of abstraction Developing a foundation class library for any purpose requires the levels of abstraction to be precisely defined. Hence the first problem considered here are the levels of abstraction in designing an IMS. We have defined five such levels of abstraction so far. The levels are: the primitives level, the units level, the blocks level, the system level, and the integration level (see Figure 1 and Table 1). Each level has associated concepts, operations, knowledge representation techniques, inference methods, knowledge acquisition tools, and development tools. They are all considered as "dimensions" along which the levels can be analyzed. The complexity and the number of concepts, operations, tools, etc. grow from the lower levels to the higher ones, hence the number of foundation class libraries rapidly increases at the higher levels of abstraction.

Level of abstraction

Objective

Level 1

Integration

Multiple agents or systems

Level 1

Level 2

System

Single agent or system

Level 2

Level 3

Blocks

System building blocks

Level 3

Level 4

Units

Units of primitives

Level 4

Level 5

Primitives

Parts of units

Level 5

Level of abstraction

Semantics

(a)

Dimensions D1 D2 . . . Dn

(b)

Figure 1. Levels of abstraction and dimensions in the proposed approach It is also important to note that diversity of concepts, techniques, methods, tools, etc. naturally extends towards the higher levels of abstraction. Higher levels are domain-dependent, and it is quite reasonable to expect further horizontal subdivisions at higher levels of abstraction. For example, it is noted in Table 1 that at Level 2 we can define tasks, problems, and tools for each of the subclasses of single agent IMSs (e.g., planning systems, or control systems). Appropriate identification of such subclasses is the topic of our current research, and also (though indirectly) of the research performed by OMG Mfg DTF, NIST, Gartner Group, and in the DARPA/I3 program. Directly connected to that problem are the contents of dedicated foundation class libraries at higher levels. We believe that for reaching consensus on these contents, appropriate vocabularies and ontologies at the higher levels must be developed first. Both Levels 1 and 2 in Table 1 are defined to specify concepts related to an IMS as a whole. The difference between the two levels is in the type of problems treated at each level. At Level 2, concepts, operations, mechanisms and tools are defined for an IMS that can function as a standalone system. For example, an intelligent system for assembly line control can be treated as such a standalone IMS. At Level 1, IMSs are designed for solving problems of coordination and synchronization of multiple other IMSs working together on a more complex problem. Blackboard-based manufacturing control systems are typical examples of IMSs at this level (see [Carver and Lesser, 1994] for a comprehensive overview of blackboard-based systems). Problems of multiple agent cooperation in virtual organizations also belong to this level of abstraction. 7

C. Dimensions Table 2 describes the five levels of abstraction with respect to some particular dimensions. Ideally, the software components/classes at each level can be built using only the components/classes from the adjacent lower level. This means, for example, that various sensors, controllers, and planners defined at the blocks level could be specified only in terms of rules, frames, neural networks, and other lower-level components. Our experience shows that this is not always possible in practice, or it is not always optimal. In other words, drawing strict dividing lines between the levels of abstraction is not an easy task, and can lead to inflexible knowledge and problem representations. However, it is also our experience that the distribution of concepts, techniques, operations, methods, and tools as shown in Table 2, closely corresponds to that of today's IMSs. Table 1 - Levels of abstraction in the proposed approach Level

Objective

Semantics

1

Integration

A complex IMS, containing multiple intelligent agents; each agent takes care of its own problem solving process; coordination and synchronization of individual agents in contributing to the overall problem solving process; domain-dependent level.

2

System

Single agent IMS as a whole (e.g., single assembly system, or single expert system); more specific instances include systems for planning, design, control, and inspection; using general-purpose components from Level 3 as building blocks for defining complex concepts, tasks, problems and tools for particular application types (such as assembly lines, robotic cells, and CAPP systems); domain-dependent level.

3

Blocks

Representational units and functional blocks defining knowledge and control structures reflecting typical data and knowledge objects, as well as the steps and activities performed when solving common classes of problems (e.g., sensor systems, planners, selectors, classifiers, monitors, controllers, and learning agents); domain-independent level.

4

Units

Knowledge representation techniques and reasoning mechanisms, supporting various representational, reasoning and learning paradigms (e.g. production rules, frames, logic, neural networks, and fuzzy sets) or a combination of two or more paradigms; domain-independent level.

5

Primitives

Basic data structures (such as Object-Attribute-Value (O-A-V) triplets) and operations (such as pattern-matching and conflict resolution in rulebased control, or methods for handling uncertainty); domain-independent level.

The classes defined in foundation class libraries can be used for development of fully reusable software components and it is easy to derive more specific classes from them in order to tune them to a particular application. The classes are designed in such a way that their semantics is defined horizontally by the corresponding level of abstraction and its subdivision (if any), and vertically by the appropriate key abstractions specified mostly along the concepts and knowledge representation dimensions. Class interface functions and method procedures are defined mostly from the operations and inference methods dimensions at each level. The knowledge acquisition and tools dimensions are used to specify additional classes and methods at each level used for important IMS development tasks of knowledge elicitation, learning, and knowledge management. Appendix B shows several details related to the classes and class libraries.

8

Table 2 - Levels of abstraction along different dimensions Level

Objective

Concepts

Knowledge representation

Operations

Inference methods

Knowledge acquisition

Tools

1

Integration

Multiple intelligent agents, distributed intelligence

Knowledge sources, problem solving supervisors

Coordination and synchronization of individual agents

Blackboard-based paradigm, multiple paradigms

Interviews, case studies

Integrated development tools

2

System

Single agent IMS, semantics of knowledge elements, application type and structure, process planning

Assembly lines, robotic cells, CAPP systems

Part type selection, scheduling, optimization, planning, design, inspection

Heuristic classification, Knowledge-based planning and scheduling, knowledge-based tool selection

Interviews, case studies, learning from examples

Dedicated integrated development tools and knowledge acquisition and learning tools

3

Blocks

Complex knowledge and control structures, functional blocks, knowledge management, problem solving tasks

Sensors and sensor systems, planners, selectors, classifiers, monitors, controllers, learning agents

Heuristic space mapping, inference method selection, input data abstraction, solution refinement, image classification, learning from examples

Generic tasks, explanation of concepts and problem solving strategies

Interviews, case studies, parameter learning, learning reasoning strategies, learning from examples, genetic algorithms

Special-purpose integrated development tools, learning tools, knowledge acquisition tools

4

Components

Knowledge organization, knowledge management, types of knowledge elements, learning paradigms

Rules, frames, semantic nets, neural networks, fuzzy sets and their combinations

Rule firing, demon procedure invocation, concept generalization

Forward chaining, backward chaining, pattern identification, inference explanation

Interviews, repretory grids, case studies, neural network training, induction, casebased learning

Development shells for expert systems, fuzzy systems, neural networks; knowledge acquisition tools

5

Primitives

Simple data, facts, attributes, structures, formulae, linguistic terms, elementary data processors

O-A-V triplets, A-V pairs, logical expressions, frame slots and facets, rule clauses, neurons, procedures, images, sound

Value assignment, uncertainty calculation, calculation of output from elementary data processors

Pattern-matching, conflict resolution, inheritance

Manual input, measurements, case studies

Programming languages, editors, data acquisition tools

9

D. The OBOA model Tables 1 and 2 represent a condensed background of a recently developed object-oriented model of intelligent systems, called OBOA (OBject-Oriented Abstraction) [Devedzic, 1996]. The model represents a unified abstraction and a taxonomy of different concepts, tools and techniques used for representing and managing knowledge in intelligent systems. The motivation for defining such an abstraction has been to provide: a) a unified and systematic representation of different elements in knowledge bases of a wide range of intelligent systems; b) specification of a set of supporting operations, inference methods, knowledge acquisition tools and learning techniques for knowledge management; c) more general knowledge access methods to be used in interactions between the knowledge base and the other modules of an intelligent system at runtime, as well as in interactions among different modules of integrated development tools at development time. The OBOA model is designed to cover the following dimensions of the abstract space of intelligent systems (see Tables 1 and 2 for an approximate reference): knowledge representation, inference paradigms and methods, communication between the knowledge base and the other modules of intelligent systems and supporting development tools, knowledge acquisition and learning. However, the model sets only general guidelines for developing and using object-oriented intelligent systems. It is open for fine-tuning and adaptation to particular applications. In fact, Tables 1 and 2 show one of many possible starting points for application-dependent adaptation of the OBOA model, the one suited for development of IMSs. It is important to note that in Tables 1 and 2 the upper two levels are domain-dependent, while the lower three levels are domain-independent (the borders between each two neighboring levels are only approximate). This means that once the lower levels are well founded, they can be used as a firm ground for design and development of the upper levels for particular domain(s). That is the essence of the OBOA model. In other words, OBOA differentiates between classes/components that are cross-domain (or "horizontal", as referred by OMG Mfg DTF [OMG, 1996]), and those that reflect adaptations to a particular application area or domain (domain-specific, or "vertical" classes/components). Speaking in terms of software architecture, application-dependent layers (Levels 1 and 2) add domain-specific classes and components on top of those which are domain-independent [Spring, 1996]. However, that doesn't mean that some classes/components at Levels 1 and 2 cannot be shared across multiple application domains. All of the agencies and research groups working in this area note the need for component objects that would reflect common higher level functionalities of multiple domains. The introduction of the levels of abstraction into the OBOA model has a consequence of separating classes and components not only functionally, but also semantically. Domain-dependent classes and components, being specified in terms of the domain semantics and built using the lower-level classes, hide unnecessary lower-level implementation details from the high-level application designer. Higher-level classes map domain concepts onto the corresponding software components. The ultimate practical goal of developing the OBOA model has been to use it as the basis for building a set of foundation class libraries for development of intelligent systems and their blocks and components. The current status of building the libraries is as follows: • Level 4 and Level 5 foundation class libraries are fully developed. They include all of the classes at the lowest two levels of abstraction that we have so far found out to be potentially useful for building IMSs [Radovic and Devedzic, 1996]; • Level 3 libraries are still under development but are implemented to an extent which permits partial development of some libraries from the upper two levels; • initial versions of a few Level 1 and Level 2 libraries are partially developed for some particular applications, like the development of IMSs [Devedzic, 1995], and the development of intelligent tutoring systems [Devedzic and Jerinic, 1997]. Note that although Levels 3, 4, and 5 contain generic classes, the OBOA model doesn't require them to be necessarily fully completed. In terms of the software architecture, they must be completed only to the extent required by a specific thread. In this way, OBOA leaves an open space for development of other basic classes/components, as new knowledge representation techniques and reasoning methods may evolve over time. Some state-of-the-art design and implementation details of the foundation class libraries are presented in a subsequent Section. The OBOA model has been developed using several different ideas coming from the fields of knowledge and data modeling, representation and management. Gruber and Cohen have described a hierarchy of knowledge representation techniques and tools, starting from most primitive ones to quite complex 10

knowledge structures [Gruber and Cohen, 1987]. Subsequently, Gruber has established design principles for ontologies for knowledge sharing [Gruber, 1993a], [Gruber, 1993b]. Debenham has developed an object-oriented formalism for modeling all the data, information and knowledge in an application (e.g., an expert system) in exactly the same way [Debenham, 1994]. Techniques for representing knowledge of external signals in real-time expert systems, described in [Devedzic, 1995], have been developed as classlike representations of properties of I/O data that real-time expert systems exchange with external processes they monitor and/or control. Finally, some ideas from the field of object-oriented databases [Zdonik and Maier, 1990] have been also adopted in the OBOA model. V. ASSUMPTIONS AND CONSTRAINTS In order to understand our design of the foundation class libraries for developing IMSs, presented in the next Section, the reader's general familiarity with object-oriented analysis and design of software systems is required. However, no special familiarity is assumed with the particular method of object-oriented design used to describe parts of our design, the Booch method [Booch, 1994], since it is visually and intuitively clear. Our approach to development of software for an IMS is to spend as much effort as possible on problem analysis and design at each level of abstraction, having an appropriate set of class libraries to start with. It is therefore extremely important to have a variety of essential classes defined in such libraries at each level of abstraction. Intuitively (and also from our own experience), the average effort needed to develop a particular class/component decreases when the variety of classes in the class libraries increases. The only way to increase this variety is to do it incrementally, extending the libraries with new classes as they are found to be necessary in the future projects. Many classes in these libraries are not likely to change once they are properly defined, and can be fully reused many times. However, there may always be a need for another class in any future project. At the moment, it is solely the user's (the IMS developer's) experience that decides upon what classes among those provided in the class libraries are most useful for each particular application. Formal measures of usefulness of the contents of the foundation class libraries with respect to specific application types are still under development. It should also be stressed that at the moment there is no appropriate source of reference regarding the problem of what classes/components exactly should be necessarily included in the libraries as most widely applicable or "standard". Official reports from other groups working in the same area show that their work on standardization is still in progress (for example, see [Doscher and Hodges, 1997], [Kemmerer and Fowler, 1997], and [OMG, 1997]) The issues like component distribution and interoperability have not been central to our work so far. Rather, we have adopted a line of research analogous to the line of NIST, described in [Schlennoff et al., 1997], in which there are two main categories of requirements for manufacturing software representational and functional (interoperability being just one of the functional requirements). Our primary concern so far has been the requirements of hierarchical representation and design of classes/components, as well as their extensibility and adaptability to specific IMS applications. The approach is not bound to development of any particular kind of IMS. However, for the sake of higher clarity and more illustrative presentation, the material presented in the subsequent Sections is partially concentrated on the design used in a practical application in the domain of real-time intelligent control. Hence the presentation of current design and implementation of our foundation class libraries has some details relevant for control applications. In the context of the manufacturing application classes defined by OMG Mfg DTF, the approach presented in the paper is concerned only with MES applications of IMSs. The only foundation class libraries considered here at each level of abstraction are those useful for development of intelligent software components for IMSs, although many others can be defined for other components as well. VI. DESIGN AND IMPLEMENTATION In the course of developing the OBOA model, we have designed several foundation class libraries at different levels of abstraction, some of which have been already used in practical projects. Domainindependent classes from the class libraries at Levels 3, 4, 5 in Tables 1 and 2 are more general and cover those intelligent concepts and operations that can be found in many intelligent software systems, regardless of their purpose and use (e.g., production rules, fuzzy sets and membership functions, learning agents, problem solvers, planners, and inference engines). Several other foundation class libraries are initially designed and partially implemented for the upper two levels, and they are concerned with domaindependent issues (e.g., IMS processing, IMS control, part type hierarchies, scheduling, and optimization).

11

All of the libraries are developed using C++ as the implementation language and MS Visual C++ as the development toolkit. We have also designed and implemented user-friendly, Windows-based supporting environments that facilitate examining and using the libraries in real IMS development. A. Organization of knowledge bases In general, a comprehensive representation of knowledge in a domain can contain several interrelated parts. Authors in the field of artificial intelligence approach this problem in different ways. The most common parts of knowledge treated in the literature include domain knowledge, control knowledge, explanatory knowledge, commonsense knowledge, temporal knowledge, and truth maintenance knowledge (for example, see [Durkin, 1994]). In OBOA, we differentiate between four types of knowledge. Figure 2 shows a simplified global view of an OBOA-based knowledge base organization. The four distinct parts shown are aggregate objects: domain knowledge (presented with a D_knowledge class icon), control knowledge (C_knowledge class icon), explanatory knowledge (E_knowledge class icon), and system knowledge (S_knowledge icon). Temporal and truth maintenance knowledge are treated as parts of control knowledge in OBOA, and commonsense knowledge is not treated explicitly at this stage of development of the model.

KB

D_knowledge

S_knowledge

C_knowledge

E_knowledge

Figure 2. Knowledge base organization Domain knowledge is represented using one or more knowledge representation techniques. It is composed of different interrelated knowledge elements. They can significantly differ regarding their semantics, types and complexity. At Level 5, there are instantiated knowledge primitives, such as simple data (like attribute or relation data) and simple knowledge elements, called knowledge chunks (including different forms of OA-V triplets, logical expressions, procedures, and neurons). At Level 4, knowledge elements come in the form of instantiated units of primitives, or knowledge units (frames, rules, semantic nets, neural networks, and fuzzy sets). At the upper levels of abstraction, domain knowledge is represented by complex knowledge elements (these are represented using either simple aggregations of knowledge components, or conceptually different techniques based on knowledge components, knowledge primitives and knowledge chunks). Regardless of the level of abstraction, all knowledge elements are derived directly or indirectly from the same concept, that of an abstract knowledge element. This stresses the common nature of all knowledge elements in a knowledge base. Control knowledge describes the system's problem solving strategies and its functional model. This knowledge is more or less domain-independent. Examples include meta-rules for describing control strategies, generic tasks of intelligent reasoning, and heuristics for performing temporal reasoning and belief revision. Explanatory knowledge defines the contents of explanations and justifications of the reasoning process, as well as the way they are generated. Some important contents of explanations and justifications include templates for template-based explanations, facts about the history of the inference process, and description of conditions under which a particular reasoning strategy can be applied. System knowledge contains various prompts, help messages, and warnings, describing the contents and structure of a particular knowledge base. Elements of system knowledge also include pointers to some useful programs, which should be handy during the knowledge base building process, since they can provide valuable information. Examples of such programs are various application programs, simulation programs and encyclopedias. Knowledge elements representing control, explanation and system knowledge are also derived using the abstract concept of knowledge element as the base class. All knowledge elements can be classified by their type (e.g., rules, frames, or chunks) and grouped into several homogenous collections (i.e., each such collection contains knowledge elements of the same type). For simplicity, this Section describes only the domain knowledge organization. The other parts of knowledge bases are discussed in a subsequent Section and elsewhere (see [Devedzic, 1995], for example). The organization of domain knowledge is illustrated in Figure 3. Homogenous collections of knowledge elements of different types are represented by the K_elements class icon, which is actually a collection of objects of K_element class. K_element class describes a single knowledge element of domain knowledge 12

and is elaborated in the next subsection. The double line from the D_knowledge class icon to the K_elements class icon, with a point close to the D_knowledge icon, means that the D_knowledge class uses the K_elements class. The 1 and n at the ends of the double line denote the cardinalities of the corresponding classes. K_elements is a generic (parameterized) class that can be instantiated to generate classes denoting collections of knowledge element of particular type. For example, the classes Frames and Rules are instantiations of the K_elements class and denote homogenous collections of frames and rules, respectively.

Frames

D_knowledge 1 n

Rules . . .

K_elements

1

n

K_element

Figure 3. Organization of domain knowledge

B. Knowledge elements The K_element class is an abstract base class describing common properties of all knowledge elements in a knowledge base. Since many classes representing different knowledge elements are derived from K_element at all levels of abstraction, K_element is implemented in a level-independent, common class library (so is the K_elements class and some other classes). The reason for this design decision was the fact that K_element is the most generic class in our design, and we have placed it in the very root of the class diagrams of each level of abstraction. Actual knowledge elements, described by subclasses of K_element, can be of different complexity and type. The most important subclasses of K_element regarding domain knowledge at Levels 4 and 5 are shown in Figure 4. Extensions of the class hierarchy in Figure 4 are possible, by less common or even new knowledge element types. Besides, this organization treats all knowledge elements the same way, regardless of their type and of how common or specific they are. The interface of the K_element class defines all common (but polymorphic) operations which could be done upon its objects (like adding, updating, or deleting). The operations are implemented in the corresponding subclasses. It can be noticed in Figure 4 that certain classes, denoting parts of more complex elements, are at the same level of hierarchy as the corresponding aggregate elements. For example, the primitives like attributes, relations and knowledge chunks are treated as "stand alone", but they are actually parts of more complex components like rules and frames. Such design allows certain simple knowledge elements to be shared between several rules, frames and other components.

K_element Rule

...

Relation Frame

Attribute K_chunk

...

Media

Figure 4. The K_element class hierarchy Attribute and Relation classes (Level 5 classes) define attribute and relation data that should be unique inside a particular knowledge base, and will just have different values assigned in the concrete knowledge elements. This organization reduces redundancy and simplifies the search process. Attribute and relation objects are used for building more complex knowledge elements. For example, the color attribute can be used in several different frames and rules and can have different values assigned to it. The actual 13

distinction is drawn by attaching the single color attribute to different knowledge objects, like the ball or car frames. K_chunk (Knowledge chunk) class objects (Level 5) can be used as slots for Frame or Media objects, or Ifand Then- parts in Rule objects. This abstract class also encapsulates all possible parts of knowledge needed for building other more complex elements. It is open for extensions with either common or even new simple elements. Figure 5 shows the class hierarchy of the K_chunk class.

K_chunk OARV

...

Action

OARVCf

...

Formula OARVmCf

OARVm

Figure 5. Class hierarchy of the K_chunk class The OARV class, as suggested in [Devedzic, 1996], corresponds to the structure: object attribute relation value and it can represent different information, choosing an appropriate object and associating appropriate attribute and relation, as well as a corresponding value. The relation establishes relationship between the attribute and its value. The OARVCf class corresponds to the structure: object attribute relation value certainty factor and is much like the previous structure, except that it has a certainty factor value associated. This class can be used for representing uncertain information, and allows for having a degree of belief in the information. The OARVm and OARVmCf classes are analogous to the OARV and OARVCf classes. They allow for having multiple value attributes, and the OARVmCf class assigns a certainty factor value to each A-V pair. The Formula class describes the knowledge information that has a certain principle of obtaining the end value, and it can be largely applied in computations. The Action class describes the procedural knowledge about some events that can happen and that involve a certain object, or actions that object can perform or that can be performed upon it. The Media class represents different multimedia knowledge elements. This class and its subclasses are defined separately and implemented in a separate class library (also at Level 5), since all of its objects require different user interface, called the multimedia interface, in order to manage operations upon them (like adding, updating, and deleting). The class hierarchy of the Media class is shown in Figure 6, according to the subclasses proposed in [Maybury, 1994]. The Media objects are stored in a multimedia knowledge base (which can be a video base, an audio base and a database), while their descriptions are stored in the common knowledge base.

Media Table

...

Sound Graph

Animation Map

...

Image

Figure 6. The Media class hierarchy Some common attributes of the Media objects could be interface_type, timing, and user_type (color-blind persons need special graphical representation), while the operations should be implemented trough polymorphism in the subclasses.

14

The Table and Graph objects represent qualitative and quantitative knowledge about the problem, usually describing the relationship between some components or attributes, and can be attached to a frame to simplify the presentation process. The Map class is meant to represent different kinds of geographic maps, like geopolitical or economic. The Map objects are widely used in higher-level knowledge elements, in combination with some other Media objects. The Image class objects can be obtained from a scanner, a camera, or simple drawings, and could be used in Frame objects for representing their graphical components (if any). The series of Image objects can represent some event or event ordering, and can be used, for instance, for creating manuals (which are defined as Level 3 knowledge elements). The Animation class objects show the dynamics of some events or objects. They are mostly used for demonstrating processes that are difficult to describe with the text alone. The Sound class objects are often used with other Media objects. A Sound object can not be represented appropriately by a textual description, since the same sound can be interpreted differently by different people. Like all other classes in the OBOA model, the Media class is not necessarily limited to its subclasses defined so far. The last two subclasses of the K_element class shown in Figure 4, the Rule and Frame classes (Level 4), correspond to the common knowledge representation techniques from artificial intelligence. They are usually composed of different K_chunk and Media objects, but are not restricted to them, so every extension is possible. The Rule objects are generally composed of If-clause and Then-clause objects, represented by K_chunk and Media objects. Frame objects can include all other knowledge elements regardless of their complexity, including K_chunk objects, Media objects, Rule objects, and other Frame objects. The Frame class supports multiple inheritance, in order to describe frame hierarchies of domain knowledge more accurately. Frame methods can be created in the form of rules or written as a source code procedure. There are much more classes in the foundation class libraries developed so far, but their description would lead into unnecessarily detailed presentation. We believe this description is sufficient for understanding the example and the analysis shown in the following two Sections. VII. EXAMPLE An example from the domain of cement manufacturing will illustrate the OBOA approach in solving a practical IMS design and development problem. A previously developed expert system for real-time intelligent control of the most complex part of the cement production process, the kiln operation [Devedzic, 1995], has been redesigned using the OBOA model and the associated classes defined in several foundation class libraries. Some interesting design details of the new version of the expert system are shown in this Section. Rotary kiln for cement manufacturing is a complex cylindrical device, consuming fuel for preheating to a high temperature (the temperature inside the kiln cylinder is around 700°C). An appropriate mixture of input material, called raw meal, is fed into the kiln as fine dust. The kiln rotates around its axis and the dust sticks adhesively to the kiln's walls. There it gradually gets burned and baked to produce clinker, coarsegrained pieces of cement which are then transported away from the kiln and milled in a special mill to get the cement dust. The cylinder axis is slightly inclined down from the raw meal feed end to the clinker output end, so that the raw meal dust and subsequently the clinker slowly slip towards the cylinder output. Raw meal must be preheated and completely dry before it is fed into the kiln. Hot smoke generated in the kiln during the clinker production is used to preheat and dry the raw meal. The hot gases are forced through spiral tubes around the raw meal containers, preheating the raw meal, after which they are cooled in a cooler and filtered. Filtering reduces the poisonous contents (mostly carbon-monoxide). Finally, the gases are released into the atmosphere. In order to control the kiln operation successfully, several measurements must be performed continuously in real-time (e.g., rotational speed of the kiln, temperature inside the kiln, and raw meal feed rate). Also several control signals (i.e. setpoint variables) must be generated simultaneously (e.g., signals driving the kiln cylinder motor, and fuel valve driving signal). The measurements are obtained from a sensor system and are converted by a data acquisition system into digital signals that drive the kiln control system. In our implementation, the control system is a real-time expert system based on a dynamic model of the kiln and on heuristic rules specifying how to handle a relatively large set of possible disturbances in the kiln operation. The disturbances are hard to express analytically but are successfully controlled in practice by experienced human operators. The kiln control task includes setting up several output signals so that the rotational speed of the kiln as well as temperature inside the kiln are kept within prespecified bounds, the carbon-monoxide content in the combustion gases are kept below maximum, and several other tasks. 15

The first version of the expert system for kiln control has been built on the basis of a well-developed methodology for building real-time expert systems [Devedzic, 1995]. In order to incorporate that methodology into the OBOA approach, we have developed a number of dedicated classes at Level 3 and distributed them into a few class libraries. The class diagram in Figure 7 shows how some of these classes have been included in the class hierarchy using the strategy described in the previous Section. Some links between the classes are omitted and some are simplified for clarity.

K_element

Rules

1

...

1

Alarm

Signal

n

n

Sensor Frame

InputSignal

...

1 1

n

1

1

n

K_chunk

OutputSignal Figure 7. Some classes for building real-time expert systems In addition to the subclasses of K_element depicted in Figure 4, three new ones, typical for real-time knowledge representation are shown in Figure 7: Signal, Sensor, and Alarm. Although their names are selfexplanatory, it should be noted that their objects are not just simple data structures; they contain built-in information gathered from experience and knowledge about the instances of the concepts they represent. For example, some alarming conditions in the system can be specified by a set of heuristic rules, hence the Alarm class uses the Rules class. Parts of sensors and signals can be described as frame objects. For example, each sensor has the Measurement attribute, which is implemented as a frame and describes how the actual measurement is processed, transformed and treated by the sensor. There are also classes describing real-time reasoning mechanisms at Level 3. The most important two are KBRTmonitor (knowledge-based real-time monitor), and KBRTcontroller (knowledge-based real-time controller). Both are subclasses of the CGT class, denoting a complex generic task of heuristic reasoning. CGT is an aggregate class composed of some other Level 3 classes and some Level 4 classes denoting inference agents of lower complexity. At Level 2, a dedicated foundation class library has been developed for describing the concepts and methods of intelligent real-time cement manufacturing. It contains classes for representing kilns, raw meal, clinker, fuel supply, and dynamic models of kiln control. VIII. ANALYSIS This Section analyzes the features of our approach and compares it to the other existing approaches mentioned in a previous Section. OBOA uses the orthogonal architecture [Rajlich and Silva, 1996] as the underlying software architecture for building IMSs. Although the orthogonal architecture may not be suitable for all domains, its essentially rectangular grid formed by layers and threads closely corresponds to OBOA's scheme of classifying software components for IMSs into levels of abstraction and defining their functionalities by appropriate dimensions. The orthogonal architecture is well suited to the separation between domain-dependent and domain-independent components, and helps discover similarities and dependencies between classes and components in different domains of IMS application. Using class libraries and software components in such an architecture makes it possible to effectively reuse existing software in a new IMS, thus minimizing the development time [ErgoComp, 1997]. Since many IMSs share a common core functionality, a highly cost-effective approach is to share the cost of designing common classes/components and their combinations and interactions across a number of IMSs. From the IMS developer's point of view, OBOA provides some widely applicable generic software to start with and a common architecture and design approach for different IMSs, presenting a common look-and-feel for many IMS development projects. Existing classes/components can be used by developers to freely access, understand, utilize, or modify the design experience gathered through development of other IMSs. In fact, the architecture itself is reused in different applications, and enforces modular thinking during development through recombination. The separation between domain-dependent and domain-independent levels of abstraction in OBOA leads to more robust IMSs, and simultaneously enables development of the domain-dependent class libraries 16

separately from the domain-independent ones. Since OBOA is an open framework, classes may be added at any level of abstraction independently, as they are needed. Even at the generic, domain-independent lower levels, it is impossible to incorporate future knowledge representation work. Therefore, it must be allowed for classes/components to be added at each level when needed. A similar idea is followed by the developers of KIF [Genesereth et al., 1990], [Ginsberg, 1991]. It is necessary, however, for all the classes at the domain-independent levels to be defined with as many details as possible, since they are used to build the upper-level classes. The upper level classes should be specified generally enough in order to be easily reused in different applications. There is apparently no consensus in the research community on what levels of abstraction should be used for definition of components and at what granularity. There is also only a partial degree of overlapping between the levels of abstraction defined in any two of the relevant approaches [Albus, 1992], [Kemmerer and Fowler, 1997], [OMG, 1996], [SEMATECH, 1997]. For example, some levels of abstraction similar to those used in OBOA are defined by OMG Mfg DTF [OMG, 1997]. A rough analogy can be drawn between their "business components" and components defined at Level 2 in OBOA. However, their business components are defined at three sublevels - business process components, business entity components, and utility components. While the first two of these sublevels correspond more to OBOA's Level 2, the utility components are more similar to OBOA's Level 3 components. There is a high degree of similarity between the OBOA approach and the work on ontologies. As it is clearly stated in [Mizoguchi and Ikeda, 1996], [Neches et al., 1991] and [Pan et al., 1989], ontologies lay the ground rules for modeling a domain by defining a common vocabulary in the domain. Since a common vocabulary and semantic interpretations, and consequently many ontologies in the area of IMSs are still to be defined, any related work can be useful. In OBOA, developing ontologies is not our main goal. However, when defining classes and class libraries we necessarily have to consider certain issues related to ontologies. Such issues include commonly used terms in the area of IMSs, commonly used parts of IMSs, and common interactions between them. It would be ideal if all the ontologies that OBOA might need are already present, so that development of classes/components could be straightforward. This way, however, we can only say that our efforts could at least help in future development of ontologies in the IMS domain, which in turn would help us improve our classes and components. The difference between ontologies and our classes/components and schemes is easy to see. The purpose of ontologies is to enable knowledge sharing through development of shared, reusable knowledge bases. The purpose of OBOA's class libraries is to provide software tools that will support shared design of such knowledge bases and the corresponding inference mechanisms, learning components, and knowledge acquisition tools. Ontologies for IMSs are more representation- and specification-oriented, in the sense that they capture knowledge structures of the domain. Class libraries and components for development of IMSs are more design-oriented, since they capture a collection of generic software structures in the domain. It is also worth comparing our approach with the approach using some integrated, high-level design and development tools for IMS development (e.g., [Cho et al., 1991]), and with the approach using lower-level tools to develop parts of the IMS and then integrating the parts "manually" (e.g., [Tsai et al., 1995]). For brevity, these two approaches are referred to as HLT (for High-Level Tools) and LLT (for Low-Level Tools) approaches in the remainder of this Section. The approach of Albus [Albus, 1992] and Huang et al. [Huang et al., 1995] is denoted the RCS approach, and our proposition is called the OBOA approach. The approaches are compared against the criteria defined in Table 3. The results of the comparison are summarized in Tables 4 and 5 in a simplified and approximate form.

17

Table 3 - Criteria for comparing the LLT, HLT, RCS, and OBOA approaches Criterion Generality Simplicity Efficiency Extensibility Uniformity of development Reusability Initial investments Cost of development

Meaning The range of applications for which a particular approach is well suited Ease of use of a particular approach in developing practical applications Reductions in development time that can be achieved using a particular approach Suitability for extending the concepts, methods, and tools used in a particular approach to meet the needs of a new application Degree of using the same methodology, design procedures, and development strategies when applying a particular approach Degree of reusing previously developed pieces of code, as well as previous architectural, design, and testing experience when applying a particular approach Costs of building or purchasing development tools, effort and time needed for training and learning how to use the tools, additional effort in putting the new tools in daily use in a software development organization Average development effort when using a particular approach

Table 4 - Comparison of four approaches to IMS development LLT

HLT

RCS

OBOA

Generality Legend Simplicity

Efficiency

High

Extensibility

Average

Uniformity

Low

Reusability

Table 5 - Comparison of initial investments and costs of application development for four approaches to IMS development LLT

HLT

RCS

Initial investments

OBOA

Legend High

Cost

Average

Low

18

The LLT approach is featured by its high simplicity and low initial investments, since only simple tools have to be provided and mastered in order to begin a project. However, most components have to be developed from scratch, thus increasing the average development effort. The approach is efficient only when developing simple components of IMSs, and the system integration usually reduces the overall development efficiency. Using the HLT approach, high efficiency and uniformity can be achieved in projects of similar types. On the other hand, generality and reusability of components developed by high-level tools are usually just moderate, due to tool dependency. There are exceptions to this observation, however. Whiteside et al. have achieved extremely high reusability of intelligent components developed for their CORBA-based manufacturing environment due to the fact that it has been developed according to the standards of distributed object technology [Whiteside et al., 1997]. Once the tool is mastered, work on further projects can be done at relatively low cost. The biggest disadvantage of this approach are its high initial investments in tools which are not always extendable to perform other tasks that come with new projects. The same results are achieved with the NIST's RCS approach, with an important difference that higher reusability is achieved with lower initial investments. Due to the fact that this approach has been constantly improved and applied over a long period of time [Huang et al., 1995], the cost and effort of using it are minimized. The approach is applicable to a wide spectrum of projects, but it is specialized for development of intelligent control systems only. Moreover, its uniform architecture at all levels of abstraction lacks flexibility and a more explicit way of expressing design heuristics. The philosophy of the OBOA approach can be simply stated as: "Don't start from scratch - start with more general but already developed components instead. From what you are given, select only those components that you really need, and adapt them for your application". A higher degree of generality and suitability for extensions in comparison with the other three approaches is achieved in this way, with most other criteria satisfied as with the RCS and HLT approaches. The following highlights of the OBOA approach regarding extensibility and uniformity/efficiency make it extremely useful in practice. Firstly, the approach is open for extensions by less common (or even new) concepts and tools at each level of abstraction. This is often needed in practical projects, since it usually follows from project requirements and IMS specification that more specific objects are needed in the system than those that can be obtained by merely instantiating the existing classes. Our experience with building IMS components shows that there is a common need for application-specific intelligent software in this area, because many options from general-purpose tools are never really used in practice, and those that are used are often unnecessarily abstract (see [Devedzic, 1995] for further discussion). The classes defined in the foundation class libraries specify some useful common properties that are inherited by all derived classes. Hence including another intelligent component in the overall class hierarchy spanned over the five levels of abstraction in most cases requires the following simple strategy to be applied: a) defining the appropriate level of abstraction for the new component; b) defining what class library at that level most likely corresponds to the nature of the new component; c) exploring the above class library and appropriate class libraries at the adjacent lower level in order to find out the subset of classes which constitute the most natural "context" for deriving the new class (i.e., defining the inheritance and using relationships for the new class); d) defining specific properties and methods of the new class; e) developing the new class using a CASE tool and possibly including it in the class library of step b). This strategy is further illustrated by the example in the previous Section. If there is a need to extend or upgrade the tools at a given level, which is rarely the case, one may have to develop a more complex strategy. Secondly, we should treat all intelligent components in a subtree of a hierarchy equally, regardless of their type and nature (whether they are homogeneous or heterogeneous). Similarly, the components should be treated equally regardless of the fact that they are common or specific to the particular project, because there is always a common class in the root of the subtree. Therefore, the common operations upon intelligent compoments in IMS (e.g., update, search, delete) use the interface of the corresponding highest class in the class hierarchy, but element-specific operations are provided through polymorphism in the corresponding subclasses. Finally, those who prefer using the other three approaches, still can benefit from the OBOA foundation class libraries. For example, it is comparatively easy to develop an integrated IMS building tool starting from the OBOA foundation class libraries, or to use some of the Level 5 or Level 4 classes as a starting point in the LLT approach.

19

IX. DISCUSSION Based on our experience in developing intelligent systems using OBOA approach and the example of the kiln operation control described in this paper, we can derive important conclusions regarding performance and complexity of OBOA approach. Firstly, there are significant problems in the initial stage of developing OBOA systems. In this stage one has to develop various low-level tools and classes in a generic, application-independent form. Although such tools and classes are very useful in the initial stage, most of them may not find application in future developments. In addition, it is quite difficult to define and organize the contents of foundation class libraries and to decide upon the priority in developing the libraries. Even if the libraries are developed to a satisfactory extent, they are more difficult to use than the integrated development tools. Since the libraries are low-level design and development tools, one has to develop an appropriate user interface in order to access their contents in a user-friendly manner. The integrated tools do not require as much programming knoledge as the libraries. However, our experience so far shows that in a long run the approach pays off. Compared to the other existing approaches, using the foundation class libraries approach has the following advantages (apart from those already mentioned in the above comparative analysis): a) incremental development of foundation class libraries eventually yields fully reliable and useful classes at a given level of abstraction; b) the developer has full control over further development, down to the level of source code (this is also possible with the LLT approach); c) the developer can concentrate on the IMS design in the first place, since many intelligent components already exist in a generic form; d) various particular systems can be easily accommodated, due to the possibility of easy extensions and application-dependent diversity of foundation class libraries at Levels 1 and 2; e) well-developed general object-oriented design methodology and CASE tools can be applied. Unlike the CORBA-compliant components that are defined by OMG Mfg DTF, the OBOA classes lack interoperability. Nontheless, they are significantly less complex. There is a great deal of criticism on complexity and additional overhead of CORBA-compliant components (e.g., [ErgoComp, 1997], [Whiteside et al., 1997]). Our work is oriented more towards representation, architectural, and design issues and specification of higher-level interactions between components of IMSs than towards object distribution issues. We are aware of the fact that developing a widely accepted scheme, architecture, model, and framework is an evolutionary process. We believe that the proposed approach will be further impoved with the experience gathered in the future. The improvements will require modifying and extending some concepts and the scheme, specifying precisely the issues that have been left unspecified or partly specified, removing some irregularities, and possibly simplifying or even merging some concepts as the technology evolves. X. CONCLUSIONS Developing the software for intelligent manufacturing systems using OBOA model is a highly systematic process. It starts from the existing foundation class libraries, which contain many useful classes for development of such systems. The classes within libraries are generic in their nature: they can be effectively used to derive specific classes that may be needed in a particular application. Thus with these class libraries developers can easily adapt to practical design problems. The class libraries are all developed according to a hierarchical classification scheme, which defines the levels of abstraction and decomposition in software design. Much of the development of a practical intelligent manufacturing system is concentrated on design and on assembly of preexisting classes. Any necessity for a new class is accommodated by: a) the possibility to identify the level of abstraction within the classification scheme for the new class, and b) the possibility to use existing classes at that level and the lower ones for possible derivation and combinations. It is also a flexible design process, because it only provides guidelines to the developer without imposing restrictions on the actual design. The approach is useful for development of IMSs in a wide range of types and complexity, from small-scale to large-scale systems. It is particularly well suited to developers who specialize in producing generic intelligent application software (tools and environments) for IMS development, both in-house and commercial.

20

The results we achieved so far by developing and using foundation class libraries for building IMSs have helped us establish a solid foundation and a research platform for further IMS research and development. Some essential features of the foundation class libraries are the following: 1. There are five fairly distinct levels of abstraction in the design of a complex IMS: the primitives level, the units level, the blocks level, the system level, and the integration level (see Table 1). The first three of them are domain-independent, while the other two are domain-dependent. The integration level may not be needed for simple IMSs. 2. Generic concepts at each level of abstraction are best formulated through incremental development, and their number grows rapidly towards the higher (domain-dependent) levels of abstraction. Some of them are specified in Table 2. 3. Universal software development tools at each level of abstraction are appropriate foundation class libraries and software components. They can be used in incremental development of more complex and integrated development tools. 4. The most common strategies for tool extensions and upgrades are incremental development of foundation class libraries and software components through experience up to the level when appropriate software repositories can be created. Based on such classes, libraries, components and repositories, one can develop special-purpose, domain-dependent integrated building tools. These features clearly answer the questions listed within the problem statement presented in Section 2. Several further research problems arise from using such an approach in practice. Firstly, it is necessary to precisely specify the foundation class libraries and define their contents at the higher levels of abstraction. This requires domain specialists to participate in research and development, since the upper levels of abstraction are domain-dependent. As the domain complexity quickly grows towards the higher levels, it is necessary to define further subdivisions of the upper levels before specifying the classes and the class libraries at these levels. The subdivisions have to be both horizontal (i.e., defining sublevels) and vertical (i.e., defining subdomains of intelligent manufacturing, such as intelligent control, intelligent assembly, or failure detection and recovery). Ontologies specification research should be performed in parallel to the development of the class libraries and software components for intelligent manufacturing systems. Secondly, a methodology for refinement of initially developed class libraries is needed. Thirdly, the approach described in the paper is concerned only with intelligent software components and tools for manufacturing systems. A possibility to integrate these components and tools with other software products should be considered as well. For example, we may need to integrate data acquisition and integration software with these components and tools. Finally, the question of standardization of such intelligent software components still remains open, although several working groups, agencies, and task forces have already taken steps towards completing that task. XI. APPENDIX A - GLOSSARY OF RELEVANT CONCEPTS Component - A reusable software part, encapsulated unit of code with a built-in interface to an objectframework. Components are usually object-oriented, but have external interfaces that allow interoperability [Adler, 1995], [ErgoTech, 1997]. Common Object Request Broker Architecture (CORBA) - A standard for distributed objects being developed by the Object Management Group (OMG). CORBA provides the mechanisms by which objects transparently communicate with each other, as defined by OMG's ORB and OMA (see below). The ORB provides interoperability between objects, built in (possibly) different languages, running on (possibly) different machines in heterogeneous distributed environments [Pope, 1997]. Distributed Computing - Computing in which components and compliant applications run on a network of computers with an underlying protocol framework that allows interoperability [ErgoTech, 1997]. Interoperability - The capability of a new application to adapt naturally to the existing environment. The ability to share existing data, produced by existing applications, with new applications [Pope, 1997]. Manufacturing Execution System (MES) - An important class of manufacturing applications, defined by OMG Mfg DTF and covering production allocation and status, data collection and acquisition, quality management, process management, maintenance management, supervisory systems, and statistical control. Middleware - An isolation layer between the network/communication operations and the application components or modules; for example, a CORBA-compliant ORB is middleware [ErgoTech, 1997]. Object - An encapsulated unit of code, containing data and procedures that function with that data. Usually the basis of a component [ErgoTech, 1997]. Object Management Architecture (OMA) - A conceptual model and a reference architecture developed by OMG, upon which distributed object-oriented applications can be developed [Vinoski, 1997]. Object Request Broker (ORB) - A mechanism (a middleware) for transparently communicating client requests to target object implementations [Vinoski, 1997]. 21

Wrapper - Code making a non-compliant application or methodology to function as a compliant one; for example, a wrapper for a legacy system can cause it to become CORBA-compliant from the view of other components in the framework [ErgoTech, 1997]. XII. APPENDIX B - OBOA CLASS LIBRARIES There are several class libraries at each level of abstraction, developed in support of the OBOA model. Table 6 shows a number of classes from different libraries, hierarchically grouped by the level of abstraction. The names of the classes reveal their obvious semantics. There is much more classes at each level than those shown in Table 6, but for the sake of clarity not all of them are shown in the table. The idea of Table 6 is only to give the reader a feeling of knowledge organization in the libraries. Table 6 - Selected classes from the class libraries at Levels 3, 4, and 5 Level

Objective

Classes

3

Blocks

Signal, Sensor, Alarm, Planner, Scheduler, Selector, GenericTask, Monitor, Controller, ExplanationGenerator

4

Units

Frame, Rule, Plan, Schedule, Explanation, InferenceEngine, FuzzySet, FuzzyOperator, FuzzyModifier, NeuralNetwork, NetworkTraining, Population, Generation, GAoperator

5

Primitives

K_chunk, Attribute, Relation, Media, Neuron, Layer, Link, Slab, FuzzyVariable, FuzzyProposition, Gene, Chromosome, DataPattern

A vertical semantic grouping is also possible for classes defined in different libraries. For example, FuzzyVariable and FuzzyProposition classes from a Level 5 class library are used by FuzzySet, FuzzyOperator, and FuzzyModifier classes from another, Level 4 class library. The kinds of relationships between different classes have had only a minor importance in making a decision at what level to put a certain class. However, most classes at a certain level are related to the classes at the lower levels by the using relationship (part-of relationship) [Booch, 1994], and can be related to some of the classes at the same level by either using or inheritance relationships. For example, the Level 3 Signal class uses the Level 4 Frame class in its implementation, and the Level 3 InputSignal and Output signal classes are inherited from the Signal class. Class hierarchies can be rather complex in the OBOA model. As an example, consider the class diagram in Figure 8, showing some class hierarchies of the control knowledge part defined in Figure 2. They represent commonly known concepts from the fields of rule-based systems and generic tasks for problem solving (see [Chandrasekaran, 1986] and [Durkin, 1994] for more details). In spite of that fact, the classes multiply at a fast rate when developing libraries with any considerable variety, necessary for practical applications.

22

HeurCl RTmonitoring Rule RTcontrol

Frame

CGT 1

...

Design_PSR 1 1

...

FC_InfEngine InfEngine

Input

FB_InfEngine

K_element

HierCl

...

BC_InfEngine

... n 1 GT 1 1 1 1

1 1

RB_InfEngine

... GTcontrol

1 1

1

1

ConRes

PatternMatcher

BottomUp

Output 1 n

n WME

TopDown

Metacontrol

...

1 1 Metarules

Figure 8. A partial class diagram for control knowledge (GT - generic task; CGT - complex generic task; GTcontrol - generic task control; HeurCl - heuristic classification; RTmonitoring - real-time monitoring; RTcontrol - real-time control; HierCl - hierarchical classification; Design_PSR - design by plan selection and refinement; WME - working memory element; InfEngine - inference engine; FB_InfEngine - frame-based inference engine; RB_InfEngine - rule-based inference engine; BC_InfEngine - backward-chaining inference engine; FC_InfEngine - forward-chaining inference engine; ConRes - conflict resolution)

23

XIII. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

R.M. Adler, "Emerging Standards for Component Software", IEEE Computer, March 1995, pp. 68-76. J.S. Albus, "RCS: A Reference Model Architecture for Intelligent Control", IEEE Computer, May 1992, pp. 56-60. D. Batory and S. O'Malley, "The Design and Implementation of Hierarchical Software Systems with Reusable Components", ACM Transactions on Software Engineering and Methodology, Vol.1, No.4, 1992, pp. 355-398. G. Booch, Object-Oriented Analysis and Design with Applications, 2nd Edition, Benjamin/Cummings Publishing Company, Inc., Redwood City, CA, 1994. N. Carver, V. Lesser, "Evolution of Blackboard Control Architectures", Expert Systems with Applications, Vol.7, No.1, January-March 1994., pp. 1-30. B. Chandrasekaran, "Generic Tasks in Knowledge-Based Reasoning: High-Level Building Blocks for ES Design", IEEE Expert, pp. 23-30, Fall 1986. W. Chen, Y. Hayashi, L. Kin, M. Ikeda, R. Mizoguchi, "Ontological Issues on an Intelligent Authoring Tool", Proceedings of The ECAI'98 Workshop on Model-Based Reasoning for Intelligent Education Environments", Brighton, England, August 1998. K.-K. Cho, S.-H. Lee, J.-H. Ahn, "Development of Integrated Process Planning and Monitoring System for Turning Operation", Annals of the CIRP, Vol.40, No.1, 1991, pp. 423-427. J.K. Debenham, "Objects for Knowledge Modeling", Proceedings of The Second World Congress on Expert Systems (electronic edition), Lisbon, Portugal, January 1994, pp. 979-985. 9 'HYHGåLü 2UJDQL]DWLRQ DQG 0DQDJHPHQW RI .QRZOHGJH %DVHV  $Q 2EMHFW2ULHQWHG $SSURDFK 3URFHHGLQJV RI 7KH

Third World Congress on Expert Systems, Vol.II, Seoul, Korea, 1996, pp. 1263-1270. [11]

9 'HYHGåLü 5HDO7LPH .QRZOHGJH%DVHG &RQWURO RI 5RWDU\ .LOQ 3URFHHGLQJV RI 7KH ,((( 6LQJDSRUH ,QWHUQDWLRQDO

Conference on Intelligent Control and Instrumentation (IEEE SICICI'95), Singapore, July 1-8., 1995., pp. 442-447. [12]

[13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

[25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36]

9 'HYHGåLü / -HULQLü .QRZOHGJH 5HSUHVHQWDWLRQ IRU ,QWHOOLJHQW 7XWRULQJ 6\VWHPV 7KH *(7%,76 0RGHO LQ GX

Boulay, B., Mizoguchi, R. (eds.): "Artificial Intelligence in Education", IOS Press, Amsterdam / OHM Ohmsha, Tokyo, 1997, pp. 63-70. D. Doscher, R. Hodges, "SEMATECH's Experience with the CIM Framework", Communications of The ACM, Vol.40, No.11, 1997, pp. 82-84. J. Durkin, "Expert Systems - Design and Development", Macmillan Publishing Company, New York, 1994. ErgoTech Systems White Paper, "Plug and Play Component Software for Manufacturing Systems", 1997, http://www.ergotech.com/ergotech/mofa.html. M.P. Evett, J.A. Hendler, and L. Spector, "Parallel Knowledge Representation on the Connection Machine", Journal of Parallel and Distributed Computing, Vol.22, 1994, pp.168-184. D.F. Ferguson, "Component Broker: Programming Model Overview", http://www.software.ibm.com/ad/cb/model.htm, 1997. T. Finin et al., "KQML as an Agent Communication Language", Proceedings of The Third Conference on Information and Knowledge Management, Galthersbourg, MD, December 1994, pp. 311-318. M. Genesereth et al., "Knowledge Interchange Format", Technical Report, Logic-90-04, Dept. of Computer Science, Stanford University, 1990. M.L. Ginsberg, "Knowledge Interchange Format: The KIF of Death", AI Magazine, Fall 1991, pp. 57-63. T.R. Gruber, "Toward Principles for the Design of Ontologies Used for Knowledge Sharing", in: N. Guarino, R. Poli (eds.), Formal Ontology in Conceptual Analysis and Knowledge Representation, Kluwer Academic Publishers, Amsterdam, 1993. T.R. Gruber, "A Translation Approach to Portable Ontology Specifications", Knowledge Acquisition, Vol.5, No.2, 1993, pp. 199-220. T. Gruber, P. Cohen, "Knowledge Engineering Tools at the Architecture Level", Proceedings of The 10th IJCAI, Vol.1, Milan, Italy, August 1987, pp. 100-103. H.-M. Huang, J. Michaloski, N. Tarnoff, M. Nashman, "An Open Architecture Based Framework for Automation and Intelligent System Control", Proceedings of The 1995 IEEE International Conference on Industrial Automation and Control: Emerging Technologies, Taipei, Taiwan, May 1995, pp. 282-288. P.D. Karp, K. Myers, and T. Gruber, "The Generic Frame Protocol," Proceedings of the 1995 International Joint Conference on Artificial Intelligence, 1995, pp. 768-774. S.J. Kemmerer, J.E. Fowler, "Initial Manufacturing Exchange Specification (IMES) - IMES Concept Document for Manufacturing Systems Integration", NISTIR 5978, National Institute of Standards and Technology, Gaithersburg, MD, 1997. D. O'Leary, D. Kuokka, R. Plant, "Artificial Intelligence and Virtual Organizations", Communications of The ACM, Vol.40, No.1, 1997, pp. 52-59. Lockheed Martin Artificial Intelligence Center, “SBD Systems Design Paper”, available at: http://sbdhost.parl.com/sbd_paper.html, 1997. R.M. MacGregor, "A Description Classifier for the Predicate Calculus," Proceedings of the Twelfth National Conference on Artificial Intelligence, (AAAI 94), 1994, pp. 213-220. R.M. MacGregor, M.H. Burstein, "Using a Description Classifier to Enhance Knowledge Representation", IEEE Expert, June 1991, pp. 41-46. M.T. Maybury, "Knowledge-Based Multimedia: The Future of Expert Systems and Multimedia", Expert Systems with Applications, Vol.7, No.3, 1994, pp. 387-396. R. Mizoguchi, M. Ikeda, "Towards Ontology Engineering", Technical Report AI-TR-96-1, ISIR, Osaka University, Japan, 1996. R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator, W.R. Swartout, "Enabling Technology for Knowledge Sharing", AI Magazine, Fall 1991, pp. 36-56. Object Management Group (Claude Baudoin, editor), "Manufacturing Enterprise Systems - A White Paper", Document mfg/96-01-02, Object Management Group, Framingham, MA, 1996. Object Management Group, "Standardizing Business Components for the Manufacturing Enterprise", Document mfg/97-1005, Object Management Group, Framingham, MA, 1997. J. Y.-C. Pan, J.M. Tenenbaum, J. Glicksman, "A Framework for Knowledge-Based Computer-Integrated Manufacturing", IEEE Transactions on Semiconductor Manufacturing, Vol.2, No.2, 1989, pp. 33-46.

24

[37] [38] [39] [40] [41] [42] [43]

[44] [45] [46]

A. Pope, The CORBA Reference Guide: Understanding the Common Object Request Broker Architecture, Addison-Wesley, Reading, MA, 1997. ' 5DGRYLü 9 'HYHGåLü 2EMHFW2ULHQWHG .QRZOHGJH %DVHV &RQWHQWV DQG 2UJDQL]DWLRQ 3URFHHGLQJV RI 7KH ,$67('

International Conference on Modeling, Simulation and Optimization, CD edition, Gold Coast, Australia, May 1996. V. Rajlich, J.H. Silva, "Evolution and Reuse of Orthogonal Architecture", IEEE Transactions on Software Engineering, Vol.22, No.2, February 1996, pp. 153-157. C. Schlenoff, A. Knutilla, S. Ray, "Unified Process Specification Language: Requirements for Modeling Process," NIST Internal Report 5939, Gaithersburg, MD, 1996. SEMATECH, "Computer Integrated Manufacturing (CIM) Specification 1.5", Document No. 930616971-ENG, SEMATECH, Austin, TX, 1997. M.B. Spring, "Reference Model for Data Interchange Standards", IEEE Computer, August 1996, pp. 87-88. I-S. Tsai, C.-H. Lin, J.-J. Lin, "Application of Fuzzy set Theory to Diagnosis System for Tracing Breakdown Causes in Weaving", Proceedings of The 1995 IEEE International Conference on Industrial Automation and Control: Emerging Technologies, Taipei, Taiwan, May 1995, pp. 200-207. S. Vinoski, "CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments", IEEE Communications Magazine, Vol. 14, No. 2, February, 1997, pp. 28-40. R. Whiteside, C. Pancerella, P. Klevgard, "A CORBA-Based Manufacturing Environment", Proceedings of The 1997 Hawaii International Conference on Systems Sciences (HICSS-97), Vol.1, pp. 34-43. S.B. Zdonik, D. Maier, "Fundamentals of Object-Oriented Databases", in: S.B. Zdonik, D. Maier (eds.): Readings in ObjectOriented Database Systems, Morgan Kaufmann Publishers, San Mateo, CA, 1990., pp. 1-32.

25

Suggest Documents