APPLICATION OF OBJECT-ORIENTED TECHNIQUES TO LINEAR

CONTINUOUS CONTROL SYSTEMS SIMULATION

by

MOSHE GOTESMAN, B.S.A.E.

A THESIS

IN

COMPUTER SCIENCE

Submitted to the Graduate Faculty of Texas Tech University in

Partial Fulfillment of the Requirements for

the Degree of

MASTER OF SCIENCE

Approved

Accepted

May, 1994

()OJ

7.3 lqqi/

ACKNOWLEDGEMENTS /'JD. I c'f.v

I want to thank all the people who helped me in this work. In particular

I want to express my gratitude to my committee chairman Dr. William Marcy.

Dr. Marcy has guided me in this work with an excellent combination and

balance of professional expertise and strong support and help throughout this

work. It is mainly thanks to this support that this work was successfully

completed.

I also want to thank Dr. Desrosiers and Dr. Oldham for their excellent

advice and remarks during this work. I also thank the other faculty members

whose advice I sought occasionally. I was never disappointed.

Finally, I want to thank my wife Pnina and children: Alon, Ella and

Oren who endured this period to enable me to complete this work.

11

TABLE OF CONTENTS

ACKNOWLEDGEMENTS

ABSTRACf

LIST OF FIGURES

CHAPTER

I. INTRODUCTION

1.1 Background

n.

1.1.1 Control Systems

1.1.2 Object-Oriented Simulation

1.2 Rationale for Proposed Research

1.3 Research Objectives

1. 4 Research stages

1.4.1 Literature review

1.4.2 Design

1.4.3 Implementation

1.4.4 Testing

1.4.5 Conclusions and summary

1.4.6 Future work

LITERATURE REVIEW

2.1 Object-Oriented Development

2.2 Simulation - General

2.3 Object-Oriented Simulation

2.4 Discrete Event Simulation

2.4.1 General Environments

2.4.2 Manufacturing

2. 4. 3 Queuing Theory

2.4.4 Miscellaneous

2.5 Continuous System Simulation

2.5.1 General

11

v

VI

1

1

1

I

2

4

5

5

5

6

6

7

7

8

8

8

12

13

13

13

14

14

14

14

2.5.2 Object-Oriented Continuous Systems Simulation 15

m AmL~IS U 3.1 General 26

3.2 Specification 26

... 111

3.3 Analysis 26

3.3.1 Quality Factors 27

3.3.2 Numerical Accuracy 27

3.3.3 User Interface 27

3.3.4 Functionality 28

3.3.5 Simulation 29

IV. DESIGN 30

4.1 General 30

4.2 Entity Relationship Diagram 30

4.3 Object Modeling Technique ( OMT) Diagram 30

4.4 Structure Chart 30

4.5 Hierarchy Structure 34

4.6 Simulation 35

v. IMPLEMENTATION 36

5.1 Introduction 36

5.2 Overview 36

5.3 Input File 37

5.3.1 Preparing a Problem for Simulation 37

5.3.2 Input File Structure 38

5.4 Output 40

5.5 External Input File 41

5.6 Classes 41

5.6.1 General 41

5.6.2 Class Dpole 41

5.6.3 Class DynamicElement 42

5.6.4 Class Extin 43

5.6.5 Class Gain 44

5.6.6 Class Integ 44

5.6. 7 Class Spole 45

5.6.8 Class System 45

5.7 User Interface 47

5. 7.1 General 47

5. 7.2 DOS User Interface 48

5. 7.3 MS WINDOWS User Interface 48

IV

VL TESTING 49

6.1 General 49

6.2 Reference Program 49

6.3 Correctness and Accuracy Testing so 6.4 Software Quality Testing 53

6.4.1 General 53

6.4.2 Selection of Testing Methodology 53

6.4.3 Application of Halstead's Metrics System 57

6.5 Analysis of Results 59

6.5.1 General 59

6. 5.2 Correctness and Accuracy 59

6.5.3 Software Quality 60

VII. Future Work 65

7.1 General 65

7.2 Extensions to CONSIM 65

7 .2.1 Extending the Class Library 65

7 .2.2 User Interface 65

7.2.3 Numerical Aspects 66

7.2.4 Multiple Input Multiple Output Systems 66

7 .2.5 Non-Linear Simulation 66

7.2.6 Discrete Systems 66

7.3 Extensions to Control Systens Engineering 66

vm. SUMMARY 67

REFERENCES 68

APPENDIX

A. CONSIM - REQUIREMENTS DEFINITION 75

B. CONSIM CODE LISTING 77

C. NUMERICAL INTEGRATION ALGORITHM 104

D. APPLICATION OF HALSTEAD'S METRICS 106

E. THE GRAPHICAL USER INTERFACE 112

v

ABSTRACT

This work describes a comparison of a control systems simulator written

with object-oriented techniques, to a simulator that was written, using the

procedural style. The objective of the research was to explore the advantages

that are expected to be gained when employing the object-oriented

methodology, as applied in control systems simulators.

The object-oriented simulator was written in C++. The program's

quality was compared to that of a high quality, commercial, procedure-oriented

simulator: The Control Systems Toolbox from MAlLAB. Halstead's software

quality metrics were used for the comparison.

The comparison between the programs showed that the object-oriented

program had an advantage over the procedure-oriented reference program in

the quality factors that were measured.

VI

LIST OF FIGURES

2.1 Simulation Categories 11

2.2 Hierarchy for a Control System 18

2.3 Simulator- Object [Vangheluwe 1989] 19

2.4 The General Structure of the NSL Program 22

2.5 Class Hierarchy of the Simulator [Park 1991] 22

2.6 Hierarchy Diagram [Ortiz 1992] 24

2.7 The Structure of a Plant and its Place in the Organic World

[Sequeira 1991] 25

4.1 Entity Relationship Diagram 31

4.2 Object Model Diagram 32

4.3 Structure Chart 33

4.4 Hierarchy Structure 34

6.1 Example of a Control System 51

6.2 Output of Simulators 52

VII

1.1.1 Control Systems

CHAPTER I

INTRODUCfiON

1.1 Background

Control systems development is a well established discipline. Use of

control systems actually began as early as ancient Greece [Dorf 1980]! The

actual formal development of the theory of control systems started during WW

II. Since then a very great deal of work has been done both on the theoretical

level and on the practical level. As a mature engineering discipline. the theory

is well developed in all the •• classicar· phases of an engineering discipline.

namely: specification, analysis, design, simulation. implementation, testing and

maintenance.

As in most scientific and engineering areas. computers became more

and more useful in control systems engineering. which is a discipline involving

both highly abstract analysis and practical engineering techniques. The use of

computers in control system engineering is a very powerful and popular tool. It

is only natural therefore that computers were used in this discipline since the

beginning of the computer era. As computer power increased in time. the use of

it for control system engineering became also more intensive. Today. computers

are a major tool in this discipline and for complex systems it is practically

impossible to work without them.

1.1.2 Object-Oriented Simulation

As systems become very large and complex. simulation becomes a

major phase in the development process of control systems. Direct testing of

such systems at the development stage is usually impractical due to the high

cost and complexity involved. Simulation in such cases remains as the only tool

for ••testing" the systems before actual implementation. As a result. great

efforts are invested in constructing good simulation programs. Writing

simulation programs is today a basic and essential skill of any control systems

engineer.

1

Under such circumstances, it is natural that a great effort was also

directed to developing general-purpose simulation packages. Such packages

provide the engineer with a powerful environment Packages of varying

complexity can be found. Starting with basic packages, which are usually used

for teaching and practicing [Golten and Verwer 1989), these systems can

simulate basic linear Single Input Single Output (SISO) control loops. They have

graphical capabilities to facilitate classical design techniques such as Bode.

Nyquist, Root-Locus, etc. At the high end of the line, there are the full blown

commercial packages [Mitchell and Gauthier 1987; Grace 1990], that can

perform simulations of large and complex systems. They enable the users to

incorporate their own blocks of code in the package, communicate and interact

with other packages and perform non-linear simulation and analysis.

Traditionally, control system simulation programs and packages were

written in the procedure-oriented paradigm. As the object-oriented paradigm

appeared, simulation packages also began to appear, using these techniques.

The importance that the control systems engineering community places on

object-oriented simulation is also reflected in regular conferences that were

established on this subject [Ege 199L Guasch 1990]. Various branches of

control system simulation are being extensively explored, such as: process

control, discrete event control, etc. However, the vast majority of work done in

this area is not in continuous control systems simulation. In fact, an amazingly

small number of works is published on this subject [Bruck 1988]. In the

literature review in this work, less than 10 sources were found that deal with

dynamic systems simulations and only two directly addressed control systems.

This leaves the subject open for research.

1. 2 Rationale for Proposed Research

The object-oriented paradigm has emerged with the intention of

introducing an improved software development paradigm as compared to the

"traditional" procedure-oriented paradigm. This was and still is the

justification for using object-oriented techniques in any software development

problem. Indeed, experience gained with this technique has demonstrated that

this paradigm is usually superior to the procedure-oriented style, particularly

for large and complex projects. Many issues of software development, that were

2

problematic in the procedure-oriented developmen~ found a better solution in

the object-oriented approach. Among these we can mention issues such as:

development costs, reusability, data hiding and encapsulation. extendability,

maintenance etc.

Object-oriented techniques are considered to be particularly suitable

for problems involving real (physical) objects, since this approach "visualizes'"

the problem components as objects. Control systems are a classical .. physical

objects" type of system. Many components of a control system such as: sensors,

controllers, actuators, etc., are "physical." This nature of a control system lends

itself naturally to the object-oriented approach. Thus it is reasonable that the

advantages of the object-oriented approach can be fully exploited when

applied to control systems simulation. There is therefore a strong basis for

assuming that using the object-oriented style for control systems simulation

will be superior to the procedure-oriented approach. Some of the advantages

anticipated are:

a. Data hiding and encapsulation. Modern control systems tend to be very

large and complex, reflecting the size and complexity of the dynamic

plants they control (spaceship, space stations, satellites, aircraft, missiles,

radar systems, advanced medical instrumentation. etc.). Almost

invariably such large control systems are written by teams of

programmers, where each member of the team writes a portion of the

program. The advantages of data hiding and encapsulation in such cases

are well known and appreciated.

b. Maintainability. This is always a problematic issue because it ties the

developing agency to the customer for as long as the program is used

(which can be many years.) As time passes, the tie weakens because the

infrastructure that existed during the development phase degrades

(hardware changes, things get lost, data are forgotten. team members

leave, etc.) Systems developed with object-oriented techniques promise

better maintainability. In ideal cases, even the customer can perform the

maintenance.

c. Testability. Complex control systems can always be viewed as aggregations

of elementary control systems. This principle can be applied repeatedly to

3

lower and lower levels of the system~ down to the single transfer function

level. In the object-oriented approach~ testing of each of these levels

individually can be easily applied, independently of the system they are

embedded in. This also facilitates the independence of individual blocks,

which contributes to modularity.

d. Modularity. In object-oriented design~ control system components and

sub-systems can easily be modeled as independent blocks. Complex

control systems can then be composed by combining such blocks. Also,

blocks in a control system can be replaced with other~ more advanced

blocks. For example~ blocks performing numerical computations (such as

integration~ etc.) can be replaced by better algorithms without need to

change other parts of the program.

e. Expandability. When using object-oriented techniques~ it is easy to add

blocks to a given simulation package to extend the scope of its

applicability. In a control system simulator~ blocks can be added to extend

the package's capability, such as adding basic transfer functions and

non -linear block types.

f. Reusability. The modular nature of a control system simulation built with

object-oriented techniques generates closed~ independent blocks of code.

Each block can represent an elementary control component or sub-system.

These independent blocks can be reused by embedding them in various

programs that are associated with control systems engineering~ such as

simulators~ CAD. testing utilities. etc.

All the above considerations make it very attractive to write continuous

control systems simulations using the object-oriented paradigm.

1.3 Research Objectives

Two objectives are defined for this research:

1. Develop a class library for simulating linear. continuous control systems;

2. Compare the object-oriented implementation of linear control systems to

the procedure-oriented techniques.

4

Based on these objectives, this work attempts to demonstrate two

things:

1. It is feasible and practical to write a control systems simulation package,

using the object-oriented techniques.

2. Using the object-oriented approach for building control systems

simulations is advantageous as compared with the procedure-oriented

approach. Issues such as: encapsulation, maintainability, testability.

modularity, reusability, etc. are addressed to demonstrate the advantages

of the object-oriented technique.

1. 4 Research Stages

1.4.1 Literature Review

The literature review covers the following subjects:

a. Background on object-oriented techniques.

b. Background on object-oriented simulation.

c. Specific examples of object-oriented simulations 1n vanous disciplines,

and

d. Control systems using object-oriented techniques.

1.4.2 Analysis and Design

A class library named "CONSIM'' was designed for continuous linear

control systems simulation. The design includes standard object-oriented

design stages, such as entity-relationship diagram, structure chart, hierarchy

diagrams, etc.

1.4.3 Implementation

The above class library was implemented. The library was written in

Borland C++ (MS-DOS), version 3.1. The package was built gradually. Each

stage was tested individually and then incorporated into the program.

5

1.4.4 Testing

1.4.4.1 Reference Simulation Program

For testing the validity and accuracy of the results of the simulation

class library, a known "standard" reference "procedure-oriented" program was

required. This work uses the CONTROL TOOL-BOX from MATLAB as

reference.

1.4.4.2 Test Cases

Several test cases are used to test the simulation capabilities and

characteristics of the program:

Individual blocks. Individual blocks simulate standard basic transfer

functions such as: integrator. pole. complex poles, etc. Each block was

tested using standard inputs: Impulse, step and ramp.

Full system. A full control system test case was selected from open

literature. This case was simulated by both the reference program

(MATLAB) and the class library.

1.4.4.3 Presentation of Output

In this work, the computation results are presented as graphs of the

object-oriented program output against that of the reference program.

1.4.4.4 Software quality measurement

Halstead's metrics system for software quality was used to compare the

quality of the class library to that of the reference program.

1.4.5 Conclusions and Summary

The analysis of the results of the tests that were applied to the programs

verified that the research objectives were met Conclusions were drawn as to

weather developing control systems simulators using object-oriented techniques

is advantageous compared with the procedure-oriented style.

6

1. 4. 6 Future Work

The following issues are considered for future work:

a. Expanding to the non -linear regime.

b. Advanced user interface (iconic-graphical).

c. Using the above work as basis for performing other stages of control

system development, such as design, implementation, maintenance, etc.

7

CHAPTER II

LITERATURE REVIEW

2.1 Object -Oriented Development

Although object-oriented development is a relatively new paradigm in

the software engineering field, it has already acquired much acknowledgement

and popularity. A relatively extensive work has already been done on the

general principles of object-oriented development Today this topic is regarded

as a standard topic in software engineering. Thus. extensive literature exists,

covering all major aspects of the software development cycle, using the

object-oriented paradigm. Some of the more known and popular texts are:

Coad [ 1991], Booch [ 1991], and McGregor [ 1992]. Also. a great number of

papers have been written, that introduce or give an overview of object-oriented

principles to professionals in various fields, in order to introduce them to the

new discipline.

2.2 Simulation - General

Simulation is as old as computers are. Today it is becoming a more and

more popular and important technique in engineering. Two factors contribute to

this trend:

1. Computers and software become more available and powerful. This makes

simulation more powerful and easily accessible too. and thus more

attractive.

2. Dynamic systems have become much larger and more complex in recent

years. This causes simulation to become increasingly vital in the

development process.

Some of the advantages and justifications for ustng simulations are

detailed in Dorf [ 1980] as follows:

a. System performance can be observed under all conceivable conditions.

b. Results of field-system performance can be extrapolated with a simulation

model for prediction purposes.

8

c. Decisions concerning future systems presently in a conceptual stage can be

examined

d. Trials of systems under test can be accomplished in a much reduced period

of time.

e. Simulation results can be obtained at lower cost than real experimentation.

f. Study of hypothetical situations can be achieved even when the

hypothetical situation would be unrealizable in actual life at the present

time.

g. Computer modeling and simulation is often the only feasible or safe

technique to analyze and evaluate a system.

The term ~~simulation" covers a wide range of applications and areas.

Kreutzer [ 1990] suggests a broad interpretation for the concept of ··simulation":

"Since any exploration of a descriptive model under a chosen experimental

frame may be viewed as a simulation experiment in some sense~ the term

simulation is often used to label a wide variety of computational methods" ( p.

27).

Indeed~ simulation can be found in a surprising number of disciplines~

such as manufacturing industry~ chemical processing~ ecological modeling~

management science~ high energy physics~ air-conditioning~ computer aided

design (CAD). civil engineering, mechanical engineering, biology, etc.

Yet diverse as these areas may seem. many can be classified into

groups that actually use very similar techniques and algorithms. For example.

one problem deals with simulating multiple queues for printing files in a

computer network system. Another problem requires simulation of a company's

customer service stations, where a customer enters a station and waits in line

for his/her turn to be serviced. Although both problems may seem entirely

different they are actually very similar. Both problems deal with items

(customers, files) waiting at multiple access locations (lines. queues) to be dealt

with (serviced, printed). In general, this type of problem is known as a discrete

event simulation problem.

Simulation problems from a great variety of disciplines can be

categorized in a similar way into several groups. Kreutzer [ 1986) provides a

discussion of the various simulation categories and languages. Also, Kreutzer et

9

al. [ 1990] gtve a graphical summary in an object-oriented style of the

simulation groups and the relations among them. This graphical description

( [taken from Kreutzer et al. [ 1990]) is shown in Figure 2.1. As can be seen

from the figure, the following groups and relations are shown:

Any simulation can be either stochastic or deterministic, depending on

whether the simulated system is of probabilistic or deterministic nature.

Simulating probabilistic systems requires to perform a large number of runs.

For each run, actual values for stochastic variables are sampled/ generated

randomly. The analysis of the system is based on a stochastic analysis of the

results from the multiple runs.

Generally, simulations can be either static or dynamic. A static simulation

is a simulation of a system that does not change in time. Dynamic simulations

deal with systems that change in time. Most of the systems that are usually

simulated are of the dynamic type.

Dynamic simulations are broken into two classes: discrete event simulation

and continuous system simulation.

Discrete event simulation - A series of discrete (usually random and

independent) events occur within a system. Each event occurs at a

predetermined discrete time. The system uses predetermined rules, that dictate

how it will deal with each event Between any two consecutive events, the

system is static and no simulation is needed. Examples include printing queues

and service lines.

Discrete event simulations can be further broken into sub classes: process

oriented simulation (e.g., chemical processing plants): event-oriented

simulation (e.g., GUrs) and activities-oriented simulation (e.g., manufacturing

shop floors.) One of the most popular discrete event systems in simulation is the

queuing network system. It has, therefore, gained its own status of a special

case in Kreutzer's hierarchy.

· Continuous system simulation - Physical objects (e.g., masses) in a system

continuously interact (e.g., through forces) and react to external stimuli (e.g.,

forces). The behavior of the objects is governed by some mathematical model

(usually a system of differential equations). The simulation of the mathematical

model produces the behavior in time of the objects. Examples include aircraft

trajectory and robot motion.

10

Simulation

Stochastic -----~1 data collectors + monitors !~------Deterministic Simulation Simulation

I distributions I / ~ Static

Simulation

Dynamic

Simulation

/~ ••• • ••

j clock!

/ ~ Discrete Event Continuous

Simulation Simulation

/ ••• •••••• •••

events, processes, activities I

source, sink

Queueing Network resource, queue,

Scenarios

/ transaction

••• •••

Figure 2.1: Simulation Categories

11

A apecial case of continuous systems. not shown in Figure 2.1. is the

control system. In a control system. special pre-designed dynamic elements are

incorporated into the non-controlled system. Thus, the elements become a part

of the system. Mathematically, the control system is an ordinary continuous

system. since the control elements are also dynamic elements. Yet, for

engineering purposes, it is practical to distinguish between the non-controlled

system and the added control elements. Therefore. control system simulation

can be regarded as a sub class of continuous system simulation.

Continuous control system simulation is the subject of this research.

Therefore, the literature review will concentrate on work that has been done in

the area of continuous control system simulation, using object-oriented

techniques. Yet, discrete event simulation was the first branch of

object-oriented simulation to be addressed. It is also by far the most

extensively explored and covered topic in object-oriented simulation. Therefore

it will be addressed briefly and generally. for completeness.

2.3 Object-Oriented Simulation

Simulation evolved side by side with the other phases of the engineering

process. such as: specification. analysis, design. etc. It is therefore only natural

that simulation program developers found great interest in the object-oriented

methodology. The fact that object-oriented techniques lend themselves

particularly to problems involving real (physical) objects, attracts simulation

specialists. because usually. simulations deal with real world objects. As time

passed. also non-physical systems were simulated using object-oriented

methods (queuing problems, management systems. ecology, etc.) The

importance that is placed today on object-oriented simulation is reflected also

in the fact that special conferences are devoted to this topic [Ege 1991. Guasch

1990]. Most of the work done so far is of the academic type. These are

preliminary programs and proof of concept packages. A relatively small effort

has been placed on solving actual "real world" problems for "real"

applications. This illustrates the fact that object-oriented simulation is a

relatively new branch of the simulation "world." At this stage, efforts mainly

12

concentrate on building the foundations of the object-oriented simulation

paradigm.

The following sections will review the work that has been done in the

area of object-oriented simulation. Simulation problems can be categorized into

two major types: discrete event simulation and continuous system simulation

(with control system simulation as a special case). The review will deal briefly

with discrete event simulation. The main part of the review will then

concentrate specifically on continuous system simulation~ with special emphasis

on control system simulation.

2.4 Discrete Event Simulation

The first area where object-oriented techniques were applied to

simulation is discrete event simulation. This is also the area where the most

extensive work was done on simulation. Most of the work was done in adopting

discrete event simulation principles to various disciplines. The following

paragraphs will cover this work by disciplines.

2.4.1 General Environments

As in any simulation area here too we can find packages that were

written as general purpose environments for discrete event simulation. Probably

the first and most famous general type discrete event simulation language was

SIMULA [Dahl 1966~ Dahl 1970~ Birtwhistle 1973a~ Birtwhistle 1973b]. This

language is an extension of ALGOL. Even though object-oriented concepts

were in their infancy at the time, SIMULA already implemented some of these

basic concepts. Since then a great deal of work was done in this area. Some

examples of general type discrete event simulation programs are: Bezevin

[ 1987]~ Bums [ 1988], Cammarata [ 1991]~ Kreutzer et al. [ 1990], Valdes

[ 1989]~ Zeigler [ 1990].

2.4.2 Manufacturing Discrete event simulation gave a great boost to simulation of

manufacturing systems. As noted in Adiga [ 1991]: " ... discrete event simulation

is the most popular and appropriate approach for modeling manufacturing

systems" (p. 2529). Some examples of work in discrete event simulation for

13

manufacturing systems are given tn Adiga [ 1991]. Borgen [ 1990]. Glassy

[ 1989], Ulgen [ 1990) and Thomasta [ 1990].

2.4.3 Queuing Theory

Queuing theory is a classical event driven system in computer science. It

is often used as a typical example or test case in education and research. Some

examples of queuing simulation using object-oriented techniques appear tn

Eldredge [ 1990). Saiedian [ 1992], Tang [ 1992] and Yoshida [ 1986].

2.4.4 Miscellaneous

Some other areas where object-oriented discrete event simulation was

used are:

ecological/biological: Baveco [ 1992];

CAD: Briers [ 1992], Smith [ 1988), VanderMeulen [ 1987];

education: Fenton [ 1989];

statistics ( Monte-Carlo): Kreutzer [ 1990];

system analysis: Lee [ 1987), Lee [ 1989];

mining: Tsiflakos [ 1992];

activity: Oloufa [ 1993], Popken [ 1991, 1992), Sher [ 1989].

2.5 Continuous Systems Simulation

2.5.1 General

A great deal of analysis and development work has been done in all

phases of continuous system engineering (specification, analysis, design,

implementation, testing and maintenance). It has a thoroughly developed

mathematical foundation, in both the linear and non-linear regimes. One of

the phases where extensive use of computers is made in this discipline, is the

simulation phase. A great number of software packages and applications are today

available as ready-made tools for performing simulations of dynamic and

control systems. Some of the applications are in the form of specific libraries or

toolboxes. that come with more general applications such as MA TLAB' s

Control System Toolbox [Grace 1990]. Others are stand-alone dedicated

14

packages that are written specifically for dynamic and control systems

simulations such as CSMP [IBM] and ACSL (Mitchell and Gauthier 1987]. All

of these are fully featured powerful programs for simulating complex linear and

non-linear dynamic and control systems. These programs are written in a

variety of languages such as C (MATLAB) and FORTRAN (CSMP. ACSL). etc.

2.5.2 Object-Oriented Continuous Systems Simulation

One of the things in common with all of the above programs is that

they were all written using the "traditional" procedure-oriented techniques. As

the object-oriented paradigm begins to acquire great popularity, we witness an

increasing number of applications using this paradigm. Naturally, work has

also been done to develop simulation applications, using the object-oriented

approach.

Applying object-oriented techniques to continuous system simulation

has been very limited so far [Vangheluwe 1989], as work in this area began

relatively late, compared to discrete event simulation. Publications in this area

begin to appear in the late 80's.

As in many other fields of software development, continuous system

simulation software is also divided into four main types:

1. General introductory overviews,

2. General simulation packages or environments,

3. Programs written for simulating specific problems. and

4. Support facilities.

Support facilities such as user interfaces [ Guasch 1990, Ozden 1991],

symbolic formula manipulation [ Cellier 1993] and combinations with expert

system/knowledge base [ Vanghel uwe 1991] are outside the scope of this work

and will not be covered here.

2.5.2.1 Introductory Overviews

Although little work has been done tn the area of object-oriented

continuous system simulation, this paradigm is gaining fast recognition and

appreciation for its potential advantages. As for any new paradigm that is

15

deemed promising, this subject has been the focus of several reviews with the following goals:

a. Introduce the reader to the new concepts of object-orientation,

b. Describe the advantages of the methodology,

c. Argue that object-oriented techniques are very suitable for continuous

system simulation in general and control systems in particular.

The following works are overviews of the above type: Elwart [ 1990],

Mutagwaba [ 1991], Tittus [ 1992], Lydon [ 1992), Barker [ 1993] and Bruck

[ 1988].

In Mutagwaba et al. [ 1991], the authors present a '"mining

industry-oriented" overview. This overview discusses vanous aspects of

object-oriented control systems and not only simulation.

In Tittus et al. [ 1992], the authors attempt to layout a complete high

level methodology for adapting object-oriented techniques to control systems

engineering. This technique is based on defining objects for the various items in

the system. Each object is described by a number of generalized states it can

reside in. "Generalized transitions" lead the object in a controlled manner from

one state to another. Invariants make sure that the object never crosses beyond

its allowed stat-space boundaries.

Barker [ 1993] provide an example of a possible hierarchy for a control

system (Figure 2.1). This example is depicted in Figure 2.2. Note the conceptual

similarity of this hierarchy to that of Figure 2.1.

2.5.2.2 General Simulation Packages or Environments

One of the first examples of a general simulation package appears in

Vangheluwe [ 1989]. As the paper's name implies, it brings some very

preliminary concepts on how to use the object-oriented paradigm with

continuous system simulation. A large portion of this work is devoted to

explaining the advantages of object-oriented techniques over

procedure-oriented techniques in general. The rest of the work is a collection of

ideas on how to apply object-oriented techniques to continuous system

simulation. The main concepts are:

16

a. The entire simulator (application) can be defined and treated as an object.

The authors describe this in a simple diagram (Fig. 4 in Vangheluwe

[ 1989]) as shown in Figure 2.3.

b. The "symbolic information" part holds the model description in a

symbolic form such as differential equations (Fig. 6 in Vangheluwe [ 1989].

gives a simple example: x· = 2•x + sqr( x)). This requires incorporation of

a symbol manipulation engine in the package. Symbolic representation is

recommended because it automates various operations. such as

linearization. stability testing and integration algorithm selection.

c. Coupling between several simulators: optimization schemes: user interface.

etc .. should be external entities to the simulator-object and handled by

some ··event handler" or ··executive" utility.

d. Modern continuous system simulation packages should incorporate some

kind of expert system or knowledge base or both.

In general. as mentioned above. this work is of a very general nature.

dealing with the highest level of abstraction only. Being one of the very first

works in the area of continuous system simulation with object-oriented

paradigm, it is a very preliminary type of work. No actual design and

implementation work is presented in this paper.

Corbin et al. [ 1991] have developed a simulation environment using

ADA. Since ADA does not support object-oriented techniques. the authors had

first developed a special library that supports object-orientation in ADA.

named "ooda'' [Corbin 1990]. Using this "extended" ADA version. they

developed a package that can simulate combinations of continuous and discrete

event systems. In this application, several independent systems can be

simulated simultaneously and interact at specific points in time. based on an

event list. In addition, a small perturbation analysis can be carried out on a

model to get a linearized version of the differential equations. The user

interface is interactive. For continuous simulation. three integration algorithms are available:

rectangular. Runge-Kutta 4th-order and a fast version of Runge-Kutta

2nd-order. The model is simulated through regular integration until a discrete

event occurs. At this point. the discrete simulation part of the package is

17

System

I

Dynamic System Static System

I I I

Control System Communication System

I

Closed Loop Open Loop

I Regulator Servomechanism

I I

I Digital I Continuous I I

I I

Adaptive PID

I I ~--J,..I __ __,

Self Tuning Model Reference

Figure 2.2: Hierarchy for a Control System

18

standard interface

symbolic information executable simulation code

Simulator - Object

Figure 2.3: Simulator- Object [Vangheluwe 1989]

invoked, which enables interaction between several independent simultaneous

simulations. After the interaction is finished, each model simulation continues

its independent continuous simulation. The package also includes a library of

"standard'' dynamic elements such as: First and second order filters: time delay

and input generators.

The main object classes of the program are:

a. The event queue. It contains a list of the discrete events and controls their

execution.

b. States. Each dynamic state (variable) is represented and simulated through

its own object.

c. Integration controller. It performs the actual numerical integration.

Generally, the authors do not elaborate on the reasons for selecting

ADA in general and object-oriented approach in particular for this project.

They only mention briefly that: "This [ OOP] makes it relatively easy for the

users to add any extra object classes required to provide support facilities for

specific simulations'' (p. 58). The authors are aware that ADA is not an "ideal"

language for object-oriented applications, which is why they found it necessary

to develop the ooda support library. Also. they acknowledge the fact that

object-oriented techniques with ADA introduce some limitations that were not

addressed in this work, such as:

19

Improving speed to enable real time operation.

improving user interface,

Expanding the package into a CASE tool.

A different area of dynamic systems where an environment for

object-oriented simulation was developed is described in Lin [ 1990] and Lin

[ 1991]. This is the area of physics. Here, a package called .. Boltzmann .. was

developed to simulate classical physics systems. The basic idea underlying the

approach is, as the authors write in Lin [ 1991]: " ... many physics phenomena

can be reduced to many-body problems. For example, many macroscopic

properties such as heat, temperature and wave phenomena can be reduced to

the motion of molecules and atoms" (p. 110).

Two basic types of classes are used in the program: Particle and

Scheme. The Particle class is an abstract class from which "actual" particle

classes are inherited. Each such class describes a "typical" physical particle,

such as: Pendulum. Lennard-Jones (particles interact through short-range

force, based on the Lennard-Jones formula) and Fluid. Each particle class is

associated with the appropriate equations, describing the interactions between

particles of this class. The Scheme class receives data regarding the particle

type (class) and the overall system structure. It then performs the simulation,

solving the appropriate equations.

The authors note the following advantages in using object-oriented

techniques in their work:

a. Modularity. Particles are classic ''real"' objects. Using classes rather then

low level structures such as numbers and arrays, enables the user to work

with high level physical concepts.

b. Reusability. Individual classes are implemented in their own modules, that

can be used in different applications.

c. Using object-oriented techniques made it much easier to write the

program. Also the code is much shorter than the code resulting from

procedure-oriented writing.

20

Another research area with growing popularity for object-oriented

simulation is that of neural networks. Neural networks are a natural candidate

for object-oriented implementation. A neural network is composed of basic,

relatively simple. repeating elements, interconnected through simple

connections. This scheme lends itself naturally to object-oriented concepts.

Many identical (or similar) objects can be instantiated from a single class and

interact through messages passed along the interconnections.

Weitzenfeld [ 1991) describes such an object-oriented framework. This

work is base on their Neural Simulation Language ( NSL). Version 2 of NSL was

written in the object-oriented paradigm. The paper [Weitzenfeld 1991]

provides an excellent overview of how and why object-orientation is

appropriate for neural network simulation. The authors specifically note a

strong analogy between neural network simulation and object-oriented

programming. It is best to detail the analogy in their own words from

Weitzenfeld [ 1991]:

Neurons are self -contained objects.

In creating a neural model, neurons are instantiated from a uniform and

basic class structure.

Neural networks are described as a hierarchy of modular objects where

higher level structures inherit from the characteristics of lower level ones.

Communication among neurons is a form of message passing.

Neural networks are by nature concurrent processes.

The general structure of the NSL program is shown in Figure 2.4.

One of the most natural disciplines for continuous system simulation is

in the area of dynamic mechanical systems. Two typical examples appear in

Park [ 1991] and Ortiz [ 1992]. Both are research works that were conducted

under the guidance of Dr. Ail-Siong Koh from the Department of Mechanical

Engineering of Texas Tech University. They naturally share some common

characteristics. In Park [ 1991], a package for simulating dynamic systems using

object-oriented techniques is presented. The package is called OODS

(Object-Oriented Dynamic Simulator). It incorporates representation of

21

' '

NETWORK

I I MODULE LAYER

I l I NEURON_LAYER I IINPUT_LAYERl loATA_LAYER l

Figure 2.4: The General Structure of the NSL Program

Object

OODS ----------------------------------------------------------------- ------------------------------------------------------------------------

System

I I I I l Part Joint Spring Damper User Force Request

Marker

--------------------------------------------------------------------------------------------------------------------------------------------

Figure 2.5: Class Hierarchy of the Simulator [Park 1991]

22

classical mechanical elements with dynamics theory (equations) and

object-oriented programming. The system is written in Smalltalk-80. The

equations governing such systems are typically a combination of loosely coupled

non-linear algebraic and differential equations. The class hierarchy of the

simulator is reproduced in Figure 2.5 from Figure 6.1 in Park [ 1991].

The Object class is the fundamental Small talk class and does not belong

to OODS. The System class is the main class that constructs and runs the

simulation. It formulates the system equations. solves them and stores the

states. Class Part represents all the mechanical parts for which states are

defined. The various parts are specifically defined as instantiations of class

Part. Class Marker contains data for each part such as mass, moment of

inertia, center of gravity, etc. Classes Joint, Spring and Damper represent the

various possible mechanical connections between parts. Class UserForce

handles external loads such as force and moment and class Request handles the

required output

The work by Ortize [ 1992] is very similar although somewhat more

restricted in scope. Ortize solves the equations of motion using a very

specialized mathematical technique: Kain·s theory. The class hierarchy is more

elaborate than that of Park [ 1991]. Figure 5.10 in Ortiz [ 1992] describes the

hierarchy diagram. The diagram is shown in Figure 2.6 with minor changes for

clarity. The similarity of this hierarchy and the one from Park [ 1991] is

apparent, as explained above.

2.5.2.3 Specific Packages

Another category of simulation programs is that of simulating specific

projects (rather then general purpose simulation packages.) The following

paragraphs bring some examples of such specific applications for continuous

system simulation.

An area where simulation may be either discrete or continuous. is

ecology. The user selects the type of simulation, based on the type of problem

at hand. An example of continuous system simulation in ecology is found in

Sequeira [ 1991]. In this work, a program is described for simulating the growth

process of a cotton plant The authors emphasize the suitability of using

object-oriented concepts for ecological/biological systems. In particular, the

23

Unary Unary Binary

CLForce Spring

CGForcr Damper

HForce Gravitation

Figure 2.6: Hierarchy Diagram [Ortiz 1992]

concept of inheritance has equivalent interpretations tn biology and

object-oriented methodology. An example of a hierarchy in biology is

described in Figure 2.7. based on Figure 2.7 from Sequeira [ 1991]. This example

shows the structure of a plant and its place in the organic world. The equation

that describes the dynamic nature of the plant's growth is a summation

expression which is a replacement to the typical differential equations in

continuous system simulation. An object-oriented application from a different area is found in Tang

[ 1991]. This is the area of systems engineering. and more specifically, hydraulic

power systems. This work describes a simulation of a transient process in a

power system called: "Load rejection." This process is simulated for a

simplified model of the power system. The program was developed with the

GoldWorks II object-oriented system development tool on a Macintosh llci

computer.

24

Organism

r I Herbivore Plant Predator

I I I

Anthonomus Heliothis organ Campoletis

I I I Fruit Leaf Root Stem

Figure 2.7: The Structure of a Plant and its Place in the Organic World

[Sequeira 1991]

25

CHAPTER ill

ANALYSIS

3.1 General

This chapter details the analysis phase for the CONSIM program. A

basic specification for the problem is defined, which provides the minimum

guidelines for the project development The analysis is based on this specification.

3.2 Specification

This work is a research with the intention of building a test prototype.

No real ncustomer'" exists for the project Therefore, developing fully featured

specifications (Requirements Definition, Requirements Specification and

Software Specification, see: Sommerville [ 1992]) is not practical here. For the

purposes of this research, the Requirements Definition (in the sense of

Sommerville [ 1992]) part only was used. The Requirements Definition appears

in Appendix A.

3. 3 Analysis

The CONSIM program is intended to be a concept demonstration

program and not a fully featured, commercial program. Therefore, emphasis is

placed on issues which facilitate the demonstration. Other issues are given the

minimum reasonable consideration. This principle is the main guideline to the

project development

The important features for this project are the following quality factors:

modularity, reusability, maintainability, expandability and complexity. All

these are factors which are strongly associated with the advantages anticipated

in object-oriented development The design, therefore, should strive to

maximize the quality of these attributes. On the other hand, the issues of

numerical quality and user interface are not part of the research objectives.

Thus a relatively small effort should be placed on these issues. The analysis

follows these principles as is detailed in the following paragraphs.

26

3.3.1 Quality Factors

The following steps are taken to maximize the relevant quality factors:

a. Each class resides in its own header file.

b. Each class is as fully independent from any other file or class as possible.

c. The main() function will construct the main time loop and will launch the

simulation. It will also handle the output data.

d. The relationships between the various modules in the program will enable

the user to use one of the following options for the main() function:

The original function provided with the program. This version ts

available in the form of an executable file and provides ~basic~~ and

fixed simulation capabilities.

A user's own version. The user will be able to write his/her own

version of the main() function~ and build it to any degree of

sophistication and specialization. He/she will then combine the

other modules of the program in a modular fashion.

3.3.2 Numerical Accuracy

The package developed in this work is a research tool to investigate the

object-oriented aspects of the problem. Accuracy (which is strictly a numerical

issue) is not an object-oriented aspect and thus is not an objective of the

research. Thus it will not be an objective to achieve high accuracy results. Result

accuracy will be addressed only to the following extent:

a. Make sure that the program is simulating the correct system~ and

b. Investigate the capability of an object-oriented simulation system to

control the accuracy of the simulation.

3.3.3 User Interface

User interface is also not an objective in this research. Therefore, the

two following versions of user interface were developed:

27

1. A .. minimum~~ DOS user interface. This interface enables a user to launch

the program under DOS directly from the DOS prompt Composition and

editing of the 1/0 files is done externally using any editor. The user has to

write or employ his/her own graphics package to inspect the results in the form of graphs.

2. A basic GUI was developed in the WINDOWS environment using VISUAL

BASIC. This is a relatively comprehensive environment in which the user

can work directly with the 1/0 files~ run the program and inspect the

results in the form of graphs.

No effort was made to elaborate the user interface beyond the above.

3.3.4 Functionality

In light of the above analysis~ it was decided to build the program as a

basic simulation engine. The engine must have all the elements necessary to

perform simulation of any given linear continuous control system. These

elements~ in the form of classes~ constitute the part of the engine that will be

implemented. Additional elements are considered and added to the analysis

and design~ but not implemented.

According to the above considerations~ the minimum set of classes that

need to be implemented contains the following:

a. System -the main simulation manager~

b. Dynamic Element- super class for all types of dynamic elements~

c. External Inpu4 and

d. Transfer Functions.

The elements that are not implemented but are included in the analysis

and design for the full picture and future enhancements are: External Input

types (Control input~ Disturbance.) and Dynamic Element types (Plan~ Sensor~

Controller~ Actuator.)

28

3.3.5 Simulation

An important issue in correctly setting up the simulation structure is the

order in which the dynamic elements should be visited during a simulation

cycle. Bad order introduces hidden and false time lags or gains into the system.

The user is NOT required to number the dynamic elements in the correct order

of visitation. Therefore, CONSIM should do it automatically. The following

paragraphs describe the considerations and reasoning, used for selecting the

methodology

In order to find the right algorithm for solving the above problem, it is

required to convert the problem from the control engineering domain to the

computer science domain. As described in the specification (Appendix A), the

system to be simulated is described by means of a block diagram. Observing the

graphical characteristics of block diagrams, used in control system engineering,

it is easy to see that a block diagram is actually a directed graph. The

requirement to visit ALL the dynamic elements of the systems means that we

need to traverse the graph. Thus the problem was converted to a classical

problem in computer science, namely: traverse of a directed graph.

There are many ways to traverse a graph. We need to find a method

that will cause the nodes to be traversed in the correct order. It is easy to see

that a depth first search ( dfs) will not prevent the bad lags/ gains, where as a

breadth first search ( bfs) will provide the correct traverse pattern.

Thus, the correct order for visiting the dynamic elements should be

decided through a bfs technique.

29

CHAPTER IV

DESIGN

4.1 General

The design is based on the analysis outlined in Chapter m. It employs

some of the classical tools used tn object-oriented development

entity-relationship diagram. structure chart and hierarchy structure diagram.

4.2 Entity Relationship Diagram

Figure 4.1 shows the entity relationship diagram for the CONSIM

program. The part of the diagram NOT closed inside the broken line was

selected during the analysis phase for implementation. The elements that are

not implemented but are included in the analysis and design for the full picture

and future enhancements are enclosed in the broken line. The diagram

conventions follow McGregor [ 1992].

4.3 Object Modeling Technique (OMT) Diagram

Once the Entity Relationship Diagram is finished, it is straight forward

to derive the Object Modeling Diagram, based on Rumbaugh [ 1984)'s OMT

technique. The Object Modeling Technique Diagram is shown in Figure 4.2

4.4 Structure Chart

Figure 4.3 shows the structure chart for CONSIM.

30

System

,.-------,1 Jr---------1-----, External lnpu Dynamic Element

------------ -------------------------------------------------------- -----------------

Control Plant

I Disturbance,___~ Sensor

Controlle·r----..!

Actuator ~------

Gain

Integrator

Single Pole

L---------------------------------------- -----1 I I I I I I

Derivator : I I I I

------------------------------------------------------------------------------------------

·---------! Not implemented ' '

Single Zero

Complex Zero

L-------------------------------------------

Figure 4.1: Entity Relationship Diagram

31

System

External Input t--------+Dynamic Element+-----+ TF (Complex Pole;

---------------------~--------------------------------------------------------- -----,

I Control Disturbance Plant Gain

Sensor ~ Integrator

Controller~ Single Pole ~--t

Actuator- Derivator

------------------------------------------------------------------------------------------

b. Aggregation Relation Single Zero

0 Generalization Relation Complex Zeror---

Association Relation L---------------------------------------~

,---------! Not implemented :

Figure 4.2: Object Model Diagram

32

l set up simulation times

1 I read set up input driving

function

create system

create dynamic element

set transfer function

type

start main()

set element

order

find element's children

run simulation

find I

get

l generate output

element element input

get element

output

response

Figure 4.3: Structure Chart

33

4. 5 Hierarchy Structure

The following hierarchy structure shows the abstract structure of each

class and its relationship to the other classes. Only those classes that were

selected for implementation are shown (Figure 4.4).

class External Input

data

class System

data

input data

internal support data

servtces

get input data

set element order

find elemenf s children

find input

class Complex Pole

data

class Dynamic Element

data

input type servtces name

input characteristics compute

input file get response

servtces

get vector input

get input

class Gain

is a Complex Pole

data --servtces

get response

class Integrator

is a Complex Pole

data

servtces

get response

type

transfer function coefficients

servtces

compute result

response

set type

get output

class Single Pole

is a Complex Pole

data

servtces

get response

Figure 4.4: Hierarchy Structure

34

4.6 Simulation

In the analysis it was demonstrated that a directed graph traverse is

required in order to get the correct order for visiting the dynamic elements.

Generally, there is a great number of abstract data structures that can be used

to implement a breadth first search.

Since there exist many "off the shelf" packages for implementing

abstract data types. it only stands to reason to take advantage of this

availability. After all, one of the major themes of object-oriented techniques is

Reuse. Therefore, it was decided to employ a ready package.

Since the program was written in Borland C++, it was straight forward

to employ the compiler's Object Library. Borland's Object Library is a library

of abstract data structures, designed with object-oriented techniques and

implemented in C++. Thus, this is a natural selection.

35

CHAPTER V

IMPLEMENTATION

5.1 Introduction

This chapter describes the implementation of CONSIM. It begins with a

general overview of the program operation. Then it describes the 1/0 structure

(command line. input file. output screen and file and driving function input

file.) Then the implementation of the various classes. Finally, some reference is

made to the user interface. The complete code of CONSIM is given in Appendix

B, and can be used for reference for this chapter.

5.2 Overview

CONSIM is a DOS program. It was noted in the analysis chapter that two

options for the main() function will be available:

1. A "standard." ready made function in the form of an executable.

providing basic capability.

2. Any version that a user may choose to write himself /herself. The classes

were implemented in such a way as to facilitate this option. This will be

shown in the paragraphs describing the implementation of the classes.

Naturally. the second option cannot be treated in this work since it is

user dependent The overview will assume that the "standard" version is used.

The executable resides in the file: "sim.exe". It takes the names of the

input data file and the output file as parameters on the command line. A third

file, for vector driving input, is optional. The syntax is as follows:

sim input .filename output .filename [vector filename}.

Full path must be used for any of the files that resides in a different

directory than that of sim.exe. The first operation of the program is to

instantiate one object of each of the following classes: Gain. Integrator. Spole.

Dpole. The main() function then begins to execute. It first checks the number

36

of arguments on the command line to insure all the required file names are specified.

Next. main() instantiates an object of class System. The constructor for

this class performs the following tasks:

Reads the input data from the input file.

Instantiates an object of the Externallnput class, that will handle the

driving function for the simulated system.

Instantiates one object of the DynamicElement class for each of the

dynamic elements in the simulated system, and sets its characteristics.

Sets the order in which the dynamic elements will be visited during the

simulation.

Function main() then opens the output file, retrieves from class System

the various simulation times. and uses them to construct the main simulation

time loop. For each time increment in the loop, main() sends a Run message to

the System object System runs one simulation cycle and returns the computed

output to main(). The main() function then writes the output to the output file,

increments the time loop and sends the next Run message. This continues until

the loop expires. At this stage the simulation terminates.

5.3 Input File

In order to correctly build the input file. it is necessary to prepare the

problem for simulation in the form of a block diagram. The input file is an

ASCII "description" of the block diagram.

5.3.1 Preparing a Problem for Simulation

To prepare a problem for simulation, follow these steps:

Draw a block diagram of the system to be simulated.

Assign a unique ID number to each block. The numbers must range from 1

to n where n is the number of blocks. The order in which the blocks are

selected for numbering is not important

37

Prepare an input file. Use the block diagram to complete the file as

described in the following paragraphs.

5.3.2 Input File Structure

The input file is a plain text file to enable the user to easily write and

read its contents. Any editor can be used for that purpose~ although a dedicated

WINDOWS GUI is supplied with this program. The structure of the input file is

fixed and must not be changed. An example of an input file is shown as file

data.dat in Appendix B. The general rules for the file structure are as follows:

Any line must start at the first character position.

A line starting with a CR/LF character combination must be a blank line.

A line starting with two forward slashes (/ !) is considered a comment line

and is disregarded.

Any combination and number of blank and comment lines may be used

between any two input items.

The file must start with at least 2 comment lines. The first can provide

general information about the file. The second can comment on the first

input item.

A line containing input data must not contain any other characters (such

as comments). The line must be terminated by a CR/LF character

combination immediately after the data (no additional characters~ either

visible or hidden between the data and the CR/LF character

combination). Data items which are two-dimensional arrays must be written in a matrix

format. Single white spaces separate adjacent numbers (no commas). Each

matrix row resides in a separate line. Matrix lines must be consecutive with

no interruption by any other data or comments. Each line (row) in a

matrix corresponds to a block in the block diagram~ in the same order

(row number in matrix= block ID number).

The order in which the data items are presented in the file is fixed.

38

The structure of an input file is as follows:

First two lines must be comment lines.

next line: Number of dynamic elements ( int) followed by the number of

inputs of the element that has the largest number of inputs ( int). Write the

two numbers on one line. separated by a single white space.

Next data item: dynamic elements type array ( int). Use the following key:

1 -gain

2 - integrator

3 - single pole

4 - double pole

Provide one value for each element, All on the same line and separated by

single white spaces.

Next data item: Dynamic elements coefficients matrix (float). Each

element must be represented by 3 coefficients, regardless of its type. An

element is assumed to be represented by a linear differential equation of

the form: ay + by + cy = x. In the Laplace plane this can be written as: as2

+ bs + c = X(s). Each row in the matrix lists the significant a b c values

(in that order) for the corresponding element. The first number in a line

should be the non zero coefficient of the highest power. For elements with

less than three significant coefficients, the extra columns will be padded

with zeros. Note the following:

for a single pole: a = 0.

for a pure integrator: a = c = 0.

for a pure gain: a = b = 0 and c = 1/K where K is the gain.

Next data item: Inputs to dynamic elements matrix (float). The number of

columns of this matrix is equal to the "number of inputs of the element

that has the largest number of inputs" (second number on the first input

line in the file). For elements with less inputs, the extra columns will be

padded with zeros. A number i in a row j indicates that element i provides

39

input to element j. The order of numbers in a row is insignificant Negative

inputs are designated by negative numbers.

Next data item: Initial conditions matrix (float). For any element type.

there must be two initial conditions: y( 0) and y( 0) in that order. Typically they are zero.

Next data item: External input function ( int) and its scale factor (float).

Write the two numbers on one line. separated by a single white space. For

the input function use the following key:

5 -Impulse

6- Step

7- Ramp

8 - Input provided on file (file described later).

Next data item: Input element (int). The element to which the external

(driving) input is applied.

Next data item: Output element ( int). The element whose output ts the

system's output.

Next data item: Start time (float). Starting time for main time loop.

Next data item: Stop time (float). Stop time for main time loop.

Next data item: Delta time (float). time step for main time loop.

5.4 Output

Output is automatically provided to the screen and to the output file

that was specified on the command line. The output available is as follows:

Screen - a list of the dynamic element numbers in order of visiting and a

single line on which the time and output value are printed "in real time''.

File - two columns of numbers. The first column is Time. The second

column is the corresponding output. Each pair of numbers is separated by

a single white space.

The screen output is primarily for debugging purposes. The data in the

output file are raw numbers that can be analyzed in any way the user chooses.

40

The WINDOWS GUI supplied with this package displays a graph of the output

versus time.

5. 5 External Input File

The external input file provides the driving input values for the system

(input function = 8) ~ instead of the standard input types, described above. The

file name can be any valid DOS name and must be specified as the third

(optional) parameter on the command line. The structure of this file must be

the same as that of the output file: Two columns of numbers. The first column

is Time. The second column is the corresponding input Each pair of numbers is

separated by a single white space. The values in the Time column must be

continuously increasing. The simulation time range (StartTime to StopTime)

must be equal or inside the input Time range.

5.6 Classes

5.6.1 General

The following paragraphs describe the implementation aspects of each

class. Each class resides in its own header file to facilitate modularity. All the

header files have a global scope. The classes are listed in alphabetical order by

name. The description of each class has the following format:

a. Title and explanation of use of class,

b. Structure template of class and explanation of its items,

c. Explanation of services.

5.6.2 Class Dpole

Function:

Calculate the response of a complex pole.

Template:

data

Services

None

Compute

GetResponse

41

Explanation:

Dpole is a super class of all the classes that calculate the response of a

dynamic element (complex pole, single pole, gain, integrator). The function

Compute is the actual numerical algorithm. The integration algorithm used by

Compute is a simple extrapolation scheme. This scheme is described in

Appendix C. The user can insert his/her own algorithm in place of the one

provided here. Alternatively. the user can change Compute to call another

function that will perform the calculation.

In the present implementation, All the other dynamic element classes

(single pole, gain, integrator) also use Compute for the calculation. Each of

these classes changes the coefficients of the differential equation to suit the

numerical structure of Compute. It then sends the new coefficients to Dpole with

a Compute message. This technique is detailed in Appendix C.

The GetResponse function merely calls Compute. This is done to give a

similar structure to all the dynamic element classes.

5.6.3 Class DynamicElement

Function: Handles all data and servtces of all the dynamic elements tn the

simulated system.

Template:

data

Services

ElementName - element name.

ElementTFType- element transfer function type.

coeff2 - coefficients of differential equation. coeffll

coeff3

DelataTime- time increment for numerical integration.

icO} - initial conditions. icl

ComputeResult - holds the result of the integration.

Response

SetTFType

42

GetOutput

Explanation:

SetTFType initializes the object and sets its attributes' values.

Response sends a GetResponse message to the appropriate element type class

(complex pole, single pole. integrator, gain.)

GetOutput retrieves the value of ComputeResult

5.6.4 Class Extin

Function:

Handles the driving input to the simulated system.

Template:

data

Services

Explanation:

Type - type of driving force (impulse, step, etc.)

ScaleFactor- scale factor for impulse, step and ramp inputs.

StartTime - simulation starting time

*pid - pointer to driving input file.

Timel Time2 _ local time and input values for interpolation inside

Inl the driving input file In2

Ex tin

GetVectorlnput

Getlnput

The constructor initializes the attributes. If the driving function needs to

be read from a file, the constructor opens it

Getlnput provides the next value of the driving function. If the driving

function needs to be read from a file, Getlnput retrieves it by sending a

message to GetVectorlnput. GetVectorlnput performs an interpolation in the

file and returns the driving input for the given time.

43

5.6.5 Class Gain

Function:

Calculates the response to a pure gain.

Template:

data

Services

Explanation:

None

GetResponse

GetResponse is the service that calculates the response. In the present

implementation, GetResponse rearranges the differential equation's

coefficients. so that the Compute service of class Dpole can perform the

integration (see Appendix C for a more detailed discussion of the numerical

implementation methodology). In the general case, however, any integration

algorithm can be used in GetResponse, or be called by it

5.6.6 Class Integ

Function:

Calculates the response to an integrator.

Template:

data

Services

Explanation:

None

GetResponse

GetResponse is the servic~ that calculates the response. In the present

implementation, GetResponse rearranges the differential equation's

coefficients, so that the Compute service of class Dpole can perform the

integration (see Appendix C for a more detailed discussion of the numerical

implementation methodology). In the general case however. any integration

algorithm can be used in GetResponse, or be called by it

44

5.6. 7 Class Spole

Function:

Calculates the response to a real pole.

Template:

data

Services

Explanation:

None

GetResponse

GetResponse is the service that calculates the response. In the present

implementation~ GetResponse rearranges the differential equation~s

coefficients~ so that the Compute service of class Dpole can perform the

integration (see Appendix C for a more detailed discussion of the numerical

implementation methodology). In the general case however~ any integration

algorithm can be used in GetResponse~ or be called by it

5.6.8 Class System

Function:

Sets up the entire simulation mechanism for calculating a single time

step.

Template:

data *TFType - pointer to the array containing the transfer function

types

*Coeff - pointer to the matrix containing the coefficients of the

transfer function

*Input- pointer to the matrix containing the inputting elements

for each element

*IC- pointer to the matrix containing the initial conditions

InputEl - number if the element to which the driving input of

the system is applied

OutputEI- number if the element whose output is sought

StartTime- simulation starting time

StopTime - simulation stop time

45

Services

Explanation:

constructor

DeltaTime - simulation time increment

lnputFunction - type of input function

ScaleFactor- scale factor of input function

NooffiynEl- number of dynamic elements

NoofCols - number of columns in input matrix

* PDynamicElement - pointer to an array of dynamic element

objects

* POrder - pointer to an array which contains the dynamic

elements in the correct order of visitation

InstTime- instantaneous simulation time

* PExtinput - pointer to an external input object

System

SetOrder

FindChildren

Findlnput

GetData

GetTimes

Run

The constructor performs the following operations:

Read the input data from the input file.

Instantiate an object of Extlnput class to handle the driving function.

Instantiate as many objects of class DynamicElement as there are dynamic

elements in the simulated system.

Set up all the DynamicElement objects.

Set the order in which the dynamic elements should be visited.

GetData

GetData retrieves the input data from the input file and assigns it to the

class's attributes.

46

GetTimes

Returns the main simulation loop times: StartTime, StopTime and Delta Time.

SetOrder

SetOrder sets the correct order in which the dynamic elements in the

simulated system should be visited. It implements a breadth first search of the

system dynamic elements (see explanation in the Analysis and Design

chapters). A breadth first search requires use of a FIFO type queue data

structure. Borland's Object Library provides several implementations of a FIFO

queue. The implementation using an array was selected for this program. The

service uses the FindChildren service to find all the children of a given node during the traverse.

FindChildren

Given a node in a directed graph. FindChildren finds all its children.

Run

Run executes a single cycle of calculations for the entire system. It

traverses all the dynamic elements in the simulated system, in the order set

earlier by SetOrder. For each element it calculates its input using Findlnput

Then it issues a Response message to the appropriate dynamic type object

(Gain, Integ, Spole, Dpol), to calculate the element's response (output) to the

above input After the entire system was traversed, Run returns the output of

the element designated as the output element (OutputEI), using the GetOutput

message.

5.7 User Interface

5. 7.1 General

The user interface was not an objective in this research. The only

requirement from the user interface was to provide the user with the minimum

functionality for using the program. Following this line of reasoning, two basic

user interfaces, which provide the minimum functionality. were developed: a

47

DOS version and a MS- WINDOWS version. These user interfaces are briefly described in the following paragraphs.

5. 7.2 DOS User Interface

The DOS user interface is actually the functionality described in the

previous paragraphs. The user prepares a standard input file and a driving

function file (optional). The program is launched from the DOS prompt,

specifying the names of the I/ 0 file as parameters on the command line. The

output is provided in the ASCD numerical form in the output file.

5. 7.3 MS-WINDOWS User Interface

The MS-WINDOWS user interface is a GUI sell program that brings all

the DOS 1/0 management functions described above, under one roof. Once the

user launches the GUI, all CONSIM' s 1/0 functionality can be handled inside it

The GUI was written in Visual Basic Pro 3. as a MS-WINDOWS program. All

the input preparation work is done inside the program in the standard

MS-WINDOWS environment CONSIM is then launched from within the GUI. It

runs the simulation as a DOS application, and upon completion, control returns

to the GUI for further 1/0 work. The GUI then can be used to further

manipulate 1/0 files and to view the simulation output in the form of a graph.

A more detailed description of the GUI' s use is given in Appendix E.

48

CHAPTER VI

TESTING

6.1 General

This chapter describes the testing of the CONSIM program. Two main

types of testing were performed:

1. Testing for correctness and accuracy. The purpose of this testing was to

ensure that the program is functionally doing what it was supposed to do,

and that the results it produces are satisfactory (correct and accurate).

2. Testing for product quality. This part was carried out to meet one of the

objectives of this research, namely: Compare the object-oriented

implementation of linear control systems to the procedure-oriented

techniques.

It is obvious that some reference program is necessary to perform both

parts of the testing. The following paragraphs describe the reference program

that was selected, and the tests.

6.2 Reference Program

The Control Systems Toolbox from MA TLAB [Grace 1990] was selected

to be the reference program for this research. The reasons for selecting this

package are as follows:

a. Quality. MA TLAB' s Control Systems Toolbox is a well known program. It

is widely used and popular in the control engineers community. Its high

quality has been established, which makes it a good reference to any new

control systems simulator. b. Code accessability. Most of the modules of the Control Systems Toolbox

are written and available to the users in plain ASCD code (called M-Files.)

This makes it possible to perform more reliable tests on the program.

c. Availability. The package was available for the research.

49

6. 3 Correctness and Accuracy Testing

For testing the correctness and accuracy of the program, several typical

examples of control systems were simulated on both CONSIM and the Control

Systems Toolbox. The output generated by both programs was plotted and the

plots compared. Both programs produced practically identical output The

following presents a typical example.

This example is taken from Grace [ 1990, page CR-15]. It describes a

typical three loop auto pilot system. The system's presentation as a block

diagram is reproduced from Grace [ 1990]. The block diagram is shown in

Figure 6.1. The data for the transfer functions are:

CASZ = .65; CASW = 220

GYRZ = .65: GYRW = 380

GYFZ = .65; GYFW = 2000

ACCZ = .75; ACCW = 700

ACFZ = .65; ACFW = 250

Ka = .00225; W; = 10; Kr = .16

~ = -280; Ma = -250; Mo = -1.5

Z0 = -.23; Za = -1.6

V m = 4220: DX = 2.235.

The simulation time period was from 0 to 1 sec.

The driving input to the system is NC and the output is NL.

The auto pilot was simulated using both MATLAB and CONSIM. The

output of both simulators is shown in Figure 6.2. Both outputs are superimposed

on one another. It can be seen that both programs produce practically identical

results (both lines in the graph match.)

so

1 2 3 17 NERR

NC 1 + _ ~-+ WERR---*Ka+-~- o K ~

L,.__ __ v_m___. _ + ~ + ~ _:_ 1 DELTA

1 + 2~s + £ w w2

w=CASW. \=CASZ

5 Ka-

4 18 6 19

1 1 1 1

AM 1 + 2~s + £ ..- 1 + 2~s + £ SLA _ 1 + 2~s + £ .- 1 + 2~s + £ ~_____, w w2 w w2 w w2 w w2

w=ACFW,

\=ACFZ

w=ACCW.

\=ACCZ

.. ...

+ +

w=GYFW.

\=GYFZ

DX

7

w=GYRW,

\=GYRZ

NL GAMMAD 11 THETAD

16 10 12 ~

13 -

- z 1 ALPHA 1 -,_ 1.,. ,. + ,;_r--M .... 1"--~ .__n___.T s ~ s THETADD + +, o

'--

14 -

Figure 6.1: Example of a Control System

51

SYSTEM;linear;closed loop;;step;input=inputl - damping ratio: 0.614 -over shoot: 1.096 at: 0.29[s]

1

0.8

0.6

output

0.4

0.2

0

-0

·2o 0.1 0.2 0.3 0.4

Figure 6.2 Output of Simulators

52

0.7 0.8 0.9 1

6.4 Software Quality Testing 6.4.1 General

The following paragraphs describe the software quality testing phase of

the research. Some known "standard'' software measurement metrics system

was sought, in order to try to get a reliable and quantitative measure of the

software quality. This chapter consists of two parts:

1. A discussion describing how the testing methodology was chosen and

2. A description of the testing and the results.

6.4.2 Selection of Testing Methodology

6.4.2.1 Procedure-Oriented versus Object-Oriented Metrics

The guiding principles that dictated the selection of the metrics system are:

a. Measuring across applications. We want to measure more than one

application. We are more concerned with the relative quality of CONSIM

(relative to MATLAB) than its absolute quality. A relative measure is

sufficient after it was established in advance that the reference application is of high quality.

b. Measuring across paradigms. A metrics system is required that can

measure reasonably reliably both procedure-oriented and object-oriented

applications.

6.4.2.2 Object-Oriented Metrics

Object-oriented Metrics are a very new discipline. The first ideas and

experiments appeared in the late 80's. Since then very little work has been done

in this area. AIJ the work in this area is very preliminary. Naturally there is not

available a metrics system for object-oriented programs that has gained any

experience and recognition in the industry and academy. Also. none of the few

suggested methods has been tested in "real life" cases.

In addition. the suggested methods for object-oriented metrics cannot

be readily applied to procedure-oriented applications. All the methods refer to

such entities as: Objects, inheritance tree depth. etc. It is difficult (perhaps even

53

impractical) to convert these entities to procedure-oriented programs. This

technical difficulty in itself is sufficient to prevent the application of

object-oriented metrics to procedure-oriented applications.

6.4.2.3 Procedure-Oriented Metrics

Procedure-oriented metrics have been developed and in use for many

years. There is a substantial accumulated experience with procedure-oriented

methodologies and their applicability and reliability are well-known and

proved (at least empirically).

There is~ however~ a question that needs to be addressed: Can

procedure-oriented metrics be applied to object-oriented programs?

Technically, applying procedure-oriented metrics to object-oriented

programs is straight forward. Most of the terminology and items that are used

in procedure-oriented metrics can be found also in object-oriented programs

(operators. operands~ functions~ logical structures, lines of code, etc.). At least,

it is usually easy to find entities in object-oriented programs that are equivalent

to procedure-oriented entities (services are equivalent to functions, messages

are equivalent to function calls, etc.)

Still there is a question: Are results of measurements from

procedure-oriented metrics that were applied to an object-oriented program

meaningful? An answer to that can be found in Barnes et al. [ 1993]. The

authors have conducted testing of object-oriented programs using

procedure-oriented metrics. They found strong correlation between these

metrics and object-oriented program qualities (see Table 2 in Barnes [ 1993].)

This indicates that procedure-oriented metrics can be reliably applied to

object-oriented applications. In light of the above considerations, it was decided to use a

procedure-oriented metrics system for this research.

6.4.2.4 Software Metrics Categories Roughly~ there are three main categories of software metrics,

depending on the desired data:

54

1. Process metrics. Measure the application development process while the development is still in work.

2. Productivity metrics. Concerned with the economic aspect of the work.

Tries to measure how much software was produced for the development

effort that was put into the work

3. Quality metrics. Measure the quality of the product according to pre defined criteria.

Obviously. in this wor~ we are concerned with Software Quality Metrics (SQM).

6.4.2.5 SQM Types

There are three main approaches to performing SQM:

1. Goal-oriented metrics. This methodology defines goals for the software

quality. The goals are usually defines in terms of the classical Quality

Factors, such as: Accuracy, clarity, completeness, etc. The Goal-oriented

metrics try to directly measure these factors.

2. Performance-oriented metrics. Measure run time performance

characteristics such as: Run time, fault tolerance, memory requirements,

etc.

3. Syntax-oriented metrics. Measure the code syntax to draw conclusions

about the software quality.

Traditionally. the object-oriented paradigm supporters emphasize

specific quality factors where the object-oriented programs should be superior

to the procedure-oriented programs. These are typically: reusability.

maintainability, complexity, etc. It is clear. therefore, that the advantages of

the object-oriented programs are supposed to be found in the goals. This

naturally draws the attention to the Goal-Oriented Metrics. However, goal

metrics are not suitable for this type of research because they require an

elaborate testing program with many participants over extended periods of

time.

55

This contradiction was resolved by Van SueTendael et al. ( 1991). In

their report. the authors show that there exists a strong correlation between

goals (they term them: Quality Factors) and syntax measurement results. They,

therefore, suggest to use syntax measurements and employ correlations to draw conclusions regarding the goals.

Syntax metrics are the most popular and widely used metrics. The reasons for that are:

a. Over 15 years of accumulated experience,

b. Easy to use and apply, and

c. Good correlation with quality factors.

It was, therefore, decided to use syntax-oriented metrics in this work.

6.4.2.6 The Relevant Quality Factors

Many quality factors have been defined through the history of software

testing. Van SueTendael et al. [ 1991) define 22 such factors. Yet it is not

necessary to measure all of those factors for two reasons:

1. Many factors are dependent on one another. For example, complexity and

simplicity are obviously complementary. Thus measuring one of these, will

automatically give the other.

2. Only a subset of the factors is claimed to be better for object-oriented

software. These factors are the ones that interest us in this research.

In the light of the above, the following quality factors were selected for

testing:

Reusability,

Maintainability,

Complexity.

Expandabili ty,

Modularity.

56

6.4.2. 7 Selecting a Syntax Metrics System

In the many years of experience with software quality metrics~ several

independent syntax metrics methodologies were developed. Some of the most popular ones are:

Halstead's software metrics,

MacCabe's cyclomatic complexity metric,

RADCs SQM methodology,

Albrecht's function points metrics,

Ejiogo' s software metrics,

Henry and Kafura's information flow metric.

Each of the above methodologies has its advantages and disadvantages.

It is outside the scope of this work to elaborate on this topic. For further

reading on this subject see Van SueTendael et al. [ 1991].

Out of the above methodologies, Halstead's software metrics system

was selected for this project for the following reasons:

a. One of the most popular and widely used techniques in the industry.

b. High correlation with quality factors.

c. Best cover of the quality factors that we want to measure in this project

It should be noted that in the two cases found in the literature review.

where procedure-oriented metrics were applied to object-oriented programs.

the researchers chose to use Halstead's method [Barnes 199 3 and Plews 1992].

6.4.3 Application of Halstead's Metrics System

Halstead's method requires counting four quantities:

1. n1 - the number of unique operators in the application.

2. N1 - the total number of operators in the application.

3. n2 - the number of unique operands in the application.

4. N2 - the total number of operands in the application.

57

These counts are then used to derive the various Halstead's method metrics. The metrics derived in this work are:

" a. N - Implementation Length. " b. V - Volume.

" c. L- Program Level. " d. E- Programming Effort

These metrics are shown in Van SueTendael et al. [ 1991] to have very

good correlation to the quality factors that were designated for testing in this work.

Halstead's method was applied to both CONSIM and MA TLAB' s

Control System Toolbox. Appendix D contains the data collection tables and

metrics calculations. Since MA TLAB's Control System Toolbox is of a much

wider scope and range of applicability than those of CONSIM. it was necessary

to carefully select the subset of modules from MA TLAB' s Control System

Toolbox that provides approximately the sane functionality as CONSIM. The list

of modules used in both applications is given in Appendix D. The count results

of the above four parameters and the metrics calculations are also given in

Appendix D.

The results of the measurements are summarized in Table 6.1

Table 6.1: Metrics results summary

parameter MATLAB SIM difference % SQF

nt 30 40 -33.3 complexity

n2 285 222 22.1 1 -modularity " 1713 1347 21.4 complexity N " 9854 7501 23.9 complexity v

" .0531 .0689 29.8 simplicity L " 185574 10886B 41.3 !-modularity E

58

The last column in the table shows the correlation of each quality

measure with the software quality factors. The correlation is direc~ that is, the

greater the metric value, the "stronger" the quality factor. For example: The A

higher N, the higher the complexity. Also: The higher E the smaller

(!-modularity) the modularity. The "difference %" column in the table

indicates the difference between the two programs in percents, with MATLAB's

Control Systems Toolbox as the base.

6.5 Analysis of Results 6.5.1 General

The following paragraphs provide the analysis of the software testing

results. The accuracy I correctness test results are discussed briefly, as these were

not objectives of the research. Nex~ the results of the quality testing are

analyzed and conclusions and recommendations are made.

6.5.2 Correctness and Accuracy

The example presented in Chapter V (Implementation), is one instance

that demonstrates the correctness and accuracy qualities in CONSIM. A

substantial number of examples were tested in this phase. All the test cases

performed on a similar quality level in terms of the above qualities. This gives

reason to believe that the program is correct

As to accuracy, the following observation can be made. When testing

for accuracy, it is appropriate to clearly (and if possible quantitatively) define

what the required accuracy is. This can easily be defined in an application

which is of the scientific/ engineering/ numerical nature. since the output is

numerical. However, in this research, the definition of the required accuracy

may be somewhat relaxed to a more qualitative level, for the following reasons.

Firs~ accuracy was not an objective of the research. Thus it was

sufficient that the numerical performance be accurate enough to warrant

correctness. This can easily be judged by visually inspecting the output in the

graphical format as shown in this report

Second, inspecting performance in the graphical form is a classical

technique in control systems engineering. Experience showed that the inspection

of the graphs is very good and sufficient for analysis and design purposes.

59

Seldom does it happen that actual numbers need be consulted. It is also

accepted, that two visually identical graphs represent two identical responses,

although numerically, there might be minute differences that cannot be seen in

the graphs due to resolution limitations.

We therefore conclude that the accuracy requirement for this research

can be defined as follows: The tested simulator is accurate if its output graph is

visually identical to that of the reference program.

The example in this report and in all the other tests performed in this

testing phase, demonstrated this accuracy. Thus it is concluded that the

accuracy requirement was fulfilled.

The design and selection of the numerical integration algorithm

followed the same reasoning. The idea was to design the algorithm to facilitate

the important software quality factors rather than performance or numerical

accuracy and stability. For that reason. a simple extrapolation scheme was

selected (see Appendix C). When using a sufficiently small time step, this

algorithm is usually adequate for well behaved systems. Linear continuous

systems are indeed well behaved. Thus using such an algorithm in CONSIM

(which simulates only linear systems) is adequate. However, when entering the

regime of badly behaved systems (such as non-linear and/or discrete), more

robust algorithms are necessary. The object-oriented approach enables to easily

incorporate other algorithms into the program (as is discussed in the

appropriate section).

6.5.3 Software Quality

6.5.3.1 Software Quality Metrics Reliability

Software quality metrics is not yet a true science. The techniques and

theoretical base for the various methodologies are of an engineering/empirical

nature. Even the quantities that we want to measure (the quality factors) are

not unambiguously (not to say quantitatively) defined. This makes the task of

measuring and interpreting the results, a difficult task. The reliability of any

known methodology is limited. One should not take the numeric measures

values ''literally." Rather they should be regarded as general qualitative

indication of the software quality.

60

In this work this difficulty is somewhat reduced, however, due to the

fact that we are not attempting to directly measure the "absolute" quality of the

product Rather, we employed relative measurement by comparing the test

results of two packages using one measurement method. This approach is valid

after having established that one of the programs was a "good" reference

program. Here, "good" stems from the fact that the reference program had the following characteristics:

a. Commercial package,

b. Has very good reputation in the professional community, c. Code is accessible in ASCll.

Thus, knowing that the reference program was a ''good" program, we

are no longer concerned if some quality measure of CONSIM is some given

number. Rather, we are interested in the difference in this measure between the

two programs. Knowing that we use a "good'' reference before measuring it,

enables us to draw conclusions about the '"absolute" quality of the tested

software by comparing its measurements to those of the reference program.

6.5.3.2 Measurement Accuracy

The inaccuracy of the metrics systems also implicates on the certainty

level of the results. Metrics inaccuracy means inaccurate measurements. In

other words, the measured values are relatively noisy. This is less important

though in comparison measurements where we are interested in differences

between measurements. If the measurement process is carried out on both

programs in an identical and consistent manner, the measurement errors are

expected to be of similar magnitude and nature. Therefore, when calculating

the differences between measurements for two programs, the errors tend to

cancel out This brings the conclusion that for purposes of comparison, software

quality metrics are relatively accurate.

Still a question should be asked: How large should the differences be to

be regarded as significant? Van SueTendael et al. [ 1991] show that the quality

factors have a typical correlation of 0.8 with Halstead's metrics. Therefore, it is

61

concluded that in this work.. differences greater than 10% can be regarded as

significant Still. no attempt is made to characterize how significant.

Thus it is impossible to postulate the accuracy. The metrics

methodologies are not advanced enough in their theoretical foundation to

provide these data. It is therefore somewhat arbitrary to decide the accuracy of

the measurement This means that the difference in a measure between two

programs cannot be taken .,literally.'" For example. if the complexity of one

program is found to be 10. while the complexity of the other is 20. one cannot

say that the second is twice as complex as the first. But one can probably say

that the second program is definitely more complex than the first.

6.5.3.3 Halstead's Method

Halstead's metrics method was found to be a straight forward and easy

technique. In fact. once the exact conventions for code interpretation are set.

the counting process is very mechanical. It seems that this type of work can be

easily automated through some computer utility. The literature review in this

work did not reveal that such a utility exists.

6.5.3.4 Measurement Results

The results of the software quality measurements are summarized tn

Table 6.1. From the table. it can be seen that except nt. all the other metrics

give consistent results. The exception of the n1 result serves to demonstrate the

''imperfecr· and engineering nature of contemporary software metrics. Had the

metrics system been mathematically sound. then all the measures would have

rendered consistent (rather than contradicting) indications. This further

stresses the point that software quality measurement results should be treated

carefully. This also may indicate that applying procedure-oriented metrics to

object-oriented programs. though easy to do (technically). perhaps degrades

the reliability of the results. In our case. since all the other measures

consistently contradict n~o it is safe to regard n1 as erroneous and disregard it.

The table shows that CONSIM is superior to MATLAB' s Control

Systems Toolbox. for the selected quality factors. The differences between the

two programs are between 20 to 40 percent. As explained above. differences of

62

such magnitude are large enough to be considered significant To further

appreciate the significance of the results. the following observations are noted:

a. MA TLAB is a high quality commercial package that was developed by a

professional team over a relatively long period of time. It has gone through

a full life cycle from specification to maintenance and upgrading. This

naturally included customer I user feedback. enhancements. improvements.

debugging. etc. All these greatly facilitated the software·s quality.

b. CONSIM is a proof of concept. experimental program. It was developed by

a single programmer. It did not enjoy the benefits of a full life cycle.

upgrading, customer/user feedback. etc.

Thus. it stands to reason that if CONSIM had been fully developed as a

commercial package. its quality would have been higher than it is at this stage.

This of course strengthens the conclusion that an object-oriented control

system simulator. such as CONSIM will probably have greater quality than that

of a procedure-oriented simulator such as MA TLAB per the quality factors that

were measured.

Based on these results, it is concluded therefore that:

Object-oriented control system simulators have a strong potential for

being of a quality, superior to that of procedure-oriented simulators.

6.5.3.5 Object-Oriented Control Systems Simulators

It was anticipated that control systems simulators are particularly

suitable to the object-oriented approach. Also it was expected that applying

this paradigm to control systems simulators should be beneficial in terms of the

classical software quality factors: Modularity. maintainability. complexity, etc.

The experimental package CONSIM demonstrated the validity of these

assumptions. Applying object-oriented techniques for this program was natural.

Visualizing a control system as a collection of interacting objects is straight

forward. It facilitated easy and simple definition and construction of the

63

classes in the system and the nature of the message passing between them. As

many of the classes described real physical objects, the classes' attributes are

the physical objects' characteristics and the classes' services are the physical

objects' actions.

In control systems there are typically a multiplicity of objects of the

same type such as: many sensors, many actuators, many controllers. etc. This

phenomenon integrates excellently with the object-oriented paradigm.

Object-oriented programs greatly benefit from systems that have a multiplicity

of objects of the same type. This is easily achieved by instantiation of many

objects from the same class.

64

CHAPTER Vll

FUTURE WORK

7.1 General

This chapter provides a brief suggestion of additional work and

extensions that can be done in the area of control system engineering using

object-oriented techniques in general and the CONSIM program in particular.

7.2 Extensions to CONSIM

The various chapters of this report mentioned some ideas for improving

and extending CONSIM. These are briefly covered in the following paragraphs.

7.2.1 Extending the Class Library

Figure 4.1 shows the general class-entity design of CONSIM. It also

shows the portion in that design that was selected for implementation in this

work and the portion that was not implemented. Full and deep design and

implementation of the portion that was not implemented can be a subject for

future research.

7.2.2 User Interface

The basic simulation engine of CONSIM has a very basic user interface.

The additional GUI that was developed for CONSIM (Appendix E), provides an

improved and easier interface. Yet in modern terms, even this user interface is

relatively simple. It is a very natural extension to the present program to add a

powerful modern user interface. Two important issues that should be addressed

in the improved user interface are:

1. Graphical description of the simulated system. The user should be able to

draw the block diagram describing the system. using graphics drawing

tools such as icons.

2. Presentation of results. The user interface should present the simulation

results on the screen dynamically. That is, the output is displayed while the

simulation is running. Also, the output should be displayed as a graph

rather than numbers.

65

7.2.3 Numerical Aspects

in this research. minimum effort was placed on the numerical aspects

of the simulation. This area can be greatly enhanced in CONSIM. issues that can

be addressed are: improved and varied integration algorithms and time step size management.

7.2.4 Multiple Input Multiple Output Systems

The present version of CONSIM is built to handle single input-single

output systems. Modem control systems are rarely this simple. CONSIM should

be able to simulate multiple input-multiple output systems.

7.2.5 Non-Linear Simulation

The real world is not linear. Limiting a simulator to the linear regime

restricts its applicability to initial approximate analysis phase only. Adding

non-linear elements (classes) to CONSIM should be straightforward and will greatly improve its usefulness.

7. 2. 6 Discrete Systems

Modem controllers are digital rather than analog. If CONSIM is unable

to handle discrete systems. it cannot cover the modern world of digital control

systems.

7.3 Extensions to Control Systems Engineering

Like any engineering discipline. control systems also covers all the

classical phases in the development of a project. namely: specification.

analysis. design. simulation. implementation. testing and maintenance. Today

all these phases are strongly computer supported. CONSIM deals with one phase

only: simulation. The industry strongly needs powerful computing tools in the

other phases too. and in particular design (CAD) and implementation

(controllers.)

As this work has demonstrated. using object-oriented techniques for

control system simulation is very beneficial. Therefore. it is reasonable to

expect that similar benefits will be achieved in all other phases of the

development cycle.

66

CHAPTER Vill

SUMMARY

Object-oriented software development is considered by many experts to

be the new generation in software development In fac~ the supporters of this

approach believe that in the coming years it will entirely replace the present

··old .. procedure-oriented paradigm. Practically, very little methodical and

accurate work has been done, comparing these paradigms in order to know

whether indeed object-oriented techniques are superior to procedure-oriented

techniques. Plews [ 1992) is the only example that was found in this research.

This work was an attempt to measure the quality of object-oriented

development. compared to procedure-oriented developmen~ as applied to a

specific engineering area: control systems engineering. The results of the tests

indicated that the object-oriented program, developed in this work has better

quality, in terms of the quality factors that were selected. This result is in

accordance with the tests described in Plews [ 1992].

The positive experience that the majority of professionals have with

object-oriented techniques, together with the results of this work and that of

Plews [ 1992), support the claim that the object-oriented methodology is indeed

promtstng. The problem that was investigated in this research was not a general

problem tn object-oriented techniques. Rather. the applicability of

object-oriented techniques to a specific engineering area was studied. However.

the author believes that the nature of this work and the approach that was

taken in the research, constitute a special case which reflects on the general

case. In other words, the results and conclusions of this work are general enough

as to be extendible to the object-oriented paradigm in general. Thus the

conclusion that object-oriented simulators are superior to procedure-oriented

simulators, is just one more example and one more area where object-oriented

techniques are demonstrated to be superior over procedure-oriented techniques.

The number of such examples in the academic research and in the

commercial application world is increasing rapidly. It gives ever more reason to

believe that the object-oriented promise is indeed fulfilled, at least until the

next generation paradigm.

67

REFERENCES

Adiga S., Glassey C. R.. "Object-oriented simulation to support research in manufacturing systems," International Journal of Production Research. December 1991. Vol. 29, No. 12, p. 2529.

Barker H. A .. Grant P. W., Jobling C., Townsend P., "Theobject-oriented paradigm: A means for revolutionising software development." Computing & Control Engineering Journal, February 1993. Vol. 4, No. 1, p. 10.

Barnes G. M.. Swim B. R., '"Inheriting software metrics,'" Journal of Object-Oriented Programming, November-December 1993, p. 27.

Baveco J. M .• Lingeman R., "An object-oriented tool for individual-oriented simulation: Host-parasitoid system application," Ecological modelling, June 1992 Vol. 61, No. 3/4, p. 267.

Bezevin J.. "Some experiments in object-oriented simulation" SIGPLAN Notices. October 1987, Vol. 22, No. 12, p. 394.

Birtwhistle

1973a.

G. M. et al.. ''SIMULA begin." Student Litterature. Auerbach.

Birtwhistle G. M .• "SIMULA: Its features and prospects," Technical Report No. s-44, Norwegian Computing Center, February 1973b.

Booch G., Object-Oriented Design with Applications, 1991, The Benjamin/Cummings Publishing Company Inc., Menlo Park, CA.

Borgen E., Neerland H., Strandhagen J. 0., "Analysis of manufacturing based on object-oriented discrete simulation." Modeling, Identification and Control, 1990. Vol. 11. No. 1, p. 43.

Briers A. C.. Clements A., "Object-oriented experience with ERIC." Microprocessors and Microsystens.1992. Vol. 16, No. 10, p. 541.

68

Bruck D. M., "Modelling of control systems with C++ and PHIGS,,. USENIX Association, Proceedings of USENIX C++ Conference. 1988, Berkeley. California.

Bums J. R., Morgeson J., "An object-oriented world-view for intelligen~ discrete, next-event simulation," Management Science, December 1988. Vol. 34. No. 12, p. 1425.

Cammarata S. J., Burdorf C., "PSE: An object-oriented simulation environment supporting persistence,'' Journal of Object-Oriented Programming, October 1991, Vol. 4, No. 6, p. 30.

Cellier F. E., Elmqvist H., ,. Automated formula manipulation supports object-oriented continuous-system modeling," IEEE Control Systems Magazine, April 1993. Vol. 13, No. 2, p. 28.

Coad P. , Yourdon E., Object-Oriented Analysis, 1991, Yourdon Press, New

York.

Corbin M. J .. Butler G. F., "Object-oriented simulation in Fortran and ADA,·· UKSC-90, Conference on computer simulation, pp. 63-68, 1990, University of Sussex.

Corbin M. J., Butler G. F., "A framework for multiple continuous and discrete simulations in object-oriented ADA,,. in: Object-Oriented Simulation 1991, Ege R. K. (Ed.), Proceedings of the SCS Multiconference on Object-Oriented Simulation, 23-25 January 1991, Anaheim, California.

Dahl 0., Nygaard K., "SIMULA - am ALGOL based simulation language,,. CACM, 1966, Vol. 9, No. 9, pp. 671-687.

Dahl 0. et al., "Common base language," Publication No. 5-22, Norwegian Computing Center, October 1970.

Dorf R. C., Modem Control Systems, 3rd ed., 1980, Addison-Wesley Publishing Co., Reading, MA.

Ege R. K. (Ed.), "Object-Oriented Simulation.,. Proceedings of the SCS Multiconference on Object-Oriented Simulation, 23-25 January 1991. Anaheim, Calif omia.

69

Eldredge D .• McGregor J. D .• Summers J. D .• ''Applying the object-oriented paradigm to discrete event simulation using C++ language,,. Simulation. February 1990, Vol. 54. No. 2, p. 83.

Elwart S. P .. Martin P. G .• New software structure extend control capabilities,'' Control Engineering, June 1990, Vol. 37, No. 7, p. 16.

Fenton J.. Beck K.. "Playground: An object-oriented simulation system with agent rules for children of all ages," October 1989, SIGPLAN notices, Vol. 24, No. 10. p. 123.

Glassey C .• Adiga S .• ··conceptual design of a software object library for simulation of semiconductor manufacturing system,'' Journal of Object-Oriented Programming, November 1989. Vol. 2, No. 4. p. 39.

Golten and Verwer partners, ··coDAS - II. ontrol System Design and Simulation (for the PC), Version 1.0, Operating manual," 1989, Golten and Verwer partners.

Grace A. et al., Control System Toolbox, User's Guide, 1990, The MathWorks Inc .. Sherborn, MA.

Guasch A. (Ed.), "Object-Oriented Simulation," Proceedings of the SCS Multiconference on Object-Oriented Simulation, 17-19 January 1990, San Diego, California.

Guasch A., Luker P. A .. "SIMBIOS: SIMulation Based on Icons and ObjectS," in: Object-Oriented Simulation, Guasch A. (Ed.), Proceedings of the SCS Multiconference on Object-Oriented Simulation, 17-19 January 1990, San Diego, California.

ffiM, System/ 360 Continuous System Modeling Program User's Manual, program number 360A -CX -16X. IBM Application Program

Kreutzer W., System simulation. Programming styles and languages, 1986, Reading, MA, Addison-Wesley.

Kreutzer W .. Stairmand M .. "C-Flavours: A SCHEME-based flavour system with coroutines and its application to the design of object-oriented simulation software," Computer Languages, 1990, Vol. 15, No. 4, p. 225.

70

Kreutzer W., ''Tiny Tim - a SMALL TALK toolbox for rapid prototyping and animation of models,·· Journal of Object-Oriented Programming, January 1990, Vol. 2, No. 5, p. 27.

Lee K.. Rissman M., D'Ippolito R., Plinta C., Van Scoy R.. "An OOD paradigm for flight simulators," Report CMU/SEI-87-TR-43, December 1987. Software Engineering Institute, Pittsburgh, PA.

Lee K.. Rissman M., "An object-oriented simulation example: A flight simulator electrical system." February 1989, Pittsburgh. PA, Software Engineering Institute.

Lin X.. "Boltzmann: An object-oriented particle simulation programming system," 1990, Ph.D. Dissertation, Los Angeles, University of California, Computer Science Dept

Lin X. A.. Karplus W. J., ''Doing physics simulation in the Boltzmann programming system,'' in: Object-Oriented Simulation 1991, Ege R. K. (Ed.), Proceedings of the SCS Multiconference on Object-Oriented Simulation, 23-25 January 1991, Anaheim, California.

Lydon W. P., "OOP's new role in software for control engineering," Control Engineering, March 1992. Vol. 39, No. 5, p. 46.

McGregorJ. D., Sykes D. A., Object-Oriented Software Development, 1992, Van Nostrand Reinhold. New York.

Mitchell and Gauthier Associates, Advanced Continuous Simulation Language, Reference Manual. Edition 4.1, 1987, Mitchell and Gauthier Associates, Concord , MA.

Mutagwaba W., Tsiflakos K., Mill A., "Object-oriented simulation,·· The Mining Magazine, February 1991, Vol. 164, No. 2, p. 103.

Oloufa A. A., "Modeling operational activities in object-oriented simulation," Journal of Computing in Civil Engineering, January 1993, Vol. 7, No. 1, p. 94.

Ortiz J. L., ''Dynamic modeling using object-oriented programming,·· Master's Thesis, Mechanical Engineering, Texas Tech University, 5 I 1992.

71

Ozden M. H., "Graphical programming of simulation models in an object-oriented environment," Simulation, February 1991. Vol. 56. No. 2. p. 104.

Park J. P.. ··An object-oriented dynamics simulator,'' Ph.D. Dissertation, Mechanical Engineering, Texas Tech University, 8/1991.

Plews M. T .. "Object-Orientation's Claims of Superiority: An Evaluation Using Software Metrics," Thesis, Department of Computer Information Systems, Colorado State University. Fort Collins, Colorado, Summer 1992.

Popken D. A., ''Hierarchical modeling and object-oriented simulation," 1991. D301.45/27-4: 1991-0020.

process u.s.

aggregation in DOCS. NO.

Popken D. A., "An object-oriented simulation environment for airbase logistics," Simulation, November 1992, Vol. 59, No. 5, p. 328.

Saiedian H.. "Object-oriented simulation of CSMA protocols," SIGSMALL/PC notes, Fall 1992, Vol. 18, No. 3/4, p. 4.

Sequeira R. A., Sharpe P. J. H., Stone N. D., El-Zik K. M., Makela M. E., '"Object-oriented simulation: plant growth and discrete organ to organ interactions," Ecological Modelling, November 1991, Vol. 58. No. 1/4, p. 55.

Sher D., Revankar S., Venkatesan R., "An object-oriented model for a radar system simulation." Department of Computer Science, State University of New York at Buffalo, 89-05. 6/1989.

Smith S. P., "A general purpose object-oriented simulation environment,'' 1988, Master's Thesis, Dept of Electrical and Computer Engineering. University of Texas at Austin.

Sommerville I., Software Engineering, 1992, Addison- Wesley Publishing Company, Wokingham, England.

Tang L. S.. ··A CPU scheduling simulation project-form structured programming to object-oriented design," SIGCSE bulletin, March 1992. Vol. 24, No. 1, p. 129.

72

Tang M. X., Smithers T., "An object-oriented simulation of hydraulic power systems," 1991, Edinburgh, University of Edinburgh, Dept of Artificial Intelligence.

Thomasta T.. Mao Y.. Hilbrecht K., Ulgen 0. M.. "Design of an automatic simulation and control program generator," in: Object-Oriented Simulation, Guasch A. (Ed.), Proceedings of the SCS Multiconference on Object-Oriented Simulation, 17-19 January 1990. San Diego, California.

Tittus M., Egardt B., "An object-oriented framework for control system design," Conference publication, 1992, No. 360, p. 135.

Tsiflakos K., Owen D. B., "Simulation of mining systems by object-oriented graphical modelling," Mining Industry Transactions, section a, May 1992, Vol. 101, p. A75.

Ulgen 0. M., Thomasma T., "SmartSim: An object-oriented simulation program generator for manufacturing systems," International Journal of Production Research, September 1990, Vol. 28, No.9, p. 1713.

Valdes R., ''An object-oriented simulation toolkit for the Mac from Imagie That!," BYTE, April 1989. Vol. 14, No. 4 p. 197.

Van der Meulen P.. "INSIST: Interactive simulation in SMALL TALK," SIGPLAN Notices, October 1987, Vol. 22, No. 12, p. 366.

Vangheluwe H. L. M., Verweij J. D., Kerckhoffs E. J. H, "The object-oriented paradigm applied to continuous system simulation," ESC 89, proceedings of the 3rd European Society for Computers conference, 1989.

Vangheluwe H., Vansteenkiste G. C., "Development of an automatic object-oriented continuous simulation environment," International Journal of General Systems, 1991, Vol. 19, No. 3, p. 263.

VanSuetendael N., Elwell D., "Software Quality Metrics," Atlantic City International Airport, N.J., Federal Aviation Administration Technical Center, Springfield, Va., 1991.

73

Weitzenfeld A .• Arbib M. A .. "A concurrent object-oriented framework for the simulation of neural networks." OOPS messenger. April 01 1991 Vol. 2. No.2.

Yoshida T.. Tokoro M.. '"Distributed queuing network simulation: An application of a concurrent object-oriented language;• March 3L 1986, Keio University. Yokohama. Japan.

Zeigler B. P.. Object-oriented simulation with hierarchical. modular models: Intelligent agents and endomorphic systems. 1990. Academic Press. Boston.

74

APPENDIX A

CONSIM - REQUIREMENTS DEFINITION

Description

It is required to produce a program to simulate linear control systems.

The system is of single input single output ( SISO) type. The program will

employ an input file and an output file. Both file names will be specified as

parameters on th command line when running the program.

Control System Description

The specific control system to be simulated is described by means of a

standard block diagram. Each dynamic element in the system is represented

graphically by a single block in the diagram, and mathematically by the

appropriate linear differential equation (the coefficients of the equations.) The

connections between the blocks are represented by arrows. The system has a

single input and a single output.

Input The driving input to the dynamic system to be simulated will be of one

of the following types:

a. Impulse with a selectable gain.

b. Step with a selectable gain,

c. Ramp with a selectable gain.

d. External (in the form of a table of input values versus time values -

residing on a file).

All the input describing the entire system should reside on an input file.

The input data should be in ASCll format so that it can be prepared and edited

using a simple text editor. It should be possible to incorporate comments in the

file, that will facilitate user understanding and be ignored by the program.

75

Output

The program's output will be generated on an output file. It will be

written to the file in ASCD format The structure of the output data will be in

the form of a two column table. The first column will contain simulation time

values. Each number in the second column will be the output value

corresponding to the time value in the same row of the first column.

76

APPENDIXB

CONSIM CODE LISTING

The following pages show the full code listing of CONSIM. The listing is

ordered alphabetically by file name.

77

I /Input data file: MA TLAB manual example DATA.DAT

I/# of dynamic elements~ maximum# of inputs to single dynamic element

19 3

I I type of dynamic elements

1214141111122111444

I I dynamic element coefficients

-.00249 0 0

.1 0 0

.16 0 0

.0071 2.3111 444.4444

100

2.Se-7 .0007 1

2.2350 0 0

4220 0 0

.23 0 0

1.6 0 0

-10 0

100

1 0 0

-1.5 0 0

-250 0 0

-280 0 0

2.066e-5 .0059 1

2.04e-6 .0021 1

2.925e-6 .0034 1

I /input to dynamic elements

000

1 4 5

260

18 0 0

78

600

19 0 0

14 15 16

9 10 0

17 0 0

12 0 0

9 10 0

11 13 0

14 15 16

13 0 0

12 0 0

17 0 0

300

780

13 0 0

I /initial conditions

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

79

00

00

I /Input function, scale factor

6 1

I /input element

1

I I output element

8

I /Start time

0

I /Stop time

1

I /Time step

.001

80

#define GAIN 1

#define INTEGRA TOR 2

#define SPOLE 3

#define DPOLE 4

#define IMPULSE 5

#define STEP 6

#define RAMP 7

#define VECfORFILE 8

#define FUNCilONFILE 9

#include <string.h>

#include <iostream.h>

#include <conio.h>

#include <stdlib.h>

#include <MA TH.H>

#include <queues.h>

#include <stdio.h>

#include ., dpole.h''

#include "gain. h"

#include "integ.h"

#include "spole.h"

#include .. dynel.h"

#include "extin.h"

#include "system.h".

Gain Gainl:

Integrator Integrator!;

Spole Spolel;

Dpole Dpolel;

81

I• DPOLE.H

Double Pole integration routine (super class for all other types of transfer functions)

Written by: Moshe Gotesman •I

class Dpole

{

} ;

private:

protected:

float Compute( float, float, float, float, float, float, float);

public:

float GetResponse( float, float, float, float, float, float, float):

float Dpole::GetResponse( float ICO, float ICl, float Input

.float cl, float c2, float c3, float DeltaTime)

{

return Compute(ICO, ICI. Input, cl, c2, c3, DeltaTime);

}

float Dpole::Compute( float ICO, float ICI, float Input

,float cl, float c2, float c3, float Delta Time)

{

}

float A, B;

A= cli(DeltaTime•DeltaTime);

B = c21Delta Time;

return (Input +(2•A + B)•ICl - A*ICO)I(A + B + c3);

82

I* Dynamic Element class

Written by: Moshe Gotesman •I

extern Gain Gain 1;

extern Integrator Integrator!;

extern Spole Spolel;

extern Dpole Dpolel;

class DynamicElement {

private:

char ElementName[ 80];

int ElementTFType;

float coeffl;

float coeff2;

float coeff3;

float DeltaTime;

float icO;

float icl;

float ComputeResult;

public:

void Response(float);

int SelfTest( void);

DYNEL.H

void SetTFType( int float float float float, float, float);

float GetOutput( void);

} ;

void DynamicElement:: SetTFType( int TFfype,

float cl, float c2, float c3,

float ICO, float ICl, float DT)

{

ElementTFType = TFType:

coeffl = cl;

83

}

coeff2 = c2;

coeff3 = c3;

icO = ICO;

icl = ICl;

DeltaTime = DT;

ComputeResult = 0;

void DynamicElement:Response( float Input)

{

if ( ElementTFType = = GAIN)

ComputeResult = Gainl.GetResponse( icO! icl. lnpu~ coeffl. coeff2! coeff3

.DeltaTime);

if (ElementTFType ==INTEGRATOR)

ComputeResult = lntegratorl.GetResponse(icO. icl. Input. coeffl. coeff2

!coeff3! DeltaTime);

if (ElementTFType == SPOLE)

ComputeResult = Spolel.GetResponse( icO. icl. lnpu~ coeffl. coeff2! coeff3

.DeltaTime):

if (ElementTFType == DPOLE)

ComputeResult = Dpolel.GetResponse( icO. icl. lnpu~ coeffl. coeff2!

coeff3

.DeltaTime):

icO = icl;

icl = ComputeResult;

}

float DynamicElement:GetOutput( void)

{

return ComputeResult;

}

84

•

I* External Input object EXTIN.H Written by Moshe Gotesman •I

class Extlnput

{

} ;

private:

int Type;

float ScaleFactor;

fioa t StartTime;

FILE •pid;

float Timel;

float Time2;

float Inl;

float In2;

char •VectorFileName;

float GetVectorlnput(float);

public:

Extlnput( int, float, float, char *);

float Getlnput(float);

Extlnput:Extlnput(int lnputFunction, float STime, float SF. char •VFN)

{

VectorFileName = VFN;

Type = lnputFunction;

StartTime = STime;

ScaleFactor = SF;

if (Type = = VECfORFILE) I /If input supplied in file, open it

{

if (Vector FileName = = " ") {

puts( "No file name specified for vector input file. \n"):

puts( "Run terminated. \n");

85

}

}

puts( nHit any key. \n"):

getch():

exit( 1):

if ((pid = fopenC~iii.m~\~~r+f~)) ==NULL) I /open vector input file

{

}

puts("~Cannot open vector data input file. Run terminated.\n"):

puts(''Hit any key.\n");

getch();

exit( 1);

fscanf(pid~ ~~%r/or~.&Time1~ &Inl); I /Initialize variables

fseek(pid~ 1, 1);

f scanf( pi d. "%f'/or~. &Time2. &ln2);

}

else I /If input NOT supplied in file. just initialize unneccessary variables

{

}

pid =NULL;

Time1 = 0;

Time2 = 0;

Inl = 0;

In2 = 0:

I /Decide input value based on input type

float Extlnput::Getlnput(float InstTime)

{ if {Type== IMPULSE)

{ if ( InstTime = = StartTime) return ScaleFactor:

else return 0;

} if (Type== STEP) return ScaleFactor:

86

}

if (Type = = RAMP) return lnstTime*ScaleFactor;

if (Type== VECfORFILE) return GetVectorlnput(InstTime);

return -1;

float Extlnput:GetVectorlnput(float InstTime)

{

if (InstTime == Timel) return lnl; I /If required time= time entry in file

else if ( lnstTime = = Time2) return In2;

else I /Find 2 time entries in file between which lnstTime resides

{

}

}

while ( InstTime > Time2)

{

fseek(pid. L 1);

Time I = Time2; I /update Timel to be ··right behind·· InstTime

Inl = In2;

fscanf(pid. "%r'lof"'.&Time2. &In2);

}

I /Interpolate table in Input file

return ln2 + (Inl - ln2)*(1nstTime- Time2)/(Timel - Time2);

87

GAIN.H

Gain integration routine (sub class of Dpole)

Written by: Moshe Gotesman *I

class Gain: public Dpole

{

} ;

private:

public:

float GetResponse( float, float, float, float, float, float, float);

float Gain::GetResponse( float ICO! float ICl! float Input

!float cl, float c2! float c3! float DeltaTime)

{

}

c3 = 1/cl:

cl = 0;

c2 = O:

return Compute(ICO! ICl! Input, cl! c2! c3! DeltaTime):

88

I* INTEG.H

Integrator integration routine (sub class of Dpole)

Written by: Moshe Gotesman *I

class Integrator : public Dpole

{

} ;

private:

public:

float GetResponse(float, float, float, float, float, float, float);

float lntegrator::GetResponse( float ICO, float ICI, float Input

,float cl, float c2, float c3, float Delta Time)

{

}

c2 = cl;

cl = 0;

c3 = 0;

return Compute(ICO, ICI, Input, cl. c2, c3, DeltaTime);

89

I •main( ) file SIM.CPP Written by: Moshe Gotesman •I

#include "defin. h"

void main( int argc~ char •argv[])

{

FILE •fp;

float 000~ jjj = 0~ Times[3] = {0~ 0~ 0};

clrscr( );

if (argc < 3)

{

puts("Must supply input and output file names.\n");

puts( "Use format sim inputfilename outputfilename\n");

puts( ~~Program term ina ted\n");

puts( "Hit any key\n~~);

getch();

exit( -1);

}

if (argc == 3) argv[3] =" ": I /No input vector

System System 1 ( argv[ 1] ~ argv[ 3]);

System 1. GetTimes( Times);

if ((fp = fopen(argv[2],"wt")) ==NULL)

{

} ;

puts('~Cannot open file. Run terminated. Hit any key.\n"):

getch();

exit( 1);

puts( "\n\n");

fprintf(fp, "%C %f\r'\ Times[O]. O);

for (float SimTime = Times[O]; SimTime <=Times[ 1];

90

}

{ SimTime = SimTime + Times[2])

float DeltaOut;

Delta Out = (Times[ 1] - Times[ 0]) I 1 000;

000 = System 1. Run( SimTime);

if (SimTime- jjj >= DeltaOut)

{

} ;

cout < < ~~Time = " < < SimTime < < •• ~ 000 = ~~ < < 000 < < ~·\r"; fprintf(fp~ "%f %f\n·· ~SimTime.OOO);

jjj = SimTime;

}

fclose(fp);

putsC•\nHit any key to continue\n••); getch();

91

I* SPOLE.H

Single pole integration routine (sub class of Dpole)

Written by: Moshe Gotesman *I

class Spole : public Dpole

{

} ;

private:

public:

float GetResponse( float, float, float, float, float, float, float);

float Spole::GetResponse( float ICO, float ICl, float Input

,float cl, float c2, float c3, float DeltaTime)

{

}

c3 = c2;

c2 = cl;

cl = 0;

return Compute(ICO, ICl, Input, cl, c2, c3, DeltaTime);

92

I •System object SYSTEM.H Written by Moshe Gotesman •I

class System

{

private:

int •TFfype;

float •Coeff;

int •Input;

float •IC;

int InputEI;

int OutputEI;

float StartTime;

float Stop Time;

float Delta Time;

int InputFunction;

float ScaleFactor.

int NooffiynEI;

int NoofCols:

DynamicElement * PDynamicElement:

int •POrder,

float InstTime;

Extlnput •PExtlnput;

void SetOrder( void);

int FindChildren( in~ int *) ;

float Findlnput( int);

void GetData( char *);

public:

System( char *, char *): void GetTimes( float *);

float Run( float);

};

System::System( char •InputFileName, char •VectorFileName)

93

{

GetDa ta( lnputFileName);

InstTime = StartTime;

I /Instantiate External input objext

PExtlnput = new Extlnput( lnputFunction. StartTime, ScaleFactor

. Vector FileName); if ( !PExtlnput)

{ I /Check for allocation success

}

cout < < "System::PExtlnput: allocation failure\n";

cout < < "Hit any key\n'';

getch();

exit( -1);

I /Instantiate NoofDynEl DynamicElement objects

PDynamicElement =new DynamicElement[NoofDynEl];

if ( !PDynamicElement) I /Check for allocation success

{

}

cout < < "System::PDynamicElement: allocation failure\n";

cout < < ·'Hit any key\n";

getch();

exit( -1);

for (inti = 0; i < NoofDynEl; i++) I /Setup DynamicElement objects

{

}

PDynamicElement[ i]. SetTFType( TFType[ i], Coeff[ i* 3 + 0], Coeff[ i• 3 + 1]

,Coeff[i•3 + 2], IC[i*2 + 0], IC[i*2 + 1]

,DeltaTime); I /3 columns in Coeff matrix;

I /2 columns in IC matrix

SetOrder(); I /Set the order in which the dynamic elements will be visited

94

}

void System:: GetDa ta( char * InputFileName) {

FD..,E •pdf;

char ch = '/';

int i. j:

if ((pdf= fopen(InputFileName,"r+t")) ==NULL) I /open input file {

};

puts( "Cannot open data input file. Run terminated. Hit any key. \n"); getch();

exit( 1);

while ((ch =='/')II (ch == '\n') II (ch == '\r')) {

}

while ( ch != '\n') { ch = getc( pdf); }

ch = getc( pdf);

ch = '/':

fseek(pdf, -1, 1):

fscanf(pdf, "%d%d''.&NoofDynEl, &NoofCols); I /read NoofDynEl,

NoofCols

I I Allocate memory for and initialize all arrays

TFType = new int[ NoofDynEl];

if ( !TFType)

{

cout < < "System::GetData:TFType: allocation failure\n";

cout < < "Hit any key\n";

getch();

exit( -1);

95

}

for ( i = 0; i < NoofDynEI; i + +) { TFType[ i] = NULL; }

Coeff =new float[3•NooffiynEl];

if (!Coeff)

{

}

cout < < ~system::GetData:Coeff: allocation failure\n~;

cout < < "Hit any key\n'';

getch();

exit( -1);

for (i = 0; i < NooiDynEl; i++) { Coeff[3•i] =NULL; Coeff[3•i + 1] =NULL;

Coeff[ 3•i + 2] = NULL; }

Input= new int[NooiDynEI•NoofCols);

if (!Input)

{

}

cout < < "System::GetData:Input allocation failure\n~;

cout < < "Hit any key\n'';

getch();

exit( -1);

for ( i = 0; i < NoofDynEl* NoofCols; i + +) { Input[ i 1 = NULL; }

IC =new float[2•NoofDynEl];

if (!IC)

{

}

cout < < "System::GetData:IC: allocation failure\n~;

cout < < "Hit any key\n";

getch();

exit( -1);

for (i = 0; i < NoofDynEl; i++) { IC[2•i] =NULL; IC[2*i + 1] =NULL; }

96

while ((ch == '/') II (ch == '\n') II (ch == '\r')) {

while ( ch != '\n') { ch = getc(pdf); }

ch = getc( pdf);

} I I read dynamic elements types matrix ch = '/'; fseek(pdf, -1, 1);

for ( i = 0; i < NoofDynEI; i++) {

fscanf(pdf, "%d", &TFType(i]);

}

while ((ch =='/')II (ch == '\n') II (ch == '\r')) {

}

while ( ch != '\n') { ch = getc(pdf); }

ch = getc( pdf):

ch = '/':

fseek(pdf, -1, 1);

for ( i = 0; i < NoofDynEI; i + +) I I read dynamic elements coefficients

{

fscanf(pdf, "%f"lof"lof", &Coeff[3•i], &Coeff(3•i + 1], &Coeff[3•i + 2]);

}

while ((ch =='/')II (ch == '\n') II (ch == '\r'))

{

}

while ( ch != '\n') { ch = getc(pdf); }

ch = getc( pdf);

ch = '/'; fseek(pdf, -1, 1);

for (i = 0; i < NoofDynEl; i++) I /read dynamic elements inuts

{

for (j = 0; j < NoofCols; j++)

97

}

{

fscanf(pdf, "%d", &Input[i•NoofCols + j]); }

while ( ( ch == '/') II ( ch == '\n') II ( ch == '\r')) {

}

while ( ch != '\n') { ch = getc(pdf); }

ch = getc( pdf);

ch = '/';

fseek(pdf, -1, 1):

for (i = 0; i < NoofDynEI; i++) I /read dynamic elements initial conditions {

fscanf(pdf, "%CO/of", &IC[2•i], &IC[2•i + 1]); }

while ((ch == '/') II (ch == '\n') II (ch == '\r'))

{

}

while ( ch != '\n') { ch = getc(pdf); }

ch = getc( pdf);

ch = '/'; fseek(pdf, -1, 1);

fscanf( pdf, "%d%f", &lnputFunction, &ScaleFactor); I I read lnputFunction

and

I I ScaleFactor

while ((ch =='/')II (ch == '\n') II (ch == '\r'))

{

}

while ( ch != '\n') { ch = getc(pdf); }

ch = getc( pdf);

ch = '/';

98

fseek(pdf! -1, 1);

fscanf( pdf. '!%d" !&InputEI); I I read InputEI

while ( ( ch == ! /!) II ( ch == !\n!) II ( ch == '\r')) {

}

while ( ch != !\n!) { ch = getc(pdf); }

ch = getc( pdf);

ch = • /'; fseek{ pdf. -1, 1);

fscanf( pdf. "%d". &OutputEJ); I I read OutputEI

while ((ch =='/!)II (ch == !\n') II (ch == '\r'))

{

}

while ( ch != !\n') { ch = getc(pdf); }

ch = getc( pdf);

ch = • /'; fseek{pdf. -1, 1):

f scanf( pdf, "%f". &StartTime); I I read StartTime

while ( ( ch == '/') II ( ch == '\n') II ( ch == '\r!))

{

}

while ( ch != '\n!) { ch = getc(pdf); }

ch = getc( pdf);

ch = ! /';

fseek{pdf. -1, 1);

fscanf( pdf! "%f" .&Stop Time); I /read StopTime

while ( ( ch = = ! /') II ( ch = = ! \n!) II ( ch = = • \r'))

{

while ( ch != !\n') { ch = getc( pdf); }

ch = getc( pdf);

99

}

ch = • /'; fseek(pdf, -1, 1);

fscanf(pdf. "%f",&DeltaTime); I /read DeltaTime

f close( pdf);

}

void System::GetTimes( float *Times) I /Provide main Time loop times {

}

Times[ 0] = StartTime;

Times[ 1] = Stop Time;

Times[2] = DeltaTime;

void System::SetOrder( void) I /Set the order in which the dynamic elements

I /will be visited

{

BLQueueAsVector<int> GT; I /Set up FIFO queue for bfs traverse

int POrderlndex = 0, found;

POrder = new int[ NooffiynEl]; I I Ordred list of elements will be placed in

I /this array

if ( !POrder)

{

I /Check for allocation success

}

cout < < "System::Run:POrder: allocation failure\n";getch();

exit(-1);

for (inti = 0; i < NooffiynEl; i++) POrder[i] = 0; I /Initialize POrder

GT.put(InputEl); I /Graph traverse always begins at InputEl

while ( POrderlndex < NoofDynEl) I /While POrder not complete

{

int NextEl, * PChildren, PChildrenlndex;

100

PChildren =new int[NooffiynEI]; I /NextEl's children will be placed in

I I this array

if ( !PChildren)

{ I /Check for allocation success

cout < < "System::Run:PChildren: allocation failure\n";getch(); exit( -I);

} ;

NextEl = GT. get(); I I Get the next element in the queue found= 0;

for ( int k = 0; k < = POrderlndex; k + +) I I Check if element at head of

I I queue is not already in POrder {

if ( POrder[ k] = = NextEI)

{

} ;

}

found= I;

break;

I /NextEI already in Porder

if (!found)

{ I /NextEI not in Porder

inti = 0;

POrder[POrderlndex] = NextEl; I /Put NextEI in POrder

1 /Find children of POrder[ POrderlndex]

PChildrenlndex = FindChildren( POrder[ POrderlndex], PChildren);

POrderlndex++;

while ( i < PChildrenlndex)

{

}

} ;

GT. put( PChildren[ i]);

i++;

I /Insert children in queue

101

}

}

puts( "Order of elements visiting:~~);

for ( int j = 0; j < NoofDynEl; j++) { cout < < POrder[j] < < " ";} puts( "\nHit any key");

getch();

int System::FindChildren(int Father~ int •PChildren) 1 /Find children of

Father

{

int PChildrenlndex = 0;

for ( int i = 0; i < NoofDynEl; i++) PChildren[ i] = 0; I /Initialize PChildem

for (int RowNo = 0; RowNo < NoofDynEl; RowNo++) I /Search Input for

children

}

{

}

for ( int ColNo = 0; ColNo < NoofCols: ColNo++)

{

I /If true: RowNo is a child

I /(Input[RowNO*NoofCols + ColNo] = lnputd[RowNo][ColNo]

if (abs(Input[RowNO*NoofCols + ColNo]) ==Father)

{

}: }

PChildren[PChildrenlndex] = RowNo + 1; I /RowNo + 1 =

I /Dynamic Element #

PChildrenlndex+ +:

return PChildrenlndex;

float System::Run(float ITime)

{

float Ellnput;

102

}

InstTime = ITime;

for (inti = 0; i < NoofDynEI; i++)

{

Ellnput = Findlnput( POrder[ i]);

PDynamicElement[ POrder[ i] - 1]. Response( Ellnput); }

return PDynamicElement[ OutputEl - 1]. GetOutput();

float System::Findlnput( int Element)

{

}

float Totallnput = 0;

I I if element is lnputEl. Get current external input

if (Element== POrder[O]) Totallnput = PExtlnput->Getlnput(InstTime);

for (inti= 0; i < NoofCols; i++) I /Search Inputs matrix to sum up input

{

I /Input[ (Element - 1) * NoofCols + i] = lnputd[ Element - 1] [ i]

if (Input[ (Element - 1)*NoofCols + i])

{

} ;

}

if (Input[ (Element- 1)*NoofCols + i] > 0) Totallnput = Totallnput

+ PDynamicElement

[ (Input[ (Element - 1) * NoofCols + i]) - 1]. GetOutput();

if (Input[ (Element- 1)*NoofCols + i] < 0) Totallnput = Totallnput

- PDynamicElement

[abs(Input[(Element- l)*NoofCols + i]) - l).GetOutput();

return Totallnput;

103

APPENDIXC

NUMERICAL INfEGRA TION ALGORITHM

The integration algorithm solves for a full complex pole type of

equation. By proper manipulation of the equation~s coefficients. the above

algorithm will integrate any other type of equation (gain. integrator. real pole).

The differential equation to be integrated has the form:

ay +by+ cy = x

where:

x- Independent variable (or input)

y- Dependent variable.

a. b~ c - Coefficients.

( 1)

A discrete approximation of a derivative of y is:

. _ Y2- Yt Y2- ~t ·

Similarly:

.. _ Yz- yl Y2- ~t ·

(2)

(3)

Placing (2) into (3) with appropriate indexes and rearranging give:

104

&&12 J,M!b22!22E~&'h.L:..:

.. _ Y2 - 2Yt + Yo Y2- (~t)2 . ( 4)

Placing (2) and ( 4) into ( 1) with appropriate indexes gives:

a Y2 - 2Yt + Yo + b Y2 - Yt _ (~t)2 ~t + CY2- X (5)

and upon rearranging:

Expression ( 6) was implemented in service Compute of the Dpole class.

The values of Yo and Yt for times to and th respectively. are set to be 0.

It is easy to see that other types of equations are special cases of the

above case. Using the following changes of the coefficients a, b, c, this

expression can be used as is for other types of equations:

For a pure gain: a = b = 0, c = i where K is the gain.

For integrator: a = c = 0.

For single pole: a = 0.

Each of the Gain. Integrator and SinglePole classes performs the

appropriate coefficient manipulation using its GetResponse service. and then

executes the expression ( 6) by using service Compute of class Dpole.

105

APPENDIXD

APPLICATION OF HALSTEAD·s METRICS

Modules

The following are lists of modules used for the test

Control System Toolbox CONSIM

blkbuild.m define.h append.m dpole.h connectm dynel.h damp.m extin.h impulse.m stm.cpp expm.m system.h int2str.m gain.h lsim.m integ.h nargchc.m spole.h roots.m

Counts

The following lists show the unique operators (nt) and operands (n2) in

CONSIM and MA TLAB Control System Toolbox. Operators and operands in the

lists are separated by a single white space. In cases where an operator or an

operand appears more than once in a list it means that these occurrences were

in different modules and did NOT represent the same operator or operand.

Also. a count named "minimum necessary number of unique operands" (n;),

which is a subset of n2 is required. The operands which belong to n; are

underlined in the lists for n2.

MA TLAB Control System Toolbox

Opera tors n 1

[] , = (call) (precedence) CR/LF for-end (from:to) " ; (:) if-end-= - * + \

(element) = = ' . I A - % I < > < = ./

106

Operands n2

File blkbuild.m

a b c d tf2ss clear append ibb9 2 ')' ii9 int2str aa9 bb9 cc9 dd9 eva I 'tf2ss( n' ',d'

File append.m

mal nal size al mdl ndl dl ma2 na2 a2 md2 nd2 d2 aa zeros bb bl b2 cc

cl c2 dd

File connect. m

mq nq q md nd d k i 1 qi find m n abs !r sign aa bb cc dd a b c d iu eye t

File damp.m

wn z a m n r eig roots error 'must be a ... ' cos imag log

File impulse.m

y x a b c d iu t nargs nargin 3 6 nargchk abcdchk dt aa bb c2d n length

ltitr

File abcdchk.m msg abc d rna na 'The A must . .' mb nb 'The A and B .. .' me nc 'The

A and C .. .' md nd 'The C and D .. .'

File c2d.m

phi Gamma a b t m n nb s expm

File expml.m e as norm inf 0 max fix X n c e d q p qpl q2pl k eX

File int2str.m

s n sprintf .Of

File length. m

1 X

107

File lsim.m

x y a b c d u t xO 4 5 m n ns nx 7 min

File menu.m

k sO sl s2 s3 s4 sS s6 s7 s8 s9 slO sll s12 s13 s14 slS s16 disp i ~blank~ ~r 's' " input 'select a ... '

File nargchc. m

msg low high number 'Not enough ... ' 'Too many ... '

File roots. m

r c n sum ~Must be ... ' inz nnz a diag ones

File step.m

y x a b c d iu t impulse a2 b2 c2 d2 series sa

File series.m

a b c d al bl cl dl a2 b2 c2 d2

File tf2ss.m

mal nal ma2 na2 abc d num den mnum nnum mden n inz 'Numerator ... '

return

File J?ltin.m run_sys index_sys in__no iu iy loop Q keyboard (coefficient)

File pltsys.m initplt i sqrt nblocks blkbuild al_eq bl_eq cl_eq dl_eq connect abc d

File plttime.m

in_type time input_gain time_resl

108

CONSIM

Opera tors n 1

Gainl Integrator! Spolel Dpolel ; (call) return:: () , = 1 * + - {} : if-then ==

'"'% & while-end><[] \n \r for-end<=>= new!<<++ II!= %d RLQueue abs

Operands n2

File define. h

Gain Integrator Spole Dpole

File dpole.h

ICO ICl Input cl c2 c3 Deltaime (return) Compute ICO ICl Input cl c2 c3 DeltaTime A B (return)

File dyne I. h

TFType cl c2 c3 ICO ICl DT ElementTFType coeffl coeff2 coeff3 icO icl

DeltaTime ComputeResult 0 Input ElementFType Gain ComputeResult

Integrator SPOLE DPOLE ComputeResult

File extin. h

InputFunction STime SF VFN Vector FileName Type StartTime ScaleFactor

VECfORFILE "" puts "No file name ... " "Run terminated.'' "Hit any

key ... " getch exit pid fopen "iii.m" "r+t" NULL "Cannot open ... " fscanf

"%rlof" Timel Inl fseek Time2 In2 lnstTime IMPULSE ScaleFactor STEP

RAMP GetVectorlnpot -llnstTime Inll (return)

File gain.h

ICO ICl Input cl c2 c3 DeltaTime (return)

File integ. h

ICO ICl Input cl c2 c3 Delta Time (return)

File sim.cpp argc argv clrscr 3 puts "Muat supply ... " "Use format .. " "Program

terminated ... " "Hit any key ... '' getch exit Times fp fopen "wt" "Cannot

109

open ... " "\n\n" fprint %f \r ··%f.%f\r" SimTime DeltaOut 1000 000 jjj "%f %f\n·· fclose

File spole.h

ICO ICl Input c1 c2 c3 Delta Time (return)

File system.h

InputFileName Vector FileName GetData lnstTime PExtlnput Extlnput cout

''System:PExtlnput. .. " "Hit any key\n'· getc '\r' PDynamicElement

DynamicElement "System: PDynamicElement. ..• , i SetTFType 2 SetOrder

InputFileName pdf '\n' "Cannot open ... " ch '/' NoofDynEl NoofCols

TFfype "System:GetData ... " Coeff "System:Coeff ... " Input

"System:GetData .... , IC ··system:GetData ... " "%d" TFType "%rlorlof" Coeff

Input OutputEl IC ··%d%f•• InputFunction ScaleFactor InputEI "%f"

StartTime StopTime DeltaTime Times GT Porder "System:Run ... " i GT.put

POrderlndex Pchildren ••system: Run ... " NextEl GT.get found k break

PChildrenindex FindChildren Father Pchildren i RowNo ColNo abs

PChildrenindex ITime i Ellnput Findlnput POrder (return) Element

Totallnput Getlnput i GetOutput Totallnput

Calculations

The following calculations derive Halstead's metrics from the above

counts:

MA TLAB Control System Toolbox

n1 = 30

n2 = 285

• n2 = 109

N = n1lnn1 + n2lnn2 = 30ln30 + 285ln285 = 1713

V = Nln(n1 + n2) = 1713ln(30 + 285) = 9854

V* = (2 + n;)ln(2 + n;) = (2 + 109)ln (2 + 109) = 523

110

" v· 523 L = V = 9854 = 0.0531

" E = v = 9854 = 185574 L .0531

CONSIM

Ot = 40

02 = 222

• 02 = 108

" N = Otlnnt + o2loo2 = 40lo40 + 222ln222 = 1347 " " V = Nlo(ot + 02) = 1347lo( 40 + 222) = 7501

v· = (2 + o;)lo(2 + o;) = (2 + 108)10 (2 + 108) = 517

,.. v· 517 L = V = 7501 = 0.0689

E = v = 7501 = 108868 L .0689

111

APPENDIXE

THE GRAPHICAL USER INTERFACE

The following pages bring a short description of the various windows of

the graphical user interface ( GUI.) Each window is shown the way it appears

during typical use. including typical data. The data are the same as those in file

DATA.DAT in Appendix B. The resulting graph, shown here is for this data

file. Compare this graph with the one appearing in Chapter VI.

112

Main Window

Transfer Function T gpes T ranafer Function Coefficients Inputs and Output Transfer Function Initial Conditions Tinaes

R~mFile

c: \•aster\si•\verl\new\sim.exe

Input File c: \•aster\sim\ver3\new\data2. dat

Output File c: \•aster\si•\verl\new\ooo.•

ector Input File

Run Draw I I Exit I

The Main window is the first window that appears as the program is

launched. It contains the main menu. The menu enables the user to move

through the various windows of the application. The top portion of the window

(inside the frame) is the main menu.

Any 1/0 files the user selects for the simulation (using the Files

window), appear in the Main window, as shown. (Vector Input File is not

selected in this example.) At this stage, the user can start the simulation by

pressing the Run button. The user can then view a graph of the output by

hitting the Draw button. Exit terminates the GUI.

113

Files Window

I Dioplf lnpuiFile II Get Input Fie I Get Run File II Save Input File I

Eel Vec:lmlnput r3 ~~~---

dala2.dat delin.h dpole.h d,nelh ellin.h gain.h ... inleg.h

Input File Title

l~c: (MS-... ] [!) ~c:\ IOIMIIer to-s• C7ver3

;.c.. new

Input data fie: MATLAB ....al

The Files window is used to select the various 1/0 files for the run. The

bottom half of the window is a MS-WINDOWS standard file selection box. The

user uses this box to highlight an 1/0 file and then clicks the appropriate button

to designate what is the function of the highlighted file. Save Input File saves

the highlighted file. Display Input File displays the input file in the Display

window. The bottom left field in the window displays the input file title as it

appears in the file to facilitate easy identification of the file. Main returns to

the Main window.

114

Transfer Function Types Window

I• of dJnaric ~-..... of -1 I of DJMIIic Elellents: Ma I oii"JUs:

D

Types:

11 2141411111 2 2111 u 4

Main

The Transfer Function Types Window is the window in which the user

enters the data for the types of the transfer functions in the system. When an

input file is selected, these data automatically appear in the appropriate fields,

and then can be edited, if necessary.

115

Transfer Function Coefficients Window

II Tran;fer Function CoeHicienls aD] I

jdtnaK ._ coellicienls

~.002490 0 .1 0 0 .1600 .11071 2.3111 444.4444 100 2.5e-7 .10171 2.UJOOO 4220 0 0 .23 0 0 1.600 ·1 0 0 100 100 ·1.5 0 0 ·250 0 0

The Transfer Function Coefficients Window is the window in which the

user enters the data for the coefficients of the transfer functions in the system.

When an input file is selected, these data automatically appear in the

appropriate fields, and then can be edited, if necessary.

116

Inputs and Output Window

Scale Factor D Input function .. I

IIUUUIUl Ele...t ~ output ....

Inputs to Ele.els

input to dyna.ic ele.ents

000 145 260 18 0 0 GOO 19 0 0 14 1516 910 0 17 0 0 12 0 0 910 0 1113 0 141516 Wain

The Inputs and Output Window is the window in which the user enters

the data for the inputs and output of the system. When an input file is selected

these data automatically appear in the appropriate fields, and then can be

edited, if necessary.

117

Initial Conditions Window

-----........... --. ............... . . 98 · ............................... . :au :: :::::::::: :::::: :::::::::::: ::: . 110 . ............................... . o o o o o o t o to o o o o to o o to o o o ott o o o o o o t o 1 o

. -8 0 . ............................... . ·.o·o . ..... .... ........ .... ... . .... .

• o 0 0 0 0 0 0 0 0 0 o 0 0 0 0 0 0 I 0 0 0 o o 0 o 0 0 o 0 0 0 0 0

: 11 ~ :: :::::::: ::::::: ::::::::: :: ::::: .0 9 ... ......... ..... ' ......... ..... .

· ·oo · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · • • • •••••• • ••• 0 •• • ••••• 0 •••••• 0 •••••

1) 8 . . ... . .... ................. . .... . :au ·:::::::::::::::::::::::::::::::: . 110 .. . ......... ............... . .... . 0 o • 0 o 0 0 0 t o 0 0 0 0 0 0 0 o 0 0 It 0 0 0 0 0 0 0 0 0 0 0 0 0 0

· to · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · . .o· 0. . ..... ................... .. ... . 0 0 I 0 0 0 0 0 0 0 0 0 0 0 o 0 0 0 0 0 0 0 I 0 0 0 0 0 0 0 0 0 0 0

: :~~ :::::: :::::: ::::::: ::::: ........ :

- -•• 0 ••• ••• 0 • • • • • • • • • 0 •••••• 0 • . 0 • • • • • • • • -........... 0 ........... 0.... .

The Initial Conditions Window is the window in which the user enters

the data for the initial conditions of the transfer functions in the system. When

an input file is selected~ these data automatically appear in the appropriate

fields. and then can be edited. if necessary.

118

Times Window

Start Tile ~:...~ -----J

Stop Tilej ..._1 __ ---J

Tille Step 1.001 I

~

The Times Window is the window in which the user enters the data for

the main loop times for the simulation. When an input file is selected. these

data automatically appear in the appropriate fields. and then can be edited, if

necessary.

119

Display Window

OJOIO), O.IDDQO.OOUDI-O.IE20 0.002101 -0.0012(1; 0.004(0) -0.003614 O.lmDJ -0.115345 0.(1&0) -0.007406 0.00710) -0.009767 O.OO!IDI -0.015233 O.OUIDJ -0.018249 0.011(0) -0.021392 0.0121DJ -0.024614 0.01. -0.027870 0.01--0.031115 0.0151DJ -0.034309 0.0171DJ -0.040388 0.01f01) -0.0432(1; o.m• -0.045837 0.(J2lDIJ -0.048256 0.021(0) -0.050440 0.0221DJ -O.Mn 0.02DII -0.054034

The display window is a general editing window in which the user can

inspect and edit the entire input file, rather than work on portions of it in

various windows.

120

Draw Window

Time Response 1.5 r-----,-----,----.----r-------.

1.0 / -'-

Output I 02 06 0 B 10

-o.s ...____---~. __ __,_ __ __.__ __ ...1..,._ _ ___J

time

Main

The Draw Window displays the simulation output on graphical form.

121