关 键 词：

JS617 街道 护栏 清洗 设计

资源描述：

以上为资料预览概图，下载文件后为完整一套设计。【清晰，无水印，可编辑】dwg后缀为cad图，doc后缀为word格式，png和jpg，gif后缀为资料预览图片。有疑问可以咨询QQ：529358737

内容简介：

Application of Model-based Diagnosis to Machine Tools* Gfinter Spur Sabine Wei$ Fraunhofer-Institute for Production Systems and Design Technology Pascalstr. 8-9 1000 Berlin 10, West Germany WEISSDBOPTZ1A.BITNET Abstract Model-based expert systems show great promise particularly in their technicaJ application. This article describes a research project in which the fundamentals for the development of model-based diagnostic expert systems in manufacturing are to be compiled. Using the example of a lathe, general ideas on machine tool modeling are presented and the concept of an on-line-coupled diagnostic system supported by an assumption-based truth maintenance system is introduced. The modeling follows a component-oriented approach using constraints to represent the behavior of the machine tool. The significance of the introduction of derived constraints and different levels of abstraction is explained. Initial experiences from the practical realization of the system point toward the applicability of this approach to other cases. 1 Introduction Mos of the expert systems used in industry today rely on associative representation of the diagnostic knowledge. However, problems occur frequently because scarce experts are difficult to free for the demanding process of knowledge acquisition and heuristically determined cause-effect or symptom-fault associations may cause inconsistencies of the knowledge base. Moreover, difficulties are faced especially in the adaptation of diagnostic systems to alterations in the mode of production as well as with the integration of any new information on faults. Model-based diagnostic expert systems have the ability to largely elude the disadvan- tages of the associative approach. In most cases, not the knowledge of the maintainers on location but that of the producer is required. The construction or alteration of the model may be modular without there arising any inconsistencies. Models of individual components may derive from knowledge of other diagnostic objects already known from other models. So far, model-based diagnostic expert systems have been developed primarily in appli- cation areas where an appropriate model was either on hand or easy to develop (cf. Davis 84, Friichtenicht 88). Already existing methods of AI-research on diagnosis like GDE *This work is part of the research project Development of a Model-Based Diagnostic Expert System for Maintenance supported by the European Recovery Programme, Berlin, No. ERP 2611. 234 (general diagnostic engine) developed by deKleer & Williams 87 cannot immediately be applied in production technology as sufficient experience for the conception of models in this area is not available. Above mentioned work deals with easily discernible, limited ob- jects such as addition/multiplier networks and resistors, or streams of energy and liquids whose models are not especially helpful for an adequate reproduction of a machine tool. This report presents the ideas involved in the modeling of a lathe as an example for complex manufacturing systems, the general concept of the ATMS-based diagnosis system, and the initial experiences from prototypical realization. 2 The Model 2.1 Modeling of Machine Tool Structure The computer-internal representation of a machine tool from which the diagnostic process can deduct causes of faults requires a model of the machines construction as well as a model of its functionality. For purposes of this representation, a component-oriented approach was used in the project described here that is similar to the ones known from literature (cf. Davis 84, deKleer & Brown 84, Strul88). Optional connections between component parts allow for a detailed modeling of the interaction of components affected. Components as well as their connections possess substructures enabling a view of the model recurrently refined, and at different levels of abstraction. This kind of repre- sentation provides for the representation of functionality in the form of constraints for components as well as for connections. The configuration and the behavior of machine tools varies with the actual production order to be executed. Our representation formalism takes this into account allowing the simultaneous modeling of mutual exclusive components like different workpiece clamp- ings. Section 2.5 describes the construction of the run-time model representing the actual configuration which the diagnostic process finally employs. To avoid a complete re-modeling of similar components or aggregates and to facilitate the realization of a component library applicable to other machine tools as well (cf. sec- tion 4) a mechanism to copy components from samples is provided. The implementation relies on the object-oriented paradigm. In default of detailed information, this approach permits a rough modeling of machine elements by using a general class component-or-connection. Roughly modeled parts may be refined later by defining subclasses with more detailed information about structure and behavior. So, while building the machine tools model, a stepwise refine-and-test strategy is possible. Each component or connection possesses information on its subcomponents, local vari- ables, terminals, and constraints describing its behavior (cf. Table 1). Terminals are special objects that may reside in several components simultaneously. They contain those variables that are common to different components. Constraints describe the relations between components or inside a component using variables. The structuring of a lathe was derived at first only from technical drawings and the parts lists which had been made available by the machine tool producer. Starting with 235 the perception of the lathe as a whole the machine was then modeled according to its elements and their connections. 2.2 Representation of the Machine Tools Behavior Constraints indicate the required relationship of inputs to outputs of a component or connection in a production process considered to be fault-free. They describe therefore the correct behavior of those machine elements and subsystems involved in the production process. Inputs and outputs are represented internally by variables which are qualified in the course of the diagnostic process by concrete values. Constraints are realized employing a class concept. Their design is simple, mainly discriminating between the different roles the variables play in the relation the constraint represents using different types of variables. Variables which are equivalent with respect to their function within a relation, e. g. the terms of sum of an adder relation, are of the same variable type. The constraints semantics are supplied by individual methods attached to it. They test if a constraint is applicable at all, compute the values of all calculable variables and restore them in a way suitable to the interface to the ATMS. Typically, these actions return more than only one value because depending on the kind of constraint involved and already known variable values it is possible to determine the values of several variables in parallel. Besides, in the course of constraint propagation different contradictionary values for the same variable may be derived. With the aid of the ATMS the system handles such values simultaneously (cf. section 3) so that the constraints methods must treat them similarly. In most of the constraint-based systems known in literature and used in diagnosis, constraints are mathematical equations describing additive or multiplicative relations be- tween physical magnitudes Sussman &: Steele 80, Davis 84, Friichtenicht 88. For these cases, determination of dependent physical magnitudes is very easy. However, this ap- proach is not sufficient for many practical applications. Often the actual dependencies of input and output cannot be pressed into such form. Especially at high levels of ab- straction, formulations of machine behavior are possible only by way of the predicates Table 1: Representation of the Lathe LATHE An instance of flavor COMPONENT-OR-CONNECTION. Instance variables: NAME SUBCOMPONENTS CONNECTIONS CONSTRAINTS VARIABLES TERMINALS LATHE (CONTROL POSITION.MEASURING.SYSTEM MAIN.DRIVE MAIN.GEAR SPINDLE.BEARING.UNIT WORKPIECE.CLAMPING WORKPIECE .) NIL (LATHE-FUNCTIONAL-CONSTRAINT WORKPIECE-CLAMPING-CONSTRAINT) (FUNCTIONAL. #) (WORKPIECE.CLAMPING. #) (WORKPIECE.CLAMPING. #) 236 characterizing the condition of individual machine elements. That is why the system de- scribed herein makes use, along with the mathematical form of representing constraints, of a representation derived from a predicate-logic description of relations between conditions of components and connections. An example of such a description is: front, bearing-funct ional (rel. 1) A back .bearing-functional A spindle-functional + spindle.bearing.unit-functional. In this example it is assumed that the functionality of the spindle bearing unit may be derived from the functioning of all its subcomponents and that conversely the functionality of its subcomponents may be derived from the correct behavior of the spindle bearing unit. Each variable may be assigned three values: TRUE FALSE, or UNKNOWN. 2.3 Derived Constraints The constraint propagation mechanism described above is not able to determine all possi- ble variable values. For instance, consider the spindle bearing units constraint described in (tel. 1) with all the variable values unknown and a similar constraint describing the relation front.bearing-functional A back.bearing-functional bearings-functional. (rel. 2) (tel. 1): front.bearing-functional A back.bearing-functional A TRUE + spindle.bearing.unit-functional (tel. 2): front.bearing-functional A back .bearing-functional e+ FALSE This could result in assigning FALSE to spindle.bearing.unit-functional. Yet, the constraint propagation mechanism is not able to exploit this information because it possesses no means to substitute FALSE for the term front.bearing-functional A back.bearing-functional in the spindle bearing units functional-constraint. The problem depicted here does not only occur in logical constraints but in constraints representing numerical relations, too. Consider for example an adder constraint with any Suppose the machine tools control informs the diagnostic system of the bearings not being functional, thus causing the system to assign the value FALSE to the variable bearings-functionaL This leads to no propagation of this value because not all the in- formation needed is available. Next, suppose the machines operator affirms that the spin- dle is functional, i. e. the system learns the value of spindle-functional must be TRUE. Based on this new information the spindle bearing units constraint is not applicable though we already know that at least one of the two variables front, bearing-funct ional and back. bearing-lunar i onal must be FALSE because of bearings-funct i onals value: 237 number of terms of sum. The reason for this general problem may be characterized as incompleteness of the model, thus indicating a solution may be found by its appropriate extension. It can be solved automatically by generating additional constraints derived from the constraints supplied by the original model. This method considers all constraints of one class at a time, generalizing variables while taking into account the role they play in the original constraints. It is applied during the construction of the run-time model described further below. The following example may illustrate this procedure. Again, consider the two constraints outlined in (rel. 1) and (rel. 2). They belong to the same class and we obtain a generalized variable g for front.bearing-functional and back.bearing-functional. Now, we instantiate the following three new constraints: (rel. 3): front.bearing-functional A back.bearing-functional g (rd. 4): g A spindle-functional + spindle.bearing.unit- functional (rel. 5): g bearings- functional Now, using the constraint described by (rel. 5) we are able to infer FALSE as the value of g. Finally, applying the constraint of (rel. 4) yields FALSE as the value of spindle-bearing-unit-functional. 2.4 Levels of Abstraction The hierarchically constructed model of the machine is created by a step-by-step refine- ment of structure of components and connections. The models depth in the individual branches varies. It depends on two factors. On the one hand, detailed description of a machine component presupposes a working knowledge of its inner structure. Behavior of the components elements must be formulated and at least partially amenable to test- ing. If, as in the example, behavior description consists of predicates, at least one of the predicates relating to the subcomponents should be amenable to testing, otherwise this behavior description will never obtain a delimitation of faults. On the other hand, it is important to determine a rational depth of diagnosis. Should for instance the cause of a fault have been precisely located within a component, the cor- responding removal of this cause, however, consist basically in the exchange of the entire element, a detailed modeling of this complexity is superfluous and only leads to lengthy computation time during the diagnostic process. Considering this point is especially im- portant in the domain of our example because of its complexity. The structuring of the model into different levels of abstraction has the advantage of delimiting fault causes in their original areas even when they cannot be caught by divergent measuring values and sensor data. This enables the identification of a faulty component at a higher level than the one at which erroneous behavior is produced even when constraints of lower levels, which have been qualified by measured values, are not impaired. This may be important any time the model of a machine element has not been totally erected, or when external influences, previously ignored by model building, now act upon the system. 238 2.5 Constructing a Consistent Run-Time Model The model of the lathes structure and behavior provided at first contains mutual ex- clusive subcomponents as mentioned in section 2.1 and an incomplete set of constraints. Therefore, a compilation of the model is necessary to delete the inconsistencies caused by concurrent subcomponents and to extend the constraint set according to the method depicted above. The compilation results in a run-time model of the actual configuration and the behavior of the lathe according to the production order to be executed. This process consists of two steps: Pruning the model: The original model may contain component descriptions defining the subcomponents to be one. of several concurrent possibilities. While processing this component model in a depth-first manner, each time the compiler recognizes one.of it questions the machine tools operator presenting all possible subcom- ponents. The operator decides which subcomponents are actually involved in the production process. By way of choosing a component he also restricts the constraint set of the model. Any inconsistencies found are reported to the operator. Extending the constraint set: To the models set of constraints remaining after the pruning step the derivation method for constraints is applied. 3 The Process of Diagnosis The process of diagnosis is initiated by a fault notification either obtained from the lathes control or from its operator. The data supplied by the control of the lathe are used in first approximation by qualifying the corresponding constraint variables of the model with these values. The problem solver subsequently propagates through the model the values of components and connections variables derived from the constraints. Inconsistencies may be found as values - no matter whether measured or propagated - failing to satisfy constraints or as different values for the same variable. These inconsistencies are the symptoms of the fault to be diagnosed. The process of diagnosis is supported by an ATMS resembling the GDE paradigm (cf. deKleer 86a, deKleer & Williams 87 for details). The ATMS is able to manage different consistent and inconsistent facts and sets of assumptions in parallel. It provides information about data and the corresponding assumptions under which they hold as well as information about inconsistent sets of assumptions and updates them permanently. Crucial to the efficiency of this approach is the interface between the problem solver and the ATMS. We realized a consumer concept (cf. deKleer 86b) to guarantee (i) that a constraint is applied only if all variables needed for the execution of the constraint have values in the same consistent set of assumptions, (ii) that each constraint is applied only once to the same set of variables, and (iii) that each constraint is applied to all known values of each constraint variable. Moreover, extending the consumers with individual types eliminates redundant inferences. The diagnostic process has been designed to activate a complete propagation of all accepted and derived values through the entire constraint net before any candidates for a 239 diagnosis are generated. This impfies that values of all the constraint variables derivable from processing data are captured in the model. Naturally, this process is very time consuming. At present, a number of strategies are aimed at minimizing that expense, for example focussing on components known to be less reliable than others, thus driving at the introduction of heuristic knowledge into the model. AT.S II ( Problem Solver Explanation Module ) J User Interface Run-TimeModel Compiler Library of Knowledge Editor Components Base , & Constraints ,., from Lathe J Figure 1: Structure of the Complete System 4 System Architecture The essential components of the diagnostic expert system described in this article are graphically depicted in Figure 1. The approach that has been described for modeling the lathe constitutes the knowledge base, which is to be further refined and supplemented by suggestions for the treatment of fault causes. As it is frequently the case that equM or similar elements must be modeled, the setting up of the knowledge base draws on a library from which the respective components, connections, and constraints can be called. Beside the knowledge base, the compiler producing run-time models, the problem solver, and the ATMS constitute the systems core. A proposed explanatory module will enable the user to obtain information as to reasons for the given diagnosis. It will utilize the fault-source found and model knowledge towards generation of simple explanation of the diagnosis. The concept described was first tested in Common Lisp with Flavors on a Symbolics 3640. The system is now reimplemented on a Sun 3/60 with Lucid CommonLisp and CLOS. 240 5 Concluding Remarks The concept of the system described in this arcticle is aimed at eliminating two major problems in building knowledge based systems for applications in production: knowledge acquisition and adaptation to alterations in the production process. Since our concept allows refinements or additions to the model whenever they are required, the adaptation to changes in the production process is accomplished easily. Even total replacement