Monthly Archives: April 2014

System Dynamics software: car or kitchen?

When we get a new car, we have to choose between different makes and models. The choice is to a large extent between complete packages, where each package has a whole variety of characteristics – fuel efficiency, size, performance, reliability .

We operate in quite a different way when we choose a kitchen. We (rarely) choose a kitchen as a complete package. Rather, we choose the individual components – the cabinets, the worktop, the cooker, the fridge and so on. We can do this because, fortunately, there is a basic infrastructure and set of conventions which allow things to work together – electricity, water and gas services, and standard dimensions.

System Dynamics software (and, indeed, most software) is like a car: we even use the term “software package”. We have to choose between one package and another, each of which has pros and cons – such as price, useability, feature-richness, and computational speed. Sure, initiatives for developing a standard model interchange language, such as XMILE, improve our ability to work with the same model on more than one platform, but that’s a bit like having several cars in the garage, and there are significant barriers, such as price, familiarisation, to the use of multiple packages.

If we think for a moment about the user interface for SD modelling, we realise that it is inherently modular: the screen consists of a number of panels.   We have the model diagram, the equation listing, a run control panel, various display tools for showing simulation results, perhaps a control panel with sliders for changing parameters, along with various dialogue windows. It is hugely wasteful for every team who wants to develop SD modelling software to have to reproduce all these components. More fundamentally, even given infinite resources to develop the software, any one platform will be a compromise between feature-richness and useability: users find too many features confusing. But on the other hand, many users will want some esoteric feature that most others don’t – the “long tail”.

As far as I know (and i’m happy to be corrected), Simile is until now the only SD modelling platform which supports this modularity, and then only to a limited extent. [Disclosure: I’m a Director and shareholder in Simulistics Ltd.] When you install Simile, even the free evaluation version, all the tools for displaying model results (graphs, tables, maps etc) are text files in the Tcl/Tk scripting language. Any user is free to edit these files, to copy and alter them, or indeed (using Simile’s API) to make their own. They can then add them into their local Simile directory, or share them with anyone else. But: this applies only to the display of results (not the display of the model); not many people know Tcl/Tk; sharing files for desktop applications is a bit tedious; and you are still after all locked into one package, i.e. Simile.

Systo sets out to see just how far we can push the kitchen model.    No aspect of the user interface is hard-wired in.    Rather, the “kitchen” (a web page) is constructed using whatever HTML the web page developer wants to provide, and whatever Systo widgets they want to include in the page.   Systo does provide a basic infrastructure (the water, gas and electricity services), but all the rest is chosen by the developers – they shop around on the web for suitable “appliances”, confident in the knowledge that they can just plug them into the web page.

Arguably, this approach is much closer to Tim Berners-Lee original conception of the web – as a peer-to-peer sharing of information. This contrasts totally with the current model: monolithic and centralised web apps on a single site, with the site owners dictating the whole of the user interface.

Of course, not everyone wants to design a kitchen from scratch.   If you are going for a week’s self-catering, you expect to find a fully-equipped kitchen waiting for you.   And so it is with modelling on the web: most users will have no interest in writing HTML, or Systo’s widget-based approach.    They just want a nice, functional site which suits their needs, in terms of the models it provides or the tools available for working with models.   That’s fine: they will just go to one of the many Systo-based web sites for doing their modelling, and they may not even be aware that the site is not a  conventional web app.

So: let’s start cooking!


Welcome to the Systo blog

Systo is  an open, adaptable and lightweight approach for viewing, building and running systems models in web pages.

At its core, Systo allows anyone with minimal knowledge of HTML and Javascript to build a web page for viewing, building and simulating the behaviour of simulation models.

The key underlying concept is that a web page is assembled from a set of widgets.   Each widget handles one aspect of working with models:; for example:
– displaying the model diagram;
– displaying a graph of simulation results;
– listing the model equations.
The following screendump illustrates the approach with a sample of widgets from a Systo-based webpage.


The way that web page developers do this is very similar to the way that they include images in a web page, but inserting <div> rather than  <img> elements at the appropriate place.  Then, instead of linking to something static (the image), the element is linked to the widget which performs the appropriate task (such as plotting a graph) – this can be done with a single line of Javascript.   The widgets themselves can live anywhere on the web: one page can pull in widgets from a variety of URLs (just like one could do with images).    

This approach is in marked contrast with almost all web apps, which provide a single, monolithic, “walled garden” web site: a single URL (such as which totally controls how you can work.    With Systo, there can be 100s of Systo-based web sites, each reflecting web-page design choices made by the web-page developer.

Moreover, anyone with the ability to program in Javascript can make their own widgets – either by modifying an existing one or by creating a new one from scratch.   Some of these could be improvements on exiting ones; others could implement some great innovative idea about how to work with models.

Together, these characteristics of Systo promise to unleash a great burst of creativity in the way we model.    Web page developers will design really engaging web pages, perhaps incorporating audio, video, graphics and images to go along with model diagrams and display of results.  Anyone interested in improving the way we work with models just has to make a single widget, piggy-backing on pre-exiting components for handling other aspects of the modelling process, rather than having to develop heir own modelling environment from scratch.

This blog starts as Systo cautiously approaches its initial release.   I will be reporting on developments, and ruminating on some of the issues faced while working on it.    Hopefully, others will join in – if only to suggest better ways of doing things!