Download to read offline
![Vocabulary Language (2/2)
Floor : Integer;
Room : Integer;
[SINA] Srisathapornphat, C. and Jaikaeo, C. and Shen, C. , Sensor information networking architecture and
applications, 2001
To address scalable operations within IoT system, hierarchical clustering should
be specified [SINA].
Building:03
regions:
Building : Integer;
Floor: 10 Floor: 15
...
Room: 5 Room: 6
Use of region construct:
• Enables system partition at logical level
• Defines scope from which software components will
produce/consume data](https://image.slidesharecdn.com/applicationdevelopmentfortheinternetofthings-230727131901-c8d57ef8/85/Application-Development-for-the-Internet-of-Things-pptx-19-320.jpg)
More Related Content
Similar to Application Development for the Internet of Things.pptx
![project[1].pdf](https://cdn.slidesharecdn.com/ss_thumbnails/project1-230928024842-d4a019d5-thumbnail.jpg?width=640&height=640&fit=bounds)
Application Development for the Internet of Things.pptx
- 1. Application Development forthe Internet of Things
- 2. Outline • Characteristics ofIoT • Application development challenges • Related work • Contribution • Conclusion • Ongoing and future work
- 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
- 4. Marriage of sensornetwork and pervasive computing Sensor network Pervasive computing Internet of things Large Scale Heterogeneity
- 5. Multiple levels Internet of Things Smart Environment Transportation Domain HVAC Detecting Fire Application INRIAoffice Google Office Deployment … Health-care
- 6. Heterogeneity of thedevices • 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 developer's responsibility to handle this heterogeneity.
- 7. Large scale • Hundredsto 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 .
- 8. No separation ofconcerns Internet of Things Application Domain-specific features Middleware specific features Wide range of hardware and software entities, running on specific platforms All concerns are largely coupled into the application logic. Need of separating all these concerns to enable reusability.
- 9. Lots of gluecode • The stakeholders have to write lots of glue code apart from an application logic: – Interfacehardware 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.
- 10. Life-cycle and futurechanges – 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
- 11. 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
- 12. Outline • Characteristics ofIoT • Application development challenges • Related work • Contribution • Conclusion • Ongoing and future work
- 13.
- 14. Contributions… 1 Conceptual model Capturesconcepts and associations to represent the IoT applications Development concerns • separation of concerns, •Promotes re-usability 2 Classification of concepts A set of modeling languages are specified in •Abstracts heterogeneity, •Abstracts large scale, •Parameterized with domain 3 4 A multi-stage model-driven approach for IoT • Supports application development stages • Links IoT development concerns •Supports automations at all stages are combined in
- 15. Our IoT ConceptualModel (1/2) Software Component It encapsulates system’s functionalities, provides interface. End-user Application Storage Service Computational service Driver Extends Extends Extends Extends Sensor Driver Actuator Driver User Store Provides access to Interacts with 1 1..* 1 1 Communicates-with 1 1..* Information consumes 1 1..* generates 1 1 Extends Extends Traditional Internet concepts ``Things’’- oriented concepts
- 16. Our IoT ConceptualModel (2/2) Entity of Interest Phenomenon affects Actuator Actuator Driver actuates Command consumes Sensor Observes Sensor Driver accesses Sensor Measurement generates Consists of Resource Device Hosts User Software Component Runs-on End-user Application Storage Service Store Computational Service Driver Information
- 17. IoT applications anditsdevelopment concerns IoT Applications Domain Application Deployment* Infrastructure • Sensor, • Actuator, • Storage • Computational Service, • End-user application • Sensor Driver, • Actuator Driver, • Storage Service • Device * I am in process of identifying a suitable name. The name could be “physical”. This concern describes the concepts that are specific to the application domain (e.g., building automation, transport) This concerns describes how the software components are connected for specifying the application logic. This concerns supply information about how the devices are grouped and physically distributed. It refers to underlying platform specific-components.
- 18. Vocabulary Language (1/2) structs: 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; One resource description for many instances. As a first step of abstracting heterogeneity, sensing and actuating entities are specified in high-level manner. One resource description for many implementations.
- 19. Vocabulary Language (2/2) Floor: Integer; Room : Integer; [SINA] Srisathapornphat, C. and Jaikaeo, C. and Shen, C. , Sensor information networking architecture and applications, 2001 To address scalable operations within IoT system, hierarchical clustering should be specified [SINA]. Building:03 regions: Building : Integer; Floor: 10 Floor: 15 ... Room: 5 Room: 6 Use of region construct: • Enables system partition at logical level • Defines scope from which software components will produce/consume data
- 20. Architecture Language RoomAvgTemp consume tempMeasurementfrom hops : 0: Room ; generate avgTemp : TempStruct ; in-region : Room ; Temperature Sensor Scope of consuming data. Scope of deployment Enables Hierarchical Clustering Room AvgTemp tempMeasurement avgTemp hops:0:Room In-region : room
- 21. Deployment Language Temperature-Sensing-Device : region: Building : 15 ; Floor : 11; Room : 0; abilities : TemperatureSensor; type : sunspot; Badge-Scanner : region : Building : 15 ; Floor : 11; Room : 0; abilities : BadgeReader ; type : android; Device Name Attached sensor/ actuator/storage with device
- 22. Vocabulary Specification Domain Expert Vocabulary Specification 1 Vocabulary Specificationusing Vocabulary Language • Sensor • Actuator • Storage Specify Input Refer Output
- 23. Architecture Specification Application Designer Architecture Specification He definesarchitecture of an application using Architecture Language. • Computational service • End-user application 2 Specify Input Refer Output Domain Expert Vocabulary Specification 1
- 24. Implementing Software Component System Designer Architecture Specification 2 Specify Input Refer Output Application Logic Application Developer Application Framework Framework Generator 3 4 Itallows application developers to focus on software component logic. Domain Expert Vocabulary Specification 1
- 25. Target Deployment Specification System Designer Architecture Specification 2 Specify Input Refer Output Application Logic Application Developer Application Framework 4 Network Manager Network description Hespecifies target deployment scenario using Deployment Language. •Device Domain Expert Vocabulary Specification 1 Framework Generator 3 5
- 26. Mapping Application Designer Architecture Specification 2 Specify Input Refer Output Application Logic Application Developer Framework Generator Application Framework 3 4 Network Manager 5 Network description Mapper Mapping files 6 It decides thespecific device where each software component will be running. Domain Expert Vocabulary Specification 1
- 27. Writing Device-Drivers Application Designer Architecture Specification 2 Specify Input Refer Output Application Logic Application Developer Framework Generator Application Framework 3 4 Network Manager Mapper Mapping files 6 Domain Expert Vocabulary Specification 1 Device Developer Device Drivers 7 5 He writesdevice drivers • sensor driver • networkdevice • Storage device
- 28. Linking Application Designer Architecture Specification 2 Specify Input Refer Output Application Logic Application Developer Framework Generator Application Framework 3 4 7 Device Developer Device Drivers Network Manager 5 Network description Mapper Mapping files 6 System Linker 8 Combinesthe generated code into the actual code to be deployed on the real devices. Domain Expert Vocabulary Specification 1
- 29. 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. Defining Application concern Defining Domain Concern Defining deployment concern Defining infrastructure concern Compiler Change in Any requirements?
- 30. Maintenance and evolution(2/2) 1.Change in vocabulary specification 2. Change in architecture specification 3. Change in network specification Spec. Initially generated framework Implementation (Application logic) Initially generated framework Change in Spec. Compile time errors Modified Impl. Preserves previous application logic and replaces the generated framework
- 31.
- 32. End-user interactions withdevices • 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.
- 33. Mobility of devices** Thecurrent 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.
- 34. Evaluating expressiveness ofmodeling languages It explores the subset ofIoT applications characteristics that may be suitably developed in the framework. What are the characteristics of IoT applications that can modeled by our approach ?
- 35. Evaluating development effortin 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.
- 36. Tentative time-line What willan Intern do with the help of me ? (next slide)
- 37. What will anIntern do ? 1. The intern will implements different applications using our framework. – Outcomes: • Expressiveness of our approach • Bugs identification and fix 2. 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.