DBStore enables advanced control of simulation parameters for more complex scenarios.
IoT is all about things which are interconnected with each other. In any realistic simulation, you may want to fine tune or tweak the system level parameters. E.g. when running an agriculture simulation, you may want to control the current average rain parameter and let each rain sensor send readings with 5% deviation from the average value. Similarly, you may want to change the destination of a driving truck in real time in order to showcase an intelligent rerouting functionality.
All these features require access to a shared database which is visible to all the running instances and could be externally modified by the user to enable changes in the simulation behavior. We are delighted to introduce DBStore which solves the above problem in an intuitive way.
Changing simulation parameters at runtime is easily doable in IoTIFY with the help of DBStore APIs (glob/gset/geomap) within template syntax. Let’s understand the concept of DBStore with this simple picture
<img align=”middle” src=”dbstore.png”/ >
Each running template instance in IoTIFY has its own copy of state object. Sadly this object can not be shared with other instances. However, they have an access to a global database, known as DBStore. DBStore offers 3 types of storages, which are essentially designed as key-value pairs. These storage could be accessed by any running client via simple APIs (glob, gset, geomap). Note that the visibility of the DBStore is global in the scope of a user account. You can not see the DBStore values of other users and vice versa. However, all the templates and all their instances will have access to the DBStore.
Using DBStore Editor UI which is accessible in Network Simulator, you could now view and edit these DBStore key-value in runtime. This is quite useful due to the following reasons.
- You could now see what DBStore values have been created by all your template instances and refresh them to observe any changes.
- By editing the DBStore values, you will be able to change the behavior of the simulation in runtime.
- You could save the last value of the state object per client in the individual DBStore keys and restore them back upon the next run.
Sounds exciting? Let discuss some more examples of using DBStore APIs.
A Connected truck ready to go anywhere
Let’s simulate a truck which starts from Hamburg in Germany and starts driving towards Munich. We would use drive() function to simulate the GPS coordinates. However, using DBStore APIs such as glob() you could achieve following two objectives
- Save the last known position of the truck when simulation finishes.
- Provide a new destination to the truck while in the middle of the trip by editing the glob value from DBStore editor UI.
Here is a template which will enable this use case.
When you run the template, truck will start driving from Hamburg to Germany.
Once you stop the template run, it will save its last position and drive from that upon the next run.
While running the simulation, you could go to the DBStore Editor and edit the destination entry. On next iteration, truck will update its destination and will start driving to that route.
Sounds exciting? Lets look at the DBStore APIs in more detail.