9. Mais sérieusement qu’est ce que c’est ?
■Définition de l’union internationale des télécommunications :
infrastructure mondiale pour la société de l'information, qui permet de
disposer de services évolués en interconnectant des objets (physiques
ou virtuels) grâce aux technologies de l'information et de la
communication interopérables existantes ou en évolution.
Source Wikipedia : http://fr.wikipedia.org/wiki/Internet_des_objets
10. • Collecter des données des objets
de la vie courante
• Stocker et analyser les données
pour lancer des actions ou pour
aider à la prise de décisions.
• Fusionner le monde réel et virtuel
A quoi ça sert
11.
12.
13. Choices – What powers the device?
Option Upside Downside Common examples
Battery (primary) Device can operate in a mobile
environment for extended
periods of time.
Device now has a current / wattage
budget (CPU cycles are not free).
Efficient and safe battery charging
requires sophisticated circuitry (you
won’t do it in firmware).
Mobile brains phones
Battery (secondary) Device can sustain function
through transient power
interrupts
Efficient and safe battery charging
requires sophisticated circuitry (you
won’t do it in firmware).
May have to add additional circuitry
to run while charging
Laptops
Main power (primary) Device can leverage all available
computing power (barring
thermal constraints)
Device functionality susceptible to
interruption during power supply
events
3D printer
Main power + backup Device can leverage all available
computing power (barring
thermal constraints), and operate
at reduced capacity during power
events.
Additional power management
circuitry. Need to reduce current
load during loss of main power.
NEST thermostat
14. Choices – What connects the device to cloud services?
Option Upside Downside Common examples
Ethernet Cheap, easy to install. No hard
bandwidth or framing limitations.
Requires hard wired connection
provided by end-user. May require
additional configuration or security
enhancements to route through
firewalls, etc.
Industrial PLC (programmable logic
controllers)
WiFi Readily available on more
sophisticated microcontrollers
and embedded devices.
Requires ambient WiFi network, and
method of managing security keys
and access (including rotation).
May require additional configuration
or security enhancements to route
through firewalls (commercial).
NEST thermostat.
Cellular Self-contained; plug and go. Communication heavily metered –
cost of operations (CoGS) borne by
service operator.
3rd party car data logger
Local (Bluetooth,
Zigbee, etc)
Minimal cost and power
requirements.
Short ranged, require field gateway
or other “smart” edge device to
proxy connections.
iBeacon
15. With the ubiquity of firewalls and NAT (network address translators),
cloud services connecting inbound to devices is typically impractical.
If two local devices want to talk to each other, two options:
Device A connects directly to device B, or vice-versa
The devices communicate through a secured cloud endpoint
(service assisted communication)
Whom connects to whom?
17. ■ LiFX lightbulbs create a mesh network between each other
■ One lightbulb elects as master, and proxies to WiFi router
■ Devices shipped from factory with a single GLOBAL PRE-SHARED KEY.
■ Break one device – break them all.
■ Remediation Options:
■ Global firmware update. How do the devices “call home” to get firmware
updates? At scale there will always be devices behind the update curve.
■ Don’t make any mistakes in the bootloader for in-field firmware updates. A
single RMA (return material authorization) can wipe out the profit from
dozens of devices.
■ Move to provisioned key-per-device. Need to build and manage key
infrastructure. Also need to incorporate key rotation (don’t make a mistake
here of the device will “bricked”).
■ Is there an out-of-band update mechanism (USB?). Is the end-user
community amenable to handling firmware updates (industrial, technical vs.
mass consumer)
Peer to peer sounds cool!
http://contextis.com/resources/blog/hacking-internet-connected-light-bulbs/
18. Choices – Let’s connect!
Option Upside Downside
UDP • Simple; datagrams require no framing.
• Efficient on bandwidth metered links.
• Impractical to secure channel.
• Need faith or out of band acknowledgement mechanism for
reliable transfer.
• Cannot reliably support ordered data streams.
• Challenging to implement return-channel (cloud to device)
for commands
TCP/IP • Simple; minimal code footprint for RTOS class
devices.
• Can use TLS to secure channel
• Bi-directional channel for notifications and
commands
• Need to handle framing on both sides of connection (or hard
code avoidance of MTU limits from end to end)
• Firewall traversal is challenging
HTTP/S • Straightforward firewall traversal, use of SSL
for channel encryption and signing
• Built in framing, can leverage semantic
conventions (REST) to publish data
• Inefficient for Signal-to-Noise ratio of bytes on wire
• Heavy device stack footprint to implement general purpose
HTTP client stack
AMQP, MQTT • Bi-directional channel for notifications and
commands
• Efficient use of bandwidth (batching, efficient
framing, etc)
• Firewall traversal is challenging
• Client stack may not fit on smaller devices
• Evolving standards and implementation levels
19. Choices – Let’s encode!
Option Upside Downside
XML • You have more money than you know what to
do with. Enjoy another mojito on your yacht.
• Extremely inefficient for both serialization/deserialization
time and wire encoding.
JSON • Self-describing (“tagged”) format requiring no
type identifiers. Readable by convention.
• Need to handle framing on both sides of connection (or hard
code avoidance of MTU limits from end to end)
• Firewall traversal is challenging
Tagged / Untagged
“standard” Binary
(Protobuf, Thrift,
etc)
• Highly efficient wire protocol with broad range
of encoder bindings for various languages
• Can use common IDL (definition) to generate
device and cloud code
• Built in support for protocol versioning
• Implementation may not be compatible with RTOS class
device BSP (board support packages)
• Until you’ve lived through the mistake, you probably won’t
use the versioning features.
Custom Binary (roll
your own)
• You can put “wrote yet another custom
protocol” on your resume
• High degree of control over bit packing,
ordering, etc.
• Can support any device.. Since you wrote it for
that device
• Very few implementations use code generation from a
common definition (result -> divergent implementations with
subtle differences)
• Rarely incorporate version management, self-describing type
and version fields, rich variable support (arrays, maps, etc)
• Take on a life of their own, generating support burdens with
inertia
20.
21. ■Cout d’un oubli ou d’un bug coté cloud :
corriger le bug , commit, push, build, deploy ( cout : 3 clics et un café)
■Cout d’un oubli ou d’un bug coté device :
Hardware : refaire tous les devices
Software : Mise à jour de firmware (est ce que c’est prévu)
Dans les 2 cas trés cher $$$
La nécessité de prototyper