Creating the Meta-model¶
At this point you should have a basic understanding of the concepts of meta-modeling in webgme and be somewhat familiar with the GUI of webgme. In this section we will build up a meta-model for the electrical circuits domain.
Which types do we need?¶
The first thing to layout when constructing a meta-model is what types our domain should include. Which these are does not only depend on the domain, but also the analysis tools being targeted. Since our target is Modelica and more specifically the Analog Electrical library as part of the Modelica Standard Library, we should take that into consideration.
This library contains a range of electrical components with a various number of pins. Looking at one of the examples we see that the pins are connected via electrical connections.
With or without Modelica a very natural breakdown of this domain is include the types:
Additionally, since our goal is to build electrical circuits, we also need a
Later we will add sub-types of components corresponding to components such as
The video below shows how you can add these types as meta-nodes starting from your empty project.
Now let’s model where these concepts can be added in the containment-hierarchy.
Circuit should be able to contain
Components wired together by
Connections. The way connections
are constructed in webgme requires us to add a containment rule for the
Connection w.r.t. the
Next section illustrates how we can make the
Connection in to an actual connection (an edge on the drawing canvas).
Pins determine where the
Connections connect the
The video below shows how to add these containment rules to our meta-model using the Meta Editor.
Sub-types of Components¶
So far our meta-model only contains a generic
Component for representing electrical components, but we need a way to represent
specific electrical components such as
There are multiple ways we can achieve this by extending the meta-model. One apporach is to add a meta-type for each type of electrical component and add the related Modelica parameters as attributes to these respectively.
Another approach is to create the different types of electrical components outside of the meta-model and treat
the Modelica parameters as separate child nodes of the
Components. This approach allows for creation of new types
without modifying the meta-model itself, but also makes the modeling a bit more cumbersome using the default visualization.
(Visualizing and modifying the parameters of a component could no longer be done from a single node.)
For the sake of simplicity we will take the first approach and limit our domain to the five
Components below (we will also leave out
the heat transfer portion in the domain).
The associated Modelica parameters can be extracted from the Modelica Standard Library using a Modelica tool, such
as OpenModelica. For each component we need to indicate its unique path or identifier
within the MSL, this will be captured by the read-only attribute
ModelicaURI. In order to map directly to Modelica
we name the ports and the other parameters the same way they’re named in MSL.
R- The resistance of the resistor in Ohm. A float greater or equal to
0with a default value of
Modelica requires each electrical system (
Circuitin our case) to contain a ground component in order to make the system solvable.
Pin, named p.
L- The inductance of the inductor in Henry. A float greater or equal to
0with a default value of
C- The capacitance of the capacitor in Farad. A float greater or equal to
0with a default value of
V- The voltage of the source in Volt. A float with a default value of
startTime- Time offset (when the voltage goes from 0 to
V) in seconds. A float with a default value of
With the approach taken the
Component meta-type itself will not have any interpretation w.r.t. our domain and will only
act as an abstract type that cannot be instantiated.
In the video an additional abstract base type,
TwoPinComponent, that defines two
n is also added. In general this
approach is not only more elegant and convenient, but also more efficient since the raw data for the two pins can be shared
and requires less data to be loaded from the server.
Connections and Ports¶
In order to create connections between
Components or rather between the
Pins of the
Components we need to
Connection into a connection like object. In webgme’s meta-model there is no first order concept of a connection,
instead such can be constructed using reserved named pointers;
dst. The target of each will be the source and
destination of the
Connection respectively. For more details on connections revisit the videos in the Meta-modeling Concepts section.
Just like with connections, there is no first order concept of a port in webgme either. Connection sources and destinations are
only constrained by the valid pointer ends defined in meta-model and can crosscut over the containment hierarchy. To make
modeling more comprehensible, it is often useful to be able to visually propagate port like children up to boundary of
the parent node. The way this is solved in webgme is through the meta-property (implemented as a registry)
Note that the usage of this property only takes effect if the decorator (the UI component responsible for drawing the box
on the canvas) implements logic using this property - this is the case for both the default Model- and SVG-Decorators.
At this point we have a complete meta-model and a small example