Graph Grammar Based Automated Virtual Lab for Bond Graphs

A Major Qualifying Project

Submitted to the Faculty of Worcester Polytechnic Institute

in partial fulfillment of the requirements for the degree in

Bachelor of Science

in Mechanical Engineering By

Daniel Grande

And

Bachelor of Science in Mechanical Engineering and Robotics Engineering

By Felice Mancini

Advisor

Pradeep Radhakrishnan Date: 4/28/2016

This report represents work of WPI undergraduate students submitted to the faculty as evidence of a degree requirement. WPI routinely publishes these reports on its web site

without editorial or peer review. For more information about the projects program at WPI, see http://www.wpi.edu/Academics/Projects.

i

Copyright Information The work presented here is copyrighted by Daniel Grande, Felice Mancini, and Professor

Pradeep Radhakrishnan.

ii

Abstract

This project presents a graph grammar based automated tool that can generate bond graphs

of various systems for dynamic analysis. A generic graph grammar based representation scheme

has been developed for different system components and bond graph elements. Using that

representation, grammar rules have been developed that enable interpreting a given system and

generating a bond graph through an algorithmic search process. Besides, the project also

demonstrates the utility of the proposed tool in classrooms to enhance value in bond graph based

system dynamics education. This classroom use case will allow for users to see multiple valid bond

graph solutions and compare a user bond graph to a computer generated one. The potential for a

desktop program presenting a user friendly interface and state equation solving is also presented

here. The underlying technique, various examples and benefits of this automated tool will be

highlighted.

iii

Acknowledgements

We would like to acknowledge the contributors to Graphsynth, for providing us with an

open source program that served as the base for the creation of our Major Qualifying Project. Also

we would like to acknowledge Professor Pradeep Radhakrishnan for his constant support,

assistance, and enthusiasm throughout the project. Finally, we would like to acknowledge

Worcester Polytechnic Institute for providing us with the tools and opportunities to pursue this

learning experience.

Executive Summary

Our Major Qualifying Project (MQP) is the development of a graph grammar based

automation tool that can generate bond graphs for electromechanical systems. Students and

professionals can use this tool to help perform different analyses on complex, multi-domain

systems. The design process is a complex and time consuming activity that can take teams of

engineers to perform. Because of recent advancements in computational capabilities, some phase

of the design process can be automated, such as the conceptual design phase and analysis phase.

There are multiple examples of programs that automatically synthesize different system designs,

including gear trains, planar mechanisms, and manufacturing process plans. There are also

multiple tools that can analyze these designs.

Of the multitude of methods to model systems, the bond graph approach to modelling is

one of the most versatile since it can be applied to multiple energy domains, including mechanical,

electrical, and hydraulic domains, as well as combinations of these domains. Bond graphs are

especially useful for generating dynamic response, since differential equations can be generated

from this type of model. Because of the graph-based nature of deriving the bond graph for a system,

graph grammar rules can be used to convert a user-defined system into a bond graph. This graph

grammar approach is what was ultimately chosen to perform our desired task of generating bond

graphs from a system. An overall outline of the process is shown below.

Figure 1 Simplified causal bond graph generation process

v

The program first requires a graph that represents a system. The user inputs this system

graph by selecting the system elements and adding them to the graph. The elements are then

connected to one another using arcs, in the same manner that the elements are connected in the

system. Once the system graph is complete, the program can automatically convert the system

graph into a causal bond graph. This is accomplished through the use of grammar rules and rulesets

that were developed in Graphsynth, an open-source graph grammar tool. Multiple rules were

developed to account for multiple system elements. Below is an example of a rule.

Figure 2 Example rule for converting a Mass system element to a Mass bond graph element

When this rule is applied, the program will search for all system elements labelled “Mass”, and

convert that element into a 1-junction with an attached I element. All of the rules developed follow

this application procedure.

The rulesets were organized in a manner that rules pertaining to converting from system

elements to bond graph elements were applied first. The graphs were then simplified, and

directionality is applied to the bonds. Finally, causality is applied to the resulting bond graph. The

rules within the rulesets are ordered in a specific manner since some rules depend on a prior rule

being applied. In some cases, there are small subsets of rules responsible for certain tasks, such as

simplifying junctions with flow through. The rule application order is crucial in these cases.

vi

In order to test our rules, we input a variety of different electrical and mechanical systems.

These systems include an electrical circuit, a half-car model suspension, a Baja vehicle suspension,

motorcycle transmission selector, hydraulic elevator, and rack and pinion system. These systems

were primarily used to debug our rules, and in some cases design new rules to account for particular

issues that arose within those systems. This facilitated the creation of a robust set of rules that can

account for multiple elements.

One of the goals of this MQP was to have the program produce differential equations and

system response graphs from the resulting system bond graph. One proposed method of doing so

involved a search process run on the bond graph that would develop the state equations, and

running a Matlab instance from within our program to run functions such as dsolve() to solve the

equations and ode45() to plot the response of the systems. Unfortunately, due to time constraints

in our project, implementing differential equations and system responses was not implemented,

although it is technically possible.

A desktop program is currently in development that is to be used to generate and analyze

causal bond graphs. This desktop program will use the rules that were developed in Graphsynth,

however the user interface will be more intuitive and designed for easy placement of system

elements and connecting elements. Another feature planned is for the user to create a bond graph

derived from a system manually, and then have the program generate the bond graph from the

system and compare the two bond graphs.

One of the purposes of this MQP was to begin development of a program that can be used

by students and professional engineers. State equations and system parameter editing can be added

in the future to make this tool more appealing to professional engineers wishing to quickly analyze

systems, and for students learning bond graph modelling techniques. The current desktop program

vii

that has been developed supports a basic implementation of showing multiple valid bond graph

solutions and comparing a student’s bond graph to a computer generated bond graph. Although

many rules were developed as part of this MQP, more testing will need to be done and potentially

more rules added as unique situations may come up when the program simplifies systems. Other

recommendations to those improving upon this MQP are automatic conceptual design automation,

further development of showing multiple bond graph solutions, and expansion on state equations

and system responses. The implications of this MQP can potentially be beneficial for engineers

and students.

viii

Table of Contents

Copyright Information...........................................................................................................i

Abstract..................................................................................................................................ii

Acknowledgements................................................................................................................iii

Executive Summary..............................................................................................................iv

List of Figures.......................................................................................................................ix

List of Tables.........................................................................................................................xi

Introduction..........................................................................................................................2

Graph Grammar Representation.........................................................................................6

Grammar Rules...................................................................................................................13

Example Systems..................................................................................................................27Example 1: Electrical System........................................................................................................27Example 2: Half Car Model..........................................................................................................29Example 3: Baja Vehicle Suspension Analysis..............................................................................32Example 4: Motorcycle Transmission Selector Analysis..............................................................36

Example 5: Hydraulic Elevator Analysis.............................................................................40

System Response Simulation................................................................................................47

Desktop Program.................................................................................................................49

Future Use............................................................................................................................57

Recommendations................................................................................................................60

Conclusions..........................................................................................................................63

References............................................................................................................................64

Authorship...........................................................................................................................66

ix

List of Figures Figure1Simplifiedcausalbondgraphgenerationprocess...........................................................ivFigure2ExampleruleforconvertingaMasssystemelementtoaMassbondgraphelement....vFigure3Overviewofthegraph-grammarmethodforgeneratingbondgraphs...........................4Figure4Graphgrammarrepresentationforamass-spring-dampersystem(a)blockdiagramfor

massspringdampersystem(b)graphgrammarrepresentationusingnodesandarcs........7Figure5Graphgrammarrepresentation(a)genericbondgraphbetweentwojunctions(b)

correspondinggraphgrammarrepresentation......................................................................8Figure6RepresentationforCausalityofCelement(a)bondgraphrepresentation(b)graph

grammarrepresentation........................................................................................................9Figure7Representationforparallelcomponentsbetweentwoendnodes(a)system

representation(b)graphgrammarrepresentationusing"PAR"label.................................10Figure8Representationforelectricaljunctions(a)circuitdiagram(b)graphgrammar

representationwhere"E_Junction"labelforthenodereferstotheelectricaljunction.....10Figure9Representationfor1junctionsadjacenttoTF(a)bondgraph(b)graphgrammar

representationusing"TFEnd"label......................................................................................11Figure10GrammarruleforconvertingMassinsystemnotationtobondgraph(a)denotesthe

nodethatwillberecognizedbyGraphSynth(b)ruleresult................................................13Figure11Flowchartdescribingdifferentrulesetsandtheirsequenceofapplication................14Figure12(a)Systemdiagramofarackandpinionsystem[14](b)correspondingsystemgraph

..............................................................................................................................................15Figure13(a)Un-simplifiedGraphobtainedafterapplyingruleset1(b)correspondingbond

graph....................................................................................................................................17Figure14(a)Graphsimplifiedleavingoutflow-throughjunctionsafterapplyingruleset2(b)

correspondingbondgraph...................................................................................................19Figure15(a)Graphwithdirectionalityafterapplyingruleset3(b)correspondingbondgraph

notation................................................................................................................................20Figure16(a)Simplifiedgraphwithdirectionsandeliminatingflowthroughjunctionsafter

applyingruleset4(b)correspondingbondgraph................................................................21Figure17(a)Firststagecausalityassignment(b)correspondingbondgraphnotation..............22Figure18Causalbondgraphwith"RFlag"label..........................................................................23Figure19(a)Causalgraphafterfirstcorrectionattempt(b)correspondingbondgraph...........24Figure20FinalCausalgraphgeneratedusingthesearchprocesscorrespondingtothebond

graphshowninFigure19.....................................................................................................26Figure21ActualbondgraphcorrespondingtothegrammarbasedgraphshowninFigure18..26Figure22:Electricalcircuitdiagram[18]......................................................................................27Figure23:Graphsynthinputoftheelectricalcircuit....................................................................28Figure24:Graphsynthoutputoftheelectricalcircuit.................................................................28Figure25Standardbondgraphnomenclatureforelectricalcircuit............................................29Figure26Systemdiagramforahalfcarmodeltounderstandpitch-planecharacteristicsofan

automobile[15]....................................................................................................................30Figure27SystemgraphforthesystemshowninFigure26........................................................30Figure28Causalbondgraphforthehalf-carmodelshowninFigure26andFigure27..............31Figure29Bajavehiclesystemdiagram........................................................................................33

x

Figure30Bajavehiclewordbondgraph......................................................................................34Figure31GraphsynthcausalbondgraphofBajavehicle............................................................35Figure32Systemdiagramofmotorcycletransmission...............................................................37Figure33Wordbondgraphofmotorcycletransmission.............................................................38Figure34Graphsynthbondgraphofmotorcycletransmissionsystem.......................................39Figure35Traditionalbondgraphofmotorcycletransmission....................................................40Figure36Hydraulicelevatorconfiguration..................................................................................41Figure37Hydraulicelevator-raisingelevatorwordbondgraph................................................42Figure38HydraulicElevator-raisingelevatorGraphsynthbondgraph.....................................43Figure39Hydraulicelevator-raisingelevatorstandardbondgraphnomenclature..................44Figure40Hydraulicelevator-loweringelevatorwordbondgraph............................................44Figure41Hydraulicelevator-loweringelevatorGraphsynthbondgraph..................................45Figure42Hydraulicelevator-loweringelevatorstandardbondgraphnomenclature...............45Figure43:ExecutingMatlabcodefromC#..................................................................................47Figure44EntryscreenoftheAutomatedVirtualLab..................................................................50Figure45ListoftasksavailablefortheuserintheAutomatedVirtualLab.................................50Figure46First-stagebondgraphobtainedwithoutsimplification..............................................51Figure47Simplifiedbondgraphshownwithdirections..............................................................51Figure48CausalbondgraphforthesystemshowninFigure46................................................52Figure49Listofpossiblestatesinthesystem.............................................................................52Figure50Athree-statecausalbondgraph..................................................................................53Figure51Firststagebondgraphoftherackandpinionbasedsystem[14]................................53Figure52Simplifiedbondgraphoftherackandpinionsystemwithdirections.........................54Figure53Causalbondgraphshownwithfour-states,wherethepinioninertiaelementisin

integralcausality..................................................................................................................54Figure54Causalbondgraphwithrackinertiaelementinintegralcausality..............................54Figure55Causalbondgraphfortherackandpinionsystemwithreducedstates.....................54Figure56(left)Systemgraphofthemass-spring-dampersystem(right)bondgraphsolution

givenbytheuser..................................................................................................................55Figure57Optiontocheckiftheuser'sbondgraphsolutioniscorrect.......................................55Figure58Basiccheckandresultstableaftercomparingthesystemgeneratedbondgraphand

theuser'ssolution................................................................................................................56Figure59Potentialforthemethodasalearningtool.................................................................59

xi

List of Tables Table1ListofmajorcomponentsusedinelectricalandMechanicaldomains.............................6

2

Introduction

Development of an engineering system is a complex activity that spans several stages and

teams. The teams are involved in gathering customer requirements, generating design concepts,

carrying out basic analysis (static and dynamic), selecting final design, performing detailed

analysis and building prototypes eventually leading to the manufacture and delivery of that system.

These are time consuming and iterative processes. In recent times, due to improved computational

capabilities, there has been an increasing trend towards the research and the development of tools

that can automate various activities in design and analysis and many have been reported in

literature. Some of them include automatically generating system designs using a conceptual

framework for gear trains [1], planar mechanisms [2] and manufacturing process plans [3]. On the

commercial front, tools such as SolidWorks [4], ANSYS [5], Working Model [6], ADAMS [7],

20sim [8], Dymola [9], etc. enable automation of various design and analysis activities hitherto

carried out manually. There are also mathematical tools such as Matlab [10] and physical modeling

languages such as Modelica [11] that can be used independently or also coupled with various other

analysis tools.

One of the challenging aspects in the automation space involve automatically synthesizing

system designs and subsequently analyzing those designs. In order to do so, a method to reliably

model the system is required, which can then be used to generate the dynamic characteristics. Of

the energy based techniques available for modeling and subsequent analysis of systems, the bond

graph approach is generally preferred because of its ability to handle multiple energy domains

especially systems in the electrical, mechanical and hydraulic domains. Not only that, the bond

graph technique is very generic, can be easily adapted in an algorithmic form and appropriate

differential equations representing the system can be generated. In this regard, Rinderle and

3

Balasubramaniam [12] proposed a component based framework for automating modeling and

analyzing systems using the bond graph technique. Wu et al [13] demonstrated a method to

automatically generate conceptual design as well as analyze the generated systems using the bond

graph method. A genetic algorithm was used to encode the bond graph of the system, generate

equations and subsequently dynamic response.

In this paper, a generic graph grammar search-based approach to generate bond graphs of

systems is presented. A flow chart of the sequence of operations in its current form of development

are presented in Figure 3.

The first step in the process is to depict the system with all its components. All the system

information is converted into a graph. This graph is then subject to various grammar rules in a

search process, which form the backbone of our approach. The grammar rules contain the basic

bond graph generation rules from literature [14, 15] as well as the logic to iteratively generate the

bond graph, complete the relevant flow-through simplifications and assign causality.

Figure 3 Overview of the graph-grammar method for generating bond graphs

[14]

5

At the end of the search process, the method is able to successfully present the bond graph

with relevant causal strokes. The eventual goal of this research is to integrate conceptual system

design as well as integrate into classroom education, which will further be elaborated in the

discussion session. The graph grammar representation used in our approach is developed using

GraphSynth [16] and the same tool is used to demonstrate this implementation and makes use of

a lot of its in-built graph manipulation functions.

The next section on representation details the scheme and rules followed by a detailed work

through using an example rack and pinion system. Additional examples will be provided along

with discussion on the potential of this approach as a desktop program and in a learning

environment followed by concluding remarks.

6

Graph Grammar Representation

The first step in the process is to represent various system components as well as bond

graph elements and junctions using graph grammar. Major components in the mechanical and

electrical domains have been chosen as we demonstrate the feasibility of our approach. Table 1

shows the different components in the two energy domains considered.

Table 1 List of major components used in electrical and Mechanical domains

Electrical Mechanical

Inductor Mass/ Flywheel

Resistor Spring

Capacitor Damper

Voltage

Source

Input

Force/Velocity

Current

Source

Levers

Transformer Gearing

Each of these components are essentially represented using a node (shown using a small

circle filled with black color in the figures here) in graph terminology. In graph grammar notation,

every node has a label, which is used to attribute a suitable function or characteristic. In this case,

that label is the component name. The labels are also used to describe other aspects of the

component. For instance, in order to model the compliance in a shaft, “Include_Stiffness” label is

appended to the component node. Similar labels are used to identify friction, bearing damping and

7

other characteristics. An example of a mass spring system and its equivalent graph grammar

notation are shown in Figure 4.

(a)

(b)

Figure 4 Graph grammar representation for a mass-spring-damper system (a) block

diagram for mass spring damper system (b) graph grammar representation using nodes

and arcs

As shown in the figure, these component as well as force/velocity nodes are connected using arcs

(edges). In addition to the components, applied forces, torques, velocities in the mechanical system

as well as input voltage and current sources in the electrical system are also included in the

representation.

The system graph thus developed requires to be converted to a graph containing different

bond graph elements such as Inductors (I), Capacitors (C), Resistors (R), effort sources (Se), flow

sources (Sf), Transformers (TF), and Gyrators (GY). 1 and 0 junctions are used to model the effort

(force) and flow (velocity) changes through various nodes in the system. Each of the bond graph

elements and junctions are represented using nodes and their characteristic (I, C and so on) as

labels. For instance, consider the two generic junctions A and B as shown in Figure 5a.

8

(a) (b)

Figure 5 Graph grammar representation (a) generic bond graph between two junctions (b)

corresponding graph grammar representation

Figure 5a shows the bond graph representation while Figure 5b depicts the graph grammar

version of the same. Here you can see that we are using each node to represent the two junctions

and labels are used to represent the junction detail (like “A” and “B”). “A” and “B” can represent

different junctions (1, 0, TF and GY) and elements (I, C, R) in the actual bond graph and

correspondingly converted as labels in the graph notation. There are also two arcs that are used to

connect the two nodes. Both are directed arcs and one of them has label “dir” to indicate the power

flow just as it is done in bond graph. The other arc has a label “none” just to ensure that during the

search process, the recognition algorithm of GraphSynth does not interfere with the intended logic.

Figure 6 shows how causal stroke is incorporated in our representation. The labels used

for causality are “2” and “3” labels on arcs and nodes. A “2” label symbolizes the causality is

pointing away from the node, or a flow is being imposed on the element (the causal stroke is not

adjacent to the node). On the other hand, the “3” label symbolizes the effort being applied causality

as shown in Figure 6. Here again the direction shown on the arc does not relate to the power

direction indicated by any bond and is just used to guide the search process.

9

(a)

(b)

Figure 6 Representation for Causality of C element (a) bond graph representation (b)

graph grammar representation

This number convention is used both on nodes for junction evaluation, and it is applied to

the arc of the element. As shown in Figure 6, the default causality applied to a C element will

generate a “3” label at the node connecting to the rest of the system, and the “C” on the capacitor

arc will be replaced with “C3.” These labels are crucial to properly evaluating causality and will

be clear while explaining grammar rules and their flow. To improve readability, the “dir” labelled

arcs are later removed, and their direction is expressed relative to causality on the causality arcs.

So a causality arc with the label “OPP” indicates direction is pointed in the opposite direction of

the location of causality, while the label “SAME” indicates directionality is pointing in the same

direction as the location of causality.

If there are two component nodes that are in parallel between the same end nodes as shown

in Figure 7a, where there is a spring and a damper in parallel between say two masses, the user

can indicate that condition using “PAR” label as shown in Figure 7b. The node with label “1” is

used to connect the end nodes while the node with 0 junction is used to connect C and R bond

graph elements.

10

(a)

(b)

Figure 7 Representation for parallel components between two end nodes (a) system

representation (b) graph grammar representation using "PAR" label

When designing electrical systems, a special “E_Junction” label is used (shown in Figure

8). This label denotes points in the graph where it is important to take note of the voltage or current.

Nodes with the label act as user placed junctions between components in an electrical system.

Often times many of these junctions are removed as flow through junctions, however there are

cases where the presence of the junction is necessary between multiple components to present the

correct bond graph.

(a)

(b)

Figure 8 Representation for electrical junctions (a) circuit diagram (b) graph grammar

representation where "E_Junction" label for the node refers to the electrical junction

11

When TF elements are used in a system, they are often flanked by two 1 junctions as shown

in Figure 7. These 1 junctions sometimes don’t have any elements attached from them except for

the next connected junction, and are thus liable to be removed via flow through or simplified if the

adjacent junction is of the same type. This is valid, however for readability these rules are designed

to leave the 1 junctions attached to transformer elements, even if they are flow through junctions

or have an adjacent junction that is the same. This is accomplished through a temporary “TFEnd”

label to signify the end of a transformer element. Nodes with this label will be ignored by

simplification, and once simplification is completed this label will be removed.

(a)

(b)

Figure 9 Representation for 1 junctions adjacent to TF (a) bond graph (b) graph grammar

representation using "TFEnd" label

A special ruleset has been created that analyzes the components in the system and generates

their basic state variables. This does not go through each component step by step and generate

state equations for each variable. The rules are designed to identify all the state variables and add

an arc with a label that is the state variable. These rules also add the basic equations for generating

relationships for each component. For example, a spring element would have an arc attached to it

with the follow label:

𝐺𝑟𝑎𝑝ℎ𝑠𝑦𝑛𝑡ℎ𝑁𝑜𝑚𝑒𝑛𝑐𝑙𝑎𝑡𝑢𝑟𝑒: 𝐹_𝑐 = 𝑘𝑥

𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑𝑁𝑜𝑚𝑒𝑛𝑐𝑙𝑎𝑡𝑢𝑟𝑒:𝐹: = 𝑘𝑥

There would also be an arc with a node with the state variable. The label on the node would be:

12

𝐺𝑟𝑎𝑝ℎ𝑠𝑦𝑛𝑡ℎ𝑁𝑜𝑚𝑒𝑛𝑐𝑙𝑎𝑡𝑢𝑟𝑒: 𝑥_𝑑𝑜𝑡

𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑𝑁𝑜𝑚𝑒𝑛𝑐𝑙𝑎𝑡𝑢𝑟𝑒:𝑥

These state variables could in a future implementation be passed to Matlab, where the system

response could be modeled.

13

Grammar Rules

The representation scheme illustrated in the previous section is the basis for various

grammar rules. These grammar rules use labels to perform different operations starting from the

system graph to generate bond graphs with causality. The grammar rules not only incorporate all

the bond graph rules from literature but also include logic defining rules such that the whole

process is generic and can be used on any system. The grammar rules work by recognizing a certain

label present in a graph, and then performing an operation.

(a)

(b)

Figure 10 Grammar rule for converting Mass in system notation to bond graph (a) denotes

the node that will be recognized by GraphSynth (b) rule result

Figure 10 shows an example rule as to how a node with label “Mass” is converted from the

system graph to a graph with bond graph elements. In the figure, the rule looks for nodes with the

label “Mass” and replaces them with the nodes and arc on the right side of the figure, the right side

of the rule. The node labeled “1” takes the place of the “Mass” node in the graph. The arc labeled

“I” and the node labeled “I:,M” are then added to the graph, connected at the “1” node. The “1”

label on the node is the bond graph label used for mechanical mass elements. The “I” label on the

arc is used to symbolize that this element is of the “I” inductance type. This is in preparation for

applying causality later on as causality does not apply based upon the actual object in the graph,

but rather just the objects type. Also, the label “_Mass” is used to identify all system components

and their bond graph equivalents for easy readability. For example, all I elements (mass, inertia,

electrical inductors) have causality applied the same way. The “1” label does not specify the type

14

of element for causality, and the “I:,M” labels also contains the “M” label. The “I:” portion of the

“I:,M” could be used to identify the item type without focusing on the item itself (identify that the

item is of I type, ignore that it’s a mass), however the system of placing the item type label on the

arc was developed for simplicity. The “I:,M” labels are used to show what the type the item is and

what the item actually is (type: I, item: Mass) [17].

The grammar rules thus developed are organized into rulesets each performing different

functions. There are thirteen rulesets (not including the state variable ruleset) with many rules

under each set. Figure 11 describes how these rulesets interact to generate a causal bond graph

from the given system graph.

Figure 11 Flow chart describing different rulesets and their sequence of application

We will explain this section using the example given in Figure 10a below.

15

(a)

(b)

Figure 12 (a) System diagram of a rack and pinion system [14] (b) corresponding system

graph

The development of a causal bond graph begins at the system level with a user creating a graph

using intuitive terms such as spring, damper, or mass. In this case, the system is a rack and pinion

based system with an input torque at pinion side while the rack is stabilized by a spring. Each

component has different properties identified – for instance the rack its mass; pinion – pitch radius,

mass moment of inertia; spring – spring constant; shaft – material stiffness constant. Gravity is

neglected in this system. Now this system is then represented as a graph as shown in Figure 10b.

It can be seen that every component is represented using nodes and the context in labels. For

example, the rack is sliding with friction in the original system diagram. Therefore, the node in the

system graph has labels “Gear_Rack”, “Include_Friction”, “Include_Mass” to completely

replicate the system. The next step in the process is to transform the labels and nodes in the system

graph to their bond graph equivalents. Before this is done, rules are run to check the validity of the

16

system. When designing systems, rules are run to check to make sure basic errors in the system

are not present. A rule is run to check for the presence of a ground junction in a system, or the

presence of a node labeled “NoGround” in the system. Every system should have a ground point,

or this requirement should be manually overridden by the user through the use of a “NoGround”

node. If these requirements are not met, the rules for generating a causal bond graph will be

prevented from running. Another check performed by the rules is a check for any disconnected

nodes. If there are nodes present that are not connected to anything, the causal bond graph

generation rules will not run. Exceptions to this rule are the “NoGround” junction, as it is simply

an override and only needs to be present and shouldn’t be connected to anything, and a junction

labeled “Gravity,” as it also shouldn’t be connected to anything and should just be present to apply

gravity to mass objects in the system. This ruleset is repeated on the system graph to convert all

the components to the initial bond graph as shown in Figure 13.

(a)

(b)

Figure 13 (a) Un-simplified Graph obtained after applying ruleset 1 (b) corresponding

bond graph

This is very similar to how it is done manually without simplifying all energy flow through

junctions. The corresponding bond graph that was manually drawn is shown in Figure 13b. The

resulting graph is referred to as the “Un-simplified bond graph”.

Simplification is the next step. It is important that accurate and thorough simplification is

performed to assign correct causality later on. Simplification occurs in two different rulesets. The

simplification rules (ruleset 2) look for a set of different cases of un-simplified junctions. In the

first case, it looks for is adjacent junctions of the same type, this being two 1 junctions connected

to one another or two 0 junctions connected to one another. These can be condensed into a single

junction, where the elements connected to one of the junctions are moved to the other, and the

junction that all the elements came from is then removed. This is handled over four rules for any

18

adjacent 1 junction and four rules for any adjacent 0 junctions. The rules use unique labels to mark

the junctions being simplified. The junction that will have all the arcs moved to it will be labeled

“4,” and the junction that will have the arcs moved from it will be labeled “5.” The arcs will then

be moved from the junction labeled “5” to the junction labeled “4”, leaving the junction labeled

“5” without any arcs. This junction can therefore be safely removed, and there will no longer be

adjacent junctions of the same type. The “4” label will be removed once the process is complete.

The rules work the same for each junction type from any energy domain.

Similarly, there are rules to simplify parallel components and grounded junctions. Junctions

that are labeled “PAR” by the user are recognized by the rules as being in parallel. These junctions

can be simplified, and this is accomplished using custom labels for this situation. A “6” label is

assigned to one parallel junction, and a “7” label is attached to the other parallel junction. At the

junction labeled “7” a new arc with a node attached is added, and the new node is labeled “8.” This

node labeled “8” will be were the parallel components will be moved to. All the components

attached to the nodes labeled “6” and “7” are attached to the node labeled “8,” leaving no

components attached to the nodes labeled “6” or “7.” At this point, the node labeled “6” can be

removed, giving accurate parallel component simplification. At this point the remaining “PAR,”

“7,” “8,” and “start” (used to prevent looping rule application) are removed.

The resulting simplified graph is shown in Figure 12. It can be seen that the rules

successfully find and correct adjacent 1 junction from the source of effort and the I element, and

combine those into one 1 junction that has both the source of effort and the I element attached.

(a)

(b)

Figure 14 (a) Graph simplified leaving out flow-through junctions after applying ruleset 2

(b) corresponding bond graph

The next step in bond graph simplification is to remove flow through junctions. These

junctions are two port 1 or 0 junctions that have one bond flowing in and one bond flowing out.

Consequently, power flows through them without any change, thus making the presence of these

junctions unnecessary. However, these junctions can only be removed if power flows in from one

side and out the other. If power flows in from one side and in from the other side, or out from one

side and out from the other, the junction cannot be removed. Therefore, directionality is necessary

to observe the flow of power and make flow through decisions. Directionality rules in ruleset 3

have been designed to assign directionality, and then the second-stage simplification is performed

using ruleset 4. The rack and pinion bond graph after applying ruleset 3 is shown in Figure 13 and

after applying ruleset 4 is shown in Figure 14.

(a)

(b)

Figure 15 (a) Graph with directionality after applying ruleset 3(b) corresponding bond

graph notation

(a) (b)

Figure 16 (a) Simplified graph with directions and eliminating flow through junctions after

applying ruleset 4 (b) corresponding bond graph

At this stage, the bond graph should be fully simplified, and therefore the next step is to

assign causality. The causality assignment is governed by 8 rulesets and in itself is a search process

within the overall search process. Causality application begins by applying default or preferred

causality (using ruleset 5) for all items except for resistors (which of course can have integral or

derivate causality). Since causality depends on the item type (for example, an I element), and not

the element itself (Mass or Inertia), there are fewer rules, as only the item type is searched for.

Causality here is applied as the default integral causality and causality validity at the junctions is

not yet evaluated. The groundwork for checking causality validity is laid, as numeric labels are

used at the junctions to mark causality. A “2” at a junction symbolizes the causality marker is away

from the junction, while a “3” at a junction symbolizes the causality marker is adjacent to the

junction. Figure 15 shows the graph after applying ruleset 5.

(a) (b)

Figure 17 (a) First stage causality assignment (b) corresponding bond graph notation

While causality is successfully applied, not all of the junctions are valid yet. The next set

of rules check to see if the causality at each junction is valid. A 1 junction cannot have more than

one imposed flow and 0 junction cannot have more than one imposed effort on to the junctions.

The “2” and “3” labels are used to check for these cases and label any junction node with “INVD”

(referring to invalid causality assignment) that don’t pass these tests. Nodes that are connected to

an R element are labeled “RFlag”, to symbolize that there is an R element present to affect

23

causality. R elements can have causality point in either direction and are thus valuable tools for

correcting causality at a junction node. The resulting graph with INVD and RFlag labels are shown

in Figure 16. It should be noted that there are no nodes with INVD labels.

Figure 18 Causal bond graph with "RFlag" label

The next is the causality correction process. The first step here is to correct causality

between 1 and 0 junction nodes and to apply causality on resistor elements. It is hoped that these

rules will make the causality in the graph valid without the need to change causality of I or C

elemental nodes. The resistor element is also assigned causality using this ruleset. As a result of

applying these rules on this system, there is an invalid causality present on an I junction node as

shown in Figure. This invalid causality will be identified, marked, and corrected. But before

correcting causality at I and C elements, a ruleset runs to remove all "RFlag” labels from the graph.

These labels are no longer necessary and can interfere with the remaining processes. Once that is

complete, causality at junctions with I and C elements is corrected. This ruleset will be reevaluating

junctions to see if they’re still invalid and changing I and C element causality accordingly. In the

case of this working example, the causality of the I element node (the mass component) at the

invalid junction node will be changed, thus satisfying the causality rules as shown in Figure 17.

By changing the causality at the I element node, it should be noted that this operation causes

derivative causality assignment and is carried out if this is the only available option.

(a) (b)

Figure 19 (a) Causal graph after first correction attempt (b) corresponding bond graph

The final steps in causal bond graph development begin with with checking for any

transformer element nodes with an adjacent invalid junction. If this is the case, the only solution

25

remaining at this point is to flip the causality of the transformer element and loop through the

causality correction process again. Two rulesets accomplish this (ruleset 10 and 11) for the two

different potential causality options for a transformer. This loop continues till all junction nodes

have valid causalities assigned. After this, a cleanup ruleset runs to remove the directionality arcs

and instead show directionality to the user using the “OPP” and “SAME” labels. This cleanup

ruleset will also remove the “2” and “3” labels from the graph now that they are no longer needed.

In this graph flipping the transformer is not necessary, however the directionality arcs are

converted to labels and the “2” and “3” labels are removed, presenting a readable graph as shown

in Figure 18 for our example. Identifying labels are used to clarify what component a bond graph

element is associated with. For example, a bearing in a system graph will be converted to an R

element in a bond graph. The node for this R element will have the label _Bearing on it to identify

to the user that this R element comes from a bearing. This is done for all components in a system

to improve clarity. Labels that allow a property to be included in analysis, such as

“Include_Inertia,” or “Include_Friction,” can be applied to several different components. As a

result, they cannot have component specific identifyinglabels. When an “Include_Inertia” label is

applied, its identifying label cannot be “_Rack&Pinion” because “Include_Inertia” could also be

used on a motor output shaft. Therefore, the labels for these components indicate they are added.

So the identifying label for “Include_Inertia” is “_Added_Inertia.” The user will then be able to

use the location of the inertia element and the fact that they know it is an added element to identify

what component it belongs to since they would have consciously added the “Include_Inertia” label.

The corresponding causal bond graph is shown in Figure 19.

Figure 20 Final Causal graph generated using the search process corresponding to the

bond graph shown in Figure 19

Figure 21 Actual bond graph corresponding to the grammar based graph shown in Figure

18

27

Example Systems

Example 1: Electrical System As shown in the working example, the rulesets are comprehensive and are able to tackle a

variety of systems. Figure 20 shows an electrical circuit whose system graph is shown in Figure

21, its causal bond graph in Graphsynth nomenclature in Figure 22, and its causal bond graph in

standard bond graph nomenclature in Figure 23. The general methodology for designing electrical

systems in our program is to connect them as they are shown in a circuit diagram. One difference

between creating graphs of electrical systems and creating graphs of mechanical systems is that,

in electrical systems, for junctions of elements with more than two connections, the user must use

a node labelled "E_Junction" so that Graphsynth can properly convert this into a zero junction.

Figure 22: Electrical circuit diagram [18]

The Graphsynth input is shown in Figure 23. We used the “NoGround” node to specify

that when creating the system, ground can be ignored. The transformer is modelled with “Coil1”

and “Coil2” on each side of the transformer in order to ensure that the transformer rule is applied

properly.

28

Figure 23: Graphsynth input of the electrical circuit

The output from Graphsynth is shown in Figure 24.

Figure 24: Graphsynth output of the electrical circuit

Figure 25 Standard bond graph nomenclature for electrical circuit

In this example, Graphsynth produces a valid bond graph of the electrical system. In general,

electrical systems are easier to model than mechanical systems because they do not need to have

any further defining labels, such as those in the motorcycle transmission.

Example 2: Half Car Model

Another example is the system shown in Figure 26 for analyzing the pitch-plane

characteristics of a car using the half-car model. The system graph is shown in Figure 27 and the

bond graph of that generated system is shown in Figure 28. These examples provide a good

overview of the potential of graph grammar based method as well as the robust nature of the rules

in generating accurate solutions.

30

Figure 26 System diagram for a half car model to understand pitch-plane characteristics of

an automobile [15]

Figure 27 System graph for the system shown in Figure 26

31

Figure 28 Causal bond graph for the half-car model shown in Figure 26 and Figure 27

The Graphsynth bond graph generation is performed behind the scenes of a more user

friendly desktop program. This program presents an intuitive user interface that focuses on

providing only the controls and options necessary for creating word bond graphs and analyzing

the resulting causal bond graph. This allows for the user to easily build a word bond graph without

being overwhelmed by all the options provided by Graphsynth, and then the Graphsynth rules will

apply to the user word bond graph in the background, and then the user will be presented with a

completed causal bond graph.

32

Example 3: Baja Vehicle Suspension Analysis

The third system being analyzed is the suspension system for a Baja off-road vehicle. This

suspension system is a fully independent suspension system linked to the frame using a double

control arm system for each wheel. The wheels in the front suspension system are designed to have

negative camber, and have ball joints where the A-arm mounts to the wheel mount to facilitate

rotation. Each A-arm and the wheel undergo plane motion, rotating about the chassis. However,

since both A-arms and the wheel are all connected to one another, they all move together, and

undergo the same plane motion. The bottom A-arm absorbs more of the force from ground impacts

than the upper A-arm, while the upper A-arm is responsible for controlling the wheel camber. The

center of mass of the off-road vehicle is towards the rear of the vehicle, approximately two thirds

of the way back from the mounting point of the front suspension. This system is therefore analyzed

as a half car model. The assumptions used in analyzing this system are as follows:

• Gravity is significant on body – this is represented as a source of effort on the body.

• Gravity is insignificant on wheels

• Small rotations only

• The Baja is modeled on a bumpy road – this is shown by the sources of flow on the tires,

Velocity_Input.

• The mass of the vehicle is lumped and includes the chassis, driver, drive train, and engine.

• The mass of suspension hardware is neglected.

• The system is treated as a half car model – therefore the chassis of the vehicle is in planar

motion. An earlier version of the group’s bond graph is used here, where the chassis is not

in plane motion. Issues with causality in this graph were discovered that it is not believed

adding additional planar motion would have corrected.

• The spindle in the system has stiffness, this is represented with a spring component in the

system.

• The angular velocity of the suspension A-arm is considered – this is represented as a lever

in planar motion in the bond graph. Each A-arm has its own planar motion lever

representation.

• The tires are 75% inflated – this is represented by the spring and damper connected to each

tire.

• The spindle has planar motion.

• Driver weighs 200 pounds – this is not considered in bond graph generation.

The first step in analyzing the system as a bond graph is converting the components of the

system into bond graph components, first as a diagram and then as a word bond graph.

Figure 29 Baja vehicle system diagram

34

Once the system is made into a word bond graph, the bond graph can be derived.

When translating the Baja vehicle system to Graphsynth, a few challenges were

encountered. The primary challenge encountered centered on the presence of invalid causality

junctions in the system. Due to 4 planar motion scenarios present in the system simulation, there

were numerous 1 or 0 junctions connected to only or many other 1 or 0 junctions. These types of

situations, where there are many connections not going to components but rather to junctions, are

difficult for the grammar rules to apply causality for.

Figure 30 Baja vehicle word bond graph

35

Figure 31 Graphsynth causal bond graph of Baja vehicle

36

As a result, invalid causality is present at a few of these junctions. A future implementation

of the causality application process may remedy this issue by choosing only rule applications that

result in no invalid junctions in the system. Also, the Graphsynth rules used here do not have

gravity applied to specific components, and the analysis of this system had gravity on the body but

not the wheels.

Example 4: Motorcycle Transmission Selector Analysis The fourth system being analyzed is a motorcycle transmission selector. This transmission system

contains a linear actuator that is used to select specific gears in the transmission. The linear actuator

consists of a DC motor connected to a single stage gear train geared for torque. Connected to the

output gear of this gear train is a worm gear that moves the gear selector in a linear direction. The

gear selector locks itself into place into one of the gears in the expandable gear train using locking

bumps. The assumptions used in analyzing this system are as follows:

• Gears mesh perfectly, so there is no friction or backlash between the gears

• Only one gear is selected at a time. This is represented by a single flywheel.

• Ratio of nut to worm gear is ‘x’. Because we do not have a rule for a screw drive system,

it is modelled as a rack and pinion system instead.

• Gear selector does not rotate

• Oil allows gears to spin freely about the tool

• Housed so no losses in the system

• N1/N2 is maximized

The first step in analyzing this system is to develop a model of it, as shown below.

Figure 32 System diagram of motorcycle transmission

This model is then used to generate a word bond graph for Graphsynth. As shown in Figure

33, for the rack and pinion nodes, there are extra labels that define whether friction, stiffness, or

mass and inertia exist in the system. These labels allow for the user to choose whether or not to

incorporate those factors when the bond graph is developed. For example, the pinion gear in this

system has the “Include_Inertia” and “Include_Stiffness” labels, meaning that this element will

have an inertia and stiffness when the bond graph is generated. The “Motor” node will expand into

a full electrical representation of a permanent magnet DC motor. The control unit is modelled as

another voltage input in addition to the voltage input provided to the system. Our rules will model

two gears in series as a transformer.

38

Figure 33 Word bond graph of motorcycle transmission

The word bond graph is used by Graphsynth to generate a causal bond graph, which is then shown

with traditional bond graph nomenclature.

39

Figure 34 Graphsynth bond graph of motorcycle transmission system.

Figure 35 Traditional bond graph of motorcycle transmission

When analyzing this system with Graphsynth, a few challenges were encountered due to

the understanding of the system and the components involved. The system uses a worm gear with

a nut to change gears, and no rules in Graphsynth directly apply to this equipment. Modeling the

control unit was also a challenge when it came to determining the proper bond graph

representation. The ME 4322 group working on the motorcycle transmission project had modeled

the control unit as a modulated gyrator, which was a challenge to represent in Graphsynth, as no

rules currently create a modulated gyrator.

Example 5: Hydraulic Elevator Analysis

The system being analyzed next is a hydraulic elevator. This system contains an elevator that

is moved up by a motor connected to a pump, and is moved down by gravity. A piston cylinder

arrangement is used to control the motion of the elevator. The pipes have friction and leakage, and

a storage tank is used to store the fluid in the system. The assumptions for the system are as follow:

• Gravity is acting on the elevator car – this is represented in the system as a source of effort

on the elevator car mass.

• There is friction between the elevator car and the wall – this is represented as a resistive

friction element on the elevator car.

• There is resistance in the pipes in the system and there is resistance from a filter – these are

represented by resistor elements in the system.

• The piston shaft has compliance – this is represented by a capacitive element in the system.

The pump in the system is interpreted for our graph generation as a positive displacement

pump, resulting in a transformer element in the bond graph. The piston cylinder system is also

represented as a transformer element in the system.

Figure 36 Hydraulic elevator configuration

Since the elevator uses a pump to ascend and just gravity to descend, there are two different bond

graphs, one for each case. The first bond graph observed is the bond graph for ascent.

42

Figure 37 Hydraulic elevator - raising elevator word bond graph

43

Figure 38 Hydraulic Elevator - raising elevator Graphsynth bond graph

Figure 39 Hydraulic elevator - raising elevator standard bond graph nomenclature

The second bond graph generated is for the elevator’s descent, as indicated by the lack of the motor

and pump in the system.

Figure 40 Hydraulic elevator - lowering elevator word bond graph

Figure 41 Hydraulic elevator - lowering elevator Graphsynth bond graph

Figure 42 Hydraulic elevator - lowering elevator standard bond graph nomenclature

46

When simulating these systems, the process was relatively straightforward. Some issues

were encountered with unmarked invalid junctions present in both the lifting and lowering phases

of the hydraulic elevator operation. This may be a bug that could potentially be eliminated by the

causality application method utilized in the desktop program for causal bond graph generation.

Another challenge was the implementation of a valve in the system. There are not any specific

rules for valves, and therefore the rule used was for a hydraulic increase, as this implemented the

same type of element, an inductor element. Another difference between our system and the one

from the student group is that our system deliberately leaves 1 junctions adjacent to transformers

in the system even if they are flow through junctions. This results in different simplification and

potentially components being attached in different locations. An example of this is occurred when

the “Tank_Input” (Se) and the R component connected to the same node were in a different

location than the student group. However, if the adjacent 1 junctions at that location were

simplified or if the flow through 1 junction adjacent to the transformer was removed, the same

result would be obtained.

System Response Simulation

One of the plans for this project was to develop state equations from these graphs, and then

send these equations to Matlab to generate system response graphs from these equations.

Generating these state equations can be done through the use of a tree search process, however due

to time constraints we were not able to accomplish this. However, we did discover that it is possible

to run Matlab code in C#. An example of this is shown below

Figure 43: Executing Matlab code from C#

Figure 43 displays C# code that runs Matlab code [19]. The arguments to the Execute()

method are strings in the form of Matlab syntax. In this particular case, the following system of

differential equations is plotted using the ode45() function in Matlab:

This process for generating graphs of the system can be automated using string functions.

Theoretically, once the state variables and equations are determined in our program, they can be

formatted in such a way that it can be passed into Matlab to automatically generate response

graphs. Because the ode45() function cannot use symbolic variables, the user would need to

manually enter these values in order for it to work. The user must also own a copy of Matlab for

this to work properly. We did explore the possibility of utilizing compiled Matlab applications that

48

did not require the user to have a full copy of Matlab installed, however it does not support

symbolic equation representation.

Another possible function that can be used to solve state equations is dsolve(), which is a

symbolic solver that can derive the time domain solutions of the state equations with symbolic

variables. This could be helpful for students if they want to check their handwritten solutions to

these differential equations.

49

Desktop Program

The automated causal bond graph generation process and the virtual lab concept that were

developed are being integrated into an actual virtual lab that can be supplemental with classroom

teaching. The platform being developed is available for trials at http://bit.ly/AutomatedVirtualLab

and a simple tutorial is available at http://bit.ly/AVLTutorial. Note that the version being described

is still in development and is susceptible to various bugs. The automated virtual lab is being

developed in C# and is currently a Windows only application. We do hope to make this a universal

application in the future. Once the features are tested, we will also open-source all the rules and

codes for further collaborative development.

The entry screen of the automated virtual lab is shown below in Figure 44. There is a menu-

bar with various functions. The “Main” drop-down menu enables users to save and clear data and

exit the virtual lab. The “System Elements” drop-down menu enables creation of the bond graph

and a sample system in mechanical translation is shown in the figure. The desktop program uses

the Graphsynth rules and methods that have been previously discussed, however they are run in

the background. The user can therefore focus on interacting with system or bond graph elements.

The main method of element editing is through a right click menu, where users can choose such

modifications as “Include_Inertia,” or users can choose two components to connect together. In its

current state, a system can be created using simple system components, and the causal bond graph

can be generated.

Once the system has been input, the user has the option to carry out a number of tasks as

shown in the Tasks drop-down menu in Figure 45. As shown in the figure, the tasks include the

ability to generate a bond graph without simplification, with simplification and with causality. The

“Check Your Simplified BG” feature will be explained in the later part of this section. Once the

50

“Obtain BondGraph without Simplification” task is clicked, the graph is shown in a much more

user-understandable version in Figure 46.

Figure 44 Entry screen of the Automated Virtual Lab

Figure 45 List of tasks available for the user in the Automated Virtual Lab

51

Figure 46 First-stage bond graph obtained without simplification

Figure 47 Simplified bond graph shown with directions

The next step in the process is to obtain simplified bond graph and is shown in Figure 47

with directions. Note here, that the directions are arbitrary and the standardization of the bond

arrows is still being worked out. Also, the graph generated after applying the simplification rulesets

is the basis for the simplified bond graph. Once this graph is obtained, the next step is to apply the

causality rulesets to obtain the causal bond graph as shown in Figure 48. The list of states is

highlighted by the blue-shaded bond and causal strokes. You may notice that the tool is also

indicating to the user that there are four-state variables possible in the system. In addition, the tool

is also able to show a drop-down combo box (as shown in Figure 49) that lists the possible states

52

(IC referring to the number of I and C elements in integral causality). While the objective is to

obtain four states, the user (say, the student in a system dynamics course) may come up with an

error and obtain fewer states than actual. This drop down box gives the user the ability to see if his

option is indeed possible and see the correct solution. Selecting an option with IC:3 will display a

result shown in Figure 49. Here you can see that the integral causal I element is now in derivative

causality. The generation of multiple options is possible through the breadth-first search being

employed for causality generation.

Figure 48 Causal bond graph for the system shown in Figure 46

Figure 49 List of possible states in the system

53

Figure 50 A three-state causal bond graph

A rack and pinion example system is also modeled in the virtual lab and the various outputs

are shown in Figures 54 to 58. You may notice that in Figures 55 and 57, there are two equally

likely causal bond graphs that can be generated. The tool has been tested with numerous other

examples and is successful in obtaining accurate causal bond graphs.

Figure 51 First stage bond graph of the rack and pinion based system [14]

54

Figure 52 Simplified bond graph of the rack and

pinion system with directions

Figure 53 Causal bond graph shown with four-

states, where the pinion inertia element is in integral

causality

Figure 54 Causal bond graph with rack inertia

element in integral causality

Figure 55 Causal bond graph for the rack and

pinion system with reduced states

Another feature that is beneficial in the educational space would be the ability to verify if

the user’s solution is correct or not. This has been implemented at a very basic level in the tool.

Shown below in Figure 56 are the system diagram and the user’s bond graph solution to the given

system. Following this, clicking on Tasks drop menu reveals an option called Check Your

Simplified BG (BG stands for bond graph) as shown in Figure 57. Clicking this, the tool imports

the system and the user’s solution from Figure 56, generates the system bond graph, compares the

system result and the user’s solution and produces the result shown in Figure 58. In Figure 58, you

55

can see that all the possible junctions and elements are listed between the system generated solution

and the user solution. At the present, the comparison is purely on the number of elements but a

comprehensive checking algorithm is being developed for integration in the tool.

Figure 56 (left) System graph of the mass-spring-damper system (right) bond graph

solution given by the user

Figure 57 Option to check if the user's bond graph solution is correct

56

Figure 58 Basic check and results table after comparing the system generated bond graph

and the user's solution

57

Future Use

Bond graph facilitate a very generic energy independent approach to dynamic analysis of

complex systems, and its potential is well known. The graph grammar based approach presented

in this paper provides a detailed and generic ruleset based method to automatically generate causal

bond graphs for different systems. A total of 143 rules spanning across various rulesets are used

to Different stages of the process were detailed as well as examples presented to show the potential

of this method.

One of the primary goals of this MQP was and remains to create a program that can be

used in the future by engineering professionals and students alike. The work on the desktop

program is designed to create a system that presents users with an intuitive way to create and

analyze causal bond graphs. This allows for the Graphsynth rule logic to be hidden from the user

and operate in the background, allowing the user to focus only on easily creating and understanding

a causal bond graph. For professional engineers, this is done with the goal in mind of using this

program in the future to aid in conceptual design. A professional engineer would be able to enter

basic parameters about a system and their objectives about a system, and the program would be

able to generate many different bond graphs that meet these requirements, and consequently

generate many different systems. Similarly, the program could be used to analyze existing systems,

using a future implementation of state equations to take a bond graph inputted by an engineer and

analyze the system response. The program will also be open source, with the goal of allowing other

users to contribute to the development of rules and other features to broaden the program’s

capabilities. It is hoped that this will create a powerful and widely applicable tool for professional

engineers.

58

The presented approach is not only designed to be used by engineers as a fairly light weight

method to automatically generate bond graphs of systems but is also designed to be a learning tool

that can be used in classrooms to enhance bond graph based system dynamics education. The

various rulesets also aid and are designed such that they can be used in this process. Currently

there already exists a set of rules designed to perform checking procedures on an inputted causal

bond graph. These rules look for common bond graph errors: adjacent 1 or 0 junctions, flow

through junctions, or junctions with invalid causality. Similar rules are used for causal bond graph

generation, however these rules are designed to identify the stated errors and correct them. The

rules present in the ruleset designed for checking causal bond graphs for education only label the

errors to identify them for the user. For example, if there are adjacent 1 junctions present, the

ruleset will identify this and label the arc between the junctions “Adjacent_1,” rather than

simplifying the adjacent junctions. This way a student can input the causal bond graph they created,

and rather than just end up with a correct causal bond graph and not learn anything, the student

will be shown areas where errors could be, allowing them to make corrections and learn more

about causal bond graph generation.

Another potential way this learning side of this tool is envisioned to work is shown in

Figure 26, whereby the student draws the system as well as the bond graph of the system. The

various rules are applied on the system graph to generate different stages of the bond graph (un-

simplified, simplified with directions and with causality). All the resulting graphs are presented to

the user as well as final graph and potential differences between the system generated solution as

well as user specified solution are highlighted. Methods to compare graph will be integrated for

the purpose. Most importantly, the user is also shown potential incorrectly developed causal bond

graphs that are generated using the causality search described in the rulesets section. This greatly

59

helps the student with the bond graph and the subsequent causality assignment process and also

provides a way to highlight potential errors in model development. We believe that this is a

valuable tool and can be adapted into a virtual lab by incorporating learning algorithms from

artificial intelligence.

Figure 59 Potential for the method as a learning tool

Means to store actual information of various geometrical and material information (mass, stiffness

constant, etc.) within the graph grammar notation as well as to allow user controlled direction

assignment are being investigated. Another area of improvement would be reduce the number of

rules required for generating bond graphs but at the same time maintaining the generic nature. In

the future, the goal is to interface this tool with a solid modeling environment such that system

graphs, bond graphs and resulting response curves can be directly generated within the assembly

view of the software.

60

Recommendations

This section will outline the recommendations for future work on the developments completed for this project. Further Testing of Existing Rules

The current database of rules is well tested for systems involving mechanical translation,

mechanical rotation, electrical components, or hydraulic components. However, this does not

mean testing should not continue. There are many different system configurations, and any one of

those configurations could cause a bug that has yet to be discovered. For example, the pulley and

belt rules are complicated and were difficult to implement, and could cause bugs in different

implementations. Thorough testing will allow the existing rules to continue to be developed

towards being as bug free as possible.

Further Development of Rules and/or Methods for Classroom Use

Currently, the only mechanism present in the MQP that facilitates the use of the software

for educational use is a set of rules designed for highlighting potential errors or oversights in a user

created bond graph. These rules, while useful and can demonstrate mistakes a user could learn

from, are limited in their function. It would be ideal if the program had the ability to take a user

generated bond graph and compare it directly to a bond graph generated by the program. By

highlighting the differences between the two bond graphs and showing the solution a student could

learn about generating an accurate bond graph. Another possibility is to have the program show

the steps for bond graph generation, in order to walk a student through the bond graph generation

process step by step. Finally, the program could also show the student numerous different correct

bond graph options for one system graph to demonstrate to the student how one system can

generate different bond graphs that are all still correct.

Implementation of Conceptual Design Automation

61

One of the original goals of this project centered on aiding engineers in the design process

by giving engineers the ability to enter their objectives for a system and some parameters and

having a program generate different potential design solutions. For example, an engineer designing

a power drill could enter how much torque they need to drive a screw into a wall, and their size

requirements. From there the program could design different gear trains that meet those needs and

present the options to the engineer. The ability to use the qualities of system graphs and bond

graphs, along with gear train generation, could give the program automated system generation

capability. These models could then be converted to solid models to represent systems in 3D.

Further Development of Program User Interface

One of the primary goals of the development of a desktop program powered by the rules

generated in Graphsynth is to provide a friendly user interface for causal bond graph generation

and analysis. Work on a desktop program has begun and it does provide an upgraded user interface

over Graphsynth. In the future it would be good to continue to expand on this user interface to

make it more intuitive and user friendly, while also incorporating features added over time.

State Equation Expansion

In the program’s current state, a ruleset is used to derive the state variables for the

components in the system. A demo was then developed that showcased a potential method for

transferring those state variables to Matlab using C# code. Once the state variables were in Matlab,

they could in theory be arranged into state equations and solved using an ordinary differential

equation solver. This feature would allow simulation of the system response of a system, and

would be a valuable tool for prototyping. A method for deriving state equations either in rules or

by using code would allow for advanced simulation of a system response right in the program.

Furthermore, the ability to solve these state equations for their respective state variables would

62

make the program a complete package that could generate the causal bond graph for a system and

provide a simulation of how the system would function.

63

Conclusions

A graph grammar rule based system for generating bond graphs for various systems is presented.

A robust system of rules enables conversion of system graphs to causal bond graphs reliably.

Different examples have been presented that show the promise of this method. The method also

has potential to be used in learning environments and for system simulation as described in the

discussion section. A desktop program has been created to facilitate these future developments.

The desktop program uses grammar rules combined with a search process for automatically

generating causal bond graphs given any system. The desktop program currently allows for the

user to see multiple valid bond graph options and performing a basic comparison between a user

bond graph and a system generated bond graph.

64

References

[1] Swantner, A., and Campbell, M., “Automated Synthesis and Optimization of Gear Train

Topologies,” ASME Design Engineering Technical Conference DETC2009/DTM, ASME, San

Diego, CA.

[2] Radhakrishnan, P., and Campbell, M., I., 2010, “A graph grammar scheme for generating and

evaluating planar mechanisms,” Design Computing and Cognition DCC’10., pp. 663–679.

[3] Fu, W., Eftekharian, A. A., Radhakrishnan, P., Campbell, M. I., and Fritz, C., 2012, “A

Graph Grammar Based Approach to Automated Manufacturing Planning,” ASME 2012

International Design Engineering Technical Conferences and Computers and Information in

Engineering Conference, American Society of Mechanical Engineers, pp. 77–88.

[4] “3D CAD Design Software SolidWorks” [Online]. Available: http://www.solidworks.com/.

[Accessed: 22-Dec-2012].

[5] “ANSYS - Simulation Driven Product Development” [Online]. Available: /. [Accessed: 16-

Feb-2016].

[6] “Working Model 2D - Home,” http://www.design-simulation.com/WM2D/index.php

[Online]. Available: http://www.design-simulation.com/WM2D/index.php. [Accessed: 25-Aug-

2009].

[7]“Adams - Overview,” http://www.mscsoftware.com/products/adams.cfm [Online]. Available:

http://www.mscsoftware.com/products/adams.cfm. [Accessed: 25-Aug-2009].

[8] Broenink, J. F., 1999, “20-sim software for hierarchical bond-graph/block-diagram models,”

Simulation Practice and Theory, 7(5–6), pp. 481 – 492.

[9] “Dymola” [Online]. Available: http://www.3ds.com/products-services/catia/products/dymola.

[Accessed: 16-Feb-2016].

65

[10] “MathWorks - MATLAB and Simulink for Technical Computing” [Online]. Available:

http://www.mathworks.com/. [Accessed: 24-Oct-2010].

[11] Broenink, J. F., 1997, “Bond-graph modeling in Modelica,” Proceedings of 9th European

simulation symposium, Passau Germany, Oct, pp. 19–22.

[12] Rinderle, J., Balasubramaniam, L., and others, 1991, “Automated bond graph modeling and

simplification to support design.”

[13] Wu, Z., Campbell, M. I., and Fernández, B. R., 2008, “Bond Graph Based Automated

Modeling for Computer-Aided Design of Dynamic Systems,” Journal of Mechanical Design,

130(4), p. 041102.

[14] “Wiley: System Dynamics: Modeling, Simulation, and Control of Mechatronic Systems, 5th

Edition - Dean C. Karnopp, Donald L. Margolis, Ronald C. Rosenberg” [Online]. Available:

http://www.wiley.com/WileyCDA/WileyTitle/productCd-047088908X.html. [Accessed: 16-Feb-

2016].

[15] Merzouki, R., Samantaray, A. K., Pathak, P. M., and Ould Bouamama, B., 2013, Intelligent

Mechatronic Systems, Springer London, London.

[16] Campbell, M., “A Graph Grammar Methodology for Generative Systems” [Online].

Available: http://repositories.lib.utexas.edu/handle/2152/6258. [Accessed: 30-Oct-2009].

[17] Jan F. Broenink, 1999, “Introduction to Physical Systems Modelling with Bond Graphs.”

From http://www.masters.dgtu.donetsk.ua/2011/fknt/kovtun/library/article6.pdf

[18] Cochin, I., 1980, Analysis and design of dynamic systems, Harper & Row.

[19] Mathworks, n.d., “Call MATLAB Function from C# Client”, from

http://www.mathworks.com/help/matlab/matlab_external/call-matlab-function-from-c-

client.html

66

Authorship This report was typed by Daniel Grande and Felice Mancini. Daniel Grande Felice Mancini dgrande770@gmail.com feliceman@gmail.com