Scenario Library et REX Discover industry- and role- based scenarios
From the Internet of Things to Intelligent Systems: A Developer's Primer
1. From the Internet of Things to
Intelligent Systems:
A Developer's Primer
Rick G. Garibay
Distinguished Engineer, Neudesic
MVP, Microsoft Azure
@rickggaribay
Level: Intermediate
2. About Me
• Distinguished Engineer, Neudesic working on IoT,
Intelligent Transportation and Hospitality & Gaming
• Microsoft MVP, Microsoft Azure
• Co-Author, “Windows Server AppFabric Cookbook”
by Packt Pub.
• Chairman, Co-Founder Phoenix Connected
Systems User Group (PCSUG.org)
• twitter: @rickggaribay
• blog: http://rickgaribay.net
• email: rick.garibay@neudesic.com | b-rigari@microsoft.com
5. This change is happening
more rapidly than anyone
imagined.
6. This change could bring
tremendous opportunity to your
business, industry and you as
a technologist.
7. The Internet of Things is the
network of physical objects that
contain embedded technology to
communicate and interact with
their internal states or the external
environment.
10. OEM Revenue Opportunity |
Market Forecast CY17
Auto & Trans Retail Manufacturing Healthcare Energy Computing Telecom Consumer
$7 B $16 B $197 B $3 B $27 B $908 B $179 B $356 B System Revenue
Intelligent
Systems
1.7T$
12. IoT Device Taxonomy
Large
Mobile
Micro
Small
POS terminal, ATM, MRI
x86, PC-like, apps
Industry handheld, POS tablet
ARM and x86, shell experience, apps
Gateways, wearables, panels, cars
ARM and x86, diverse hardware, no shell
Controllers, fixed-use, sensors, actuators
ARM, constrained hardware, headless
22. Data-Driven Insight
• Data –> Information –> Insight ($+)
–Make more efficient use of resources
(reduce cost, environmental impact)
Example: Power management in buildings and data centers
–Provide more targeted products and
services (increase revenue, social
impact)
Example: Preventive maintenance, optimal usage analytics for
expensive machines
• “Things” = a rapidly expanding source
of raw material for the Insight pipeline
23. Action at a Distance
• Data isn’t the only raw material being unlocked by the IoT
– The ability to act remotely – automatically and intelligently
– Remote control is a source of efficiency
– Enables new forms of customer interaction and engagement
• IoT extends customer engagement opportunities to physical
products
• Taking engagement with customers beyond the point of sale
– Preventive maintenance
– Best practices guidance
– Proactive sales
– Remote servicing
• From CRM to PRM – “Product Relationship Management”
24. From IoT to Intelligent Systems
Large
Mobile
Micro
Small
M2M/
Device to
Cloud
27. MQ Telemetry Tranport (MQTT)
• Born out of IBM MQ Series messaging middleware product
• Compact binary protocol – min. 7 byte overhead per message
sent
• No structured message – message bodies are byte arrays
• Simple topic name based pub/sub messaging model
– Send to topic name, e.g., “/a/b/c/d” or “/a/b/e/f”
– Subscribe to topic name, e.g., “/a/b/c/d” or use wildcard, e.g., “/a/b/#”
• Reliable – fire-and-forget to reliable, exactly-once delivery
• Two innovative, device-oriented features:
– Retain – mark a message to be delivered to new subscribers on
connection
– Last will and testament – register message to be sent on abrupt
disconnect
• Not general purpose – lacking key features, e.g., flow control
• Standardization in progress through OASIS
28. Constrained Application Protocol
(CoAp)
• Embedded web transfer protocol (coap://)
• Asynchronous transaction model
• UDP binding with reliability and multicast support
• GET, POST, PUT, DELETE methods
• URI support
• Small, simple 4 byte header
• DTLS based PSK, RPK and Certificate security
• Subset of MIME types and HTTP response codes
• Built-in discovery
• Optional observation and block transfer
29. Advanced Message Queuing
Protocol 1.0 (AMQP)
• Efficient – binary connection-oriented protocol
• Reliable – fire-and-forget to reliable, exactly-once delivery
• Portable data representation and structured message
definition
• Flexible – peer-peer, client-broker, and broker-broker
topologies
• Broker-model independent – no requirements on broker
internals
• Rich flow control – multiplex multiple data streams over a
connection
• OASIS Standard (Oct 2012); International Standardization in
progress
– Somewhat controversial…
30. Message Types
Voluntary
information flow
from device to
another system.
Requests for
information from
device to other
systems.
Instructions
from other
systems to a
device.
Information flow
from other
systems to the
device.
Telemetry Inquires Commands Notifications
31. Default Connectivity Model
• Connectivity (IPv6 + VPN)
– Give every device a routable IP address
– Devices expose services for control/query
operations
– Command Source is either on premise or remote,
enabled by a bridge of some sort.
– Remote access is enabled within the VPN’s routing
domain
32. Default Connectivity Model
Connections are
command source
initiated.
Connections are
command source
initiated.
Device exposes a
service/API
Device exposes a
service/API
Command
Source
Command
Source
34. Default Connectivity Model
Challenges
• Addressability
– Requires network-layer intervention
– Doesn’t work for devices that are loosely connected (roaming,
frequently offline)
• Security
– By default, every protocol that can be routed over Ethernet can flow –
and between any two nodes
– SSL/TLS is not an option on many small devices.
– VPN controls access to IP addresses and ports, not application
endpoints (lack of granular authorization)
– Many devices are not VPN-capable due to resource/bandwidth
constraints
• Efficient scale
– VPN infrastructure is expensive and costly to maintain
– Does not address device management.
Think 1K, 10K, 100K+ devices
35. On-Premise Brokered Device
Communications
• Connectivity (IPv6 + VPN)
– Give every device a routable IP address.
– Devices participate in pub-sub messaging on-prem or
via VPN using industry standard protocol like MQTT.
– Command Source is either on premise or remote,
enabled by a bridge of some sort.
– Remote access is enabled within the VPN’s routing
domain.
36. On-Premise Brokered Device
Communications
Device subscribes to
broker via TCP, etc.
Device subscribes to
broker via TCP, etc.
Device BrokerDevice Broker
Typically a socket
connection.
Typically a socket
connection.
Messaging happens
on premise, attack
surface minimized.
Messaging happens
on premise, attack
surface minimized.
MQTT, etc.
Command
Source
Command
Source
Must be on premise
or somehow bridged.
Must be on premise
or somehow bridged.
38. On-Premise Brokered Device
Communications Challenges
• Addressability
– Device and broker are intimately connected.
– Doesn’t work for devices that are loosely connected (roaming,
frequently offline).
• Security
– SSL/TLS is not an option on many small devices.
– Many devices are not VPN-capable due to resource/bandwidth
constraints.
• Efficient scale
– VPN infrastructure is expensive and costly to maintain.
– External commands require some kind of a gateway service.
– Does not address device management.
Think 1K, 10K, 100K+ devices
39. Service Assisted Communications
• 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 via TLS (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
Backend
Components
Cloud GatewayCloud Gateway
InboxInbox
OutboxOutbox
CommandAPICommandAPI
ProtocolHeadProtocolHead
40. Service-Assisted Communications
Connections are
device-initiated and
outbound
Connections are
device-initiated and
outbound
NAT/Firewall
Device (Router)
NAT/Firewall
Device (Router)
IP NAT
Cloud
Gateway
Cloud
Gateway
Command
Source
Command
Source
Port mapping is
automatic, outbound
Port mapping is
automatic, outbound
Device does not
listen for unsolicited
traffic
Device does not
listen for unsolicited
traffic
No inbound ports
open, attack surface
is minimized
No inbound ports
open, attack surface
is minimized
Access-controlled
command API
Secure, managed
hosting platform
Access-controlled
command API
Secure, managed
hosting platform
DNS
myapp.cloudapp.net
41. IoT Cloud Platform “Stack” –
Abstract Model
Non-IP
Capable
Devices
IP
Capable
Devices
CloudGateway
Custom
Code
CloudPlatform
Services
Enterprise
Systems
Third-Party Data
and Services
A B C D E F
Field
Gateway
44. Azure – IoT Cloud Gateway
Non-IP
Capable
Devices
IP
Capable
Devices
CloudGateway
Custom
Code
CloudPlatform
Services
Enterprise
Systems
Third-Party Data
and Services
Field
Gateway
A B C D E F
ServiceBus
A/B
ServiceBus
A/B
Custom
GWRole
Pattern 1: Device Direct Pattern 2: Custom Gateway
45. Telemetry Routing with the Azure
Service Bus
Split the stream
Enable parallel processing
Implement different Q QoS levels
Level and balance the load
Topic SubsFilters
Service Bus
Device 2
Receiver 2b
Device 1
Device 3
Receiver 2a
Alerts
Data
Receiver 1
Alert
Processor
Storage
Pre-processor
46. 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
Target individuals or groups
Set delivery timeouts (TTL)
Deal with spotty connectivity
Traverse NATs/firewalls
securely
50. Service Bus MessagingService Bus Messaging
Device Gateway Accelerator –
Reference Architecture
(Reykjavík)
1. Custom Protocol
Gateway
2. Telemetry Pump and
Adapters
3. Command Gateway
4. Provisioning Service
and Metadata Store
Custom Protocol Gateway HostCustom Protocol Gateway Host
MQTTMQTT CoAPCoAP ……
Telemetry/Request
Router
Telemetry/Request
Router
Notification/Command
Router
Notification/Command
Router
AdaptersAdapters Command API HostCommand API Host
Provisioning
Service
Device
Metadata
and Key
Store HDInsightHDInsight
BizTalkBizTalk
OrleansOrleans
AzureStorageAzureStorage
AzureDbsAzureDbs
ServiceBusServiceBus
HTTP
HTTP
DevicesDevices
AMQP
11
22 33
44
ConfigurationConfiguration
HTTP
YourProcessYourProcess
51. Device Gateway – Partition
Topology
• The “Partition” is a set of resources dedicated to a specific
device population (or subset thereof).
• The “Master” role manages partition deployment and device
provisioning into the partitions.
PartitionMaster
Partition
Repo
Partition
Repo
Command TopicsCommand Topics
Service Bus Standard ProtocolService Bus Standard Protocol Custom ProtocolCustom Protocol
Device RepoDevice Repo
in0000in0000 inFFFFinFFFF…in0001in0001 in0002in0002
AMQPAMQP HTTPHTTP MQTTMQTT Custom Protocol HostCustom Protocol Host
Protocol AdaptersProtocol Adapters
diagdiagallall diagdiagallall diagdiagallall diagdiagallall
Telemetry Pump/RouterTelemetry Pump/Router
N Instances
Telemetry
Adapter
Telemetry
Adapter
Telemetry
Adapter
Telemetry
Adapter
Telemetry
Adapter
Telemetry
Adapter
Deployment
Runtime
Deployment
Runtime
out0000out0000 outFFFFoutFFFF…out0001out0001 out0002out0002
s0001s0001
s0002s0002
s03E7s03E7
s0001s0001
s0002s0002
s03E7s03E7
s0001s0001
s0002s0002
s03E7s03E7
s0001s0001
s0002s0002
s03E7s03E7
g0000/
rte0000
g0000/
rte0000
g0000/
rte0001
g0000/
rte0001
out0out0
out1out1
out2out2
n Groups of m Routers
out0out0
out1out1
out2out2
g0001/
rte0000
g0001/
rte0000
g0001/
rte0001
g0001/
rte0001
out0out0
out1out1
out2out2
out0out0
out1out1
out2out2
Provisioning
Runtime
Provisioning
Runtime
Ingestion Topics (Telemetry)Ingestion Topics (Telemetry)
Command
API Host
Command
API Host
52. Device Gateway – Customer
Topology
• Global coverage achieved by spreading partitions across multiple Azure
regions
• Reference architecture supports up to 1000 distinct partitions
• Number and distribution of partitions driven by data volumes, business
continuity, legal and proximity considerations
55. Device
(Non-ISS)
Device
(Non-ISS)
Event
Hub
Azure
Storage
Rich Device Registry & Object Model of “Things”Rich Device Registry & Object Model of “Things”
Azure
ISS
Customer Apps
HDInsights
BI Systems
3rd Party Solutions
Data Flow
ISS Solution built on Azure
SQL
Azure
Event
Hub
Basic
Device
Registry
ISSSecurity,
Privacy&
SharingControls
IoT Rule
Templates
IoT Rule
Templates
Natural Language
Query
Natural Language
Query
ISS
Agents
ISS
Agents
ISS
Agents
ISS Solution
SingleAccount,PerdeviceBilling,
etc.
SingleAccount,PerdeviceBilling,
etc.
Command & Control
Azure
Event
Processing
ISS
Portal
ISS
Portal
56. More on ISS
• //build 2014: Windows and the Internet of Things:
http://bit.ly/1ijTeyW
• Internetofyourthings.com
57. More on Reykjavik/Device
Gateway
• //build 2014: Internet of Things with Azure Service Bus:
http://bit.ly/1m4MMME
• Neudesic is currently offering industry-specific
briefings on IoT.
• The Azure M2M team is very interested in working with
early adopters.
• If you or your organization think you’re a candidate for
Device Gateway and are interested in learning more
connect with us:
http://neudesic.com/iot
Invitation code: VSLChicago
58. References
• Internet of Things with Azure Service Bus:
http://bit.ly/1m4MMME
• Windows and the Internet of Things:
http://bit.ly/1ijTeyW
• Subscribe!: http://channel9.msdn.com/Blogs/Subscribe
• Service Assisted Communications:
http://vasters.com/clemensv/CategoryView,category,Ar
chitecture.aspx
• Internet of Things & Azure Service Bus:
http://bit.ly/1jFf5k5 and http://bit.ly/1jFf5k5
• M2MQTT Library for .NET MF:
http://m2mqtt.codeplex.com/
• Special thanks to Clemens Vaster, Markus Horseman
and Todd Holmquist-Sutherland on the Microsoft Azure
M2M team.
59. About Me
• Distinguished Engineer, Neudesic working on IoT,
Intelligent Transportation and Hospitality & Gaming
• Microsoft MVP, Microsoft Azure
• Co-Author, “Windows Server AppFabric Cookbook”
by Packt Pub.
• Chairman, Co-Founder Phoenix Connected
Systems User Group (PCSUG.org)
• twitter: @rickggaribay
• blog: http://rickgaribay.net
• email: rick.garibay@neudesic.com | b-rigari@microsoft.com