Conférences « objets connectés » (IOT)
Open Wide Ingénierie Paris, 9 octobre 2014
Programme de la conférence
● Introduction à l'IOT (P Ficheux)
● Technologies utilisées (N Aguirre)
● Systèmes d'exploitation pour l'IOT (P Ficheux / JJ Pitrolle)
● Plate-formes matérielles (P Ficheux)
● Consommation (JJ Pitrolle)
● Neopixl (F Dewasmes)
● National Instruments (A Goude)
● Nodesign.net (U Petrevski)
● Hitronetic (H Gory)
Internet des objets (IOT), introduction
Pierre Ficheux ([email protected]) Octobre 2014
15 milliards d'objets connectés, et moi, émoi...
(Libération 2013)
Une définition de l'IOT
● Internet ne se prolonge habituellement pas au-delà du monde virtuel
● Internet fonctionne dans un mode actif « je me connecte à Internet » → je change de monde
● IOT (Internet Of Things)
– Extension d'Internet à des objets et à des lieux du monde physique → web 3.0
– Échanges d'informations et de données provenant de dispositifs présents dans le monde réel vers/depuis le réseau Internet
« Cyber-physical systems (CPS) enable the physical world to merge with the virtual leading to an Internet of things,
Topologie IOT (FreeRTOS)
● Un système embarqué intégré à un système d'information étendu
● Convergence « little data » / « big data »
Embedded system :-)
Nouveau concept ?
● IOT n'est pas un nouveau concept au sens
technologique du terme mais n'est pas uniquement un
« buzz » marketing
● Utilise des technologies éprouvées (IP, RTOS, …) mais adaptées aux objets matériels connectés (taille,
consommation, …)
● Conséquence de la généralisation des systèmes
embarqués + l'omniprésence de la technologie et de la communication auprès du grand public
● Utilise/nécessite les technologies d'intégration actuelle des réseaux (IPv6, « cloud », ...)
● Au niveau industriel, évolution du M2M (machine to machine) vers des protocoles standards → unification
Classification des objets
● Automobile
● Électroménager
● Appareils de mesure (santé, environnement, ...)
● Composants élémentaires (ampoule)
● Montre, lunettes, vêtement
● Industrie (automates PLC)
● Certains sont connectés depuis longtemps, la nouveauté est l'autonomie et l'intégration
● La santé est le 1er véritable marché « grand public »
– Économies
– Disponibilité du personnel
Déjà en 1995
● En 1995, le chercheur français Christian HUITEMA (à l'origine d'IPv6) évoque l'évolution vers l'IOT
« Il y a déjà des microprocesseurs, en fait de tout petits ordinateurs dans bien d’autres endroits [...]. D’ici quelques
années, le développement et les progrès de l’électronique aidant, ces microprocesseurs deviendront sans doute de vrais
ordinateurs élaborés et il sera tout à fait raisonnable de les connecter à Internet. »
Évolution de l'accès actif → auto
● Actif → l'utilisateur client connecte sa machine au réseau Internet et accède à un serveur
– PPP (modem), TELNET (telnet), FTP (ftp) → 70's 80's
– HTTP (Lynx, Mosaic) → 90's
● Semi auto → smartphone (utilisateur moins averti)
– Intègre et « simplifie » les protocoles précédents + DHCP, Wi-Fi, ...
– Publie des informations automatiquement (position) → IOT
● Auto → IOT
– Autonomie de l'objet, fonction(s) dédiée(s)
– « zeroconf »
– L'intelligence du réseau compense la moindre
Problèmes et verrous
● De nombreux produits concernent uniquement des
« geeks » → pas d'effet de masse, pas de marché
● On reste dans le « gadget » → Nabaztag (2005)
● Spectre de la « domotique » → nouvelle chance ?
● Contexte économique difficile pour le grand public →
$1500 pour les premières Google glass
● Sur les objets portés, problème de l'uniformité et du design → alliance Google / Ray-Ban
● Problème légal et sécurité des données
L’article 34 de la loi informatique et libertés oblige l’organisme responsable du traitement des données à en préserver la
sécurité. «L’utilisateur doit pouvoir contrôler si les puces communiquent ou pas, et avec qui»
Projection économique
● Entre 2010 et 2012, les objets connectés sont passés de 4 milliards à 15 milliards selon Idate → 2 fois plus que la population mondiale !
● En 2020, ces objets électroniques seront :
– 30 milliards selon Gartner
– 80 milliards d’après Idate
● L' Europe à la recherche de nouveaux marchés !
● L' Europe a « peu » profité du marché de
l'Internet/Telecom malgré les innovations techniques
● Soutien de l'état → plan « objets connectés »
« On a raté les smartphones, on a raté les tablettes, j’espère qu’on ne ratera pas l’Internet des objets » (Anne Lauvergeon)
● Il reste à trouver un modèle économique...ou se faire
Moteur de recherche dédié
● SHODAN indexe les objets exposés sur le réseau (routeur, caméra, ...)
Quelques exemples
● TBD, pèle mêle d'objets
Démonstration
● Exemple de FlashAir, carte SD « connectée »
Bibliographie
● http://www.internet-of-things-research.eu/about_iot.htm
● http://www.entreprises.gouv.fr/politique-et-enjeux/nouvelle-france-industrielle/objets-connectes
● http://www.liberation.fr/economie/2013/11/03/15-milliards-d-objets-connectes-et-moi-emoi_944254
● http://www.shodanhq.com
● http://www.idate.org
● http://www.frandroid.com/actualites-generales/209531_5-choses-devez-savoir-les-google-glass
● http://www.stuffi.fr/categorie/domotique
● http://www.edevice.com/products/healthgo-plus
● http://www.huffingtonpost.fr/2014/03/25/google-glass-ray-ban-lunettes-connectees_n_5025752.html
● http://www.shodanhq.com
● https://github.com/OWF/Slides-2013/tree/master/CODE/internet-of-things
● https://sen.se/store/mother
● http://article.wn.com/view/2014/01/30/Techtopia_Mother_20_Here_Comes_the_Internet_of_Things/
● http://www.toshiba-components.com/FlashAir
● « Et Dieu créa l'Internet » par Christian HUITEMA (Eyrolles, 1995)
Protocoles de communication pour l'IOT
Nicolas Aguirre ([email protected]) Octobre 2014
Modéle OSI
Le modèle OSI …
Application Presentation
Session Transport
Network Data Link
Physical
Ethernet 802.3
Wifi 802.11
UDP TCP
IP IPv4 IPv6 HTTP FTP ...
Les technologies pour l'IoT
Classiques :
Ethernet Wifi
Bluetooth
Spécifiques :
Zwave EnOcean 802.15.4 Zigbee 6LowPan Thread NFC
Bluetooth
● Bluetooth 4 Low Energy ou BT Smart
Idem que BT mais consomme moins d'énergie Même portée, même débit
Support de profils très spécifiques
● HTP — medical temperature measurement devices.
● GLP — blood glucose monitors.
● BLP — blood pressure measurement.
● HRP — for devices which measure heart rate.
● CSCP — for sensors attached to a bicycle or exercise bike to measure cadence and wheel speed.
● RSCP — running speed and cadence profile.
● CPP — cycling power profile.
● LNP — location and navigation profile.
Supporté dans Linux via Bluez5 (kernel + userspace)
ZWave
Entiérement propriétaire Appartient à Sigma Designs
Beaucoup d'équipements compatibles
grand public
Principalement utilisé pour la domotique Bande des 900Mhz
Faible consommation
Mesure et contrôle à distance Support du Mesh
Projet open source : OpenZwave Supporté par les box domotique
Zigbee
Propriétaire : Zigbee Alliance Basé sur couche 802.15.4
Support dans le noyau linux ?
NON bien que linux-zigbee existe Linux supporte les couches 802.15.4
Beaucoup de chips compatibles
Chip radio seuls
Microcontrolleur + Radio
Cout de la licence dans les chips
Basse consommation Bande des 2,4GHz
Zigbee
Application Presentation
Session Transport
Network Data Link
Physical
Ethernet 802.3
Wifi 802.11
UDP TCP
IP IPv4 IPv6 HTTP FTP ...
802.15.4
ZIGBEE
6LowPan
Normet IETF (RFC4944) Basé sur le 802.15.4
Ipv6 pour les objets connectés Compression des entêtes ipv6 Routage mesh
Trames courtes (128 octets)
Supporté par Linux, Contiki, RIOT, FreeRTOS Une Adresse IPV6 pour chaque nœud
Routage de type Mesh possible
RPL : Routing Protocol for Low power and Lossy Networks : IETF/RFC
6LowPan
Application Presentation
Session Transport
Network Data Link
Physical
Ethernet 802.3
Wifi 802.11
UDP TCP
IP IPv4 IPv6
6LowPan HTTP FTP ...
802.15.4
6LowPan Linux Kernel
Originellement linux-zigbee :)
Support de différents chips radio comme le MRF24j40 Support en Upstream et via backports (compat-
wireless/compat-drivers)
Support des couches 802.15.4 Support du 6LowPan
Implémentation RPL en userspace
Amélioration du support depuis le noyau 3.6
Thread
Samsung, Arm et Nest (Google), le prochain standard ?
Protocoles Applicatifs
CoAP
(Co)nstrained (A)pplication (P)rotocol HTTP sur UDP
Compression de http pour les protocoles contraints Idéal pour consulter des ressources
L'object est serveur
Le client consulte les informations
Implémentation opensource : libcoap (c) Californium (cf fondation eclipse => java)
MQTT
(M)essage (Q)ueue (T)elemetry (T)ransport 1ére version par IBM en 1999
Architecture Publish/Subscribe Broker au milieu
MQTT-SN : version MQTT over UDP Piloté par la fondation Eclipse
Implémentation opensource : Mosquitto
Architecture Démo
Démo
Contiki sur Capteur de témpérature Contiki en tant que Border Router
Communication sans fil 802.15.4/6LowPan Linux en tant que passerelle
Broker Mqtt sur linux Emoncms sur un server
Push et log des données sur le serveur distant
Affichage des courbes et des données sur une application HTML5
http://sourceforge.net/projects/libcoap/
http://sourceforge.net/projects/linux-zigbee/
https://backports.wiki.kernel.org/index.php/Main_Page http://www.z-wave.com/
http://www.zigbee.org/
https://datatracker.ietf.org/wg/6lowpan/documents/
http://mqtt.org/
http://mosquitto.org/
http://www.eclipse.org/paho/
http://www.threadgroup.org
Systèmes d'exploitation pour l'IOT
Pierre Ficheux ([email protected]) Octobre 2014
L'IOT, un réseau d'OS
● L'IOT associe « little data » et « big data »
● Les OS interviennent à plusieurs niveaux
– Serveurs → UNIX/Linux, Windows ?
– Terminaux (IHM déportée) → Android, iOS, Linux, Windows
– Objets connectés (?)
● La nécessité de l'OS dépend de la complexité de l'objet
● La fonction de communication (réseau) nécessite le plus souvent un OS
● Le lien entre les OS est la standardisation des protocoles et des formats de données
Contraintes des OS pour « objets »
● Principaux critères
– Empreinte mémoire
– Consommation
– Stabilité
– Prise en compte du temps réel
– Coût ! (des milliards d'objets...)
● Mais également
– Évolutivité
– Portabilité
– API standards (POSIX, Web) → maintenabilité, personnel
● Ces critères correspondent à des « RTOS open
Typologie des OS (rappel)
● GPOS (General Purpose OS)
– Multi processus / multi thread
– Multi utilisateur
– Forte empreinte mémoire
– En général pas TR
– Bonnes capacités réseau
→ UNIX, Linux, Windows, …
● RTOS (Real Time OS)
– Faible empreinte mémoire
– Mono processus / Multi thread
– Exécutif ou véritable OS ?
Cas de l'IOT
● Un RTOS adapté respecte les critères
● Contrainte → ajouter les protocoles dédiés à l'IOT (6LoWPAN)
● Le choix du logiciel libre favorise l'adoption d'OS
comme « service » → focalisation sur la valeur ajoutée de l'objet
● Le logiciel libre évite le coût récurrent de la licence (15 milliards d'€...)
● Développement d'OS dédiés mais ils sont proches des RTOS → exécutif temps réel = 1 noyau + 1 application multi thread
● Certains objets complexes (avec IHM) peuvent utiliser des GPOS comme Android (wear ?) ou Linux / µCLinux
Quelques OS libres pour l'IOT
● RTOS adaptés
– FreeRTOS
– Lepton
– RTEMS
● OS dédiés
– TinyOS
– Contiki
– RIOT
→ souvent assez éloignés des standards (C/POSIX)
● GPOS (adaptés)
GNU/Linux
Contiki
● Système d'exploitation développé par le Swedish Institute of Computer Science (SICS, 2002)
– Open source, licence BSD
– Ultra léger
– Flexible
– Plate-forme d'émulation et de simulation → Cooja
● Couche réseau uIP et uIPv6
● Optimisé pour la consommation
● Chargement dynamique de modules
● Bien adapté aux capteurs (quelque dizaines de Ko) → à partir des 8 bits (démo sur 8051, datant de 1980)
● Bonne documentation et nombreux exemples
● API de programmation « spécifique » (et quelques mots
RIOT
● Démarré en 2008 et maintenu par l'INRIA
● Licence GNU LGPL (et non GPL)
● Peut fonctionner avec 1,5 Ko de RAM !
● Temps réel
● Multi-threading complet
● Support C/C++ « standard » très proche de la
programmation classique → réponse aux limitations de Contiki
● Réseau 6LoWPAN
● CPU 16 et 32 bits
● Présenté par ses concepteurs comme le « Linux de
RTEMS
● Real Time Executive for Missile/Military/Multiprocessor Systems
● Exécutif TR avec API dédiée ou POSIX
● Utilisé dans le militaire puis le spatial (ESA, NASA, EADS Astrium, ...)
● Communauté réduite mais active
● GPL modifiée assez contraignante
● Non prévu au départ pour le réseau → portage couche réseau BSD
● Approche minimaliste pour des environnement contraints
● Maintenu par la société OAR Corp. (USA)
Lepton
● « Système d'exploitation » temps-réel pour des cibles embarquées aux ressources et puissances limitées
● Ajout d'un couche POSIX à un noyau temps réel libre ou propriétaire → portabilité, code standard !
● Licence MPL (entre BSD et GPL...)
● Cibles visées 16 ou 32 bits→ Micro-contrôleurs Cortex M4/M3/M0/M0+, ARM9, MIPS…
● 3 axes de développements:
– Ressources matérielles limitées/basse, consommation
– Réutilisation
– Environnement de développement / mise au point
● Disponible sur eCos, Segger embOS, FreeRTOS
GNU/Linux
● UNIX !
● Fonctionne uniquement sur 32 bits
● Fonctionnement sans MMU possible → µCLinux
● Très large communauté
● Extensions temps réel disponibles
● Empreinte mémoire importante → plusieurs Mo
● Licence GPL (pour le noyau)
● Pas d'optimisation de la consommation d'énergie
● Toutes les API possibles sont disponibles !
● Réservé aux objets complexes
● Excellent connectivité réseau
Android
● Basé sur un noyau Linux modifié par Google pour optimiser – entre autres - la consommation
● Équipe plus d'un milliard de téléphone
● Démarrage plus timide pour les autres « devices »
● Partiellement open source, contrôlé par Google → développement non communautaire
● Empreinte mémoire importante, largement supérieure à celle de GNU/Linux (plusieurs centaines de Mo) → IHM
« obligatoire »
● Développement en Java, pas vraiment en POSIX
● Existe déjà sur certains objets (montres, …)
● Version spécifique « wear » pour les objets plus légers (montres, lunettes)
Hello Android wear !
Conclusions
● Le choix en OS dédié et (RT)OS adapté n'est pas toujours simple
● Les OS dédiés utilisent souvent des API et des outils non standards → intérêt de Lepton
● Les OS classiques (Linux, Android) ont une empreinte mémoire importante
● Le panel d'objets est important (de l'automobile au capteur...) et il n'y a pas UN système utilisable
● L'important est la compatibilité des protocoles
● L'utilisation d'un OS libre est fortement conseillée !
● L'offre OS libre semble être majoritaire ?
Bibliographie
● http://www.contiki-os.org/start.html
● http://contiki-os.blogspot.fr/2014/02/thingsquares-contiki-iot-workshop.html
● http://www.inria.fr/centre/saclay/actualites/riot-un-os-open-source-pour-l-internet-des-objets
● http://www.riot-os.org
● http://www.riot-os.org/docs/riot-infocom2013-abstract.pdf
● http://ecos.sourceware.org/
● http://o10ee.com/lepton
● https://source.android.com
● http://www.android.com/wear
Plate-formes, matériel et IOT
Pierre Ficheux ([email protected]) Octobre 2014
IOT et smartphone
● L'IOT est lié (doit faire avec) à l'explosion du smartphone
– Plus de 50% dans les pays industrialisés
– Globalement 2 milliards de smartphones en 2015
● A ce jour le marché naissant de l'IOT est lié à celui du smartphone et dérivés (tablettes, liseuses, …)
● Le smartphone est l'interface privilégiée de l'objet connecté
● Utilisation de « micro contrôleur » sur l'objet et CPU puissant sur le smartphone (dual core, quad core) → Apple A8 / ARM 64 bits / 20 nm
● L'objet lui même est lié à la disponibilité de matériel et logiciel « bon marché » → effet de masse
(R)Évolution du matériel
● Évolution du x86 vers ARM
● Création d'un marché autour des « hobbyistes » en électronique
– Arduino, Raspberry Pi & friends
– Adafruit, Snootlab & friends
● Les professionnels utilisent parfois ces plate-formes ou du moins profitent de la baisse des coûts
● Développement et conception simplifiés
– généralisation de l' open hardware (partiel mais pragmatique)
– utilisation de modules CPU
– nouveaux langages (HTML5, Python)
Versatile PB and sons !
€€€€ !
< 20 €
< 30 €
< 25 €
Cependant...
● Certaines plate-formes génériques permettent de créer une « maquette » mais difficilement la version
définitive → on reste dans le mode « hobby » !
● La connectivité nécessaire n'est pas toujours disponible
– Wi-Fi
– BT
– Capteurs divers
● Un créateur d'objet n'est PAS un développeur logiciel et encore moins un intégrateur système → « fusion » art / design / technologie
● Un objet connecté devrait/doit être aussi simple à
« programmer » qu'un site web !
WeIO
● WEIO est une plate-forme ARM basée sur OpenWrt → distribution Linux utilisée sur les routeurs
● Open source + open hardware
● Fournit un IDE pour développer en HTML5 ou Python
● Extraits de la présentation :
« Today we have miniature and cheap computer coming from UK.
Raspberry Pi is great real computer but...
Today we have one user friendly tool that comes from Italy.
ARDUINO is great to learn basics but...
We need versatile and friendly platform that can be easily connected with Web services or offer new ones. Connecting objects must be as easy as « hello world »
NéoObjects need dedicated interfaces and hardware.
Computers are too generalist platform for them. Also, they need
Carte WeIO
Architecture WeIO
GNU/Linux !
Optimisation du temps
IDE WeIO (HTML5 / Python)
Exemple de réalisation
Bibliographie
● http://www.acmesystems.it/aria
● http://www.buildinginternetofthings.com/
● http://www.raspberrypi.org/tag/internet-of-things/
● http://www.toshiba-components.com/FlashAir/
● http://www.cbnews.fr/etudes/2-milliards-de-possesseurs-de-smartphones-en-2015-a1013350
● http://www.we-io.net/
● https://www.indiegogo.com/projects/weio-platform-for-web-of-things
● http://www.nodesign.net/portfolio/waelice
● http://www.nodesign.net/portfolio/wasnake
● http://www.labaleine.org/yann-guidon.htm
● http://www.arborescence.org/article445.html
● http://snootlab.fr
Consommation énergétique
●
Contexte/Définition
●
Métriques
●
Facteurs clés
●
Cibles
Contexte
● 2013 : 14 milliards* d'appareils connectés
● 2020 : 50 milliards*
● 2030 : 100 milliards*
● De + en + appareils connectés MAIS de l'énergie de + en + chère
● Implication de tous les acteurs nécessaires
Définition
● Puissance instantanée
– P = U * I W : Joule/sec
● Puissance moyenne dissipée
– Pmoy = Pd + Pcc + Pf
Pcc et Pf négligables dans notre cas =>
Pmoy = A . C . Vdd^2 . F [SENTI]
● A : nombre moyen de transition/cycle =>
f(complexité)
● C : capacité circuit Vdd : alimentation
Gains de consommation estimés
● Algorithmique* : 10 à 100 fois
– Option de compilation, complexité, taille des structures
● Architecture* : 10 à 90 %
– Parallélisme, pipeline, unité dédiée, ..
● Circuit* : 10 à 20 %
– Routage
* : [SENTI]
Consommation énergétique soft ?
● Optimisation en temps et en espace
=> énergie AUSSI de + en +
● En général, énergie consommée liée au temps d'exécution
● Métriques :
– Nombre de cycles par instructions
– Temps d'exécution des cycles proportionnel à la fréquence de fonctionnement
– Puissance (instantanée/moyenne) en unité de cycles.
Facteurs clés
● Tâche complexe :
– Structures du code
– Architecture processeur
– Architecture carte finale
Cibles
● Passerelle/Objets mobiles
– Androïd, OpenWRT, GNU/Linux, *BSD , ..
● Capteurs
– Lepton, Contiki, freeRTOS, RTEMS, ..
Mobiles/Passerelle
● Passerelle
– Relais entre réseaux d'objets connectés et Internet
– Contraintes faibles
=> Moins consommer c'est Mieux
● Mobiles
– Configuration, Visualisation de résultats fournis par objets connectés
– Contraintes énergétiques > à celle de passerelles (batteries)
Passerelle,Mobiles : Outils
● PowerTop
● CPUfreq
● Oprofile
● Perf
Passerelles/Mobiles : Optimisation
● Suppression du Read Ahead -Mechanism pour FLASH [READH]
– Désactivation du prefetch opéré par VFS (mise en cache data en fonction accès)
– Utilisation de systèmes de fichiers adaptés, gain :
● JFFS2 (40 %)
● YAFFS (25 %)
=> Gain en terme de consommation énergétique : moins de code exécuté
Passerelles/Mobiles : Optimisation
● Dynamic Voltage and Frequency Scaling [DVFS]
– Ordonnanceur Power-Aware
– Configuration des tâches en fonction de
fréquence/voltage disponibles (création d'un modèle)
– Adaptation de la fréquence de fonctionnement en fonction des temps mort disponibles
Objets connectés
● Capteurs, Actionneurs
● Contraintes énergétiques fortes
● Outils propriétaires :( => Power-debugging
– IAR [IAR]
● Module complémentaire à sonde JTAG
– Energy micro [EM32]
● Disponible uniquement sur KIT d' EVAL
Optimisations communes
● Suppression GPIO flottantes
● Désactivation horloges des périphériques non utilisées (clock gating)
● Utilisation des modes low-power (sleep, deep-sleep, hibernate)
● Options de compilation [COMP_OPTS]
Initiatives libres
● MAchine Guided Energy Efficient Compilation [MAGEEC]
– Application de multiples options de compilation
– Exécution code + mesure de consommation
● Carte de mesure disponible [MAG_HARD]
– Stockage des données énergétiques dans une base de données
– Prise de décision par algorithme évolutionniste i.e.
Machine learning
Bibliographie
[IEA] :
http://www.iea.org/publications/freepublications/publication/MoreData_LessEnergy.pdf [READH] : Revisiting Read ahead Efficiency for Raw NAND Flash Storage in Embedded Linux, Univ. Europeenne de Bretagne, Pierre Olivier, Jalil Boukhobza, Eric Senn
[DVFS] : Low-Power Scheduling with DVFS for common RTOS on Multicore Platforms, THALES Communications & Security, Shuai Li, Florian Broekaert
[COMP_OPTS] : http://arxiv.org/pdf/1303.6485v2.pdf
[MAGEEC] : http://mageec.org/w/images/c/c5/Tsb-eec-mageec-18-jul-13.pdf [MAG_HARD] : http://mageec.org/wiki/Power_Measurement_Board
[IAR] : http://files.iccmedia.com/2013/arm-conference/pdf/ARM-Con-1A-08-IAR.pdf
[EM32] : http://www.mouser.com/pdfdocs/low-power-energy-micro-energy-debugging.pdf [SENTI] : http://r2d2.enssat.fr/bindocs/publications/SEN_CI_97_2.pdf
