Скачать 243.02 Kb.

Bahill, A. T. and Szidarovszky, F., Comparison of dynamic system modeling methods, Systems Engineering, 12(3):183200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, AZ 857210020 ABSTRACT This paper compares stateequation models to statemachine models. It compares continuous system models to discrete system models. The examples were designed to be at the same level of abstraction. This paper models these systems with the following methods: the statespace approach of Linear Systems Theory, settheoretic notation, block diagrams, use cases, UML diagrams and SysML diagrams. This is the first paper to use all of these modeling methods on the same examples. Keywords: Modelbased systems engineering, UML, SysML, linear systems theory, 1. INTRODUCTION System design can be requirements based, function based or model based. Modelbased system engineering and design has an advantage of executable models that improve efficiency and rigor. One of the earliest developments of this technique was Wymore’s [1993] book entitled Modelbased System Engineering, although the phrase Modelbased System Design was in the title and topics of Rosenblit’s [1985] PhD dissertation. Modelbased systems engineering depends on having and using wellstructured models that are appropriate for the given problem domain. There are two types of systems: static and dynamic. In a static system, the outputs depend only on the present values of the inputs. Whereas, in a dynamic system the outputs depend on the present and past values of the inputs [Botta, Bahill, and Bahill, 2006]. In computer design, these two basic types of systems are called combinational and sequential. Combinational systems do not require memory devices, hence they are called memoryless. Sequential systems require memory to capture the state behavior. In combinatorial systems, the output depends only on the present inputs. Whereas, in sequential systems the output depends on the sequence of previous inputs. In mechanical engineering, these two types of systems are called static and dynamic. Static systems are described with algebraic equations and the outputs depend only on the present values of the inputs. Whereas, dynamic systems are described with differential or difference equations and the system behavior depends on the history of the inputs. This paper only considers dynamic systems. The purpose of this paper is to compare and contrast several systems engineering methods for modeling two different types of dynamic systems and eventually to explain systems composed of both types of systems. The motivation for this paper was to show how the SysML diagrams fit in with traditional modeling methods. The paper is intended to assist a modeler in understanding the pros and cons of different modeling methods as they apply to different classes of problems. Some dynamic systems are modeled best with state equations while others are modeled best with state machines. Stateequation systems are modeled with differential or difference equations. For example, a baseball’s movement can be modeled with state equations for position, linear velocity and angular velocity all as functions of time. In contrast, statemachine systems focus less on physical variables and more on logical attributes. Therefore, these systems have memory and are modeled with finite state machines. Most digital computer systems are modeled best with state machines. Newton [1687] was the first to apply equations to model and understand stateequation systems. Much later, during World War II, the use of feedback produced a dramatic improvement in system design. In this period, because the primary purpose of dynamic system design was to stabilize the firing of guns on naval ships, the field was called fire control systems. After the war the frequency response techniques for solving differential equations were developed. Later, in the 1960s, the statespace techniques bloomed and they are still the dominant method [Szidarovszky and Bahill, 1998]. Typical stateequation systems include analog computers as well as electrical, mechanical, hydraulic, pneumatic, thermal, economic, chemical and biological systems. Turing [1936] was the first to model and explain statemachine systems. His Turing Machine (a state machine with a memory) could solve all solvable sequential logic problems. The field came to be known as finite state machines. The digital computer is the preeminent example of statemachine systems. The methods that will be used in this paper to model these systems include the statespace approach of Linear Systems Theory (for both continuous and discrete systems) [Szidarovszky and Bahill, 1998], Wymorian settheoretic notation [Wymore, 1993], block diagrams, use cases, UML diagrams [OMG UML, 2007; Fowler, 2004] and SysML diagrams [OMG SysML™, 2007; SysML, 2007]. In designing complex systems, such as an airplane or an automobile, it might be necessary to use all of these methods together. Some parts might be continuous while others are discrete. Some might be modeled best with UML diagrams and others with block diagrams, depending on the problem and the backgrounds of the engineers involved. So although one system could use all of these methods, in this paper we will discuss each method separately. Section 2 of this paper examines stateequation systems and uses as an example a simple spring, mass, dashpot system. Section 3 examines statemachine systems and uses as an example a simple spelling checker. Most realworld systems are modeled as either stateequation systems or statemachine systems. However, there are physical systems where both types of models are useful together: for example, systems using water, because the heat flow equations are different depending on whether H_{2}O is in its liquid, solid or gas state. Section 4 presents a problem where the selection of the preferred modeling approach is not clear. 2. STATEEQUATION SYSTEMS First, we will look at an example from the field of Linear Systems Theory. In particular, we will use a method called the statespace approach. 2.1. Continuous Systems This section is based on Szidarovszky and Bahill [1998] and Ogata [2004]. Consider the mechanical system illustrated in Figure 1. Assume an ideal spring, mass and dashpot, and frictionless wheels. Assume initial conditions are zero and do a small signal analysis. Create a statespace model for this system. Figure 1. SpringMassDashpot system. In general, the systems engineer gets models from the domain experts. For this system, assume we are given these models. We will use SI units: the spring constant (k) has units of N/m, the damping coefficient (b) has units of N·s/m and the mass (m) has units of kg. Now, let us define the input, output and states. The force f(t) is applied to the system and it produces a displacement x(t). Define f(t) as the input u and the displacement x as the output. From the diagram, which can be rewritten as . The system is of second order, so we need to select two state variables. Let us choose the position x and the velocity. So that we have The state equations then become Rewriting the state equations and the output equation in matrix form, we obtain These equations are in the standard form of with Block Diagrams Block diagrams, as shown in Figure 2, are used to illustrate stateequation systems [Buede, 2000]. Figure 2. Block diagram of the SpringMassDashpot system. 2.2. Discretetime Systems Unlike the previous continuoustime system, for physical systems containing computers we are only interested in the system’s behavior at discrete time intervals. Many other physical systems can also be modeled as discrete systems [Wymore, 1993], if we assume a fast enough sampling rate. For discrete systems, we have as a good approximation If we write this as There are also systems that are inherently discrete without computer control. For instance, if you borrowed dollars from a bank and agreed to pay interest of r percent per month and make n monthly payments of amount P, then the balance, B, that you will owe can be written as , where h is one month. Stability of continuous and discrete systems It is well known that if you start with a continuous system and add sensors, a digital processor and actuators to make it discrete, then the discrete system will be closer to instability than the continuous system. Consider a continuous system and its discrete counterpart . For the continuous system the coefficient matrix is , while for the discrete system it is , where h is the step size in the time scale. Let be the eigenvalues of , then the eigenvalues of the corresponding discrete system are . Assume now that is an eigenvalue of . The condition for asymptotic stability is that be negative. The corresponding condition for the discrete system is that be inside the unit circle, which happens if and only if . In summary, to be stable (i) for a continuous system (ii) for a discrete system . Notice that (ii) implies (i). If (ii) is true, then , that is, which can be written as . However, notice that (i) does not imply (ii). So the asymptotic stability of the discrete system implies that the corresponding continuous system is also asymptotically stable. However, the asymptotic stability of the continuous system does not imply asymptotic stability of the corresponding discrete system for all h. We usually choose h to be small. But how small should it be? Assume that . The discrete system will be asymptotically stable if h is sufficiently small. Condition (ii) can be rewritten as , that is or , where the right hand side is positive. In the case of nonlinear systems we have the same conclusions, except instead of the matrix , we use the Jacobian of the continuous system. 2.3. Wymorian Notation Next, we can put this SpringMassDashpot system into Wymorian settheoretic notation [Wymore, 1993]. Wymore uses, for example, the symbol p2 for a particular value of the second input, x2 for a particular value of the second state variable and y2 for a particular value of the next state of the second state variable, etc. Thus, Wymore’s y is not the same as the output y in the above equations. Comments are enclosed in /* markers */. Let us name the system Zsmd. Then Zsmd = {SZsmd, IZsmd, OZsmd, NZsmd, RZsmd} where SZsmd = RLS ^ 2, /*There are 2 state variables and they take values from the set of real numbers,.*/ IZsmd = RLS, /*The input values will be real numbers.*/ OZsmd = RLS, /*The output values will be real numbers.*/ NZsmd = {((x, p), y): x SZsmd; p IZsmd; y SZsmd; if x = (x1, x2) then y = [y1, y2] = [(x1 + hx2), ( hkx1/m + (1  hb/m)x2 + hp/m)]}, /*The state equation. Remember p is a value of the input.*/ RZsmd = S1Zsmd. /*The output is the first state variable.*/ Please note that with Wymorian notation a system can be described with a dumb typewriter: it does not require a computer, a word processor, a drawing program, an equation editor, subscripts, superscripts, or even italic and boldface fonts. 2.4. UML Representation There are no appropriate UML diagrams for stateequation systems. 2.5. OMG SysML™ Model The OMG Systems Modeling Language (OMG SysML™) was created as systems engineering extensions to the Unified Modeling Language (UML). SysML reduces UML's softwarecentric restrictions and adds two new types of diagrams: Requirement diagrams to help manage requirements and Parametric diagrams to help with performance and quantitative analysis. SysML was designed to model large complex systems such as an automobile. Requirement diagrams are used to efficiently capture functional, performance and interface requirements, and Parametric diagrams are used to precisely define performance and mechanical constraints such as maximum acceleration, curb weight, air conditioning capacity and interior cabin noise. SysML also enhanced the semantics and greatly increased the usage of UML’s Activity diagram, Block Definition diagram and Internal Block diagram. This section is written at the nuts and bolts level. It shows complete, detailed use of SysML constructs. However, it does not present topdown descriptions of large complex systems. It does not address the massive concurrency and interfaces of large complex systems. Most examples of large complex systems do not give a complete model at the nuts and bolts level. They usually discuss the toplevel and then drive down to the bottom on only a few traces: they only show slivers of the whole system. A nice example that spans the whole hierarchy is the Hybrid SUV example [OMG SysML, 2007; Friedenthal, Moore and Steiner, 2007]. It is impossible to show a complete example of a highlycomplex highlyparallel system. Therefore, this paper does not discuss the hierarchy of systems: this paper models only simple systems, but its coverage is complete. All of the examples are deliberately at the same level of abstraction [Mellor, Scott, Uhl and Weise, 2004; Bahill, Szidarovszky, Botta and Smith, 2008]. SysML is supported by the OMG XMI 2.1 model interchange standard for UML 2 modeling tools. It has also been conceptually aligned with the ISO 10303 STEP AP233 (http://www.ap233.org/) data interchange standard for systems engineering tools. SysML supports model management concepts that include views and viewpoints, which extend UML's capabilities and are architecturally aligned with IEEEStd14712000. The SysML can use state equations to specify constraints on properties of the system and its environment using the block definition diagram (bdd) and the parametric diagram (par) [OMG SysML, 2007]. First, we define the input and output of our SpringMassDashpot system. The input is a flow port: energy flows through this port. It is the force applied to the mass. The output is the position of the mass: it is a standard port. Inputs and outputs are often shown on an internal block diagram (ibd). Next, we want to show the components of our SpringMassDashpot system. We do this in a block definition diagram, as shown in Figure 3. The block for each component can be further elaborated to shows its functions, interfaces and properties. In Figure 3, we only see examples of some of the properties of the blocks, such as the position of the Mass. The applied force is labeled Fixed Reference. Figure 3. Block definition diagram (bdd) showing the components of the Mechanical System. In SysML diagrams the header has four fields: the type of diagram (in this case, bdd standing for block definition diagram), the type of model element that the diagram represents (package), the name of the model element described in the diagram (Mechanical System) and the fourth field is user defined and can, for example, state the purpose of the diagram (Components of SpringMassDashpot system). The arrow with a black diamond head indicates a composition relationship. Table I explains the roles and abbreviations shown in Figures 3 to 7.
Next, we want to present the constraints or equations that describe our mechanical system. Figure 4. Block definition diagram (bdd) defining constraints for the mechanical system. The bdd of Figure 4 defines the state equations in the < Now we want to show how these general equations can be instantiated to a particular SpringMassDashpot system. The top part of Figure 5 is based on the blocks of Figure 3 and the bottom part is based on the constraints of Figure 4. The interconnections show the bindings of the parameters. Figure 5. Parametric diagram (par) using nested part notation showing the statespace equations for a particular SpringMassDashpot system. The parametric diagram of Figure 5 shows how the parameters from each of the equations can be bound together to create a complex network of equations. The constraint blocks that were specified in the bdd of Figure 4 are bound to one another to create a network of the state equations that bind the parameters together. Although not explicitly shown here, the parametric diagram enables the properties of the SysML design models, such as the spring constant of the spring, to be unambiguously associated with the parameters of the equations. In this way, the “system design model” and the “system analysis model” can be fully integrated. The full power of this approach becomes apparent as many different analysis models related to performance, reliability, mass properties, etc. are integrated with the system design model that may be defined via activity diagrams, internal block diagrams, etc. Each property that is constrained by the parametric equations may include values, including probability distributions, with units and dimensions. The dimension represents the fundamental quantity type. For example, the width of an object may have a dimension of length and units of feet or meters. The assignment of units and dimensions is accomplished by typing the property with a value type that includes the applicable dimensions and units. A fully compliant SysML tool can check to confirm the compatibility of the units and dimensions of its properties, and avoid significant issues that have occurred when the units have been improperly matched. A parametric diagram is not an equation solver like MATLAB or Mathematica. It does not define independent and dependent variables. It merely shows bindings, or equality. For example, the parametric diagram of Figure 5 shows that dx_{1}/dt is equal to the velocity of the mass. It does not tell you how to solve for it. In contrast, an equation solver might state something like, to update x_{1} start with the initial position and integrate x_{2} using AdamsMoulton or RungeKutta integration routines. Figure 6 presents an alternative parametric diagram with the same content but a different notation. Figure 5 uses nested part notation. For example, the parameter b in the second state equation is bound to the dampingCoef, which is in turn drawn as a box inside of the Dashpot, which is drawn as a box inside of the SpringMassDashpot. Whereas Figure 6 uses dot notation, which specifies the path down through the nested part hierarchy to the property. For example, ‘smd.b1.dampingCoef’ specifies that the dampingCoef is a property of the Dashpot ‘b1’, which is part of the SpringMassDashpot ‘smd’. The abbreviations smd and b1 were introduced in Figures 3 and 4. These part names are separated with periods or “dots.” Figure 6. Parametric diagram (par) using dot notation showing the statespace equations for a particular SpringMassDashpot system. State equations are always tightly coupled: they are usually thought of as a matrix. In SysML, constraints can be composed of more than one equation. Therefore, our bdd could be composed as shown in Figure 7. Figure 7. Block definition diagram (bdd) for the mechanical system, with two equations in one constraint. 3. STATEMACHINE SYSTEMS 3.1. Spelling Checker Statemachine systems are studied in traditional digital logic books such as Katz [1993] and in contemporary objectoriented books such as Blaha and Rumbaugh [2005]. The following is problem 311 from Chapman, Bahill and Wymore [1992]. Design a system for detecting spelling errors. Or more simply, create a state machine to implement the spelling rule "i before e except after c." If a word violates this rule, your system should stop processing words and produce an error signal. When the human acknowledges the mistake and turns off the error signal, your system should resume processing words. For example, the words piece and receive are correct so your system should continue processing words. However, weird violates this rule, so your system should stop and wait for human action. You may assume that bizarre sequences such as "ceie" will go undetected and that Professor Lucien Duckstein will not use it. Describe your inputs, outputs and states. Label your states with meaningful names. Assume the system starts in a reset state. State all assumptions you make. Finally, describe how you will test your system. 3.2. The Use Case Approach Name: Check Spelling Iteration: 1.4 Derived from: Problem 311 of Chapman, Bahill and Wymore [1992] Brief description: The system scans a document and implements the spelling rule "i before e except after c." Added value: Author gets a more professional document. Level: Low Scope: The document being processed Primary actor: Author Supporting actor: Document (We are not using a dictionary.) Frequency: Many times per day Precondition: A document must be open. Trigger: Author asks the system to check the spelling. Main Success Scenario: 1a. System scans the document one letter at a time. If it finds a spellingrule violation, it turns on the error signal and waits for Author to respond. 2. Author resets the system [repeat at step 1]. 