Application development for the internet of things

1,255 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,255
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
38
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Application development for the internet of things

  1. 1. Application Development for the Internet of Things Pankesh Patel 24th January, 2013
  2. 2. Outline• Characteristics of IoT• Application development challenges• Related work• Contribution• Conclusion• Ongoing and future work
  3. 3. Characteristics of ``things’’• May have sensors attached• May have actuators attached• Can communicate with other things• Can be involved in the information exchange between ``physical’’ and ``virtual’’ worlds 3
  4. 4. Marriage of sensor network and pervasive computing Sensor network Pervasive computingLargeScale Heterogeneity Internet of things
  5. 5. Multiple levels[IoTSurvey] Internet of Things Domain … Smart Health-care Transportation Environment DetectingApplication HVAC FireDeployment INRIA office Google Office [IoTSurvey] L. Atzori, A. Iera, and G. Morabito. The Internet of Things: A Survey. Computer Networks, 54:2787–2805, 2010.
  6. 6. Outline• Characteristics of IoT• Application development challenges• Related work• Contribution• Conclusion• Ongoing and future work
  7. 7. Heterogeneity of the devices• Different types of sensors and actuators (e.g., temp. sensor, badge reader)• Different implementations (e.g., Android, iOS).• Different interaction modes (pub/sub, req./resp., command)• Different data unit (e.g., ‘C, ‘F) Ideally, it should not be the developers responsibility to handle this heterogeneity.
  8. 8. Large scale• Hundreds to thousands of devices equipped with sensors and actuators• Reasoning such a scale is not feasible/practical. Need of adequate abstractions to present the large scale in suitable manner .
  9. 9. No separation of concernsWide range of hardware Domain-specific and software entities, Middleware specific features running on specific features platforms All concerns are largely coupled Internet of Things Application into the application logic. Need of separating all these concerns to enable reusability.
  10. 10. Lots of glue code• The stakeholders have to write lots of glue code apart from an application logic: – Interface hardware and software components – Interface software components and middleware. – mapping code for device and software component Ideally, the glue code should be generated, allowing the stakeholders to focus only on the application logic.
  11. 11. Life-cycle and future changes– Development: The application logic has to be analysed and separated into a set of distributed tasks for the underlying network.– Deployment : The tasks have to be implemented for the specific hardware.– Evolution: future changes in the infrastructure and application requirements. Covering application development life-cycle
  12. 12. Summary• An approach 1. Covers all application development stages 2. Links IoT development concerns 3. Supports modeling language (abstracts heterogeneity and scale) 4. Provides automations at all stages
  13. 13. Outline• Characteristics of IoT• Application development challenges• Related work• Contribution• Conclusion• Ongoing and future work
  14. 14. Related work Approaches Motivation Examples DisadvantagesDatabase •Provide SQL-like interface, TinyDB, Cougar, SINA • Only for homogeneous •Address scale for data- devices collecting application • Missing development life-cycleLibrary- or •Offer abstractions to Gaia with Olympus, •Lots of glue code,toolkit based implement applications Context toolkit •No separation of concerns • Address heterogeneity •Missing development life-cycle partiallyModel-driven •Raise the level of abstractions ATaG, Only cover a limited subset of in program specifications (in DiaSuite, requirements UML/textual language) and PervML transforms into working implementations
  15. 15. Outline• Characteristics of IoT• Application development challenges• Related work• Contribution• Conclusion• Ongoing and future work
  16. 16. Contributions… Classification of concepts1 Conceptual model Captures concepts and associations 2 Development concerns to represent the IoT applications • separation of concerns, •Promotes re-usability are specified in are combined in3 A set of modeling languages •Abstracts heterogeneity, A multi-stage model-driven •Abstracts large scale, 4 •Parameterized with domain approach for IoT • Supports application development stages • Links IoT development concerns •Supports automations at all stages
  17. 17. Our IoT Conceptual Model (1/2)It encapsulates system’sfunctionalities, providesinterface. Communicates-with Traditional 1..* 1 consumes 1..* 1 SoftwareInternet concepts Information Component 1 generates 1 Extends Extends Extends Extends End-user Storage Computational Driver Application Service service Interacts 1 1 Provides Extends Extends with access to 1 1..* Sensor Actuator User Store Driver Driver ``Things’’- oriented concepts 17
  18. 18. Our IoT Conceptual Model (2/2) Entity of Consists of Observes Phenomenon Interest affects Actuator Sensor accesses actuates Resource Actuator Sensor Hosts Driver Driver Device generates consumes Runs-on Software Component Command Sensor Measurement End-user Storage Computational DriverApplication Service Service Information User Store 18
  19. 19. IoT applications and its development concerns Domain Application • Sensor, • Computational • Actuator, Service, • Storage IoT • End-user application Applications Deployment* Infrastructure • Device • Sensor Driver, • Actuator Driver, • Storage Service This concerns describesinformation about howspecific to the application This concern supply howconcepts that components are are grouped This concerns the the software are the devices connected for It refers to underlying platform specific-components. domain (e.g., buildingapplication logic. specifying the automation, transport) and physically distributed.* I am in process of identifying a suitable name. The name could be “physical”.
  20. 20. Actuator Vocabulary Lang. Device action Affects Phenomenon (Domain) (e.g., Heater) Information/ Deployment command Lang. Architecture Lang. Computational Service (Deployment) Computational Device (Application) Service Computes Information and take decision Computational(e.g., Calculate Avg) Sensor Service Measurement Observes Phenomenon Vocabulary Lang. Device Sensor Storage Stores info.(e.g., Temperature Sensor ) (Domain) about Phenomenon (e.g., User’s Preferences) 20
  21. 21. Vocabulary Language (1/2) As a first step of abstracting heterogeneity, sensing and actuating entities are specified in high-level manner. One resource description for many implementations. One resource description for manystructs: instances. TempStruct tempValue : double; unitOfMeasurement : String;resources: sensors: TemperatureSensor generate tempMeasurement : TempStruct; actuators: Heater action Off(); action SetTemp(setTemp: TempStruct); storages: ProfileDB generate profile : TempStruct accessed-by badgeID : String; 21
  22. 22. Vocabulary Language (2/2) To address scalable operations within IoT system, hierarchical clustering should be specified [SINA]. Building:03 regions: Building : Integer; Floor : Integer; Floor: 10 ... Floor: 15 Room : Integer; Room: 5 Room: 6Use of region construct: • Enables system partition at logical level • Defines scope from which software components will produce/consume data [SINA] Srisathapornphat, C. and Jaikaeo, C. and Shen, C. , Sensor information networking architecture and applications, 2001 22
  23. 23. Architecture Language avgTemp In-region : room Room AvgTemp tempMeasurement hops:0:Room Scope of consuming Temperature data. SensorRoomAvgTemp Enables consume tempMeasurement from hops : 0: Room ; Hierarchical generate avgTemp : TempStruct ; Clustering in-region : Room ; Scope of deployment 23
  24. 24. Deployment LanguageTemperature-Sensing-Device : Device Name region : Building : 15 ; Floor : 11; Room : 0; Attached sensor/ abilities : TemperatureSensor; actuator/storage type : sunspot; with deviceBadge-Scanner : region : Building : 15 ; Floor : 11; Room : 0; abilities : BadgeReader ; type : android; 24
  25. 25. Vocabulary Specification 1 Vocabulary Specification using Vocabulary Language Domain Vocabulary • Sensor Expert Specification • Actuator • StorageSpecifyInputReferOutput 25
  26. 26. Architecture Specification 1 2 Domain Vocabulary Expert Specification Architecture Application Specification Designer He defines architecture of an application using Architecture Language. • Computational service • End-user applicationSpecifyInputReferOutput 26
  27. 27. Implementing Software Component 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer Framework Generator 3 4Application Application ApplicationDeveloper Logic Framework Specify Input Refer It allows application developers to focus onOutput software component logic. 27
  28. 28. Target Deployment Specification 1 2 Domain Vocabulary Expert Specification Architecture System Specification Designer 5 Framework Generator Network Network 3 description Manager 4Application Application ApplicationDeveloper Logic Framework Specify He specifies target deployment scenario Input using Deployment Language. ReferOutput •Device 28
  29. 29. Mapping 1 2 Domain Vocabulary Expert Specification Architecture Application Specification Designer 5 Framework Generator Network Network 3 description Manager 4 Mapper 6Application Application ApplicationDeveloper Logic Framework Mapping files Specify Input It decides the specific device where Refer each software component will beOutput running. 29
  30. 30. Writing Device-Drivers 1 2 Domain Vocabulary Expert Specification Architecture Application Specification Designer 5 He writes device drivers Framework • sensor driver Generator • actuator driver Network Network 3 • storage service description Manager 4 Mapper 6Application Application 7 ApplicationDeveloper Logic Framework Mapping files Device Device Developer Specify Drivers Input ReferOutput 30
  31. 31. Linking 1 2 Domain Vocabulary Expert Specification Architecture Application Specification Designer 5 Framework Generator Network Network 3 description Manager 4 Mapper 6Application Application 7 ApplicationDeveloper Logic Framework Mapping files Device Device Developer Specify Drivers 8 Combines the generated code into Input System Linker the actual code to be deployed on Refer the real devices.Output 31
  32. 32. Maintenance and evolution(1/2)E.g., Adding a new applications in the existing infrastructure.E.g., Moving an application from one deployment to other.E.g., Implementing and plugging new device drivers. Change in Any requirements? Defining Defining Defining Defining Compiler Domain Application deployment infrastructure Concern concern concern concern 32
  33. 33. Maintenance and evolution(2/2) 1. Change in vocabulary specification 2. Change in architecture specification 3. Change in network specification Preserves previous application logic and replaces the generated Implementation framework (Application logic)Spec. Initially generated Initially generated Change in Compile time Modified framework framework Spec. errors Impl.
  34. 34. Outline• Characteristics of IoT• Application development challenges• Related work• Contribution• Conclusion• Ongoing and future work
  35. 35. ConclusionRequirements Solved in our approachAbstracting • Vocabulary language (Different types of resources , DifferentHeterogeneity types of implementations) • Architecture language ( different types of interactions)Abstracting • Architecture and vocabulary lang. (system-level)Scale • Scope constructsSeparation of concern • Conceptual model , capturing concepts and association • Classification of development concerns (enabling reusability)Automation in Code generation and task mapping techniquesdevelopmentCovering application • Links development concernsdevelopment stages • Supports automation in software development • Combines modeling languages • Supports for each stage of application development
  36. 36. Outline• Characteristics of IoT• Application development challenges• Related work• Contribution• Conclusion• Ongoing and future work
  37. 37. End-user interactions with devices• The end-user is going to play a major role in the IoT applications. – Originator: an user triggers an event or query to the application. – Recipient: an user is notified a final results by the application. – Intermediary: an user is prompted as required. We will provide abstractions to specify these users’ interactions with applications.
  38. 38. Mobility of devices**• The current version of our modeling language considers only static topology where the devices do not move once they are deployed. We will support mobile devices in our future version of modeling languages.** I am investigating this future challenge.
  39. 39. Evaluating expressiveness of modeling languages• It explores the subset of IoT applications characteristics that may be suitably developed in the framework. What are the characteristics of IoT applications that can modeled by our approach ?
  40. 40. Evaluating development effort in the real-world• It evaluates the time required to develop an application.• To measure the development effort, we plan to give our framework to our lab members with a suitable application.• From this experiment, we will measure the total time to develop an application.
  41. 41. Tentative time-line Month TODO listFebruary (1) Journal paper submission (2) Finish future workMarchAprilMayJune Thesis Writing and Thesis submissionJulyAugustSeptember Presentation preparationOctober Thesis defense What will an Intern do with the help of me ? (next slide)
  42. 42. What will an Intern do ?1. The intern will implements different applications using our framework. – Outcomes: • Expressiveness of our approach • Bugs identification and fix2. The intern will implement a wrapper between our framework and a middleware. – Outcomes: • Prototype implementations in real-world.3. The intern will write a documentation of our approach on web- pages. – Outcomes: • It will guide the developers to develop IoT applications. • It will help our future PhD students to further extend this work.

×