A4WSN: an Architecting environment 4 Wireless Sensor Networks
•
1 recomendación•922 vistas
These are the slides of the talk I gave the 17th of January at the Communications Group of the Middlesex University, London.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a A4WSN: an Architecting environment 4 Wireless Sensor Networks
Similar a A4WSN: an Architecting environment 4 Wireless Sensor Networks (20)
Más de Ivano Malavolta
Más de Ivano Malavolta (20)
Último
Último (20)
A4WSN: an Architecting environment 4 Wireless Sensor Networks
- 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!