The SMN software methodology provides a very flexible modelling framework so the range of things that can be done with it is VAST. But here we begin with a brief overview of the SMN modelling framework in the context of a very simple modelling scenario in order to introduce some of the general principles of modelling with SMN.
We will create a simulation of two systems (systemA and systemB). These two systems have simple numerical states and relations. We can think of them as two tanks that are connected via pipes of different sizes. The numerical states define how much fluid is in each tank and the numerical relations define what proportion of this fluid flows through the pipes.
First lets familiarise ourselves with the modelling interface. There are several ways to construct SMN models (including a programmable API) but here we will be creating a model definition using a specific subset of OWL (web ontology language), which is a standard RDF/XML format for describing complex concepts and relations.
In metaphysics, an ontology is the set of all entities that we believe to exist and the set of all relations that are believed to exist between these entities – it defines the scope of that which is believed to be real. In the context of semantic technology an ontology defines all entities and relations that exist within some conceptual domain.
When we use OWL to define system models the conceptual context is virtual systems and their interactions within a virtual universe. The ontology defines the scope of what is possible within the virtual universe.
For a good introduction to OWL (and in particular Protégé – OWL) see this tutorial, also see the official documentation.
For a complex system, once the class hierarchy and system hierarchy of the ontology have been constructed, the relations between systems have been defined and the atomic systems instantiated as individuals, this is saved as an OWL file, which is then loaded by the SMN engine and translated into a system model, which can be simulated by the engine.
In this tutorial the system is simple enough that many of these steps can be skipped, to keep the focus upon the core principles. Later tutorials will provide an introduction to the design of complex systems.
When using OWL, there are many interfaces via which we can create, test and visualise ontologies, however in this tutorial we will use Protégé, (others include Neon-Toolkit, OntoStudio, etc).
First we create a new ontology and call it:
It could be any name so long as it is unique.
Then we import the SMN base ontology, which gives us a modelling framework upon which we can construct system models. Here we will use the simplest SMN framework, however there is also a framework to assist with the development of more complex systems, which will be explained in a later tutorial.
In the ontology browser, click where the red arrow is pointing and a dialogue opens asking where the ontology is to be imported from. In this case we will import it from a local file called smn.owl.
We are then asked to give its name space a prefix, the prefix 'smn' is recommended.
This means that, for example, a concept defined as 'system' in the “smn.owl” ontology will be shown in this ontology as 'smn:system'.
Now that the SMN modelling framework is loaded, lets take a look at what it offers. First click on the “OWL Classes” tab and expand the class hierarchy.
We see that it defines two main classes (atomicSystem and atomicInteraction). The more complex modelling framework defines more classes that can be useful when designing a complex system, but for the actual SMN model itself, these two classes are all that is needed.
Using OWL we can define logical relations between classes, this can be very useful when constructing the model. Notice above that the class 'atomicSystem' receives input from and sends output to the class 'atomicInteraction'.
Also notice above that the class 'atomicInteraction' transmits information from and to the class 'atomicSystem'. Furthermore, an interaction only occurs between exactly one system and another.
When creating a complex system you can create your own logical relations between the system classes that you define and this allows the model to be automatically checked for consistency. Other automated reasoning procedures can also be applied such as inference to discover things not explicitly asserted in the model but implied by the logic of the model.
Next lets look at the “Properties” tab.
Above we see some relations between classes, with their domains, ranges, inverses and so on. For example, we see that the 'transmitsTo' relation can only exist from an atomicInteraction to an atomicSystem and its inverse is 'inputsFrom'. Hence, if an interaction channel transmits information to a system, then that system receives information from that interaction channel.
Next, within the “Property Browser”, click on the “Datatype” tab:
Above we see the data that actually defines a system within the SMN model. For example, the systemId is a “long integer” that belongs to an atomicSystem.
If we then clicked on the “Annotation” tab we would also see that there is one annotation property defined called 'modelId' which defines the identifier for the whole model.
That was a very quick overview of the SMN modelling framework within Protégé-OWL. Now we will create a simple system model using SMN and Protégé-OWL.
First we define a unique modelId identifier for our new model. In the “Metadata” tab click where the red arrow point to create a new annotation for the whole ontology.
Select the annotation type 'modelId' and enter some value.
Defining the Structure of the Model
Now click on the “Individuals” tab and we will create the two systems and their interactions. Select atomicSystem as the class of object you would like to create and then click where the red arrow is pointing to create an instance of this class.
Below we have created two instances called systemA and systemB.
We can see that there are various pieces of information that can be filled in for each system. The range of requested information depends on the previously defined logical restrictions and relations, and the form is automatically generated by Protégé and can be customised from the forms tab. We will come back to this form in a moment, but first lets create the interactions.
Here we have created four interactions:
AtoA and BtoB represent self-interaction, I.e. the proportion of fluid that remains within a tank.
AtoB and BtoA represent the proportion of fluid that flows between tanks.
Now lets connect these various instances up into a model. For interaction “AtoA” we see that it transmits from system A and also transmits to systemA. In the red outlined fields above this information can be entered by clicking on the icon with a '+' in order to add an existing resource, which brings up the following dialogue box.
Now we fill in the information for each interaction.
Above we see the interaction “BtoA” that transmits from systemB to systemA.
The inverse relations are automatically filled in, hence for systemA we see that it receives input from “AtoA” and “BtoA”, and it sends output to “AtoA” and “AtoB”. Now the system model is completely connected.
Visualising the Structure of the Model
Now we will visualise the model to get a feel for its structure (which is trivial in this example). Then we will fill in the data that defines the various attributes of the systems and interactions.
First add the “Jambalaya” tab by selecting from the menu: OWL->Preferences and then selecting the “tabs” tab and selecting 'Jambalaya'. There are many plugins available and several good visualisation methods but Jambalaya is very user-friendly.
Then in the Jamabalaya tab we can view the model in various ways, for example, below is a nested view of all classes, instances and relations of all kinds.
This is a dynamic view where each of the classes, instances and relations can be expanded/contracted or queried (by hovering the mouse of them - above, the mouse is hovering over the highlighted relation – but the screen capture program didn't capture the mouse pointer). One can also edit the details of any object from this view with relative ease.
We can also restrict the visibility to only show objects that have outputsTo or transmitsTo relations using the dialogue shown below.
This gives us the following view.
This view makes the structure of the model quite obvious, there are two systems that interact with each other and also self-interact. Above, the mouse is hovering over the highlighted relation.
Defining the Details of the Model
So now that we know what the model looks like and that its structure is what we wanted, now we will fill in the data that defines the attributes of the systems and interactions.
Above we see some attribute data for systemB. We define the system as being active on the first iteration. We give the system a response function, this can be the name of any C function that we have previously defined and loaded into the SMN engine – the matrixMultiplication function that is shown expects a list of pairs, it multiplies each pair and then sums them all into a total. We give the system a unique identifier, if this is left out a random unique identifier is assigned by the engine. And finally we give the system a state value of 4000.0 (litres) using a double precision number. If it was a physical tank that we wished to monitor and control then we could here define a stateFunction instead of a stateLiteral, then whenever the SMN engine required the state of the tank the function would be called, which would determine the state of the tank and report this to the engine.
Above we see some attribute data for interaction BtoB. We give it an output proportion of 0.7 using a double precision number, this means that 70% of the fluid in tank B remains in tank B. We could also define an input parameter that defines how much of what is available to be received with the remainder representing leakage from the system.
We could also define input and output functions that are any predefined functions that filter the data as it passes through the interaction channel. But for this simple system these are not required.
The salient details of the model are:
systemA contains 44.0 litres of fluid,
systemB contains 4000.0 litres of fluid.
SystemA retains 90% of its fluid to itself and sends 10% to systemB.
SystemB retains 70% of its fluid to itself and sends 30% to systemA.
(Note that this is a VERY simple system, hence it has not utilised any of the advance features of SMN, but we will come across those in later tutorials.)
Now we have defined the initial state of the model, the question arises, how would it evolve if it were animated? By animating it in SMN we can find out! To understand how this is possible, look into how SMN works and what SMN is.
Just save this file as twoSystems.owl and load it in SMN (download here) then run it. At a linux command prompt, type the following command and you will get the following output:
(Note: the SMN engine is developed in ANSI C and can be compiled for any platform, however at present it has only been compiled on an amd64 linux machine.)
./smnengine twoSystems.owl Loaded 2 systems: sysIds = {10, 20, } SV: {44.000000, 4000.000000, } printing sm: metaData = 4, 2, 2, 2, 2 row(0): col(0) -> I/O(N, 0:0.900000) col(1) -> I/O(N, 0:0.300000) row(1): col(0) -> I/O(N, 0:0.100000) col(1) -> I/O(N, 0:0.700000) Now running the model: ended on iteration(75) SV: {3033.000000, 1011.000000, }
Above, we see a brief print out of the initial model. This is then animated and reaches a steady state after 75 iterations where systemA has 3033.0 litres and systemB has 1011.0 litres.
Because this system was very simple the output from the SMN engine is very simple, but if we used the more advanced features of SMN the output may be an interactive graphical program or some other complex dynamical system.
This discussion has skipped over many many details but it has hopefully outlined the basic principles and illustrated that system models can be designed and constructed using OWL and ontology editors and then animated using SMN. More details will be explained in later tutorials.
For the next tutorial we will create a slightly more complex model of a drink machine that provides a graphical display where the user can drag and drop coins into a coin slot, lights will display what drinks are available given the amount of money inserted, these can be selected by clicking on buttons, and a drink is then delivered in the drink chute whilst the change is delivered in a change chute. Also, the machine can run out of drinks or change at which point an indicator light comes on.
www.Anandavala.info 12th Sept 2008