The document discusses the A4WSN framework designed for modeling and managing software architecture in wireless sensor networks (WSNs). It outlines various components such as modeling languages, node configurations, and a programming framework that facilitate the separation of concerns and abstraction in WSN software development. Additionally, it highlights future work opportunities and calls for contributions to enhance the framework's capabilities.

1. Università degli Studi dell’Aquila
Ivano Malavolta
DISIM Department, University of L’Aquila
ivano.malavolta@univaq.it

2. Who is Ivano?
If you think good architecture is expensive,
try bad architecture.
... Brian Foote and Joseph Yoder
Software Architecture & Model-Driven Engineering
applied to
Wireless Sensor Networks
Mobile Applications
Autonomous Quadrotors

3. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

4. * International Workshop on Software
Engineering for Sensor Network Applications
Problem Definition
From the SESENA* 2012CfP: Abstraction
“the development of WSN software is still carried out in a rather
primitive fashion, by building software directly atop the OS and by
relying on an individuals hard-earned programming skills”
“WSN developers must face not only the functional application
requirements but also a number of challenging, non-functional
requirements and constraints resulting from scarce resources”
Separation of Model-based
concerns Analysis

5. Main Drivers of A4WSN
Abstraction
by masking the complexity of low-level, hardware details
Separation of
concerns
by clearly separating application, HW, and deployment
aspects of a WSN
Model-based
Analysis
by facilitating the analysis of both functional and non-
functional properties

6. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

7. The A4WSN Framework third-parties can contribute
with code generation or
analysis plugins
Separation of Model-Based
Abstraction
concerns Analysis

8. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

9. A4WSN
3 modeling languages
Physical
WSN nodes environment
configurations
Software
Architecture

10. Software Architecture
Structure
components
ports
application data
messages
Behaviour
events
conditions
actions

11. SA: Structure
Components. Units of computation with internal state and
well defined interface
Ports. Interaction points with the external environment
Connections. Message-based communication channels
between ports
Application data. Variables in the scope of the component

12. SA: Behaviour
Each Component can contain a description of its behaviour
The behaviour is based on:
1. Events-conditions-actions
2. Modes

13. SA: Actions
Sense gets some data from a sensor and stores the read
value into a specific application data
ex: get current temperature
Actuate activates and actuator, optionally an application
data can be used to pass a parameter to the actuator
ex: actuate a water sprinkler
SendMessage sends a message via a specific message port
Unicast, Multicast and broadcast supported

14. SA: Actions
StartTimer starts a timer which can be triggered later.
Cyclyc, delay and period properties supported
StopTimer stops a previously started timer
StoreData puts some (manipulated) data into an
application data of the component
SyncServiceCall calls an external service (ex. web service)
AsyncServiceCall calls an external service, the result of the
call will be available via a dedicated event
Fork and Join are used to sync the control flow

15. SA: Events
ServiceCallback is triggered when the result of an
AsyncServiceCall is available
ReceiveMessage is triggered when the component
receives a message
TimerFired is triggered when a previously started timer is
activated

16. SA: Behavioural Flow
Behavioural flow is specified by means of Links
A link can exist: E A
1. from an event E to an action A: in this case after the event E is
triggered, A will be executed
2. from an action A1 to another action A2: in this case, A2 is
executed immediately after A1
A1 A2
Conditions are boolean expressions (optionally) associated to links
E t > 30 A
The execution flow goes through a link only if its condition
evaluates to true

17. SA: Modes
A specific status of the component
ex. sleeping mode, energy saving mode, etc.
At any given time, one and only one mode can be active in a
component
The component reacts only to those events which are defined
within its currently active mode

18. Example*
*This example is taken from our journal paper...

19. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

20. Nodes Configuration
Types of nodes
OS
MAC protocol
routing protocol
installed sensors
installed actuators
energy sources
communication devices

21. Node
A nodes specification is composed of a set of WSN node types
Node Attributes:
• OS
• ex. TinyOS, Contiki, Mantis, LiteOS, ...
• macProtocol
• ex. T-MAC, S-MAC, WiseMAC, SIFT, ...
• routingProtocol
• ex. GEAR, LEACH, HEED, ...

22. ex. light sensor,
Node temperature sensor,
smoke sensor...
Node
Sensors
Sensors
Sensors
Memory
Additional
Memory
memories Actuators
Microcontroller Actuators
Actuators
RF
RF ex.
RFs
sprinklers,
leds, lights,
Energy Source
Energy Source switches...
Energy Sources
can be either continuous, degradable, or harvested

23. Microcontroller
Represents the entity which performs tasks, processes data and
controls the functionality of other components in the sensor node
Microcontroller
0_1
0_* ADC 1_* RF
CPU
0_* CPU
DAC CPUs Timer 1_*
Storage memory 1_1
1_1 Memory
Program memory 1_1

24. Power Modes
A Node can specify a set of Power Modes
Each power mode identifies a set of node elements (such as
memory, DAC, RF comm. device, etc.) and distinguishes between
which elements are active and which elements are disabled
Communication Mode Sensing Mode

25. Example*
*This example is taken from our journal paper...

26. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

27. Physical Environment
A 2D space with:
• obstacles
freely positioned
with their own shape
with attenuation coefficients
• deployment areas
freely positioned
with their own shape

28. Example*
As
Am
*This example is taken from our journal paper...

29. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

30. Keeping Models Integrated
Two special models weave together SA, nodes and
environment specifications
Actually, they are WEAVING MODELS

31. The Mapping Model
Links together an SAML model and a NODEML model
It defines how components are deployed into each configured
nodes
Separation of Concerns
It helps in clearly separating the application layer of a WSN from
all the other lower levels
this aspect is new in the WSN domain
Architects can focus on the application from a functional point of view in
SAML, and only later they will focus on low-level aspects

32. The Deployment Model
Weaves together a NODEML model and an ENVML model
It defines how node types are
1. instantiated, and
2. virtually deployed in the physical environment
A DEPML model presents a single type of link: Deployment Link
A deployment link considers a node in the NODEML model, and
assigns it to an area in the ENVML model

33. Area and Nodes Distribution
Nodes can be distributed in three different ways:
Random Grid Custom
each node is placed nodes are placed on a each node can be manually
grid with a certain
randomly within the area placed within the area
number of rows and
columns
N2
N1
N1
BS
N3

34. The Deployment Model
Each node type can be instantiated ”n” times within a specific area
this allow architects to focus on generic components and
node types in SAML and NODEML, while in DEPML we
consider the final shape of the network
DEPML models are the only place in which we reason about the final
node instances, in the other models we reason about types

35. Example* custom distributed nodes
NODEML DEPML ENVML
oxymeter
As
Am
monitor
*This example is taken from our journal paper...

36. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

37. Programming Framework
C1 Cn A1 An
Programming
Code Generation Framework Analysis
Manager Manager
UI
Validation
Manager
Model
Adapter
Messages Models Parameters
Manager Provider

38. Programming Framework
Code Generation Manager
Defines the extension point for code generation engines
It checks which plugins are currently extending its extension point
and makes their facilities available to the end user
Exposes a common Java API to plugin
developers, so that they can easily
interact with all the other components of
A4WSN (validation, model adapters, etc.)
Analysis Manager acts similarly, but it is for analysis engines

39. Programming Framework
Models
Stores all the WSN models developed by architects and designers
Models can be stored:
- in the file system*
- in some server in the cloud
- in some in-memory representation
Model Adapter
Exposes a common interface to the other components of A4WSN
to access the models in an homogeneous way
*currently, this is the only available solution in the A4WSN prototype

40. Programming Framework
Validation
Executes all the operations to validate A4WSN models:
- predefined checks
- user-defined checks (via a plugin)
Messages Manager
Graphically shows informative messages to the user.
Supports three kind of informative messages: information
warning
error

41. Programming Framework
UI Manager
Responsible for the main facilities interacting with the user
interface:
- Code Generation Engines View
- Analysis Engines View
- Code Generation Contextual Menu
- Analysis Contextual Menu
- Validation Trigger
- Progress Feedback
- Additional Parameters View

42. Programming Framework
Parameter Provider
Manages the additional parameters that a code generation or
analysis plugin may require
Makes user-provided parameters available and easily accessible
to the plugin requiring them
Supported types:
string, integer, float, boolean, local resource,
remote resource accessible over HTTP

43. Anatomy of a Plugin
To contribute to A4WSN, each plugin must adhere to the
following “signature”, A4WSN will take care of the rest

44. Anatomy of a Plugin
Code generation-specific
Analysis-specific

45. Anatomy of a Plugin

46. Roadmap
Problem Definition
A4WSN
Modeling Environment
Software Architecture
Nodes Configuration
Physical Environment
Keeping Models Integrated
Programming Framework
Tool Support

47. Tool Support
SAML – NODEML – ENVML:
Dedicated Graphical and Tree-based editors
models
graphical
editor palette
bird
view
properties

48. Work-in-Progress Components
MAPML: Tree-based editor
DEPML: Tree-based editor
Programming Framework as Eclipse plugins
with defined extension points
First version of prototype available at
http://www.di.univaq.it/malavolta/files/ME4AWSN_v0.1.zip

49. Conclusions & Future Work
languages programming
refinement framework development
node
configurations
marketplace? code
generators analysis engines

50. We are looking for Plugin Contributions!