Your SlideShare is downloading. ×
0
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
The Internet of things for integration people - UKCSUG - public version
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Internet of things for integration people - UKCSUG - public version

621

Published on

Version with some slides removed of the presentation in London on June 20.

Version with some slides removed of the presentation in London on June 20.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
621
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • AMQP is the most powerful of the protocols and would be my first choice if the requirements allow for it:
    most flexibility in terms of messaging patterns
    highest throughput with advanced flow control
    bi-directional socket connection makes command & control very low latency
    ability to use a single connection for telemetry and C&C
    Well-established standard etc.

    HTTP would be my second choice at this point, primarily because it’s natively supported in Service Bus.

    MQTT would require a custom protocol gateway in Reykjavik, with the associated overhead of running/maintaining the gateway VMs. As a protocol, it does also allow for bi-directional socket connections, but lacks flexibility in terms of messaging patterns and flow control.
  • AMQP is the most powerful of the protocols and would be my first choice if the requirements allow for it:
    most flexibility in terms of messaging patterns
    highest throughput with advanced flow control
    bi-directional socket connection makes command & control very low latency
    ability to use a single connection for telemetry and C&C
    Well-established standard etc.

    HTTP would be my second choice at this point, primarily because it’s natively supported in Service Bus.

    MQTT would require a custom protocol gateway in Reykjavik, with the associated overhead of running/maintaining the gateway VMs. As a protocol, it does also allow for bi-directional socket connections, but lacks flexibility in terms of messaging patterns and flow control.
  • Transcript

    • 1. Get your geek on The Internet ofThings on the Microsoft stack Some slides of this presentation have been removed, because some information could not yet be published
    • 2. Nice to meet you SamVANHOUTTE CTO 6 year - BizTalkV-TSP 1st year - Integration MVP sam.vanhoutte@codit.eu +32 474 849 993 @SamVanhoutte be.linkedin.com/in/samvanhoutte/ > 60 Active integration customers International Focus - HQ in BEFocused on integration solutions 2000 Belgium 2004 France 2013 Portugal 60 employees > 50 consultants BizTalk certifiede-news + SoMe 2012 & 2013 Partner of the Year Award Finalist Application Integration
    • 3. The Internet of Things 3 The Internet of EverythingM2M communicationSpecial purpose devicesSmart things
    • 4. Smart Products Grid Renewables Oil/Gas/Coal Recovery and Distribution Points of Sale Restaurants Hotels Fuel Stations Patients Clinics Hospitals Nursing Homes Mobile Care Safety Security Comfort Lighting Automation Manufacturing Integration and Automation Remote Servicing Predictive and Reactive Maintenance Water Waste Pollution Control Fire Emergency Public Safety Law Enforcement Letters Packages Containers Tanks Bulkware Games Events Sports Television Streaming Traffic Buses Cars Trucks Trains Vessels Aircraft Bikes Smart Energy Smart Retail Smart Mobility Smart Logistics Smart Factory Smart Cities Smart Entertain- ment Smart Health- care Smart Building Home
    • 5. 5 Smart mobility - buses
    • 6. 6 Smart & ecological travel - hotels
    • 7. 7 Solar energy & energy management
    • 8. The device side
    • 9. Connectivity Mobility Range Power usage Ethernet Attached - - WIFI Mobile 150m High LTE Mobile 30 km High Zigbee Mobile 100m Low BLE Mobile 50m Low NFC Mobile 5cm Low
    • 10. Chosing the right protocol ➔ How powerful are the devices ? (CPU / battery-power) ➔ What’s the network connectivity? ➔ Reliable / intermittent ➔ Costly or free ➔ What are the latency requirements for telemetry or command & control? ➔ What’s the data volume? ➔ How many devices are to be connected? 10
    • 11. Protocol standardization Patterns Latency Transport AMQP All Higher TCP HTTP Inquiries & telemetry Medium TCP MQTT Telemetry Low TCP CoAP Inquiry (req/reply) Low UDP XMPP Commands & Notifications Low TCP
    • 12. Protocol preference ➔ AMQP ➔ Well-established standard ➔ Most flexibility in terms of messaging patterns ➔ Highest throughput with advanced flow control ➔ Bi-directional socket connection for low latency C&C ➔ Same connection for telemetry & C&C ➔ HTTP is natively support by Service Bus ➔ MQTT ➔ requires custom protocol gateway at this point ➔ Allows for bi-directional socket connections ➔ Lacks flexibility in messaging patterns & flow control 12
    • 13. Steps to activate a device Configure time & network settings Activate device on gateway Get gateway configuration Security – key management Give feedback – Status & diagnostics
    • 14. Device prototyping & development 14 Gadgeteer GHI Netduino Arduino Raspberry PI Intel Galileo .NET Micro Framework Open source hardware Open source software .NET Micro Framework C on Arduino Duino shield Linux (Raspbian) Full featured Powerful Supports Windows
    • 15. Demo – Raspberry PI Telemetry 15
    • 16. What’s in it for us, integration guru’s
    • 17. IoT Patterns Telemetry Information flowing from a device to other systems for conveying status of device and environment Inquiries Requests from devices looking to gather required information or asking to initiate activities Commands Commands from other systems to a device or a group of devices to perform specific activities Notifications Information flowing from other systems to a device (-group) for conveying status changes in the rest of the world
    • 18. Integration scenarios Command API Telemetry event integration Telemetry big data analysis Complex event processing Event filtering and anomaly processing
    • 19. Service Assisted Communication
    • 20. Service-Assisted Communications Connections are device-initiated and outbound NAT/Firewall Device (Router) IP NAT Cloud Gateway Command Source Port mapping is automatic, outbound Device does not listen for unsolicited traffic No inbound ports open, attack surface is minimized Access-controlled command API Secure, managed hosting platform DNS myapp.cloudapp.net
    • 21. How it Works ➔ Devices connect via open standard protocols ➔ AMQP 1.0 and HTTP supported natively by the Service Bus ➔ MQTT, CoAP and others can be implemented via custom gateway/adapter model ➔ Sockets secured viaTLS (or a lightweight variant) ➔ Each device has a dedicated Inbox/Outbox on the Gateway ➔ Device sends telemetry/alerts and routes service invocations via its Outbox ➔ Device receives commands and queries from its Inbox ➔ Correlated request/reply patterns can be implemented on top of these two messaging channels ➔ The device knows, and has access to, only its own specific inbox/outbox endpoints (URI’s) Backend Components Cloud Gateway Inbox Outbox CommandAPI ProtocolHead
    • 22. Telemetry Routing with the Azure Service Bus     Topic SubsFilters Service Bus Device 2 Receiver 2b Device 1 Device 3 Receiver 2a Alerts Data Receiver 1 Alert Processor Storage Pre-processor
    • 23. Routing Commands with the Azure Service Bus TopicSubs Filters Service Bus Device 2 Device 1 Device 3 Sender 2 Model A Device 3 Sender 1 Model T Model T Model A    
    • 24. Session A Request-reply over service bus 24 API Device DeviceSubscriptionCommandTopic ResponseQueue ReplyToSessionId=A SessionId=A
    • 25. Request – Reply pattern Demo 25
    • 26. Project “Reykjavik”
    • 27. Slides removed for publication
    • 28. Demo – Solar Panel Telemetry & commands “Reykjavik” 28 Gateway Partition IN OUT Command API Azure API Management Service Bus
    • 29. Intelligent Systems Services
    • 30. Slides removed for publication
    • 31. Microsoft & IoT
    • 32. IoT initiatives Project “Reykjavik” Intelligent Systems Service (ISS) WindowsOnDevices.com Big Data (HDinsight) Machine learning & Project “Orleans”
    • 33. 33 THANKYOU AND NOW, QUESTIONS? OR DRINKS?

    ×