Sensor Simulation System Article No.3

The DEHEMS Sensor Simulation System (DS3) is now constructed around a very simple Event-Driven Architecture (EDA). The reason we have chosen this model is the fact that we wanted our system to mimic, as close as possible, the structure of the real-life hardware energy monitoring system which is primarily composed of loosely coupled components (meters, sensors, gateways). While the meters sensors and gateways in a given household constantly need to exchange messages, there is no need for communication between sets of DEHEMS energy monitoring components situated in different households, as each set sends its acquired data directly to the DEHEMS storage engine.

Structural similarity to the real-life monitoring system is required in order to allow DS3 to simulate communication and data acquisition errors, hardware failures and dynamic appliance selection filters. Moreover, the flexibility provided by an event-driven architecture enables the rapid transformation of DS3 into a hybrid simulation platform in which part of the sensor readings come from real-life sensors which smoothly interact with the rest of the system.

The Java platform was chosen for our first implementation of DS3, as we wanted to develop a cross-platform application and future developments are related with creating user oriented web applications based on simulation and applets.

There are two main types of objects in DS3:

• sensor objects contain the logic for the gross direct simulation stage and output the values that would be produced by individual appliance sensors or by basic temperature or gas sensors;
• monitor objects provide the logic for the detailed pattern based simulation stage, where their role is largely similar to that of modern real life household energy meters like Current Cost 128; they collect data from individual appliance sensors, and (with a frequency of 10 times per minute), use the data to construct the spot household energy consumption profile; the only difference is that, unlike real meters, they do not have access to a general household electric consumption sensor (the Current Cost clamp) and as such, they have to accurately simulate these sensor readings using predefined consumption patterns.

In order to achieve the design imperative of taking maximum advantage of the underlying hardware architecture, DS3 employs a multithreaded consumer producer design pattern (figure below).

Two types of threads exist in DS3:
-multiple manager threads which have the role of producing as many aggregated data packages as possible (producers);

- -a single exporter thread which has the role of forwarding the aggregated data packages via network to the DEHEMS storage engine (consumer).

The interaction between threads is kept to a minimum in order to increase efficiency. Each manager thread holds individual pools of sensor and monitor objects which only need to interact with objects hosted in the same thread in order to produce aggregated data packages.
Data sharing between the producer threads and the consumer thread is realized via a common queue fitted with a bounding mechanism.
Scalability is very easy to achieve using this multithreaded architecture with the sole requirement of choosing the number of manager threads according to the physical architecture of the computer. The best test results have been obtained when the number of manager threads exceeded by one the number of processing cores of the computer.

Our last post regarding DS3 will present some of the results we have obtained so far using the system.

Research Institute e-Austria homepage: www.ieat.ro/