Some ideas on runtime data visualization in python simulation

In this post I consider some ideas on data visualization for python simulations.


This data visualization concept which I am talking about is not the one which we typically encounter at the end of a simulation run when we have a set of collected data which we plot and analyze using various statistical means.  What I am really interested in is, the visualization ( and animation ) of runtime data structures of a simulation model during the simulation run which can present a very intuitive view to the user about the internal working of the model. This way we actually get to see , how our main data structures are getting changed / altered during the runtime to get a decent picture of the model performance and this can also help in debugging.


Just to give an example to get the things more clear, we are aware of the TCP sliding window protocol. Now , if we have a simulation model for the sliding window protocol , then obviously we will be having a data structure for maintaining the sliding window. In python this could be a list or a set data structure.    So, during runtime, the sliding window data structure will encounter various operations like addition , deletion of packets ( or sequence numbers ) and sliding through the data and increasing/decreasing the size of the window etc, etc.  If we can standardize a set of visual representations for these operations and a set of animations for representing the data changes on the data structure then this can act as a very effective framework to analyze the data at runtime.  


To develop such a standardized framework we have to consider some commonalities between the data structures.

-  All the data structures are essentially sequences of data .

-  All the data structures provide facilities to add and delete single or multiple data sequences. (An exception is a tuple which we will discuss about later ).


Next we examine the exceptions and special cases for some data structures.

- We also deal with primitive data like an integer float or a character. These can be considered as special cases of single data sequences.

- There are certain data structures which are immutable as in the case of a tuple in python. So the visualization framework needs to be aware of it.


- We also encounter strictly defined sub sequences within sequences in data structures. A typical example if this is the dictionary. Here we always have multiple key value pair sequences as part of the main data sequence of the data structure.    


Considering the above commonalities and  the exceptions , we can design a visualization framework with the following basic features.

- The framework will be attached to a set of python variables containing the data structures and will monitor them.

- The framework will be aware of immutable data types and special strict sequencing of data structures like a integer ( a single value sequence ) or a dictionary ( a sequence of sub sequences containing a key and value ).  


- The framework will support animation sequences for every change in the data within a    sequence.   


- The framework will support special highlighting whenever the sequence is modified ( data added, deleted , changed ). This will also apply to special strict sequences and immutable datatypes in the following ways.

- In case of single value data structure , the framework can display the new value of the              data along with the sequence of previous values or the diff of previous value.


-  In case of strict sub sequences , the framework can display the non constant part of                the sequence as a single value data structure as mentioned above. For example , in a                dictionary the key will always remain constant whereas the value of the key will                        change.  So this value can be treated as a single value data sequence.

  -  In case of immutable data types like tuples, the framework will keep a tab of the variable    containing the data and will have a animation or highlighting sequence defined whenever            the variable is reassigned to contain a new tuple sequence.  

- The framework will support the enabling / disabling of display of a sub section of the sequence by defining a pair of bounds ( upper and lower bound ) for the data structure sequence.


- The framework will support the enabling / disabling of highlighting  of a sub section of the sequence by defining a pair of bounds ( upper and lower bound ) for the data structure sequence.


These are some of the basic features which I can think of , based on the sliding window example. I will extend this list with a few more features which may seem desirable.

In my next post I will try to come up with some ASCII based simple diagrams of the visualizations which I have discussed here.  I hope that will make more sense to the readers rather than going over the descriptions here,as they say "A picture is worth a thousand words" .



Python based Simulation as an aid to Foresight

It is a well known fact that Python language has a very easy to learn structure which help in rapid development. Any beginner programmer can also realize this within a short time and this was also one of the fundamental goal of the its creator, Guido van Rossum.  This fact has been exemplified by many commercial software projects which started as python code for rapid prototyping and later on were very easily ported to C++   / JAVA based languages.  


I was also impressed with the neat and clean, strict indent based syntax of python code , the first time I came across one program.  Throughout my life and career, I have remained a strictly C/C++   programmer with occasional doses of shell scripts and TCL scripts.  When I learned TCL , I realized the prowess of a interpreted dynamic language. TCL was also well suited for my work on telecom equipment testing and over a period of time I became a pro in it. But I always felt the lack of object oriented programming features in TCL which eventually used to become a big mess in larger programs. I learned python as part of a official training program for a project ramp up plan for one of our clients. Although I never had the need to use python in the project but I felt attracted towards it and began to explore it in my free time.       


Now some off python incidents in my life........


One of my biggest fascinations have been to see or work on a computer animation which explains the concept of any phenomenon which is a set of complex logic ( or a complex interaction of systems ). Visual description of a complex system is obviously more productive than a theoretical explanation and realizing this I began to explore more on how I can make use of this in my work domain , i.e. in case of telecommunication protocols and systems. Over time I realized that it is better to have a simulation program with graphics animation capabilities rather than a animation alone. A robust simulation can parallel the actual system and this can enable it to be programmed to behave similar to the actual system whereas an animation is basically just a set of hard coded image sequences which are rigidly defined and offer no programmability and cannot parallel a complex system in any case.


My initial attempt to build a simulation program was for the 8051 microcontroller. I intended to build a software 8051 chip module which could connect to peripherals and could be obviously loaded with the assembly program  which would then execute on it ( executed by the underlying simulation engine )  . I also fantasized of having a visual environment where I could see the 8051 and the peripherals connected by wires ( buses ) and sending signals  and drawing a chart of the clock cycle and the bus cycles and seeing the assembly code getting executed. I saw this as a great tool for teaching the 8051 system and also as a aid in developing applications on the 8051 microcontroller. The language I chose for this was JAVA as I was learning it at that time and I also felt that JAVA has a very good graphics library which would help me for developing the visual simulation along with animation capabilities. I pursued the development for some time and eventually developed a small 8051 execution engine ( which could support a limited subset of the 8051 assembly language ) and a  small LED peripheral along with a crude looking visual GUI for runtime visual simulation ( the overall GUI was indeed crude but the LED GUI was fascinating, especially the turning on and turning of of the LEDs during execution of programs was enthralling). With the initial success I started dreaming about developing a complete visual simulation environment for the 8051 microcontroller along with a variety of peripheral modules to connect and experiment with applications. Unfortunately , I could never have to time to work on it and job pressure compelled me to abort it midway.


This whole experience taught me two important things. Number one, it is important to have a generic simulation engine which can be extended or used to model any real system. In my 8051 simulator , I wrote the simulation engine from scratch and was completely engrossed in the internal workings of the microcontroller , so I wrote the engine with that in mind and as a result the simulation engine was not generic at all but a very very specialized one which could be reused only for microcontroller or microprocessor based systems.   By having a generic simulation engine , one can extend it to model any real system you want to simulate , however the effort in extending will obviously increase with complexity and if the generic simulation engine is well designed then it will scale well.


Number two, it is important to identify the abstract concepts and rules related to interactions between systems in real world so that all specialized or complex interactions can be broken into simple rules and the generic simulation engine can support those rules. In the study of a complex system, we can always break it down to a set of simpler components and then analyse the interactions between them. At the fundamental level, these interactions are simply a sequence of messages exchanged between the components which may occasionally result in a reaction. It is these interactions which drive the system as a whole and the multitude of components and their interactions make the system really complex. With a generic simulation engine we can split the system into multiple components generically and define and extend the interactions which can cater to all types of systems. This can also aid in managing the visual simulation aspect of it as each kind of interaction can have a associated generic rule which has a defined animation which will be visualized during execution in runtime.    In case of my 8051 simulator , the main interactions were the system buses between the controller and the peripherals and the data exchanged were in bits or bytes. I modeled the system interaction based on this concept and hence I could not use it for an application where I had to pass a direct current  to a certain bus at a fixed voltage level.


Another important lesson for me was about the fundamental design of computer simulation which is based on discrete events and the advancing of simulation execution is based on time stepping . I realized these concepts which writing the simulation engine but was too fascinated by the fantasy of the visual look and feel of the 8051 s/w board that I paid little attention to this.


After this initial attempt , I decided to devote some time in researching some simulation tools. I came across many of them on the internet and they all seemed to concur with my learnings. The most comprehensive tool which I found was the OPNET simulation engine. It has a open source version called OMNET++ and comes with a good set of examples on modelling and simulating various telecom networks and networking protocols. Further exploration of the tool reinstated my belief about the genericness of the simulation engine and its supported interactions. The OMNET++ is a very very good tool indeed but it lacked a impressive visual interface. it has its own language for designing a network topology that can be visualized in runtime but the overall look and feel of the visual simulation components and their interactions during runtime is poor. 


A closer scrutiny of the visual features of OMNET simulation gave birth to one more concept in my mind. By seeing the system under simulation and seeing the visual interactions between its components, I realized that it would be really nice if we could gaze inside each component and see how it is interacting with the external world. In visual terms this would mean that we could somehow get inside the component ( by clicking the mouse on its GUI widget) and then see the animations of its internal sub component interactions. This would give a 360 degree view of the whole system under simulation and would be a great way of exploring each aspect of the system execution and performance.   We could also have generic rules for the interactions of the subsystem with its internal data structures ( FIFO, Queues, Pools etc. ) which could be described as animations and  seeing the animations in runtime could give more insights into the working of the subsystem.      


Now , back to python .........


 After exploring OMNET for few months I was convinced that more needs to be done about the visual aspects  of simulation to make it more intuitive. I had already been working with python and had realized that python already had a very good collection of graphics and GUI libraries which could do the trick. The only missing part was the availability of a generic simulation engine. Few months of rigorous google searches led me to Simpy simulation library and after another few months of exploring it, I was convinced that this was it. Simpy offered all the basic features which I was looking for and now I has to build my simulation library on top of it, which can be called "generic". I have started to build the library on top of SimPy and have a rudimentary prototype working, with which I have modeled a few of the OMNET examples like the FIFO model.    



  After having experienced the initial joy of developing a generic simulation engine I can say that my mind is now in a ecstatic mood and millions of ideas are swirling in my mind. I am fantasizing of building the simulation engine into a such a robust tool ( a simulation based communication product development tool )  which can not only help to design a prototype of a system but can also help to foresee design or performance issues well ahead of time.  This , I believe is a big challenge in the current scenario  ( I refer to the telecommunication & Hi-technology product development scenario ) because the time to develop a product is always less due to competition in the market. Also,there is a huge lack of foresight in an average human being which only gets diminished with added work pressure. This is especially true in case of high technologies and niche domains where the expertise is rare to find.   So this is what I mean when I quote the subject of this blogpost  "Python based Simulation as an aid to Foresight". I am beginning to envisage this python based simulation system to aid in foresight by being part of a telecom software project design lifecycle. Any system defect caught in the design stage is lest costly then being uncovered later ( closer to release or launch dates ) and by offering its foresight in identifying the defect the simulation engine can work with the human being's inherent hindsight to develop a robust system upfront. 


This concept of simulation based design is obviously not at all new. If we look around, especially in the manufacturing or automotive or aerospace industries we will find out that many simulation tools are being used in product design and this practice has been incorporated in their design process long back. Just to present an example , the Boeing 767 was entirely designed using computer aided design and simulation and that too , way back in the 1970's. However, in software design processes, this methodology is not widespread even today ( except probably for software systems which are built on top of these hardware or mechanical systems , as in the case of avionics of an airplane ) . Partly , I feel , because in manufacturing, automotive or aerospace industries involving mechanical and hardware components, the cost of fixing a design defect in later stages of product development is usually very very high compared to a purely software based system hence they need to adhere to rigid quality standards which need to be backed by simulated models to analyse the design. In telecommunication industry also, ( where I belong to ) this practice is not followed widely even in mission critical software systems which are build on top of hardware or embedded systems and involved complex system interactions.This, along with ever reducing time to market, has created a big void in the overall quality matrices of telecommunication products and system design and something needs to be done about it.


By using Python for rapid application development, with a host of graphics and visualization tools ( python based ) coupled together with Simpy, I envisage to build such a robust tool which will not only offer simulation driven engineering of communication and computing system but will also aid in analysis and decision making so that it can be used with ease by engineers of all skill levels.The ultimate goal is to be able to integrate such a tool into the software development lifecycle of any process model ( be it waterfall or agile or accelerated prototyping and feasibility study based model ) .  


Apart from being helpful in design, a simulation engine with a robust animation can be a really great tool for training. I have come across multiple training sessions on telecom protocols which are usually presented as mere bulleted points in a powerpoint presentations. This is overtly boring and does not help even a bit when it comes to explaining a complex piece of interaction between two systems. A runtime animated sequence of the interactions ( backed of course by the underlying simulation engine ) can work wonders in this case. I leave it to the readers to ponder over it and suggest some ideas about how to make this training aspect of the simulation more intuitive. 

Choice of simulation engine

A Simulation engine, as we all know, is the heart of a simulation system. In case of python, there are not many opensource simulation libraries available which fit my bill. Most of the libraries are either targeted for specific domains or are too heavy weight or they are usually good for virtual physics simulations.  I was looking  of a simulation engine which was , first of all very light weight, second of all , generic and simple enough which could handle any discrete event simulation scenario and lastly should  be purely pythonic.


I used to carry out regular and scheduled google searches to find out various python based simulation tools available on the web. Initial attempts led to lot of disappointments but I persisted and finally one day I stumbled upon a tool called SimPy. After going through the documentation ( pretty well written one but a bit scattered) , i felt that it suits my purpose. Initially , I had some amount of confusion about the use of yield function call in python ( I was still learning python , back them and am still a novice ) , but after trying out the initial sample simulations (Simpy uses the yield function as the basis of scheduling events ) , I was convinced about its capabilities and fell in love with it.


Another factor in choosing a opensource tool is the amount of activity surrounding the development. In case of SimPy, this was not an issue and i found the mailing list to be quite responsive. One issue thought which is not certain at this point of time, is about the scalability aspect of the tool. I am not sure if the tool will behave erratically in case of large , complex simulations with hundreds of simulation objects interacting with each other. For now I have decided to ignore it and based on the tools simplicity and the development activity around it, I have developed a certain amount of faith in the developers for handling any such eventuality.

Many thanks to Klaus and Tony for coming up with this wonderful tool.     


The Beginning

This is the beginning. The beginning of a complete platform for development of a python based simulation system which can simulate any communication system or entity.


The main idea is to develop a platform tool which can easily model any communication protocol , entity or a system. This will be inline with the OMNet tool and will try to make use of the dynamic scripting features of python to make this tool more friendly and customizable.     


 The overall goal is to develop this tool as an expert system which can be used for training as well as a simulation model/engine to experiment with challenging system designs and to foresee and .rectify issues related to complex system integration activities.


I look forward to any collaboration from anyone who is passionate about python and has interests in design and development of simulation tools or systems ecpecially in the field of telecommunications .  

Copyright(c) 2017 -
By using this website, you signify your acceptance of Terms and Conditions and Privacy Policy
All rights reserved