Mapping of application model to architecture model (wireless sensor system)

The proposed work will cover the definition and implementation of a mapping mechanism that constructs an executable system model for an application-specific sensor network simulation. The desired system model, which will be based on a wireless sensor network, shall be built by using appropriate submodels that separately represent system behavior (function model), its physical implementation (architecture model) and application-specific model (i.e., mobility).

Function model: it describes target system behavior by using logical sensor entities, which provide typical sensor network functionalities, like sensor processing, radio communication, and data management. A behavior of such a logical entity would be given in certain separate state diagrams (compatible with UML statecharts). The sensor processing diagram represents basic operations for accessing sensors and processing sensor data, i.e., data averaging or compression. The communication diagram represents basic communication protocol and is the main part of the function model. The data management diagram specifies local data storage handling (data is removed after successful transmission or due to memory overflow). The function models can be defined for the source and destination entities differently.

Architecture model: it contains potential physical parameters for physical sensor nodes, that can be obtained from technical descriptions of available hardware platforms or some prototype models: sensor type/delay, memory size, processor type, radio transmission range/rate.
Two types of hardware architecture models are chosen: COTS (Berkeley Mica series) and SoC (VHDL/FPGA) models and both support the TinyOS operating system.

Application-specific model: radio channel models, group/individual mobility model.

Mapper: According to a given application scenario, it constructs a system model that comprises of aforementioned three separate models: function, architecture and application-specific models.
It takes certain parameters from application requirements: a number of the target objects (i.e., animal under biological study), additional properties/restrictions of the target objets and base stations (i.e., mobile or stationary, possible communications), study area, intended positions for obtaining data from the targets (if destinations are stationary), candidate sensor node hardware architecture (one or more) etc.

The mapper creates the same number of the instances (a simple PTII actor that can contain required parameters for the function and mobility models) for the source nodes; the amount is equal to a number of target objects. The maximum possible number of the instances for destination nodes (or base stations) will be derived from the number of the base stations (or their positions). By default, all source nodes will be mobile and all destination nodes will be stationary and only existing communication is between the sources and destinations (restriction: no communication between sources).

The system is verified by simulation and evaluated with certain metrics, such as connectivity/delay (a function of the numbers of sensors, destination nodes, and positions, communication protocol, memory), and power consumption/network lifetime (a function of architecture, communication protocol, and the numbers of sensors). Because of complexity in estimating power consumption, only connectivity/delay will be considered at first.

When any of source nodes is in communication distance of any of destination nodes and the destination node is active they will exchange data until the communication terminates due to distance. During communication, physical delays will be introduced by a channel model and the architecture model.

Possible application scenarios:
- mobile sources and stationary destinations
- both sources and destinations are mobile
- communication is only between sources and destinations, but not between sources
- communication is possible between sources, and sources and destinations.
- above scenarios in case of 2-3 different communication protocols (protocol descriptions will be taken from the Zebra project)

A diagram below shows structure of components that will be defined and implemented within the work.



Comment:
- Implementation (in blue, PTII actors)
- Definition (in pink, UML compatible)
- Definition (in green, actor-oriented/PTII compatible, classes)