What Is a System and Why Model Systems?

We have discussed that at the core of the mechatronic world is a mechanical system. We have all come across terms such as engineering systems, trans-mission system, transportation system, digestive system, fi nancial system,

system engineering, and so on. These are terms used in different domains with the common theme being the concept of a “system.” A system may be defi ned as an entity that is separable from the rest of the universe (the environment) through physical and/or conceptual boundaries. The system boundary is a logical separation between what is inside the boundary and what lies in the outside world. Although a system is separable from the sur-roundings, it can interact with the surroundings (Karnopp, Margolis, and Rosenberg, 2006). Systems can receive information and energy from the outside world and also send out information and/or energy (Figure 1.4).

Systems may be made of interacting parts such as subsystems, and sub-systems are made of components. For example, an automobile can be considered an engineering system that interacts with the surroundings.

It receives input from the surroundings such as input from the driver, fric-tion from the road, and wind drag; it releases exhaust and heat, makes noise, and so forth. The automobile is made of many subsystems such as the drive train, transmission, brakes, and more. These subsystems are in turn made of components such as pistons, gears, bearings, and pumps, for example. While systems are made of components (or subsystems), a system is much more than just the sum of all its parts. Even though the parts that make up a system can be well designed and work well independently, it does not necessarily mean that the system will function well when these components are all put together. Ensuring that the system functions well after assembly is not a trivial task and has to be done well. For a successful fi nal product, a “systems viewpoint” is therefore very important.

Systems are dynamic as nature; that is, with the passing of time their behavior changes in response to varying external inputs. So understanding any system’s dynamic behavior is much more important than knowing its static behavior. An understanding of system behavior is a core requirement of taking a “system viewpoint.” Models of systems are very useful tools for understanding dynamic behavior of systems. System models may be

FIGURE 1.4

Schematic showing system, system boundary, and inputs and outputs.

Information input

Information output Power input

Power output System

Environment

Boundary

scaled physical models or mathematical models. Scaled physical models may be physical prototypes and provide a hands-on understanding of system behavior. For many real-life systems, building physical models may often be cost prohibitive or not possible for other reasons. At the conceptual design stage, building a physical model is not possible either. Mathematical models are much cheaper to construct and are extremely powerful if they are constructed properly. Building useful mathematical models requires a good understanding of system behavior at the component level, and the model builder needs to make realistic assumptions. Just as the name sug-gests, a model is a representation of a system, but it is not necessarily the whole system. Models always involve some simplifi cations that are a result of assumptions made by the developer. The actual assumptions may vary from one situation to another, but some of common approximations that are typically used for system modeling are

Neglect small effects: Include the dominant effects but neglect

•

effects that have relatively small infl uence.

Independent environment: The environment is not affected by

•

what happens in the system.

Lumped characteristics: Physical properties for system

compo-•

nents are assumed to be lumped even though they are, in reality, distributed across the geometry.

Linear relationships: Constitutive relationships are assumed to be

•

linear over the range of operation of the system even though, in reality, they may not be exactly linear.

Constant parameters: Parameters defi ning component properties

•

are assumed to be constant.

Neglect uncertainty and noise: Any uncertainty or noise in the

•

data are neglected.

As a result of making these assumptions, the governing equations in the system model turn out to be a set of linear ordinary differential equations with constant parameters. The solutions of these ordinary dif-ferential equations are relatively easier to obtain, and they describe the dynamic behavior of the system. If these simplifying assumptions are not made, the equations would be a set of nonlinear partial differential equa-tions with time and space varying parameters. This later set of equaequa-tions would perhaps yield a more accurate mathematical model of the system, but would not be very useful because these types of equations are much harder to solve. Without good and effi cient solution techniques, the model would not yield results that would be useful for engineers. The advan-tages gained by making the simplifi cations far outweigh the bits of infor-mation that get lost due to these assumptions.

Mathematical system models and their solutions become powerful tools in the hands of system designers. They can be used for answering differ-ent questions such as:

Analysis: For given input and known system (and state variables),

•

what would be the output?

Identifi cation: For given input history, the output history is known;

•

What would the model and its state variables be?

Synthesis: For given input and a desired output, can a system be

•

designed (along with its state variables) such that the system per-forms the way desired?

Learning how to develop useful system models takes time and experi-ence. We therefore go about the three listed activities in the order that they are stated. Beginning system modelers spend a lot of time learning to “analyze” systems. Only after a good bit of experience do they ven-ture into system “identifi cation.” And “synthesis” requires the maximum amount of experience in the fi eld.

Because a model is somewhat a simplifi cation of reality, there is a great deal of art in the construction of models. An overly complex and detailed model may contain parameters virtually impossible to estimate and intro-duce irrelevant details that may not be necessary. Any system designer should have a way to fi nd models of varying complexity so as to fi nd the simplest model capable of answering the questions about the system under study. A system could be broken into many parts depending on the level of complexity one needs. System analysis, through a breakdown into its fundamental components, is an art in itself and requires expertise and experience.

In this book we will go through a systematic methodology of develop-ing models of engineerdevelop-ing systems so that their dynamic behavior may be studied. Unless otherwise specifi ed, we will always make the assump-tions that we have discussed here. Model development and its use will be focused mainly towards the process of analyzing system behavior.

We hope that with some practice in the area of system analysis, students would be ready to start tasks in system identifi cation and design.

1.3 Mathematical Modeling Techniques Used in Practice Many different approaches have been used in the development of system models. One of the most common methods is deriving the state–space equations from fi rst principles, specifi cally Newton’s laws for mechanics, Kirchoff’s voltage and current laws for electrical circuits, and so forth. These

different equations are then numerically solved to obtain system responses.

There are several graphical approaches that are popular among different technical communities. One approach is linear graphing, where state–

space equations are modeled as block diagrams connected by paths show-ing the fl ow of information from one block to another. Figure 1.5 shows a SIMULINK model of a permanent magnet DC motor built by joining differ-ent SIMULINK function blocks with proper information fl ow paths.

Control engineers also like to use a block diagram approach, but with the Laplace transformed form of the governing equation. This can be called the transfer function form, and the operations are carried out in the s, or frequency, domain rather than the time domain.

An important step in all of these methods is the derivation of the gov-erning relationships. Within a single domain (ME, EE, etc.) deriving the governing equations may not be diffi cult because we may be within our specifi c area of expertise; but when we work in a multidomain environ-ment, it becomes somewhat more diffi cult for someone who is not suitably trained. The root cause of this diffi culty is in how we have been trained.

Within each discipline of engineering, system representation and solution techniques have evolved along different paths. We are trained to think that statics, dynamics, circuit analysis, electromagnetism, hydraulics, and so on are different subject areas where different solution techniques are used for problem solving. These artifi cial barriers between disciplines highlight the differences without providing a hint of the underlying simi-larities that are much more prevalent than the perceived differences.

This concept of similarities among different disciplines has been used in the modeling method called bond graphs. Bond graphs represent fl ow of power within the system, and the bonds that tie together different parts of the model are called power bonds. This method looks similar to the signal fl ow graph method but is not quite the same. The biggest dif-ference is in what the bonds represent. In the signal fl ow approach, the

FIGURE 1.5

A signal fl ow diagram of a permanent magnet DC motor modeled in SIMULINK.

1

bonds that connect different blocks in the model transmit information about a single variable. In bond graphs the bonds transmit information of two variables, the product of which is power. Figure 1.6 shows the bond graph representation of the same motor whose signal fl ow model is shown in Figure 1.5.

In our presentation here we have chosen the bond graph approach to model systems. The most important reason for this is that within the bond graph method, basic components that make up systems in different disciplines may be represented using a few generalized components. The similarities that already exist among the different disciplines are used very effi ciently by this method. Thus, this method is very well suited for modeling mechatronic systems. Bond graph method is based on the fl ow of power. Power is a product of two quantities, force and velocity or voltage and current (these are called effort and fl ow as generalized quantities). Every component in a mechatronic system has to deal with these two quantities that make up power. Drawing of the bond graph representations is algorithmic and, as a result, the user can become pro-ductive quite quickly. The derivation of equations from the bond graph representation of a system is algorithmic as well, so a computer program can easily do it. Even if the user has to derive the mathematical equations, the algorithmic approach is a lot more robust and confi dence generating for the user than any other method. All these advantages make the bond graph method a very powerful tool for modeling mechatronic systems.

Figure 1.7 shows a schematic of how the bond graph method works.

A bond graph model showing power fl ow among different system com-ponents is drawn. The bonds are assigned causal information to the bonds. This leads to the process of deriving the governing equations for the system. The equations, also called the state–space equations, are a set of coupled ordinary differential equations. These equations are solved numerically (usually). And the solution provides information about sys-tem response.

FIGURE 1.6

A bond graph representation of a permanent magnet DC motor.

Se

1.4 Software

Several commercial software tools use bond graphs to model systems 20Sim, Symbols2000, AMESIM, and CAMP-G are four such tools. Using the editing features of these tools the user may build up the bond graph model and then perform necessary simulation studies. Most of these tools have an object-oriented modeling feature as well. This means, for exam-ple, that if the user wants to use a motor in a model, an object icon for a motor already exists in the software database and the user just needs to add it to the model. This feature makes modeling even easier for people who do not want to deal with the details of what happens within these objects but want to focus entirely on putting together a system model.

Underneath the object icon, though, the model is still bond graph based in these tools.

In this text we have used 20Sim for all the simulation models and analy-ses results that have been reported. This is only because the author is most familiar with this particular tool and has had a very pleasant experience working with it. 20Sim has a very user-friendly editing capabilities that the user can build a bond graph model with quite quickly. The solution algorithms are robust as well as fast. The user can quickly visualize the result of their work. Users can easily revise the constitutive relationships for all the basic components in order to model advanced behavior. One of the things I have to tried to do throughout the text is perform simulations

FIGURE 1.7

Flowchart showing the bond graph based modeling process.

Mechatronic system

Bond graph representation

of system

Causality assignment Derivation of

system equations

Solution of equations

System response

and demonstrate how the simulation results look for almost every example model that has been developed. I feel this is necessary for students learning this technique for the fi rst time. In the example simulations included in the book, I have not put great effort in using exact representative data. In a few cases when such data was readily available, I have made use of it. But in many others, I have made it up using engineering judgment. Also, in some example simulations, I have specifi ed units for parameters and in others I have not. In cases where units are not specifi ed, parameters used are still in consistent units; throughout this text I have used SI units only.

Problems

1.1. Choose a mechatronic system or subsystem. Some possible examples are steer-by-wire, autofocus camera, disk drive, scan-ner, and microwave. Study the physical system (if available) and or information about the system carefully to understand the sys-tem boundaries, what type of input the syssys-tem receives, and what output it provides. If you designed such as system, what would possible design specifi cations be? What are some of the design constraints? What sensors and actuators would be used in this system?

1.2. One of the mechatronic systems that has been in the news a lot is the Mars Rover. The Mars Rover has been very successful in a harsh environment and at a remote location. Research the Mars Rover, and identify the different components that make this a mechatronic system. Also research how the designers achieved the solution to tough design problems associated with the Mars Rover and its mission.

1.3. Many of the systems in today’s automobile have transitioned from purely mechanical to mechatronic systems. Pick one such system, and identify how the task this system did was done in the old design versus how it is done in the newer version. What compo-nents are replaced and with what have they been replaced?

13

2