- Email: [email protected]
Database considerations in manufacturing systems integration
Robotics & Computer-Integrated Manufacturing, Vol 4, No 3/4, pp 571-583, 1988
0736-5845/8853 00 + 0 00 Pergamon Press plc
Pnnted in Great Bntam
• Paper
DATABASE CONSIDERATIONS IN MANUFACTURING INTEGRATION
SYSTEMS
S O U N D A R K U M A R A a n d INYONG H A M The Pennsylvama State University, Department of Industrial and Management Systems Engineering, 207 Hammond Building, University Park, PA 16802, U.S.A. This paper deals with ideas that could form a basis for manufacturing integration. In recent times more attention is being paid to the idea of applying artificial intelligence (AI) techniques to manufacturing. However, very little attention is being paid to the proper use of these techniques. This research work explores three basic ideas: 1. Applications of the entity-relationship approach to knowledge representation. 2. The basic philosophy of expert database systems and 3. Integration of manufacturing systems from the above two concepts. The approaches for 1 and 2 are explained with actual implementation experiences, while a framework for integration is proposed from a more philosophical perspective.
This paper tries to explore at a conceptual level the necessity for looking into RDBMS for the implementation of expert systems in the manufacturing domain. A scheme for automatic knowledge acquisition, the entity-relationship decision schema (ER-DS), is proposed and the suitability of expert database systems for manufacturing systems is explored. A framework for manufacturing integration is also proposed.
1. INTRODUCTION Flexible manufacturing systems, factory automation and intelligent manufacturing systems are the most talked about areas of research today. Artificial intelligence (AI) is being widely advocated for the integration of the factory. A number of expert systems (ES) have been developed for process planning, process control and CAD data retrieval. However, very little attention has been given to the development of a common database philosophy for factory automation. From a conventional or contemporary point of view, the underlying philosophies of manufacturing systems can be considered to be similar in nature. The major differences can be attributed to variations in the hierarchical treatment of these systems. The advent of the latest technologies has seen manufacturing systems adapt themselves to these advancements. In the immediate past we have seen the development of a number of applications of artificial intelligence to manufacturing systems. However, seldom have the questions " D o we really need AI to solve these problems?" and "Can we effectively marry the existing relational database management systems (RDBMS) to expert system ideas?", been addressed. It is paradoxical that these AI based systems were developed with very little attention to conceptual modelling. 11
2.
INTELLIGENT MANUFACTURING SYSTEMS (IMS) The underlying notion of flexibility is crucial to any IMS. In a dynamic environment, the adaptability of the manufacturing system is of paramount importance. When flexibility has to be considered, the system should be totally integrated. Figure 1 gives a possible integrated manufacturing framework. This framework can be viewed from a management level. A hierarchical framework may seem more suitable but from flexibility point of view, the interactions need to be viewed as being lateral. There is a continued, closed-loop interaction among the various sub-systems. Any perturbance in one sub-system will lead to changes in other sub-systems. One main point of interest in manufacturing systems is that of data types. Though the volume of data is large, the variation in data types is not very high. This leads 571
572
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
1- . . . . . . . . . I I i I I I ]
Knowledge
Machine database
/
Ii I Functlonabty I I I I I L-_
~,J
I
Heuristic knowLedge
,/
) I
AnOt~lCOt tOOk
ProcesspLans
GT coding
_1
I
½
I=
Deslc~n
CAD dot.abase
l
TOOLselection [ knowledge
Schedubng
1
'--,
1 2. 3. 4.
Small volumes Intentional (schema level) Imprecise Statements apphcable to large group of facts 5. Supphed by experts
Data Large volumes Extensional (database level) Verifiable (could be erroneous) Factual, atomic Maintained by clerks
DBMS. The possible advantages of using the database-centered approach are: 1. Selective and controlled data sharing, 2. Central control of data security and redundancy, 3. Semantic integrity and maintenance, and 4. Query optimization. In addition to central control distributed databases provide: 1. Location advantage, 2. Increased system reliability, 3. Increased system performance through the use of parallelism, and 4. The ability to add additional nodes.
Monufocturlng ceLLs d
Fig 1. Framework for integrated manufactunng systems.
to the question "if the number of data types is not large, can we use the DBMS in an effective manner?" The discussion so far throws light on the following three aspects: 1. Current-day manufacturing is dynamic, 2. Manufacturing is data-intensive and 3. Integration is predominantly an issue of combining decisions. From the AI perspective, knowledge-based systems (KBS) deal with data or knowledge and suggest tools that can be used. However, the manufacturing scientist's concern is the effective use of these tools. Expert systems are one of the most common tools of artificial intelligence used in manufacturing systems. In the following pages, we explore the possibilities of using conventional relational database management systems and the idea of ES for a better integration of manufacturing systems. 2.1. Knowledge vs. data Gio Widerhold 3 summarizes the distinction between data and knowledge. From this perspective one can draw the distinctions between DBMSs and KBSs. Many current information systems involve large, centralized databases under the supervision of a
3. DATABASE SYSTEMS A database system is basically a computerized record-keeping system. The overall purpose of a database system is two-fold: 1. To maintain data and 2. To supply data on demand. The first deals with data organization. The conceptual schema dictates the type of data model one needs to use. Database definitions range from simple hierarchical systems to complex network schemes. A popular one is the relational model. The second aspect deals with query retrieval strategies. A database management system encompasses both the ideas explored here. A DBMS is a (set of) software application tool(s) which provides for the maintenance of a database and gives users access to shared information. A major problem scenario is that in which multiple users are trying to access the same information. Should the DBMS allow for every user to access every piece of information or should it selectively allow users to do certain operations only on certain parts of the database system? This question leads to some considerations regarding data access control, updating provisions, concurrency control, data integrity and security. A DBMS has two major functions: 1. To allow the user to specify data and 2. To retrieve data. A problem associated with the development of any DBMS, whether to cater to the needs of small or large databases, remains the same. A DBMS should
Databases in manufacturingsystems• S. KUMARAand I. HAM allow for easier development of application programs which would facilitate data definition and data manipulation. The overall structure of a DBMS design, either for shared or dedicated information, remains the same. However, it might be easier to implement a DBMS in a dedicated small-volume environment. The essence of a DBMS lies in: 1. Declaring the data models (physical schema) and 2. Having an efficient search mechanism to retrieve information from the data models defined. In short, both expert systems and DBMS deal with data, but at different levels of abstraction. 4. EXPERT SYSTEMS: BASIC IDEAS Expert systems in the crudest sense capture the knowledge of experts in a domain. Expertise in a domain is directly related to the knowledge of the expert. By the same reasoning, the efficiency of an expert system depends on the available knowledge. Hence expert systems are also known as knowledge-based systems. General AI methods used to solve generalized problems, the so-called weak methods of AI, do not have sufficient expertise to solve problems effectively. Since each expert system is tailored to a specific domain, the degree of reasoning and related strategies in these systems is much greater than those of general AI problem-solving methods. An expert system can be defined as "a tool which has the capability to understand problem-specific knowledge and uses domain knowledge intelligently to suggest alternate paths of action". Misconceptions about expert systems arise from them simply being considered as collections of I F - T H E N constructs. Expert systems not only use techniques to transfer knowledge but also use analytical tools to evaluate it and techniques to learn. A program having a few I F - T H E N constructs and a set of analytical tools cannot be classified as an expert system. An expert system should be able to understand new knowledge, draw references and justify and explain its reasoning process. Specialists in manufacturing are beginning to take an interest in expert systems as a means of solving problems in their domain. Several prototype systems are being built in the areas of manufacturing, facilities layout, maintenance and fault diagnosis. In most of the manufacturing problems, the solutions are not deterministic and provide many alternative courses of action. The solution adopted depends on the advice of the expert system. The development of an expert system involves four major stages: 1. Problem definition,
573
2. Knowledge acquisition, representation and coordination, 3. Inference mechanism and 4. Implementation. The stage of knowledge acquisition, representation and coordination is one of paramount importance. Basic research in manufacturing is geared towards an automated and integrated factory of the future. This poses certain special problems. In an automated environment it becomes necessary to consider the following: • Proper coordination between on-line knowledge and expert systems, • Separation of declarative and procedural knowledge, • Independent updating and modification of knowledge and • The ability to learn. The main point of concern is the database aspects of these systems. Typically, knowledge in an expert systems is represented in terms of: 1. Simple production systems, 2. Structured production systems, 3. Frame systems, and 4. Logic systems. In a typical manufacturing environment, specialized expert systems will be dedicated to specific tasks. Each of these systems could use any of the above four knowledge-representation schemes. All of these systems must be able to draw inferences and modify their knowledge base. It is evident that one needs to have proper knowledge coordination and integration. The above discussion highlights some basic ideas about database systems, expert systems and the nature of intelligent manufacturing systems. It is established that there is a common link between expert systems and DBMSs. It is also true that integration is possible by means of effectively combining the DBMS philosophy with expert systems ideas. The subsequent discussion highlights two approaches developed for effectively combining the principles of RDBMs and ESs.
5.
ENTITY RELATIONSHIPS AND ITS APPLICATIONS IN INTEGRATION Knowledge representation can broadly be defined as "the development of data structures leading to effective inferential procedures, using the available data". Knowledge used in an expert system is of two types: 1. Declarative knowledge and 2. Procedural knowledge.
574
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
Usually, facts about objects, events and relations are classified in declarative knowledge. Procedures or rules which interact with the facts to derive inferences fall into procedural knowledge. However, declarative and procedural knowledge are not completely independent. Hence, if interactions between procedural and declarative knowledge are not properly considered, it might lead to insufficient or improper use of knowledge. Facts describe the state of the system, which serve to activate procedural rules. The firing of a rule or a set of rules changes the state of the system. Due to the firing of a rule, new facts are created or old facts are deleted from the knowledge base. We define the following to discuss these aspects: 1. Static knowledge: The declarative knowledge describing the state of the system, which does not undergo any change due to the application of the procedural rules. 2. Dynamic knowledge: Declarative knowledge which undergoes change or new declarative knowledge added to the knowledge base as a result of the application of rules. 3. State: The configuration of the domain as described by the declarative knowledge. 4. Operator: A rule from the procedural knowledge acting on the declarative database, resulting in a new state of the system. The above four need to be considered in the development of an expert system. The following questions need to be answered in detail before knowledge representation is undertaken: 1. What static declarative knowledge is required to describe the state of the system? 2. What procedural knowledge is required to describe a resulting state? 3. What dynamic knowledge is required to describe a resulting state? The answer to the first question leads to the identification of the static knowledge. The consequent application of rules, as identified in the second question, reveals the dynamic aspects of the database. In order to understand this behavior, a formal representation is necessary to structure the knowledge. Declarative knowledge can be viewed as a relational data model, which involves both intentional or conceptual representation and an extensional representation. The entity-relationship approach is useful in arriving at the intentional representation. Traditionally, in the relational data models the entity-relationship diagrams (E-R diagrams) are fixed and represent static databases. The dynamic behavior of the database is not specified via the E-R diagram. While developing an expert sys-
tem, conventional E-R diagrams can be used to develop the conceptual schema of the static declarative knowledge. We propose an E-R decision schema (E-R DS) for the conceptual schema development of dynamic databases. The proposed approach is illustrated through an example system.
5.1. Approach for formal representation We define the formal approach for knowledge representation as follows: 1. Identify the features of the expert system • purpose of the expert system • synthesis methodology. 2. Identify static knowledge. 3. Identify procedural rules. 4. Identify the interactions between procedural rules and static knowledge. 5. Develop an E-R decision scheme. The following discussion explains this methodology. 5.2. Identification of the features of the expert system To identify static and dynamic knowledge, it is necessary to understand the system. We explain our framework via the intelligent facilities layout analysis and planning (IFLAPS) expert system. The problem of industrial facilities layout design faced by the manufacturing engineer is very complex. Facilities layout can be defined as "the optimal arrangement of departments/machines in a plant such that it facilitates the production process and satisfies the constraints imposed by the analyst". Conventionally, the problem is solved as a single criterion optimization problem. Given the number of departments, the number of different products and volume of production, the available methodologies try to determine that configuration of departments which minimizes the total materials handling cost. Most of the approaches view the above situation as a quadratic assignment problem and try to generate the solution space through some acceptable search mechanism. If the analyst wants to change certain departments, the whole problem is handled again as a new one and the current solution is not of much help. In real life, this problem has multiple criteria. In addition to the materials flow criteria considered in the conventional approaches, certain additional factors also need equal consideration, such as: 1. Flexibility of the layout. 2. Special requirements for certain departments, 3. Safety considerations and 4. Aesthetic appeal.
Databases in manufacturing systems • S. KUMARAand I. HAM Some of these, like special requirements, may have to be satisfied without exception, while others, like aesthetic appeal, may be satisfied to a particular level. Moreover, when the analyst is dissatisfied with a particular generated configuration, he should be able to change certain constraints and the level of constraint satisfaction, if required. In this work the facilities layout problem is treated as a multi-objective problem and solved via an expert system. The multiple objectives considered are: 1. Minimizing material handling cost, 2. Maximizing safety level, 3. Maximizing flexibility of the layout, 4. Maximizing personnel appeal and 5. Maximizing the level of satisfaction of special requirements. An expert system is developed for generating alternate layout configurations for the layout problem. The knowledge about the problem is acquired through an interactive dialog with the user. Typical types of knowledge may be: 1. N u m b e r of departments, 2. Number of locations available and available resources, 3. Special requirements for departments and 4. Production volumes. The special requirements are classified into hard and soft constraints. The user has the flexibility to ascertain the required levels of fulfillment of these constraints or he can leave it to the expert system to decide the levels for him. The heuristic methodology to generate the efficient set (set of satisfying solutions) works on the principle of constraint-directed search. For each of the constaints, their fulfillment is treated as a sub-goal matching. The heuristic starts by assigning the department, with the hard constraint having the highest priority to the relevant location and successively tries to satisfy the other department requirements. Once a department is assigned, its neighboring location (the location to the left, top, right or bottom) becomes a candidate for assignment and the next highest priority department is chosen for assignment to the candidate location. If the location does not satisfy the constraints required by the department, then its neighbor is considered as a candidate. The heuristic assignment continues until all the sub-goals are matched. For the resulting generated configuration, the satisfaction level and the cost are determined. After each assignment, the expert system enters into a dialog with the user to check for any additional constraint incorporation or deletion of old constraints.
575
The overall configuration of the system as described above leads to further detailed analysis, to identify the static and dynamic aspects of knowledge. 5.3. Identification o f static knowledge The declarative knowledge is modeled as a relational database. Some of the entity sets identified are: 1. Department 2. H e a t producing department 3. Water requiring department 4. Compressed air requiring department 5. Manpower working department 6. Flammables in department, etc. The entity-relationship diagram shown in Fig. 2 is used to represent the conceptual scheme. Department is a relation with the attributes department number, department name and area required. Heat producing is another relation with the attributes department n u m b e r and heat intensity. This can be represented uniquely with the relationship heat. The resulting formal representation for the static knowledge is given in Table 1. For example, noise producing is a relation having the attributes department number and noise level with Dept. as a primary key. For the locations available on the ground plan, a similar E-R diagram can be drawn. Table 2 describes Table 1. Relational database scheme for departments Heat producing (Dept #, Heat Intensity) Water requiring (Dept #, Qty of water) Compressed air requiring (Dept. #, volume) Door requiring (Dept #, # of doors) Personnel (Dept #, # of people) Noise producing (Dept. #, Noise level) Flammables in (Dept. #, Flammable material) Heavy machinery (Dept. #, weight) Power generating (Dept. #, power level) Hazardous (Dept. #, hazard level) Special requirements (Dept #, sp requirement) Department (Dept #, Dept. name, are reqmred) Italic attributes are the primary keys. Table 2 Relational database scheme for locations Location (Location #, Area, Load bearing cap, celhng height) Neighbor (Location #, Neighbor location #, left, right, top, bottom) Has adjacent (Locauon #, Neighbor location #) Door avadable (Locanon #) Water available (Location ~) Available 1 (Location #, number of doors) Available 2 (Location #, qty of water) Available 3 (Location #, volume of air) Italic attributes are the prrrnary keys.
576
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
IH,ot° ,°°l
,rr°°,ro01
,,,,0orlro°,oo0 Co ,
+
IDepartment. I
Fig. 2. Entity-relationship diagram (conceptual schema).
the corresponding relational database scheme. For example, location is a relation having the attributes location number, area, load bearing capacity and ceiling height with location number as the primary key. Available 1, Available 2 and Available 3 are the relations describing the number of available doors. Quantity of water and volume of compressed air available in locations 1, 2 and 3, respectively. It can be seen from the above discussion that the identification of static knowledge leads to an E-R representation. The E-R diagram can be immediately translated to a relational database scheme, which can be converted to logic clauses for implementation.
3. The priority is highest and 4. There is a location available and 5. The location has a door THEN: Assign the department in question to the location considered. The above procedural rule can be translated to a P R O L O G implementable form. A procedure consists of one or more assertions or clauses of the form P0:- P1, P2, . . . , Pn which can be read declaratively as: " P 0 is T R U E if P1 and P2 a n d . . , and Pn are true." or
5.4. Identification of procedural rules The procedural rules can be classified as: 1. Rules for knowledge acquisition, 2. Rules for inference, 3. Rules for control, 4. Rules for reasoning and 5. Rules for data-ordering. In this section we deal with rules of inference. These rules are used to synthesize a layout configuration. The heuristic algorithm explained in section 5.2 can be represented as a set of rules. Consider the example: " D e p a r t m e n t raw material needs a door and a door is available at location number 1, and the priority for door allocation to the raw material department is 1.00 (highest)". In general a rule of the above forms can be written as follows: IF: 1. There is a department and 2. The department needs a door and
" T o satisfy goal P0, first satisfy goal P1 then goal P2 t h e n . . , goal Pn." An examination of the above structure reveals that the antecedents are represented as: :-P1, P2 . . . . . Pn (on the RHS) and the consequence as P0 (on the LHS). To satisfy each of the goals, it might be required to satisfy other goals. For example, the location should not have been assigned to any other department. For satisfying this rule we may have to invoke another rule. This is knowledge about the knowledge of the assignment of the department. Such a rule about a rule, or knowledge about knowledge, is known as a meta-rule, which in this case is: IF: Any of the departments is not assigned to the location in question
Databases in manufacturing systems • S KUMARAand I HAM
THEN: The location in question is available for assignment. A rule that invokes a meta-rule is called a Level-1 rule. A meta-rule can invoke a meta-meta rule. In PROLOG, the rule described earlier can be represented as follows: door_needed_check:door_required (x), door_available (y), not (assignment (x,_)), not (assignment (_, y)), priority_index (x, door_requirement, 1.00), assign1 (x,y). The inference mechanism works by linking the rules effectively. All the procedures are represented in the above fashion and similar procedures or rules are linked with each other, thus defining the procedural knowledge base.
5.5. Identification of interactions between static
knowledge and procedural rules To understand the behavior of the database it is essential to study the interactions between procedural rules and the declarative knowledge base. Consider the example rule given in section 5.4: "Assign the department in question to the location considered." Assume that the department in question is the raw-materials department and the Instances of relational scheme: department (001, raw material, 1000). door_required (001). priority index (001, door_requirement, 1.00). door_available (10). The following meta-rule states that, when a department is assigned to a location, then we need to remove the instance of the relation (available location) for the location # 1 0 considered. Any of the departments is not assigned to the area in question THEN: The location in question is available for assignment. In addition, we need to create a new relation assignment_made and instantiate the attributes to the department and to the relevant location: for example, assignment (001,10). Therefore, dynamically we need to remove certain instances of a set of relations from the database and add new relations and instances to the database. These interactions are typically complex. The analyst needs to identify all the five types of rules
577
described earlier and the resulting interactions with the static knowledge. This will lead to the identification of the dynamic entities. 5.6. Development of E-R decision scheme There are no formal representation methods available for capturing the dynamic behavior of declarative knowledge. By the creation of new relations and updating their instances, the state description changes. For the representative rule considered in section 5.4, the subgoals of the rule can be identified as: door_required (x): sub-goal 1 dooravailable (x): sub-goal 2 not (assignment (x,_)): sub-goal 3 not (assignment (__,y)): sub-goal 4 priority_index (x, door requirement, 1.00): sub-goal 5 not (priority_index(_, door requirement, 1.00)): sub-goal 6 Figure 3 represents the E-R decision scheme for this rule. The knowledge is represented by the relations: Department (Dept # , name, area). Resource requiring (Dept # , resource, qty). priority_index (Dept # , requirement, priority). Available (Location # , resource, qty). Location (Location # , load capacity, area). Door_available (Location # ) . Free (Location #). Assignment (Dept # , Location #). Doorrequiring (Dept #). priority (Dept # , resource, index). Some of these, like department, location and priority, are static. The other relations are either created or deleted by the application of a rule. To look into the dynamic behavior of knowledge, it is essential to apply the rule to the E-R diagram and study the consequences. Sub-goal 1 tries to match an instance of the relation doorrequiring; let this be Operation I (O1). Similarly sub-goal 2 tries to match an instance of door-available location (02). Table 3 gives the above matching operations. In the forward process, as each sub-goal is matched a "yes" indicates goal fulfillment and the next sub-goal is considered. When any of the goals fail, the search is stopped and an alternative rule is fired. A point of interest in the table is what happens when backward chaining is undertaken. In the forward chaining of all subgoals, the success of the first six goals allows sub-goal 7 to succeed. This involves a state change. A new relation Assignment is created for the first
Robotics and C o m p u t e r - I n t e g r a t e d Manufacturing • V ol ume 4, N u m b e r 3/4, 1988
578
I
I ResourcerequiringI
I IDeportment]
J Avall.abteJ __J
I
Fig 3
Ent]ty-relatlonshlp decision schema
time and an instance when sub-goal 7 succeeds will be: Assignment (Dept x, Location y). The instance of Free(y) is deleted from relation Free. Once sub-goal 7 succeeds, the LHS of the goal succeeds, this leads to backtracking to sub-goal 6, where the database has not been dynamically updated. From priority-index relation, due to 05, the tuple for departmentx is deleted. 0 3 and 0 4 result in
the insertion of corresponding instances in the relation Assignment. 0 2 and O1 result in the deletion of corresponding instances from the relations doorrequiring and door_available. It can be seen from this E-R decision scheme for a simple rule application, the quantum of dynamic changes instantiated. A thorough look into the E-R DS can lead to a better design of the knowledge base, by avoiding redundancy. On the other hand, if the analyst has a conceptual scheme and rules
Table 3. E-R d e o s l o n scheme table for matching ope ra t i ons Subgoal used
Operatmn
1 2 3
O1 02 03
4
04
5
O5
6
06
7
07
8
08
Description Is door r e q m r e d for a d e p a r t m e n t ? Is there a location with a door? Is the d e p a r t m e n t avadable for assignment? Is the location avadable for assignment 9 Is the priority of this d e p a r t m e n t highest? ls the priority of all other d e p a r t m e n t s lower? Make an ass]gnment of the d e p a r t m e n t m questmn to location considered Free location moved
* In&cates dynamic update, - in&cates no change
State-change forward ba c kw a rd
Status
Relation update
Yes Yes Yes
-
* * *
door_reqmrmg door_avadable resource_requmng
Yes
-
*
resource_requmng
Yes
-
*
available
Yes
-
-
--
.
assignment
.
.
.
Databases in manufactunngsystems• S. KUMARAand I. HAM
579
described verbally, he can undertake the same process and define his rules more rigidly, which is advantageous from an implementation viewpoint.
tuple y • project # = tuple x • project # ; store tuple y • part # print tuple y • part # (numbers and tuple x • contractor
6. EXPERT SYSTEMS AND DBMS A DBMS deals with data and an ES uses knowledge. Knowledge, typically, is intentional, in small volumes and supplied by experts. Data, on the other hand, are large volume, extentional and matter-offact. A DBMS uses query retrieval and an ES inference mechanism to retrieve information or to perform logical deductions. This concept is explained through a small database in the following example. Tables 4A and 4B define a conceptual relational schema for a small parts-project database.
end. The response to the query will be:
Table 4A. Part relation (PA-R) Part # P1 P2 P3 P4
Part name
Project
Nut Bolt Screw W~dget
J1 J2 J3 J1
Interpretation: P1 is a nut and is used by project J1 Table 4B. ProJectrelation (PA-R) ProJect # J1 J2 J3
J4
City
Contractor
London New York Bombay Pans
Smith Wemman Mltuh P~erre
Interpretation: Project J1 is m London and the contractor ~s Smith. The DBMS should provide means for converting this conceptual relational schema into a physical schema. It should also have application programs to retrieve the required information. The similarities between query retrieval and ES deductive inference can be brought out by considering a typical example query: Query: Give the name of the contractor who lives in Bombay and the parts used by the project in that city. An algorithmic procedure for the implementation of the search for the query retrieval is as follows: begin From relation, R1 select the attribute city and choose tuple x where tuple x. city = Bombay; store tuple x • project # , tuple x • contractor; select relation R2 and select that tuple(s), y, where
MITULI P3 This retrieval scheme, however general, can be implemented in specific, to this application. An implementation in SQL is of the form SELECT FROM WHERE
CONTRACTOR, P # PR-R, PA-R J # IN (SELECT J # FROM PR-R WHERE CITY -- 'BOMBAY' IN (SELECT P # FROM PA-R)) The expert systems approach as discussed typically consists of a declarative and procedural knowledge base. The declarative knowledge consists of the relations and the procedural knowledge consists of the rules to retrieve the required information. A logic implementation scheme will be of the form: (in binary-two place predicate structure): Parts-Projects (P1, J1). Parts-Projects (Pz, J2). Parts-Projects (P3, J3). Parts-Projects (Pa, J4). part-names (P1, nut). part-names (P2, bolt). part-names (P3, screw). part-names (P4, widget). project-city (jl, London). project-city (j2, New York). project-city 03, Bombay). project-city (j4, Paris). city-contractor (London, Smith). city-contractor (New York, Weinman). city-contractor (Bombay, Mituli). city-contractor (Paris, Pierre). Typically the query retrieval language can be implemented through a set of rules. In logic form the rule to retrieve the answer is of the form: select-names-parts (Y,K,X):city-contractor (X, Y), project-city (Z,X), part-projects (K,Z). When the city variable X is instantiated to Bombay, the search for an answer will be triggered.
580
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
It can be seen from the above example system that in the event of highly structured information, query retrieval and application of a rule base share similar characteristics. The two approaches broadly illustrated here pertain to query evaluation in a DBMS and deductive inference in an expert system. To answer a question, the query evaluation process basically builds an evaluation tree, without backtracking. The deductive inference mechanism finds a proof to a theorem; in this case, a proof for the conjecture:
(JY, JK I select-name-parts (Y, K) ---> city-contractor (X, Y)A project-city (Z, X)A part-projects (K, Z))? (X: mstantiated to Bombay). Whenever an explanation needs to be given, the inference mechanism backtracks to give an appropriate reasoning explanation. Essentially the basic ideas are of search in both systems. A look into the two systems, a DBMS and an expert system, leads to certain interesting observations. It is definitely difficult to add new data to a DBMS. This necessitates the revision of data structures. In an ES it is relatively easy. The application program for query evaluation is easier to develop and the tree takes care of integrity. The integrity constraints have to be built into the inference mechanism and this leads to a check on the consistency of all the rules m the knowledge base. On the other hand, in the event of missing and partial information, the deductive inference mechanism may be more useful. We are now faced with two basic issues: 1. If the database is structured, then the constraint knowledge can explicitly be embedded in the DBMS application software. 2. It is not very easy to modify search in deductive inferencing to accommodate integrity constraints. This poses an interesting question. Can we design our expert system in such a manner that it can use the structure of a DBMS and the flexibility of expert systems? This leads to the consideration of expert database systems.
2. Structured data can be used in the DBMS architecture and 3, The DBMS can act as an intermediary between on-line data and the knowledge that needs to be used by the expert system. Figure 4 shows a framework for expert database systems design in Industrial Engineering. For example, consider the following systems: 1. Process planning system, 2. Job-shop scheduling system, and 3. Quality control system. In a process planning system, considerations regarding features and alternative process plans play an important role. The characteristic data about features are extracted from the C A D database. Most of the expert systems in the process planning realm try to consider these data and build an inference mechanism to identify the features. In reality, it may not be beneficial to use the inferential process for this purpose. A DBMS system can be defined in which application programs are used to implement the query evaluation tree to extract the required information for answers. A preprocessor can be used to convert these data to the appropriate physical knowledge-representation scheme for the expert system. The second system, a job-shop scheduling system, uses information about capacities, demands and products. The system uses dispatching rules to find a schedule which optimizes on a given criterion. The major issues in this case are those of changing KnowLedge= bosed procetmI,J'~
Comm~a(shored) clatabase
I (chstr, buted)
6.1. Expert database systems The basic philosophy behind expert database systems is that of combining the structure of DBMS and the deductive inferential reasoning of expert systems. Such an approach would be of immense use for the following reasons: 1. Inferential processes need not be used on high volume data,
Data coltechor
F~g. 4. Expert database systems architecture for industrial engineering apphcatlons.
Databases in manufacturing systems • S. KUMARAand I HAM
demand patterns and stochastic processing times. Due to the slow nature of symbolic languages, the expert system will be slow if it uses modules to generate the processing times (which is true at least with large systems). This burden of demand analysis and stochastic time considerations can be left to the DBMS and the information generated can be used by the expert system. On the other hand, illstructured information can be handled by the expert system. The third system we are considering is that of quality control. In a quality control system real-time information is of immense value. A vision or an image processing system needs to be used to track the defects in a part under production. The image data need to be converted into symbolic information and used by the expert system. If the expert system has to perform image or vision analysis, it would amount to using the ES inefficiently. The ES which has to do inferencing on quality control should be stripped from the overhead of statistical analysis of the image or vision data. Moreover, in this case, the ES deals with a large volume of dynamic data, whose maintenance should be left to the DBMS. In general the design of any expert system needs the following consideration. 1. Whether the ES should be stripped from the rigor of processing large volumes of data and retrieving information from them. 2. Whether the burden of maintaining a shared knowledge base be left to the DBMS or the expert system. The answer to the first question is that if the knowledge is structured and requires data processing, the DBMS should handle it. For the second question, it is felt that the ES should not be taxed with maintaining the shared (common) knowledge base. The DBMS should maintain it. Figure 4 proposes a scheme for an expert database system architecture. At the lowest level, the on-line sensor information, image data, vision data and CAD data are collected. These have to be analyzed and converted to a database. The DBMS should maintain the application programs and the evaluation trees for routine query retrieval. It will be useful to have a relational distributed database. The various expert systems should interact with the DBMS through a knowledge representation (KR) converter. The purpose of the KR converter is to convert the data from the DBMS into a usable scheme for the expert systems. This requires the need to analyze the applications and designing the expert systems from a common knowledge-representation point of view.
581
MANUFACTURING INTEGRATION: A FRAMEWORK In the previous sections, we dealt extensively with the concepts of RDBMSs and expert systems. The following represent three claims, which are the outcomes of this research: Claim 1: Manufacturing systems are data intensive. The volume of data handled is large. However, the data types are few. Claim 2: It is possible to clearly distinguish between the operators (rules) and relations in a manufacturing system. The ER-DS approach lends itself to automation. Claim 3: The routine tasks in a manufacturing system can be handled via a query retrieval scheme which will be an integral part of a RDBMS. Such a system needs to be distributed. A meta-level expert system can be used to integrate the expert system modules and the RDBMS scheme. Keeping these three claims in view, a framework for manufacturing integration is proposed. Figure 5 represents the proposed framework. The major aspects of the framework are: 1. Development of a design theory, 2. Group technology coding and classification, 3. Process planning and 4. CAD/intelligent designer. Figure 5 clearly shows the hierarchical and lateral interactions. In the ensuing discussions we explore 7.
function amotlc I (oxl Des=gn approach) ~
General part functlonaL
l
descrBptlon
/
extractor I
Intelligent transLator
]
/
GTcode developer (expert system)
CAD/roteLtlgent designer
I
Totallyautomated process planner (TAPP)
l
Manufactur=ng system control
I ~Data
Data ~o~=ng I
Fig 5. Database and AI-related framework for manufactunng integration
582
Robotics and Computer-IntegratedManufacturing• Volume4, Number 3/4, 1988
the possible ideas of integration from the view of the three claims. 7.1. Development of a design theory Given a part description, the system would use an axiomatic approach based on mathematical logic and pattern recognition. The idea here is one of defining partial design as predicates. These predicates will be matched intelligently with the dictionary of specifications and the appropriate partial designs will be retrieved and by suitably combining the sub-designs the part design can be defined. Considerable work from a database point of view in design theory development has been done by Yoshikawa. TM 7.2. GT coding Given a part design, it is theoretically possible to define a GT code. The system will automatically develop the GT code. the system will identify the design features, then look into the classification possibility and define an appropriate part family code. The distinct feature of this system would be one of an interaction between the GT scheme and a CAD database. The system will use the GT code in conjunction with the design theory to develop the CAD database. Such an approach can be very effective in making the system learn about new parts and in automatically generating the GT code and subsequently a CAD database. The envisaged process is essentially one of using the design database effectively. At this stage the ideas of expert database systems are of immense use. 7.3. Intelligent process planning Though GT has acquired wide popularity, very little effort has been made to use this information in designing process plans. Our aims is to extract the information from GT codes and use them to define the process plan. The function of process planning is experience-based. Hence, there is a need for a system which deals with symbolic manipulation and uses the expert knowledge. There is a need for designing an expert system. The ideas discussed under ER-DS and EDS can effectively be used to design the process planning system. The proposed framework is a set of complex interactions between the various databases and expert systems. The design theoretic approach will form the basis for the system. It is intended to perform the design function based on an axiomatic approach. This naturally lends itself to defining the relational schema. Given a general part description, an ES module will translate the description to axioms that can be used by the design function cells. The
design function will rely heavily on a search-based pattern recognition system. The recognition system in this case needs to be implemented based on attribute grammars. The design information can now be defined as types of relations. The GT code developer interacts with these instances to define the GT codes. The GT code and CAD database in conjunction will be used to trigger the process planning system. The framework for integration can be viewed as being comprised of the following: 1. Conceptual modelling, 2. Identification of DBMS schema, 3. Identification of ESs modules, 4. A query retrieval language for the manufacturing framework (SQL based), 5. Development of ER-DS for • Design • Feature extraction • Part translation • GT code building • Process planning • Controlling, and 6. Linking of the above five through a meta-level expert system, based on the EDS philosophy. 8. CONCLUSIONS The research work reported in this paper deals with three distinct ideas: 1. Relational database management systems and the use of defining the operators in the E-R DS approach, 2. Expert database systems, and 3. Manufacturing integration. The main point which came to light is that one needs to clearly identify the static and dynamic knowledge so that the operators (rules) can be used to identify the relationships and the contributing relations. Such an approach leads to automating the rule-writing process. It also clearly helps in identifying the rules and the relations of the RDBMS. The expert database systems philosophy shows clearly that certain tasks can be accomplished through a query-retrieval system. This leads to identifying important rules that only need to be incorporated into the expert systems modules. The routine retrieval can be left to the RDBMS, which implies that the ESs modules and the RDBMS should be interfaced via a meta-level ES. In order to design a consistent and minimal RDBMS, the E-R DS approach would be of immense help. The ideas of both the ER-DS and EDS can be incorporated into the general framework given in Fig. 5. While designing the modules it would be appropriate to use the ideas explored in the ER-DS
Databases m manufacturing systems • S. KUMARAand I HAM and EDS approaches. The advantage of such a system, which would use these two philosophies, lies in its ability to be uniform and flexible. Integrity constraints can easily be maintained in such a system. The ER-DS approach has been implemented using Prolog. The expert database systems idea is implemented for integrating: 1. A vision system and 2. R o b o t path planning system. The relational schema for this is implemented in Pascal and the two expert systems in Prolog.
9. 10. 11. 12.
13. REFERENCES 1. Barkocy, B.E., Zdebhck, W.J.: A knowledge based system of machining-operation planning, in Proceedings of AUTOFACT 6, pp. 2.11-2.25, 1985. 2. Barr, A., Davidson, J.: Representation of knowledge. In Handbook of AI, Barr, A., Fiegenbaum, E. (Eds). Computer Soence Department, Report No. STANCS-80-793, Stanford University, 1980. 3. Brodie, M.L., Mylopoulos, J., Schmidt, J.W. (Eds): On Conceptual Modelling. New York, Springer, 1984. 4. Brachman, R., Levesque, H.: The knowledge level of KBMS. In On Knowledge Base Management Systems, Brodle, M.L., Mylopoulos, J. (Eds). New York, Spnnger, 1986. 5. Clocksin, W.F., Mellish, C.S.: Programming tn Prolog. Berlin, Springer, 1981. 6. Date, C.J.: An Introduction to Database Systems. New York, Addison Wesley, 1983. 7. Fox, M.S.: The intelligent management system: an overview. Technical Report C M U - R I - T R - 8 1 - 4 , Intelligent Systems Laboratory, The Robotics Institute, Carnegie-Mellon University, 1981. 8. Fox, M.S., McDermott, J.: The role of databases in
14.
15. 16.
17. 18.
583
knowledge-base management systems. On Knowledge Base Management Systems, Brodie, M.L., Mylopoulos, J. (Eds). New York, Springer, 1986. Ham, I, Hitomi, K, Yoshida, T.: Group Technology. Boston, Kluwer-Nijhoff, 1985. Hatvany, J.: Available and missmg AI tools. Ann. CIRP 35: 1986. Hatvany, J.: Distinguished lecture series. Lectures given at Penn State University, University Park, PA 16802, USA, March-April 1987. Kerschberg, (Ed.) Expert database systems. Proceedings of the Ftrst Internattonal Workshop on Expert Database Systems, Klwah Island, S.C., 1984. Menlo Park, Benjamin Cummings, 1986. Kimura, F., Suzuki, H.: Variational product design by constraint propagation and satisfaction in product modelling. Ann. CIRP, 35: 1986. Kumara, S., Kashyap, R.L.: Entity-Relationships and their applications to expert system development. Proceedings of the International Conference on Systems Man and Cybernatics, IEEE, Arizona, Nov. 1985. Smith, J.M.: Expert database systems, a database perspective. In Expert Database Systems, Kerschberg, L. (Ed.). Menlo Park, Benjamin Cummings, 1986. Tirupatikumara, S.R., Kashyap, R.L., Moodie, C.L.: Artificial intelligence techniques in facilities layout planning--the development of an expert system. Technical Report, TR-ERC 86-1, Engineering Research Center for Intelligent Manufacturing Systems, Schools of Engineering, Purdue University West Lafayette, IN 47907, Dec. 1985. Wilderhold, G.: Knowledge versus data. In On Knowledge Base Management Systems, Brodie, M., Mylopoulos, J. (Eds). New York, Springer, 1986. Yoshikawa, H.: General design theory and a CAD system. In Man-Machine Commumcatlons in CAD/ CAM, Sata, T., Warman, E (Eds). North Holland Publishing Company, IFIP, 1981.
0736-5845/8853 00 + 0 00 Pergamon Press plc
Pnnted in Great Bntam
• Paper
DATABASE CONSIDERATIONS IN MANUFACTURING INTEGRATION
SYSTEMS
S O U N D A R K U M A R A a n d INYONG H A M The Pennsylvama State University, Department of Industrial and Management Systems Engineering, 207 Hammond Building, University Park, PA 16802, U.S.A. This paper deals with ideas that could form a basis for manufacturing integration. In recent times more attention is being paid to the idea of applying artificial intelligence (AI) techniques to manufacturing. However, very little attention is being paid to the proper use of these techniques. This research work explores three basic ideas: 1. Applications of the entity-relationship approach to knowledge representation. 2. The basic philosophy of expert database systems and 3. Integration of manufacturing systems from the above two concepts. The approaches for 1 and 2 are explained with actual implementation experiences, while a framework for integration is proposed from a more philosophical perspective.
This paper tries to explore at a conceptual level the necessity for looking into RDBMS for the implementation of expert systems in the manufacturing domain. A scheme for automatic knowledge acquisition, the entity-relationship decision schema (ER-DS), is proposed and the suitability of expert database systems for manufacturing systems is explored. A framework for manufacturing integration is also proposed.
1. INTRODUCTION Flexible manufacturing systems, factory automation and intelligent manufacturing systems are the most talked about areas of research today. Artificial intelligence (AI) is being widely advocated for the integration of the factory. A number of expert systems (ES) have been developed for process planning, process control and CAD data retrieval. However, very little attention has been given to the development of a common database philosophy for factory automation. From a conventional or contemporary point of view, the underlying philosophies of manufacturing systems can be considered to be similar in nature. The major differences can be attributed to variations in the hierarchical treatment of these systems. The advent of the latest technologies has seen manufacturing systems adapt themselves to these advancements. In the immediate past we have seen the development of a number of applications of artificial intelligence to manufacturing systems. However, seldom have the questions " D o we really need AI to solve these problems?" and "Can we effectively marry the existing relational database management systems (RDBMS) to expert system ideas?", been addressed. It is paradoxical that these AI based systems were developed with very little attention to conceptual modelling. 11
2.
INTELLIGENT MANUFACTURING SYSTEMS (IMS) The underlying notion of flexibility is crucial to any IMS. In a dynamic environment, the adaptability of the manufacturing system is of paramount importance. When flexibility has to be considered, the system should be totally integrated. Figure 1 gives a possible integrated manufacturing framework. This framework can be viewed from a management level. A hierarchical framework may seem more suitable but from flexibility point of view, the interactions need to be viewed as being lateral. There is a continued, closed-loop interaction among the various sub-systems. Any perturbance in one sub-system will lead to changes in other sub-systems. One main point of interest in manufacturing systems is that of data types. Though the volume of data is large, the variation in data types is not very high. This leads 571
572
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
1- . . . . . . . . . I I i I I I ]
Knowledge
Machine database
/
Ii I Functlonabty I I I I I L-_
~,J
I
Heuristic knowLedge
,/
) I
AnOt~lCOt tOOk
ProcesspLans
GT coding
_1
I
½
I=
Deslc~n
CAD dot.abase
l
TOOLselection [ knowledge
Schedubng
1
'--,
1 2. 3. 4.
Small volumes Intentional (schema level) Imprecise Statements apphcable to large group of facts 5. Supphed by experts
Data Large volumes Extensional (database level) Verifiable (could be erroneous) Factual, atomic Maintained by clerks
DBMS. The possible advantages of using the database-centered approach are: 1. Selective and controlled data sharing, 2. Central control of data security and redundancy, 3. Semantic integrity and maintenance, and 4. Query optimization. In addition to central control distributed databases provide: 1. Location advantage, 2. Increased system reliability, 3. Increased system performance through the use of parallelism, and 4. The ability to add additional nodes.
Monufocturlng ceLLs d
Fig 1. Framework for integrated manufactunng systems.
to the question "if the number of data types is not large, can we use the DBMS in an effective manner?" The discussion so far throws light on the following three aspects: 1. Current-day manufacturing is dynamic, 2. Manufacturing is data-intensive and 3. Integration is predominantly an issue of combining decisions. From the AI perspective, knowledge-based systems (KBS) deal with data or knowledge and suggest tools that can be used. However, the manufacturing scientist's concern is the effective use of these tools. Expert systems are one of the most common tools of artificial intelligence used in manufacturing systems. In the following pages, we explore the possibilities of using conventional relational database management systems and the idea of ES for a better integration of manufacturing systems. 2.1. Knowledge vs. data Gio Widerhold 3 summarizes the distinction between data and knowledge. From this perspective one can draw the distinctions between DBMSs and KBSs. Many current information systems involve large, centralized databases under the supervision of a
3. DATABASE SYSTEMS A database system is basically a computerized record-keeping system. The overall purpose of a database system is two-fold: 1. To maintain data and 2. To supply data on demand. The first deals with data organization. The conceptual schema dictates the type of data model one needs to use. Database definitions range from simple hierarchical systems to complex network schemes. A popular one is the relational model. The second aspect deals with query retrieval strategies. A database management system encompasses both the ideas explored here. A DBMS is a (set of) software application tool(s) which provides for the maintenance of a database and gives users access to shared information. A major problem scenario is that in which multiple users are trying to access the same information. Should the DBMS allow for every user to access every piece of information or should it selectively allow users to do certain operations only on certain parts of the database system? This question leads to some considerations regarding data access control, updating provisions, concurrency control, data integrity and security. A DBMS has two major functions: 1. To allow the user to specify data and 2. To retrieve data. A problem associated with the development of any DBMS, whether to cater to the needs of small or large databases, remains the same. A DBMS should
Databases in manufacturingsystems• S. KUMARAand I. HAM allow for easier development of application programs which would facilitate data definition and data manipulation. The overall structure of a DBMS design, either for shared or dedicated information, remains the same. However, it might be easier to implement a DBMS in a dedicated small-volume environment. The essence of a DBMS lies in: 1. Declaring the data models (physical schema) and 2. Having an efficient search mechanism to retrieve information from the data models defined. In short, both expert systems and DBMS deal with data, but at different levels of abstraction. 4. EXPERT SYSTEMS: BASIC IDEAS Expert systems in the crudest sense capture the knowledge of experts in a domain. Expertise in a domain is directly related to the knowledge of the expert. By the same reasoning, the efficiency of an expert system depends on the available knowledge. Hence expert systems are also known as knowledge-based systems. General AI methods used to solve generalized problems, the so-called weak methods of AI, do not have sufficient expertise to solve problems effectively. Since each expert system is tailored to a specific domain, the degree of reasoning and related strategies in these systems is much greater than those of general AI problem-solving methods. An expert system can be defined as "a tool which has the capability to understand problem-specific knowledge and uses domain knowledge intelligently to suggest alternate paths of action". Misconceptions about expert systems arise from them simply being considered as collections of I F - T H E N constructs. Expert systems not only use techniques to transfer knowledge but also use analytical tools to evaluate it and techniques to learn. A program having a few I F - T H E N constructs and a set of analytical tools cannot be classified as an expert system. An expert system should be able to understand new knowledge, draw references and justify and explain its reasoning process. Specialists in manufacturing are beginning to take an interest in expert systems as a means of solving problems in their domain. Several prototype systems are being built in the areas of manufacturing, facilities layout, maintenance and fault diagnosis. In most of the manufacturing problems, the solutions are not deterministic and provide many alternative courses of action. The solution adopted depends on the advice of the expert system. The development of an expert system involves four major stages: 1. Problem definition,
573
2. Knowledge acquisition, representation and coordination, 3. Inference mechanism and 4. Implementation. The stage of knowledge acquisition, representation and coordination is one of paramount importance. Basic research in manufacturing is geared towards an automated and integrated factory of the future. This poses certain special problems. In an automated environment it becomes necessary to consider the following: • Proper coordination between on-line knowledge and expert systems, • Separation of declarative and procedural knowledge, • Independent updating and modification of knowledge and • The ability to learn. The main point of concern is the database aspects of these systems. Typically, knowledge in an expert systems is represented in terms of: 1. Simple production systems, 2. Structured production systems, 3. Frame systems, and 4. Logic systems. In a typical manufacturing environment, specialized expert systems will be dedicated to specific tasks. Each of these systems could use any of the above four knowledge-representation schemes. All of these systems must be able to draw inferences and modify their knowledge base. It is evident that one needs to have proper knowledge coordination and integration. The above discussion highlights some basic ideas about database systems, expert systems and the nature of intelligent manufacturing systems. It is established that there is a common link between expert systems and DBMSs. It is also true that integration is possible by means of effectively combining the DBMS philosophy with expert systems ideas. The subsequent discussion highlights two approaches developed for effectively combining the principles of RDBMs and ESs.
5.
ENTITY RELATIONSHIPS AND ITS APPLICATIONS IN INTEGRATION Knowledge representation can broadly be defined as "the development of data structures leading to effective inferential procedures, using the available data". Knowledge used in an expert system is of two types: 1. Declarative knowledge and 2. Procedural knowledge.
574
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
Usually, facts about objects, events and relations are classified in declarative knowledge. Procedures or rules which interact with the facts to derive inferences fall into procedural knowledge. However, declarative and procedural knowledge are not completely independent. Hence, if interactions between procedural and declarative knowledge are not properly considered, it might lead to insufficient or improper use of knowledge. Facts describe the state of the system, which serve to activate procedural rules. The firing of a rule or a set of rules changes the state of the system. Due to the firing of a rule, new facts are created or old facts are deleted from the knowledge base. We define the following to discuss these aspects: 1. Static knowledge: The declarative knowledge describing the state of the system, which does not undergo any change due to the application of the procedural rules. 2. Dynamic knowledge: Declarative knowledge which undergoes change or new declarative knowledge added to the knowledge base as a result of the application of rules. 3. State: The configuration of the domain as described by the declarative knowledge. 4. Operator: A rule from the procedural knowledge acting on the declarative database, resulting in a new state of the system. The above four need to be considered in the development of an expert system. The following questions need to be answered in detail before knowledge representation is undertaken: 1. What static declarative knowledge is required to describe the state of the system? 2. What procedural knowledge is required to describe a resulting state? 3. What dynamic knowledge is required to describe a resulting state? The answer to the first question leads to the identification of the static knowledge. The consequent application of rules, as identified in the second question, reveals the dynamic aspects of the database. In order to understand this behavior, a formal representation is necessary to structure the knowledge. Declarative knowledge can be viewed as a relational data model, which involves both intentional or conceptual representation and an extensional representation. The entity-relationship approach is useful in arriving at the intentional representation. Traditionally, in the relational data models the entity-relationship diagrams (E-R diagrams) are fixed and represent static databases. The dynamic behavior of the database is not specified via the E-R diagram. While developing an expert sys-
tem, conventional E-R diagrams can be used to develop the conceptual schema of the static declarative knowledge. We propose an E-R decision schema (E-R DS) for the conceptual schema development of dynamic databases. The proposed approach is illustrated through an example system.
5.1. Approach for formal representation We define the formal approach for knowledge representation as follows: 1. Identify the features of the expert system • purpose of the expert system • synthesis methodology. 2. Identify static knowledge. 3. Identify procedural rules. 4. Identify the interactions between procedural rules and static knowledge. 5. Develop an E-R decision scheme. The following discussion explains this methodology. 5.2. Identification of the features of the expert system To identify static and dynamic knowledge, it is necessary to understand the system. We explain our framework via the intelligent facilities layout analysis and planning (IFLAPS) expert system. The problem of industrial facilities layout design faced by the manufacturing engineer is very complex. Facilities layout can be defined as "the optimal arrangement of departments/machines in a plant such that it facilitates the production process and satisfies the constraints imposed by the analyst". Conventionally, the problem is solved as a single criterion optimization problem. Given the number of departments, the number of different products and volume of production, the available methodologies try to determine that configuration of departments which minimizes the total materials handling cost. Most of the approaches view the above situation as a quadratic assignment problem and try to generate the solution space through some acceptable search mechanism. If the analyst wants to change certain departments, the whole problem is handled again as a new one and the current solution is not of much help. In real life, this problem has multiple criteria. In addition to the materials flow criteria considered in the conventional approaches, certain additional factors also need equal consideration, such as: 1. Flexibility of the layout. 2. Special requirements for certain departments, 3. Safety considerations and 4. Aesthetic appeal.
Databases in manufacturing systems • S. KUMARAand I. HAM Some of these, like special requirements, may have to be satisfied without exception, while others, like aesthetic appeal, may be satisfied to a particular level. Moreover, when the analyst is dissatisfied with a particular generated configuration, he should be able to change certain constraints and the level of constraint satisfaction, if required. In this work the facilities layout problem is treated as a multi-objective problem and solved via an expert system. The multiple objectives considered are: 1. Minimizing material handling cost, 2. Maximizing safety level, 3. Maximizing flexibility of the layout, 4. Maximizing personnel appeal and 5. Maximizing the level of satisfaction of special requirements. An expert system is developed for generating alternate layout configurations for the layout problem. The knowledge about the problem is acquired through an interactive dialog with the user. Typical types of knowledge may be: 1. N u m b e r of departments, 2. Number of locations available and available resources, 3. Special requirements for departments and 4. Production volumes. The special requirements are classified into hard and soft constraints. The user has the flexibility to ascertain the required levels of fulfillment of these constraints or he can leave it to the expert system to decide the levels for him. The heuristic methodology to generate the efficient set (set of satisfying solutions) works on the principle of constraint-directed search. For each of the constaints, their fulfillment is treated as a sub-goal matching. The heuristic starts by assigning the department, with the hard constraint having the highest priority to the relevant location and successively tries to satisfy the other department requirements. Once a department is assigned, its neighboring location (the location to the left, top, right or bottom) becomes a candidate for assignment and the next highest priority department is chosen for assignment to the candidate location. If the location does not satisfy the constraints required by the department, then its neighbor is considered as a candidate. The heuristic assignment continues until all the sub-goals are matched. For the resulting generated configuration, the satisfaction level and the cost are determined. After each assignment, the expert system enters into a dialog with the user to check for any additional constraint incorporation or deletion of old constraints.
575
The overall configuration of the system as described above leads to further detailed analysis, to identify the static and dynamic aspects of knowledge. 5.3. Identification o f static knowledge The declarative knowledge is modeled as a relational database. Some of the entity sets identified are: 1. Department 2. H e a t producing department 3. Water requiring department 4. Compressed air requiring department 5. Manpower working department 6. Flammables in department, etc. The entity-relationship diagram shown in Fig. 2 is used to represent the conceptual scheme. Department is a relation with the attributes department number, department name and area required. Heat producing is another relation with the attributes department n u m b e r and heat intensity. This can be represented uniquely with the relationship heat. The resulting formal representation for the static knowledge is given in Table 1. For example, noise producing is a relation having the attributes department number and noise level with Dept. as a primary key. For the locations available on the ground plan, a similar E-R diagram can be drawn. Table 2 describes Table 1. Relational database scheme for departments Heat producing (Dept #, Heat Intensity) Water requiring (Dept #, Qty of water) Compressed air requiring (Dept. #, volume) Door requiring (Dept #, # of doors) Personnel (Dept #, # of people) Noise producing (Dept. #, Noise level) Flammables in (Dept. #, Flammable material) Heavy machinery (Dept. #, weight) Power generating (Dept. #, power level) Hazardous (Dept. #, hazard level) Special requirements (Dept #, sp requirement) Department (Dept #, Dept. name, are reqmred) Italic attributes are the primary keys. Table 2 Relational database scheme for locations Location (Location #, Area, Load bearing cap, celhng height) Neighbor (Location #, Neighbor location #, left, right, top, bottom) Has adjacent (Locauon #, Neighbor location #) Door avadable (Locanon #) Water available (Location ~) Available 1 (Location #, number of doors) Available 2 (Location #, qty of water) Available 3 (Location #, volume of air) Italic attributes are the prrrnary keys.
576
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
IH,ot° ,°°l
,rr°°,ro01
,,,,0orlro°,oo0 Co ,
+
IDepartment. I
Fig. 2. Entity-relationship diagram (conceptual schema).
the corresponding relational database scheme. For example, location is a relation having the attributes location number, area, load bearing capacity and ceiling height with location number as the primary key. Available 1, Available 2 and Available 3 are the relations describing the number of available doors. Quantity of water and volume of compressed air available in locations 1, 2 and 3, respectively. It can be seen from the above discussion that the identification of static knowledge leads to an E-R representation. The E-R diagram can be immediately translated to a relational database scheme, which can be converted to logic clauses for implementation.
3. The priority is highest and 4. There is a location available and 5. The location has a door THEN: Assign the department in question to the location considered. The above procedural rule can be translated to a P R O L O G implementable form. A procedure consists of one or more assertions or clauses of the form P0:- P1, P2, . . . , Pn which can be read declaratively as: " P 0 is T R U E if P1 and P2 a n d . . , and Pn are true." or
5.4. Identification of procedural rules The procedural rules can be classified as: 1. Rules for knowledge acquisition, 2. Rules for inference, 3. Rules for control, 4. Rules for reasoning and 5. Rules for data-ordering. In this section we deal with rules of inference. These rules are used to synthesize a layout configuration. The heuristic algorithm explained in section 5.2 can be represented as a set of rules. Consider the example: " D e p a r t m e n t raw material needs a door and a door is available at location number 1, and the priority for door allocation to the raw material department is 1.00 (highest)". In general a rule of the above forms can be written as follows: IF: 1. There is a department and 2. The department needs a door and
" T o satisfy goal P0, first satisfy goal P1 then goal P2 t h e n . . , goal Pn." An examination of the above structure reveals that the antecedents are represented as: :-P1, P2 . . . . . Pn (on the RHS) and the consequence as P0 (on the LHS). To satisfy each of the goals, it might be required to satisfy other goals. For example, the location should not have been assigned to any other department. For satisfying this rule we may have to invoke another rule. This is knowledge about the knowledge of the assignment of the department. Such a rule about a rule, or knowledge about knowledge, is known as a meta-rule, which in this case is: IF: Any of the departments is not assigned to the location in question
Databases in manufacturing systems • S KUMARAand I HAM
THEN: The location in question is available for assignment. A rule that invokes a meta-rule is called a Level-1 rule. A meta-rule can invoke a meta-meta rule. In PROLOG, the rule described earlier can be represented as follows: door_needed_check:door_required (x), door_available (y), not (assignment (x,_)), not (assignment (_, y)), priority_index (x, door_requirement, 1.00), assign1 (x,y). The inference mechanism works by linking the rules effectively. All the procedures are represented in the above fashion and similar procedures or rules are linked with each other, thus defining the procedural knowledge base.
5.5. Identification of interactions between static
knowledge and procedural rules To understand the behavior of the database it is essential to study the interactions between procedural rules and the declarative knowledge base. Consider the example rule given in section 5.4: "Assign the department in question to the location considered." Assume that the department in question is the raw-materials department and the Instances of relational scheme: department (001, raw material, 1000). door_required (001). priority index (001, door_requirement, 1.00). door_available (10). The following meta-rule states that, when a department is assigned to a location, then we need to remove the instance of the relation (available location) for the location # 1 0 considered. Any of the departments is not assigned to the area in question THEN: The location in question is available for assignment. In addition, we need to create a new relation assignment_made and instantiate the attributes to the department and to the relevant location: for example, assignment (001,10). Therefore, dynamically we need to remove certain instances of a set of relations from the database and add new relations and instances to the database. These interactions are typically complex. The analyst needs to identify all the five types of rules
577
described earlier and the resulting interactions with the static knowledge. This will lead to the identification of the dynamic entities. 5.6. Development of E-R decision scheme There are no formal representation methods available for capturing the dynamic behavior of declarative knowledge. By the creation of new relations and updating their instances, the state description changes. For the representative rule considered in section 5.4, the subgoals of the rule can be identified as: door_required (x): sub-goal 1 dooravailable (x): sub-goal 2 not (assignment (x,_)): sub-goal 3 not (assignment (__,y)): sub-goal 4 priority_index (x, door requirement, 1.00): sub-goal 5 not (priority_index(_, door requirement, 1.00)): sub-goal 6 Figure 3 represents the E-R decision scheme for this rule. The knowledge is represented by the relations: Department (Dept # , name, area). Resource requiring (Dept # , resource, qty). priority_index (Dept # , requirement, priority). Available (Location # , resource, qty). Location (Location # , load capacity, area). Door_available (Location # ) . Free (Location #). Assignment (Dept # , Location #). Doorrequiring (Dept #). priority (Dept # , resource, index). Some of these, like department, location and priority, are static. The other relations are either created or deleted by the application of a rule. To look into the dynamic behavior of knowledge, it is essential to apply the rule to the E-R diagram and study the consequences. Sub-goal 1 tries to match an instance of the relation doorrequiring; let this be Operation I (O1). Similarly sub-goal 2 tries to match an instance of door-available location (02). Table 3 gives the above matching operations. In the forward process, as each sub-goal is matched a "yes" indicates goal fulfillment and the next sub-goal is considered. When any of the goals fail, the search is stopped and an alternative rule is fired. A point of interest in the table is what happens when backward chaining is undertaken. In the forward chaining of all subgoals, the success of the first six goals allows sub-goal 7 to succeed. This involves a state change. A new relation Assignment is created for the first
Robotics and C o m p u t e r - I n t e g r a t e d Manufacturing • V ol ume 4, N u m b e r 3/4, 1988
578
I
I ResourcerequiringI
I IDeportment]
J Avall.abteJ __J
I
Fig 3
Ent]ty-relatlonshlp decision schema
time and an instance when sub-goal 7 succeeds will be: Assignment (Dept x, Location y). The instance of Free(y) is deleted from relation Free. Once sub-goal 7 succeeds, the LHS of the goal succeeds, this leads to backtracking to sub-goal 6, where the database has not been dynamically updated. From priority-index relation, due to 05, the tuple for departmentx is deleted. 0 3 and 0 4 result in
the insertion of corresponding instances in the relation Assignment. 0 2 and O1 result in the deletion of corresponding instances from the relations doorrequiring and door_available. It can be seen from this E-R decision scheme for a simple rule application, the quantum of dynamic changes instantiated. A thorough look into the E-R DS can lead to a better design of the knowledge base, by avoiding redundancy. On the other hand, if the analyst has a conceptual scheme and rules
Table 3. E-R d e o s l o n scheme table for matching ope ra t i ons Subgoal used
Operatmn
1 2 3
O1 02 03
4
04
5
O5
6
06
7
07
8
08
Description Is door r e q m r e d for a d e p a r t m e n t ? Is there a location with a door? Is the d e p a r t m e n t avadable for assignment? Is the location avadable for assignment 9 Is the priority of this d e p a r t m e n t highest? ls the priority of all other d e p a r t m e n t s lower? Make an ass]gnment of the d e p a r t m e n t m questmn to location considered Free location moved
* In&cates dynamic update, - in&cates no change
State-change forward ba c kw a rd
Status
Relation update
Yes Yes Yes
-
* * *
door_reqmrmg door_avadable resource_requmng
Yes
-
*
resource_requmng
Yes
-
*
available
Yes
-
-
--
.
assignment
.
.
.
Databases in manufactunngsystems• S. KUMARAand I. HAM
579
described verbally, he can undertake the same process and define his rules more rigidly, which is advantageous from an implementation viewpoint.
tuple y • project # = tuple x • project # ; store tuple y • part # print tuple y • part # (numbers and tuple x • contractor
6. EXPERT SYSTEMS AND DBMS A DBMS deals with data and an ES uses knowledge. Knowledge, typically, is intentional, in small volumes and supplied by experts. Data, on the other hand, are large volume, extentional and matter-offact. A DBMS uses query retrieval and an ES inference mechanism to retrieve information or to perform logical deductions. This concept is explained through a small database in the following example. Tables 4A and 4B define a conceptual relational schema for a small parts-project database.
end. The response to the query will be:
Table 4A. Part relation (PA-R) Part # P1 P2 P3 P4
Part name
Project
Nut Bolt Screw W~dget
J1 J2 J3 J1
Interpretation: P1 is a nut and is used by project J1 Table 4B. ProJectrelation (PA-R) ProJect # J1 J2 J3
J4
City
Contractor
London New York Bombay Pans
Smith Wemman Mltuh P~erre
Interpretation: Project J1 is m London and the contractor ~s Smith. The DBMS should provide means for converting this conceptual relational schema into a physical schema. It should also have application programs to retrieve the required information. The similarities between query retrieval and ES deductive inference can be brought out by considering a typical example query: Query: Give the name of the contractor who lives in Bombay and the parts used by the project in that city. An algorithmic procedure for the implementation of the search for the query retrieval is as follows: begin From relation, R1 select the attribute city and choose tuple x where tuple x. city = Bombay; store tuple x • project # , tuple x • contractor; select relation R2 and select that tuple(s), y, where
MITULI P3 This retrieval scheme, however general, can be implemented in specific, to this application. An implementation in SQL is of the form SELECT FROM WHERE
CONTRACTOR, P # PR-R, PA-R J # IN (SELECT J # FROM PR-R WHERE CITY -- 'BOMBAY' IN (SELECT P # FROM PA-R)) The expert systems approach as discussed typically consists of a declarative and procedural knowledge base. The declarative knowledge consists of the relations and the procedural knowledge consists of the rules to retrieve the required information. A logic implementation scheme will be of the form: (in binary-two place predicate structure): Parts-Projects (P1, J1). Parts-Projects (Pz, J2). Parts-Projects (P3, J3). Parts-Projects (Pa, J4). part-names (P1, nut). part-names (P2, bolt). part-names (P3, screw). part-names (P4, widget). project-city (jl, London). project-city (j2, New York). project-city 03, Bombay). project-city (j4, Paris). city-contractor (London, Smith). city-contractor (New York, Weinman). city-contractor (Bombay, Mituli). city-contractor (Paris, Pierre). Typically the query retrieval language can be implemented through a set of rules. In logic form the rule to retrieve the answer is of the form: select-names-parts (Y,K,X):city-contractor (X, Y), project-city (Z,X), part-projects (K,Z). When the city variable X is instantiated to Bombay, the search for an answer will be triggered.
580
Robotics and Computer-Integrated Manufacturing • Volume 4, Number 3/4, 1988
It can be seen from the above example system that in the event of highly structured information, query retrieval and application of a rule base share similar characteristics. The two approaches broadly illustrated here pertain to query evaluation in a DBMS and deductive inference in an expert system. To answer a question, the query evaluation process basically builds an evaluation tree, without backtracking. The deductive inference mechanism finds a proof to a theorem; in this case, a proof for the conjecture:
(JY, JK I select-name-parts (Y, K) ---> city-contractor (X, Y)A project-city (Z, X)A part-projects (K, Z))? (X: mstantiated to Bombay). Whenever an explanation needs to be given, the inference mechanism backtracks to give an appropriate reasoning explanation. Essentially the basic ideas are of search in both systems. A look into the two systems, a DBMS and an expert system, leads to certain interesting observations. It is definitely difficult to add new data to a DBMS. This necessitates the revision of data structures. In an ES it is relatively easy. The application program for query evaluation is easier to develop and the tree takes care of integrity. The integrity constraints have to be built into the inference mechanism and this leads to a check on the consistency of all the rules m the knowledge base. On the other hand, in the event of missing and partial information, the deductive inference mechanism may be more useful. We are now faced with two basic issues: 1. If the database is structured, then the constraint knowledge can explicitly be embedded in the DBMS application software. 2. It is not very easy to modify search in deductive inferencing to accommodate integrity constraints. This poses an interesting question. Can we design our expert system in such a manner that it can use the structure of a DBMS and the flexibility of expert systems? This leads to the consideration of expert database systems.
2. Structured data can be used in the DBMS architecture and 3, The DBMS can act as an intermediary between on-line data and the knowledge that needs to be used by the expert system. Figure 4 shows a framework for expert database systems design in Industrial Engineering. For example, consider the following systems: 1. Process planning system, 2. Job-shop scheduling system, and 3. Quality control system. In a process planning system, considerations regarding features and alternative process plans play an important role. The characteristic data about features are extracted from the C A D database. Most of the expert systems in the process planning realm try to consider these data and build an inference mechanism to identify the features. In reality, it may not be beneficial to use the inferential process for this purpose. A DBMS system can be defined in which application programs are used to implement the query evaluation tree to extract the required information for answers. A preprocessor can be used to convert these data to the appropriate physical knowledge-representation scheme for the expert system. The second system, a job-shop scheduling system, uses information about capacities, demands and products. The system uses dispatching rules to find a schedule which optimizes on a given criterion. The major issues in this case are those of changing KnowLedge= bosed procetmI,J'~
Comm~a(shored) clatabase
I (chstr, buted)
6.1. Expert database systems The basic philosophy behind expert database systems is that of combining the structure of DBMS and the deductive inferential reasoning of expert systems. Such an approach would be of immense use for the following reasons: 1. Inferential processes need not be used on high volume data,
Data coltechor
F~g. 4. Expert database systems architecture for industrial engineering apphcatlons.
Databases in manufacturing systems • S. KUMARAand I HAM
demand patterns and stochastic processing times. Due to the slow nature of symbolic languages, the expert system will be slow if it uses modules to generate the processing times (which is true at least with large systems). This burden of demand analysis and stochastic time considerations can be left to the DBMS and the information generated can be used by the expert system. On the other hand, illstructured information can be handled by the expert system. The third system we are considering is that of quality control. In a quality control system real-time information is of immense value. A vision or an image processing system needs to be used to track the defects in a part under production. The image data need to be converted into symbolic information and used by the expert system. If the expert system has to perform image or vision analysis, it would amount to using the ES inefficiently. The ES which has to do inferencing on quality control should be stripped from the overhead of statistical analysis of the image or vision data. Moreover, in this case, the ES deals with a large volume of dynamic data, whose maintenance should be left to the DBMS. In general the design of any expert system needs the following consideration. 1. Whether the ES should be stripped from the rigor of processing large volumes of data and retrieving information from them. 2. Whether the burden of maintaining a shared knowledge base be left to the DBMS or the expert system. The answer to the first question is that if the knowledge is structured and requires data processing, the DBMS should handle it. For the second question, it is felt that the ES should not be taxed with maintaining the shared (common) knowledge base. The DBMS should maintain it. Figure 4 proposes a scheme for an expert database system architecture. At the lowest level, the on-line sensor information, image data, vision data and CAD data are collected. These have to be analyzed and converted to a database. The DBMS should maintain the application programs and the evaluation trees for routine query retrieval. It will be useful to have a relational distributed database. The various expert systems should interact with the DBMS through a knowledge representation (KR) converter. The purpose of the KR converter is to convert the data from the DBMS into a usable scheme for the expert systems. This requires the need to analyze the applications and designing the expert systems from a common knowledge-representation point of view.
581
MANUFACTURING INTEGRATION: A FRAMEWORK In the previous sections, we dealt extensively with the concepts of RDBMSs and expert systems. The following represent three claims, which are the outcomes of this research: Claim 1: Manufacturing systems are data intensive. The volume of data handled is large. However, the data types are few. Claim 2: It is possible to clearly distinguish between the operators (rules) and relations in a manufacturing system. The ER-DS approach lends itself to automation. Claim 3: The routine tasks in a manufacturing system can be handled via a query retrieval scheme which will be an integral part of a RDBMS. Such a system needs to be distributed. A meta-level expert system can be used to integrate the expert system modules and the RDBMS scheme. Keeping these three claims in view, a framework for manufacturing integration is proposed. Figure 5 represents the proposed framework. The major aspects of the framework are: 1. Development of a design theory, 2. Group technology coding and classification, 3. Process planning and 4. CAD/intelligent designer. Figure 5 clearly shows the hierarchical and lateral interactions. In the ensuing discussions we explore 7.
function amotlc I (oxl Des=gn approach) ~
General part functlonaL
l
descrBptlon
/
extractor I
Intelligent transLator
]
/
GTcode developer (expert system)
CAD/roteLtlgent designer
I
Totallyautomated process planner (TAPP)
l
Manufactur=ng system control
I ~Data
Data ~o~=ng I
Fig 5. Database and AI-related framework for manufactunng integration
582
Robotics and Computer-IntegratedManufacturing• Volume4, Number 3/4, 1988
the possible ideas of integration from the view of the three claims. 7.1. Development of a design theory Given a part description, the system would use an axiomatic approach based on mathematical logic and pattern recognition. The idea here is one of defining partial design as predicates. These predicates will be matched intelligently with the dictionary of specifications and the appropriate partial designs will be retrieved and by suitably combining the sub-designs the part design can be defined. Considerable work from a database point of view in design theory development has been done by Yoshikawa. TM 7.2. GT coding Given a part design, it is theoretically possible to define a GT code. The system will automatically develop the GT code. the system will identify the design features, then look into the classification possibility and define an appropriate part family code. The distinct feature of this system would be one of an interaction between the GT scheme and a CAD database. The system will use the GT code in conjunction with the design theory to develop the CAD database. Such an approach can be very effective in making the system learn about new parts and in automatically generating the GT code and subsequently a CAD database. The envisaged process is essentially one of using the design database effectively. At this stage the ideas of expert database systems are of immense use. 7.3. Intelligent process planning Though GT has acquired wide popularity, very little effort has been made to use this information in designing process plans. Our aims is to extract the information from GT codes and use them to define the process plan. The function of process planning is experience-based. Hence, there is a need for a system which deals with symbolic manipulation and uses the expert knowledge. There is a need for designing an expert system. The ideas discussed under ER-DS and EDS can effectively be used to design the process planning system. The proposed framework is a set of complex interactions between the various databases and expert systems. The design theoretic approach will form the basis for the system. It is intended to perform the design function based on an axiomatic approach. This naturally lends itself to defining the relational schema. Given a general part description, an ES module will translate the description to axioms that can be used by the design function cells. The
design function will rely heavily on a search-based pattern recognition system. The recognition system in this case needs to be implemented based on attribute grammars. The design information can now be defined as types of relations. The GT code developer interacts with these instances to define the GT codes. The GT code and CAD database in conjunction will be used to trigger the process planning system. The framework for integration can be viewed as being comprised of the following: 1. Conceptual modelling, 2. Identification of DBMS schema, 3. Identification of ESs modules, 4. A query retrieval language for the manufacturing framework (SQL based), 5. Development of ER-DS for • Design • Feature extraction • Part translation • GT code building • Process planning • Controlling, and 6. Linking of the above five through a meta-level expert system, based on the EDS philosophy. 8. CONCLUSIONS The research work reported in this paper deals with three distinct ideas: 1. Relational database management systems and the use of defining the operators in the E-R DS approach, 2. Expert database systems, and 3. Manufacturing integration. The main point which came to light is that one needs to clearly identify the static and dynamic knowledge so that the operators (rules) can be used to identify the relationships and the contributing relations. Such an approach leads to automating the rule-writing process. It also clearly helps in identifying the rules and the relations of the RDBMS. The expert database systems philosophy shows clearly that certain tasks can be accomplished through a query-retrieval system. This leads to identifying important rules that only need to be incorporated into the expert systems modules. The routine retrieval can be left to the RDBMS, which implies that the ESs modules and the RDBMS should be interfaced via a meta-level ES. In order to design a consistent and minimal RDBMS, the E-R DS approach would be of immense help. The ideas of both the ER-DS and EDS can be incorporated into the general framework given in Fig. 5. While designing the modules it would be appropriate to use the ideas explored in the ER-DS
Databases m manufacturing systems • S. KUMARAand I HAM and EDS approaches. The advantage of such a system, which would use these two philosophies, lies in its ability to be uniform and flexible. Integrity constraints can easily be maintained in such a system. The ER-DS approach has been implemented using Prolog. The expert database systems idea is implemented for integrating: 1. A vision system and 2. R o b o t path planning system. The relational schema for this is implemented in Pascal and the two expert systems in Prolog.
9. 10. 11. 12.
13. REFERENCES 1. Barkocy, B.E., Zdebhck, W.J.: A knowledge based system of machining-operation planning, in Proceedings of AUTOFACT 6, pp. 2.11-2.25, 1985. 2. Barr, A., Davidson, J.: Representation of knowledge. In Handbook of AI, Barr, A., Fiegenbaum, E. (Eds). Computer Soence Department, Report No. STANCS-80-793, Stanford University, 1980. 3. Brodie, M.L., Mylopoulos, J., Schmidt, J.W. (Eds): On Conceptual Modelling. New York, Springer, 1984. 4. Brachman, R., Levesque, H.: The knowledge level of KBMS. In On Knowledge Base Management Systems, Brodle, M.L., Mylopoulos, J. (Eds). New York, Spnnger, 1986. 5. Clocksin, W.F., Mellish, C.S.: Programming tn Prolog. Berlin, Springer, 1981. 6. Date, C.J.: An Introduction to Database Systems. New York, Addison Wesley, 1983. 7. Fox, M.S.: The intelligent management system: an overview. Technical Report C M U - R I - T R - 8 1 - 4 , Intelligent Systems Laboratory, The Robotics Institute, Carnegie-Mellon University, 1981. 8. Fox, M.S., McDermott, J.: The role of databases in
14.
15. 16.
17. 18.
583
knowledge-base management systems. On Knowledge Base Management Systems, Brodie, M.L., Mylopoulos, J. (Eds). New York, Springer, 1986. Ham, I, Hitomi, K, Yoshida, T.: Group Technology. Boston, Kluwer-Nijhoff, 1985. Hatvany, J.: Available and missmg AI tools. Ann. CIRP 35: 1986. Hatvany, J.: Distinguished lecture series. Lectures given at Penn State University, University Park, PA 16802, USA, March-April 1987. Kerschberg, (Ed.) Expert database systems. Proceedings of the Ftrst Internattonal Workshop on Expert Database Systems, Klwah Island, S.C., 1984. Menlo Park, Benjamin Cummings, 1986. Kimura, F., Suzuki, H.: Variational product design by constraint propagation and satisfaction in product modelling. Ann. CIRP, 35: 1986. Kumara, S., Kashyap, R.L.: Entity-Relationships and their applications to expert system development. Proceedings of the International Conference on Systems Man and Cybernatics, IEEE, Arizona, Nov. 1985. Smith, J.M.: Expert database systems, a database perspective. In Expert Database Systems, Kerschberg, L. (Ed.). Menlo Park, Benjamin Cummings, 1986. Tirupatikumara, S.R., Kashyap, R.L., Moodie, C.L.: Artificial intelligence techniques in facilities layout planning--the development of an expert system. Technical Report, TR-ERC 86-1, Engineering Research Center for Intelligent Manufacturing Systems, Schools of Engineering, Purdue University West Lafayette, IN 47907, Dec. 1985. Wilderhold, G.: Knowledge versus data. In On Knowledge Base Management Systems, Brodie, M., Mylopoulos, J. (Eds). New York, Springer, 1986. Yoshikawa, H.: General design theory and a CAD system. In Man-Machine Commumcatlons in CAD/ CAM, Sata, T., Warman, E (Eds). North Holland Publishing Company, IFIP, 1981.