1 / 19

Sens4U: Wireless Sensor Network Applications for Environment Monitoring Made Easy

Sens4U: Wireless Sensor Network Applications for Environment Monitoring Made Easy. Krzysztof Piotrowski and Steffen Peter. Agenda. Background Use case Extended module concept Application logic definition Ideal configuration Conclusions. Scenario 1: Monitoring Beaver Behavior.

madlyn
Download Presentation

Sens4U: Wireless Sensor Network Applications for Environment Monitoring Made Easy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sens4U: Wireless Sensor Network Applications for Environment Monitoring Made Easy Krzysztof Piotrowski and Steffen Peter

  2. Agenda • Background • Use case • Extended module concept • Applicationlogicdefinition • Ideal configuration • Conclusions

  3. Scenario 1: Monitoring Beaver Behavior

  4. Scenario 2: Opencast mine

  5. Background • TwocomplementaryPhDtheses • ConfigKit – automaticcreationofmodule-based WSN softwareconfigurationsbased on securityrequirements • tinyDSM – configurabledatastoragefor WSNs witheventdetectionand user-defineddataitems, replicationandconsistency • Combinationofthesesupportsacceleratedapplicationdevelopment • Extensions in bothareasneeded • Extension oftheConfigKitconcepttosoftwareandhardwareandarbitrary (not securityonly) setofrequirements • Simplificationofmethodsallowingthedescriptionofapplicationlogicthatbecomesthe top-level softwaremodule • Environment monitoringapplicationsastheareaofthe Sens4U project

  6. Usecase • Customer defines her requirements: • Locations, Measurements, Maintenance, Reliability • The integrator inputs these into the Planning tool • The Expert System combineschosenmodulesaccordingtotherequirements • The Verificationprocessmaytrigger additional loop, e.g., updatingthemodulepooloradjustingtherequirements • The chosenconfigurationisimplemented • Wefocus on environmentmonitoringscenarious

  7. Y-chart analogy Module Pool

  8. Roles in the development process • End user • Application designer • Integrator User Module Pool ComponentDeveloper FrameworkDesigner

  9. Module Pool relations • includesdefinesthat a modulebelongsto a larger module, e.g., a µC belongsto a nodeplatform. • usesdefinestheinterfacesusedby a givenmodule • providesdefinesinterfacesprovidedby a givenmodule • has_parameterdefinesthevalueof a parameterfrom a providedinterfaceforthegivenmodule • requires_parameterdefinestherequiredvalue(s) of a parameterfrom an usedinterfaceforthegivenmodule

  10. Applicationlogicdefinition • Transformation ofthe non-technicalrequirementsinto a setoftechnicalrequirements • The mosttrickypartofthesystem

  11. Requirements • Requirements are: • Technical parameters and constraints • Description of environment • Description of participants (user, attacker) in the scenario • User requirements are often fuzzy and non-technical • Need for translation of user requirements to technical requirements • User selects and parameterizes properties from a requirement catalogue • They will be translated to technical requirements • Example: Requirements User Requirements Technical Requirements • - Application type (health care, home, industrial) • Required security attributes (concealment, integrity, robustness) • Parameters Attacker model and capabilities

  12. Applicationlogicdefinition, cont • Possible on different detail/experiencelevels • Macroprogramming • Scripting • Pure moduleprogramming • Weidentifiedthemostcommonpatterns (requirementscatalogue) • Withthefocus on environmentmonitoring • Weprovide a GUI todefinetheapplicationlogic (Planning Tool) by: • Providing thegroundviewforthemonitoredarea • Definingcommunicationenvironmentandobstacles • Definingthemeasuringpoints,proceduresanddatadependencies • Prototype implementation will beavailablesoon

  13. Methodology Find models to express properties as function between requirements and system Requirements components • Does the system under development satisfies the requirements? Models Component and system model • How to define requirements? • understood by users • Precise for the system SYSTEM Formal framework

  14. Methodology: CompositionProcess RequirementsCatalog Property Repository Component Repository Requirements Working Model Composition Selection init Input für Selection Goal: Noconflicts Look forsuitable Components

  15. The ideal configuration The configurationsthataregeneratedwiththetoolstheyinfluence

  16. The ideal configuration Forexample: Interface A - Parameter A1 - Parameter A2 Interface B - Parameter B1 Interface C - Parameter C1 • Eachconfigurationconsistsofmodulesconnected via interfaces

  17. Conclusions Wepropose a systemthat: • supports the non-WSN-experts in the specification of they real-life target system requirements, • provides a module description framework to support computer aided application development and module testing, • allows creating application specific/optimized software and hardware configurations, • does not only suggest software compositions, but also suggests hardware components with diverse granularity (platform, chip, module) and functionality (accelerators, sensors, actuators) to fulfill the given task, • utilizes an user and process model that emphasizes the applicability by non-WSN-experts.

  18. Thankyouforyourattention!

  19. The deploymenttool

More Related