Composing and Sharing Dynamic Models in an Agent-Based Concurrent Engineering Environment Brian Howley Mark Cutkosky Center for Design Research Stanford University 560 Panama Street, Stanford, CA 94305 cutkosky,
[email protected]
Abstract Sharing design information in a distributed engineering team is a challenging problem. Ideally, the information exchange should be flexible enough to accommodate different levels of abstraction required for different engineering design and analysis tasks. We propose a solution in which specialists, and the programs they use, are modeled as agents who share a common communication language and ontology. The ontology includes both a symbolic representation of the equations describing system behavior and the conditions (such as parameter ranges) over which the model is valid. We use the a hybrid modeling paradigm to generate consistent models at multiple levels of abstraction and demonstrate the approach with design analysis tasks for a stepper motor actuated positioning system.
1. Introduction Modern consumer products involve a mix of technologies with an associated diversity of underlying models. The products are typically designed by teams of engineering specialists who, in today’s global economy, may not be co-located, and may not belong to a single organizational unit. Under such circumstances, the sharing of detailed knowledge is a challenge. Errors and inconsistencies can lead to costly back-tracking and extra design cycles. One approach to address these difficulties is to model the engineering process as a collaboration among agents. The agents may represent people, acting through a user interface, or they may represent autonomous programs that perform a specific task, such as manufacturability analysis or dynamic simulation. In general, human agents are temporally and geographically distributed and use heterogeneous platforms and software analysis tools. The problem of sharing information can be formalized if the agents adhere to a common communications language and protocol, and a shared ontology (a formal representation of terms and definitions) in the domain of interaction. In an engineering team, specialists exchange information at different levels of abstraction. At the highest level of abstraction are representations used primarily in the conceptual design stages for communication among human experts. A model at this point often consists of knowledge of the physical structure (components and their topology for
Gautam Biswas Knowledge Systems Laboratory Stanford University Gates Computer Sciences Bldg Stanford, CA 94305
[email protected] example) as well as knowledge of relevant physical phenomena. At more detailed levels, design information includes equations that describe system behavior and constraints. The lowest level of design information is parametric information, which assigns a specific numerical value to a physical or geometric property. Our agent-based system consists of one or more designers and a system model described using the Compositional Modeling Language (CML) [Falkenhainer, et al, 1994]. The model is a logical description of the system that is composed from representations built by individual agents. Information exchange between agents is accomplished by updating and querying the CML model. Model representations are exported in order that design agents can perform analyses and simulations with their own specialized tools. In previous work [Ozawa, et al, 1998a and 1998b], we have demonstrated model information exchange at the parameter level. A limitation with this approach is that parametric information is tied to a preexisting model; neither the underlying model itself, nor the assumptions and constraints applied to the model are shared. Conversely, equation level information exchange can support different levels of model abstraction and is better suited for early design stages where parametric relationships may be changing rapidly. Furthermore, assumptions used to generate the model such, such as valid frequency and parameter ranges, can be shared explicitly. We believe such explicit information can help designers avoid misunderstandings that lengthen the design cycle. This paper describes an ontology for exchanging equation level information between design agents. The ontology is intended to support a broad class of lumped parameter systems including continuous, discrete, and hybrid (discrete and continuous) systems. Motivation for this approach is provided with an example design of a stepper motor drive for a portion of a digital versatile disk (DVD) optical tracking system. An analysis task to determine the effect stepper motor pulses have on tracking performance requires a detailed continuous time model. On the other hand, testing a command sequence for a desired velocity profile requires only a simple discrete model of the motor. The continuous and discrete time models represent two very different levels of abstraction. We use a hybrid modeling ontology [Mosterman, et al, 1998] within CML to provide multiple levels of abstraction in a unified machine interpretable form.
2. CML and Agent Infrastructure Compositional Modeling Language (CML) is a general purpose declarative modeling language for representing physical knowledge. CML is intended to facilitate model sharing between research groups, many of which have long been using similar languages. These languages are based primarily on the language originally defined by Qualitative Process Theory [Forbus 1984] and include the languages used for the Qualitative Physics Compiler [Farquhar 1994], compositional model formulation [Falkenhainer, et al, 1994]. CML uses a domain theory to describe the general classes of objects and phenomena in the system of interest. The domain theory consists of two sets of definitions: (i) entities that define domain objects, and (ii) model fragments that capture the domain physics. Entities are persistent objects such as resistors, capacitors, springs, containers, etc. Model fragments describe the behavior of a single entity and interactions, such as collisions or flows, between entities. Model fragments can also include restrictions on their use (saturation limited output, for example). These restrictions are known as applicability conditions and are a major feature of the language’s usability. The scenario describes the entities comprising the system, their configuration, and a set of initial conditions. Once a domain theory is constructed, it can be used to model different physical devices under a variety of conditions. These conditions are specified in a model scenario. A user specifies a scenario that specifies model entities, their configuration and initial conditions. From the scenario, the CML implementation automatically identifies applicable model fragments. The model fragments are used to construct a symbolic description of the system and a set of governing equations. The equations may be solved or simulated to produce a behavioral description. Because the conditions under which the model fragments hold are stated explicitly in the domain theory, the system is able to assemble new models that describe the device as it moves into new operating regimes. Our agent-based system consists of one or more designers and a system model described in CML. The model is composed from representations built by individual agents. When an agent requires information outside her domain of expertise (for instance a servo designer may need both mechanical and electrical dynamic models for analysis), the information is obtained by querying the CML model. When an agent modifies some portion of the system, the agent updates the CML model so that other agents will be informed of this change. This approach is based on the agent interaction technology described in [Cutkosky, et. al, 1993]. The engineers and their tools interact through agents using the standard communications language, KQML. The communications are built on open Internet standards, TCP/IP, SMTP, and FTP. To facilitate the wrapping of commercial engineering tools we have developed the Java Agent Template (JAT). A
description of JAT is beyond the scope of this paper, but details on the beta-release of JAT can be found at http://java.stanford.edu. Briefly JAT is a package of programs written in the Java language that allow users to quickly create new software agents that communicate over the Internet. JAT facilitates construction of agents that send and receive messages in KQML and provides services including name registration, queuing and buffering of messages, connect/disconnect and security. Agents can be stand-alone programs or applets, downloaded through a standard web browser. Interfaces have been created for programs written in C++ and Lisp as well as Java.
3. Model Composition CML provides a logical description of lumped parameter continuous time systems that can be manipulated to generate machine interpretable symbolic equations. The model formulation is based on a bond graph representation of the system. Bond graphs provide a uniform framework for modeling system dynamics across multiple domains [Karnopp, et al, 1990]. CML entities are subclasses of one of the following: generalized inertias, resistances, or capacitances, flow sources, effort sources, 1-Junctions (series connections), 0Junctions (parallel connections), transformers, or gyrators. State variables are associated with capacitances and inductors. For 1-Junctions, effort variables associated with all capacitive components and flow variables of the first inductance entities become state variables. For 0-Junctions, flow variables associated with all inductive components and the effort variable of the first capacitive entity become state variables. For example, if two generalized inertias are connected in series (1-Junction), the algorithm assigns a single state variable to both. The state variable is the flow associated with the combined inductance. Systematic methodologies exist for extracting the state vector from a given bond graph model, and then building the state equations as a set of first order differential equations. Starting from the constituent relation of the components associated with state variables the equation building algorithm performs successive algebraic manipulations using constituent element relations, plus the bond graph equivalent to Kirchoff’s voltage and current laws to reduce the state equations to the form d(xi)/dt = f(x, u) where x and u are the state and input vectors and xi is a particular element of the state vector.
4. Dynamic Model Ontology To support multiple levels of abstraction we use a hybrid modeling paradigm [Mosterman, et al, 1998]. A hybrid model incorporates both continuous and discrete time. The hybrid model paradigm simplifies analysis of complex non-linear behaviors by 1) time-scale abstraction of fast non-linear behavior, and 2) parameter abstraction that ignores small parasitic component parameters. To
avoid the complex nonlinearities that arise in analysis of detailed continuous models, system behaviors are often abstracted to simpler piecewise continuous behaviors with discrete transitions between the piecewise regimes. 4.1 Hybrid Models Hybrid modeling paradigms [Mosterman and Biswas, 1998] supplement continuous system description by mechanisms that model discrete state changes resulting in discontinuities in the field description and the continuous state variables. Previous work [Mosterman, 1997, and Mosterman and Biswas, 1997] has formulated a systematic approach to hybrid modeling of dynamic physical systems based on a local switching mechanism implemented as finite state automata. The dynamically generated topology in a mode is used to translate the switching specifications to conditions based on state variables. Switching conditions may be expressed in terms of the values immediately before switching occurred, (a priori values), or in terms of the values computed by solving the initial value problem for the newly activated mode (a posteriori values). We have also established an ontology of discrete transition types in physical system behavior [Mosterman, et al, 1998]. Figure 4.1 illustrates a general hybrid system. Differential equations form a common representation of continuous system behavior. The system is described by a state vector, x. Behavior over time is specified by field f which in general is a function of time, the state, and an input vector, u. Discrete systems, modeled by a state machine representation, consist of a vector of discrete states, α. Mode changes caused by events, σ, are specified by the state transition function φ, i.e., αi+1 = φ(αi,σ) A transition may produce additional discrete events, causing further transitions. A mode change from αi to αi+1, may result in a field definition change from fα i to fα i+ 1 . Discontinuous changes in the state vector are governed by an algebraic function g, x+ = gαα i + 1 (x). Discrete mode i
changes are caused by an event generation function, γ , associated with the current active mode, αi,
γ α ( x ) ≤0 → σ j . i
4.2 Ontology for continuous time models The CML model onotology defines terms and definitions for the continuous time portion of the hybrid model paradigm. The ontology is written in the Knowledge Interchange Format (KIF) [Genesereth and Fikes, 1992]. KIF is a computer language based on first order logic and used to exchange information between disparate programs. The ontology is built from the EngMath [Olsen, 1997] and CML ontologies and is not described completely, but with sufficient detail for illustration. The continuous model consists of a state vector, input vector, output vector, a field, a set of initial conditions, and a set of model constraints or applicability conditions. The field is a set of ordinary first order differential equations
Figure 4-1: General Hybrid System that describe how the state vector evolves with respect to an independent variable. The continuous-model relation is: (continuous-model state-vector input-vector output-vector field initial-conditions constraints) state-vector defines the elements of the state vector, input-vector defines the elements of the input vector, output-vector defines the elements of the output vector. field defines the state vector field, initial-conditions defines the model initial conditions, and constraints is a
description over what range of state and input vector values the model is valid. Elements of the state, input, and output vectors are described in terms of bond graphs. All states are either an inertia flow associated with some generalized inertia, or a capacitive effort associated with a generalized spring. Inputs are either generalized voltage (force) or current (velocity) sources. state-vector is a list such that any element of the list is a state-element. Similarly, inputvector is a list such that any item of the list is an inputelement. Outputs are described in terms of input and state vector elements. field is a list that includes the declaration of an independent variable, and a differential equation for each element in the state vector. A differential equation is an equation relation in which the first element (the left hand side) is restricted to be a derivative relationship, and the second element (the right-hand side) is an expression including only numerical values and state and input vector elements. The following statements express the constraints on input and state vectors and their elements in KIF. The statement “(=> a b)” is the implication “if a then b”. Variables are preceded by a question mark and may be universally or existentially qualified. The term (stateelement ?x) is true when the variable ?x is a state-element. We omit similar constraints on the output-vector, field, initial-condition , and constraints relationships for brevity.
(=> (state-element ?x) (or (exists (?l) (and (inductance ?l) (inertia-flow ?x ?l))) (exists (?c) (and (capacitance ?c)) (capacitive-effort ?x ?c)))))
generated (in CML) on demand. This is a subject for future research. The example we describe in the following section is relatively simple and avoids these complexities.
(=> (input-element ?u) (or (source-voltage ?u) (source-current ?u)))
5. Information Exchange Examples
(=> (state-vector ?xv) (forall (?x) (=> (item ?x ?xv) (state-element ?x)))) (=> (input-vector ?uv) (forall (?u) (=> (item ?u ?uv) (input-element ?u))))
4.3 Ontology for hybrid models Hybrid models consist of the following: one or more continuous time models, a set of discrete states that define different operating modes, transitions between modes, a set of discrete events, a function that computes signal values from the continuous time state and input elements, a function that generates discrete events from these signals, and a function that computes initial conditions for the continuous time state vector when transforming from one mode of operation to another. The hybrid-model relationship is (hybrid-model discrete-states discrete-events state-transitions signals signal-events initializations continuous-models) discrete-states are states, α, described in Section 4.1, that describe the current operating mode. discretestate typically include boolean variables such as switch position. discrete-events is a list of events that cause changes in α. state-transitions describes how α changes when discrete events occur. signals is a mode dependent function of continuous time state and input variables (the function h in Figure 4.1), and signal-events define how signal outputs generate discrete events (γin Figure 4.1). initializations is a set of relationships between the a prior and a posteriori continuous time variables (g in Figure 4.1). Finally, continuous-models is a list of continuous-model relationships as described in Section 4.2. The elements of the hybrid-model relationship can be quite large. Complex systems with a large number of discrete components (such as switches, relays, etc.) have a large number of modes. In general, since these modes can change system dynamics a different continuous-model is required for each mode. Also, different functions for generating signals and signal-events may be required in each mode. Finally, a different function to re-initialize continuous state variables after a mode transition, (the function g in Figure 4.1), may be required. Assuming N modes the number of transition functions in 2 initializations is on the order of N . A general approach to this problem might be to partition the hybrid model into frequent and rare events, so that in the event of a rare or unexpected mode transition, additional signals, signal-events , and initializations functions can be
Under a project sponsored by Toshiba Corporation, we are studying agent-based methods to the design of a next generation digital versatile disk (DVD). The positioning mechanism for the laser stylus of a DVD consists of two major subassemblies: the carriage, and the pickup head (PUH), which contains the laser optics and is mounted on the carriage. The pickup head moves relative to the carriage via voice coil motors that provide precise positioning with high bandwidth but over a limited range. The PUH servo follows eccentrities and irregularites in the DVD tracks and runout in the spindle. These errors are typically less than 1 mm and desired tracking accuracy is on the order of 0.1 micro-meters. Seek motions over multiple tracks require repositioning the carriage. Additionally, while the PUH is reading the disk, the carriage slowly follows DVD tracks as they spiral inward. In the following examples, the carriage is driven by a stepper motor through a gear box, and engineering agents are required to perform analyses to determine the effect of stepper motor pulses on tracking, and to determine whether the drive train has sufficient authority to follow a desired velocity profile. 5.1
Stepper Motor Disturbances While Tracking
While the pickup head is tracking, the stepper motor moves 1 pulse every 5 to 12 seconds to follow DVD tracks. Through a gear train, each pulse moves the PUH carriage 0.1 mm. These pulses impart an acceleration disturbance on the PUH mass which must be compensated by the PUH servo. The servo designer needs a continuous time model of the stepper disturbance to verify tracking errors remain within limits. The equations of motion for a 2 phase PM stepper motor are given below [Zribi and Chiasson, 1991]: d dt d dt d dt d dt
(ia )= [va − Ria + K mω sin( N rθ )]/ L (ib )= [vb − Rib + K mω sin( N rθ )]/ L (ω )= [− K mia sin( N rθ ) + K mib cos( N rθ ) − (θ )= ω
Bω − τ L ]/ J
x = ρθ Where ia, ib are currents to the motor windings, ω, and θ are the rotor velocity and angular position, va, vb are voltage inputs, R and L are the motor winding resistance and inductance, Km is the motor torque constant (in general a function of speed), Nr is the number of steps per revolution divided by 4 (equal to the number of rotor teeth), B is the coefficient of viscous friction, J is the combined inertia of the rotor, gear train, and carriage mass, and τL is a disturbance torque. Finally, carriage displacement is related
to rotor position by the gear ratio, ρ. We assume negligible backlash. The servo designer queries the CML model for a continuous time model of PUH-Carriage. The designer wishes to import the model to perform the analysis with a local application. In the Figure 5.1, PUH-Carriage is the name of the CML model fragment that describes the PUH carriage. This term is assumed to be part of a design level ontology engineers have agreed to and formalized in the CML model. (ask-one :sender Controls :receiver CML :language KIF :reply-with continuous-model :content (get-model-continuous Carriage-Motor))
The response from the CML model is given below: (reply :sender CML :receiver Controls :language KIF :in-reply-to continuous-model :content (continuous-model (state-vector (inertia-flow x1 (inductor circuitA stepper-motor)) (inertia-flow x2 (inductor circuitB stepper-motor)) (inertia-flow x3 (+ (inertia rotor stepper-motor) (inertia gear-train stepper-motor)(* (gear-ratio geartrain stepper-motor) (gear-ratio geartrain stepper-motor)(mass carriage))) (capacitive-effort x4 (torque-constant stepper-motor))) (input-vector (voltage-source u1 (inputvoltage circuitA stepper-motor)) (voltage-source u2 (input-voltage circuitB stepper-motor)) (currentsource u3 (disturbance-torque rotor stepper-motor)) (output-vector (output y1 x1) (output y2 x2) (= y3 x3) (= y4 (* x4 (gear-ratio gear-train stepper-motor))) (field (independent-variable t) (diff-eq (D/Dt x1) (/ (- (+ u1 (* 8.96e-3 x3 (sin (* 50 x4)))) (* 2.1 x1)) 5.5e-4) (diff-eq (D/Dt x2) (/ (- (+ u2 (* 8.96e-3 x3 sin (* 50 x4)))) (* 2.1 x2)) 5.5e-4) (diff-eq (D/Dt x3) (/ ((* 8.96e-3 x2 (cos (* 50 x4)))(+ (* 8.96e-3 x1 (sin (* 50 x4))) (* 3.e-5 x3) u3)) 3.1e-7) (diff-eq (D/Dt x4) x3)) (initial-conditions (= t 0) (= x1 0) (= x2 0) (= x3 0) (= x4 0) (= u1 0) (= u2 0) (= u3 0)) (constraints (and (>= u1 -10) (= u2 -10) (= x1 -.5) (= x2 -.5) (= x3 -350) ( e1 (= alpha1 (position switch1 circuitA steppermotor)))) (transition t2 (=> e2 (= alpha2 (position switch1 circuitB steppermotor))))) (signals null) (signal-events null) (initializations (=> t1 (=> (= alpha1 positive) (init u1 10))) (=> t1 (=> (= alpha1 off) (init u1 0))) (=> t1 (=> (= alpha1 negative) (init u1 –10)))(=> t2 (=> (= alpha2 positive)(init u2 10))) (=> t2 (=> (= alpha2 off) (init u2 0))) (=> t2 (=> (= alpha2 negative) (init u2 –10)))) (continuous-model (state-vector (inertia-flow x1 (+ (inertia rotor stepper-motor) (inertia geartrain stepper-motor) (* (gear-ratio gear-train stepper-motor) (gear-ratio gear-train stepper-motor) (mass carriage))) (capacitive-effort x2 (torque-constant stepper-motor))) (input-vector (voltage-source u1 (inputvoltage circuitA stepper-motor)) (voltage-source u2 (input-voltage circuitB stepper-motor)) (currentsource u3 (disturbance-torque steppermotor)) (output-vector (output y1 x1) (output y2 (* x2 (gear-ratio gear-train steppermotor))) (field (independent-variable t) (diff-eq (D/Dt x1) (* 2.89e4 (- (+ (* 0.48 u2 (cos (* 50 x2))) (* 4.27e-3 x1 (sin (* 50 x2)) (- (cos (* 50 x2)) 1))) (+ (* 0.48 u1 (sin (* 50 x2))) (* 3.e-5 x1) u1))) (diff-eq (D/Dt x2) x1)) (initial-conditions (= t 0) (= x1 0) (= x2 0) (= x3 0) (= x4 0)) (constraints (and (>= u1 -10) (= u2 -10) (= x1 -350) (
