Post on 25-Dec-2021
transcript
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