12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract




Скачать 243.02 Kb.
Название12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract
страница1/5
Дата18.01.2013
Размер243.02 Kb.
ТипДокументы
  1   2   3   4   5

Bahill, A. T. and Szidarovszky, F., Comparison of dynamic system modeling methods,

Systems Engineering, 12(3):183-200, 2009.

Comparison of Dynamic System Modeling Methods

A. Terry Bahill

Ferenc Szidarovszky

Systems and Industrial Engineering

University of Arizona

Tucson, AZ 85721-0020

ABSTRACT

This paper compares state-equation models to state-machine 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 state-space approach of Linear Systems Theory, set-theoretic 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: Model-based systems engineering, UML, SysML, linear systems theory,

1. INTRODUCTION

System design can be requirements based, function based or model based. Model-based 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 Model-based System Engineering, although the phrase Model-based System Design was in the title and topics of Rosenblit’s [1985] PhD dissertation. Model-based systems engineering depends on having and using well-structured 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. State-equation 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, state-machine 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 state-equation 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 state-space techniques bloomed and they are still the dominant method [Szidarovszky and Bahill, 1998]. Typical state-equation 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 state-machine 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 state-machine systems.

The methods that will be used in this paper to model these systems include the state-space approach of Linear Systems Theory (for both continuous and discrete systems) [Szidarovszky and Bahill, 1998], Wymorian set-theoretic 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 state-equation systems and uses as an example a simple spring, mass, dashpot system. Section 3 examines state-machine systems and uses as an example a simple spelling checker. Most real-world systems are modeled as either state-equation systems or state-machine 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 H2O 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. STATE-EQUATION SYSTEMS

First, we will look at an example from the field of Linear Systems Theory. In particular, we will use a method called the state-space 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 state-space 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 state-equation systems [Buede, 2000].



Figure 2. Block diagram of the SpringMassDashpot system.

2.2. Discrete-time Systems

Unlike the previous continuous-time 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 set-theoretic 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 state-equation 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 software-centric 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 top-down 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 top-level 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 highly-complex highly-parallel 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 IEEE-Std-1471-2000.

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.

Table I. Explanation of role names

Usage name, or part name, or Role

Explanation

k1

Role name of one particular spring

m1

Role name of one particular mass

b1

Role name of one particular dashpot

af1

Role name of one particular applied force

firstEq

First state equation

secondEq

Second state equation

outputEq

Output equation

smd

Role name for the SpringMassDashpot








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 <> blocks. These state equations for this smd Analysis Context may have originally been specified in an analysis library. This enables the same equations to be reused for many different contexts. The arrows with solid (black) diamond endings are composition relationships, which means that the smd Analysis Context comprises the FirstStateEquation, the SecondStateEquation and the OutputEquation. The arrow with a white (open) diamond head indicates an aggregation relationship between the smd AnalysisContext and the SpringMassDashpot block from Figure 3. In the parameter lists, on the left of the colon are the parameters, or names as they appear in the equation, and on the right of the colon are their units.

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 state-space 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 dx1/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 x1 start with the initial position and integrate x2 using Adams-Moulton or Runge-Kutta 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 state-space 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. STATE-MACHINE SYSTEMS

3.1. Spelling Checker

State-machine systems are studied in traditional digital logic books such as Katz [1993] and in contemporary object-oriented books such as Blaha and Rumbaugh [2005]. The following is problem 3-11 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 3-11 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 spelling-rule violation, it turns on the error signal and waits for Author to respond.

2. Author resets the system [repeat at step 1].
  1   2   3   4   5

Похожие:

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconM. A. University of Arizona, Tucson (AZ), 1983. Employment

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconAtilim university faculty of engineering department of industrial engineering course description and practice

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconPrinciples of Modeling, Modeling techniques, Modeling classification, Limitation of Mathematical Modeling, Role of mathematical modeling in modern Engineering

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconModeling & Tools: Information Systems Using the Knowledge Pyramid to Characterize Systems J. N. Martin, The Aerospace Corporation Modeling & Tools: Multiple Sectors

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconPhD: University of Sarajevo, Sarajevo, Bosnia-Herzegovina, June 1, 1991 Thesis: “Systems Approach to Modeling of Integrated Decision Support Systems” msc: University of Sarajevo, Sarajevo, Bosnia-Herzegovina, June 27, 1987

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconDepartment of Bio-Industrial Mechatronics Engineering, National Taiwan University

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract icon2001 Systems Engineering Capstone Conference • University of Virginia

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconSystems Engineering: a new Approach to Complex it-based Technological Systems in Engineering Education

12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconSystem of design dokuments for construction. Elements оf sanitary engineering systems sumbols
Система проектной документации для строительства. Условные обозначения элементов санитарно-технических систем
12(3): 183-200, 2009. Comparison of Dynamic System Modeling Methods A. Terry Bahill Ferenc Szidarovszky Systems and Industrial Engineering University of Arizona Tucson, az 85721-0020 abstract iconAuburn University, Auburn Alabama Major: Industrial Engineering in Manufacturing gpa: 0 0 Thesis: Learning optimization for cpn-based control of robot position. Bachelor of Science (B. S.), 1982

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница