Source POUR L'IOT À l'ère du edge computing - Systematic Paris-Region
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Open
source POUR L’IOT
À l’ère du edge computing
1
Som
maire 31
32
32
32
35
INTÉGRATION PLATEFORME
CLOUD DEVOPS
Assets management
Gestion logique
Code source
Pipelines d’intégration continue
36 Images microservices
4 Préface 37 Recettes d’industrialisation
6 Les auteurs 39 Gestion des périphériques : préférence
pour les mises à jour over the air (OTA)
7 Avant-propos 39 Data collection
Pour les métriques
8 Introduction et rappels 40
40 L’approche stockage temps-réel
10 DE L’IOT VER L’I-IOT 42 L’approche stockage intermédiaire
11 EDGE COMPUTING 44 L’approche long terme
46 L’approche toutes durées
12 SECURITY BY DESIGN 47 Gestion des logs
13 Virtualisation 47 L’approche visualisation de logs temps-réel
16 Norme ISO 62443 48 L’approche stockage de logs généraliste
49 L’approche gestion du cycle de vie
20 IOT ET OPEN SOURCE
50 Monitoring et supervision
24 Intégration 50 Dashboards
Du système d’exploitation 51 Dashboards pour les métriques
à la gestion bout en bout 52 Dashboards pour les logs
25 INTÉGRATION ENVIRONNEMENT 53 Alertes
D’EXÉCUTION IOT 54 Digital twins
26 Les architectures d’exécution ouvertes, 55 Représentation IO
ou Open Hardware 56 Approche simulation 3D
27 Les systèmes d’exploitation embarqués 57 Approche abstraite
27 Partie 1 : langages, licences et sources
58 LE CONTINUUM EDGE-CLOUD
28 Les systèmes d’exploitation embarqués
Partie 2 : architectures, ressources 65 Conclusion
28 et fonctionnalités
29 Les orchestrateurs microservices IoT/Edge 66 Bibliographie
2 3
Pré
faceDepuis la publication de notre premier livret Protéger les utilisateurs en éduquant les
bleu consacré à l’IoT, qui avait rencontré un éditeurs et les fournisseurs est l’enjeu social
grand succès, le secteur a littéralement explosé majeur de la communauté open source, dans
et conforté l’impérieuse nécessité d’implémenter un monde tendant vers des approches de plus
des solutions logicielles libres et open source, en plus numériques et automatiques, favorisées
garantes d’infrastructures résilientes et par l’arrivée de la 5G et le déploiement massif
créatrices de services, en s’appuyant sur des de l’IoT. Ce guide s’inscrit directement dans cet
standards ouverts. objectif, porté par le Hub open source à travers
Systematic, dont les auteurs sont membres
Cet opus couvre comme le premier toutes industriels et animateurs sur leurs sujets
les couches de l’IoT, des plus applicatives techniques.
aux plus proches du matériel, et met plus
particulièrement l’accent sur trois tendances Si ce guide est le reflet de leurs expertises
constatées par les auteurs sur ce marché en à date, il a aussi vocation à évoluer.
mutation permanente : L’écosystème open source sur ces sujets étant
1. l’approche industrielle de l’IoT, en intégrant les particulièrement dynamique, il est d’autant
problématiques de sécurité et d’industrialisation plus difficile d’avoir une cartographie globale
2. l’approche DevOps pour la gestion IoT au et exhaustive. Le format numérique de ce livret
niveau Cloud, de l’intégration à la supervision en va favoriser les itérations et les mises à jour en
passant par le déploiement parallèle des solutions open source qu’il met en
3. l’IoT au centre des nouvelles orientations Edge avant.
Philippe Montargès
- Cloud, à travers les solutions structurant le Président du Hub
continuum Edge - Cloud En remerciant ses auteurs et en vous en Open Source de Systematic
souhaitant bonne lecture. Paris-Region
4 5
Les
En quelques années la situation a bien évolué Il y a 4 ans (en 2016)
auteurs
et lorsqu’on évoque l’IoT on pense surtout nous avions publié la
aux produits et services des membres du première version du
livret bleu consacré à
club des GAFAM. Si Apple et Facebook n’ont l’utilisation de l’open
pas réellement mis le pied dans ce marché source dans l’internet
(tout en restant des hébergeurs de données des objets. Cette
commerciales majeurs - les leurs qui sont version était désormais
obsolète et, du fait
souvent les nôtres), Amazon et Microsoft se
des compétences
taillent aujourd’hui la part du lion grâce à leurs du rédacteur, était
solutions AWS et Azure. À fin 2019 les parts de focalisée sur les
frederic.desbiens@ Frédéric DESBIENS est Gestionnaire des marché étaient estimées à 33 % pour AWS, 17 % technologies liées aux
eclipse-foundation.org pour Azure, 6 % pour Google et donc 44 % pour systèmes embarqués et
Programmes IoT et Edge Computing à la
aux protocoles réseau,
Fondation Eclipse. À ce titre, il supervise les les autres fournisseurs.
ce qui constitue une
activités de plus de 50 projets open source et faible partie du sujet.
trois groupes de travail. Vous le trouverez sur Comme dans l’édition précédente, et sachant
Twitter sous l’identifiant @BlueberryCoder. que ce livret est rédigé dans le cadre du Hub
Open Source (HOS) du pôle de compétitivité
pierre.ficheux@smile.fr Pierre FICHEUX est Directeur technique de Systematic, notre approche aura pour but de
la division ECS (Embedded and Connected favoriser les solutions à base d’outils open
Systems) de la société SMILE (https://www.smile. source tout en adoptant bien entendu une
eu/fr/offres/embarque-iot). Il est également approche pragmatique. Bref nous serons
enseignant dans plusieurs écoles d’ingénieurs, militants sans être dogmatiques !
auteur de nombreux articles ainsi que de Dans la suite de cette introduction nous
plusieurs ouvrages et livres blancs sur les décrirons les éléments qui ont marqué
systèmes embarqués, le logiciel libre et l’IoT. l’évolution de l’IoT ces dernières années.
Avant-
jonathan.rivalan@ Jonathan RIVALAN est responsable de la cellule
alterway.fr de Recherche et Développement d’Alter Way
propos
depuis 2014. Les travaux menés par son équipe
visent l’optimisation des plateformes Cloud
DevOps, plus précisément par des pratiques
de scoring, billing, monitoring, et analyse en
continue par Machine Learning (clustering,
régression linéaire, NLP, etc.). L’intégralité de
leurs résultats sont publiés en open source.
6 7
Introduction
et rappels
Même si les solutions IoT sont beaucoup plus 3. La partie Cloud incluant le stockage de
fréquentes que lors de la parution de la dernière données et la couche de présentation (IHM ou
version de ce livret, il nous semble nécessaire Interface Homme Machine).
avant d’entrer dans les détails de rappeler 4. Les différents clients permettant de consulter
les principaux éléments d’une architecture les données (interface web, application mobile).
IoT. On peut donner une définition simple de
l’IoT comme étant une extension de l’Internet
Connectivité 2 Connectivité 1
permettant l’accès à des systèmes physiques (et Protocoles de communication Protocoles de communication
DSL, FTTX, cellulaire… XXXXXXXXXXX
non plus seulement des pages web). Interface utilisateur
Usages clients
Le but de l’IoT est avant tout de collecter des
données issues de capteurs répartis sur un PASSERELLE OBJET CONNECTÉ
territoire. Ces données sont le plus souvent Intelligence locale Hardware
Pré-traitement data Capteurs, connecteur
filtrées puis mises à disposition sur un ensemble (stockage/envoi) radio
de serveurs familièrement nommé Cloud.
Plateforme Plateforme 800 Stockage local Software
Le schéma ci-dessous indique les différents IoT de services de données interface utilisateur,
(ou SI Client) (stockage) intelligence locale
niveaux du système (de droite à gauche)
1. La partie capteur basée sur des architectures
Partenaires
de faible puissance (microcontrôleur) et utilisant
des systèmes d’exploitation adaptés (voire du Architecture IoT
bare metal, i.e. pas de système d’exploitation Si le dialogue entre certaines couches est
mais un logiciel dédié). totalement standard (accès aux données
2. Une couche de filtrage comportant un depuis un terminal via le protocole HTTP et
algorithme plus ou moins complexe (allant du un navigateur classique), la communication
entre les capteurs utilise souvent des
simple tri de données à de l’IA plus complexe).
protocoles dédiés (6LoWPAN, BLE, ZigBee) et
Cette partie utilise des calculateurs largement
la communication entre le routeurs de bordure
plus évolués (architecture 32 ou 64 bits) et des
et le Cloud utilise également des protocoles
systèmes d’exploitation évolués type Linux.
applicatifs spécifiques. Encore aujourd’hui le
En l’absence de traitement, cette couche se
protocole MQTT (initialement Message Queuing
bornera à la réalisation du routage des données
Telemetry Transport, créé par IBM en 1999 !) est
des capteurs vers le Cloud (routeur de bordure
largement utilisé et disponible auprès de tous
ou border router).
les fournisseurs de Cloud.
8 9
Le principal paradoxe de l’IoT est le fait de Time Operating System) ou un logiciel dédié
rendre révolutionnaire (au sens marketing (qui devra être modifié). Si la carte existante
du terme) une association de technologies est déjà capable d’acquérir les données et de
existantes. Cependant la bonne foi nous les transmettre (si elle est déjà sous Linux), une
conduit à penser que même si ces technologies simple adaptation logicielle sera suffisante.
existaient déjà depuis des décennies De nombreux systèmes de supervision
(capteurs, systèmes d’exploitation embarqués, de processus industriels existants ont été
traitement de données, serveurs, terminaux de développés récemment en utilisant cette
consultation), l’évolution technique a permis de approche. Cependant, même dans le cas de l’I-
les associer et de les rendre accessibles à un IoT il est assez fréquent que la partie matérielle
plus grand nombre d’applications. (capteurs) soit banalisée.
De ce fait, les prévisions d’un Eldorado de l’IoT
DE L’IOT VER L’I-IOT grand public évoquées lors de la première
Le déplacement du marché de l’IoT vers l’IoT version du livret n’ont pas été confirmées et
industriel ou B2B (I-IoT) est une autre évolution les brosses à dent, ceintures connectées et
majeure. En effet, la quasi-totalité des projets autre gadgets n’ont jamais connu le succès
actuels en informatique industrielle sont prévu (ce qui n’est pas vraiment une surprise).
désormais assortis d’une partie liée à la collecte Dans la plupart des cas, les services utiles
et au traitement des données. Si l’on quitte le au grand public peuvent être fournis par une
monde industriel, de nombreux projets IoT sont application mobile et à ce jour le smartphone
principalement focalisés sur la partie Cloud, est le seul objet connecté B2C (très) largement
la partie matérielle (capteur, voire routeur de déployé ! Selon des statistiques de 2019, 67 %
bordure) étant souvent banalisée et les capteurs de la population mondiale est équipée d’un
achetés sur étagère. Le modèle économique est smartphone. Dans certains pays d’Europe, le
alors difficile à trouver, mis à part pour ceux qui taux dépasse 100 % car chaque utilisateur
jouent sur le volume qui jouent sur le volume des dispose de plusieurs appareils !
données traitées.
EDGE COMPUTING
La plupart des développements spécifiques Ce sujet est souvent lié aux applications
ont lieu dans le monde industriel car la mise industrielles de l’IoT. Alors que les architectures
en place d’un projet d’IoT peut conduire pour initiales se bornaient à intégrer des capteurs
certains marchés sensibles et/ou à forte valeur délégant le traitement des données au
à l’adaptation de composants existants. À Cloud, l’ajout de devices en Edge Computing
titre d’exemple un système embarqué peut (périphérie de réseau) permet un traitement
nécessiter l’ajout d’une carte d’acquisition et de partiel des données en amont du Cloud (par
transmission de données. Le tout est souvent exemple un filtrage). Cette approche a de
réalisé grâce à une carte Arm fonctionnant nombreux avantages à la fois techniques et
sous Linux embarqué (par exemple sous Linux/ économiques :
Yocto) et communiquant avec la carte existante.
La carte initiale peut utiliser un RTOS (Real
10 11
1. Amélioration de la bande passante (réduction À ce jour, le seul objet connecté grand public
des accès au Cloud ce qui entraîne également largement répandu (le smartphone) n’a jamais
une réduction des coûts) connu de problème majeur car la sécurité
2. Diminution de la latence (temps de réponse) fut prise en compte lors de la conception des
pour des applications “temps réel” systèmes concernés (iOS et Android pour citer
3. Simplification des contraintes liées aux les deux principaux). Le système d’exploitation
exigences réglementaires sur le stockage des Android étant basé sur le noyau Linux nous
données pouvons citer diverses fonctionnalités du
Les principaux fournisseurs permettent noyau liées à la sécurité comme ACL, SMACK,
l’intégration de fonctionnalités Edge dans leur dm-verity et bien entendu le projet SELinux
réseau. Les architectures utilisées au niveau (développé par la NSA). Ce dernier (dont
Edge dans les gateways sont assez éloignées de un sous-ensemble est utilisé par défaut
celles des capteurs. Selon l’IoT developer survey sur Android) est d’une grande complexité
réalisé par la fondation Eclipse (version 2020), mais garantit également un très bon niveau
43 % des systèmes utilisent Linux. Les systèmes d’intégrité du système. SMACK a une approche
d’exploitation utilisés dans les capteurs sont plus simple (S pour simplifed) et il est utilisé
plutôt de type FreeRTOS et dans une moindre dans le framework AGL (Automotive Grade
mesure Zephyr (de la fondation Linux). Linux) basé sur Yocto. AGL est un concurrent
d’Android Automotive OS pour la mise en place
SECURITY BY DESIGN de systèmes d’IVI (In Vehicle Infotainment).
La sécurité est l’enjeu majeur pour assurer Le dernier composant (dm-verity) se charge
l’évolution des solutions IoT. Certains disent, de vérifier l’intégrité des blocs du système
à juste titre, que la réticence du grand public de fichiers afin d’empêcher le démarrage en
est en grande partie liée aux incertitudes cas d’une modification binaire non validée. À
concernant la sécurité des systèmes IoT et plus cela nous pouvons ajouter les notions de boot
particulièrement la confidentialité des données sécurisé et la possibilité de chiffrer les partitions
traitées. L’adoption du RGPD en 2016 met en du système ce qui permet d’éviter le vol de
place un cadre plus strict mais son utilisation données personnelles même si le terminal est
est complexe lorsqu’on l’applique au concept compromis.
du Cloud qui est par définition délocalisé. Il
existe de nombreux exemples de problèmes de Virtualisation
sécurité graves mettant en cause des systèmes La notion d’hyperviseur est utilisée depuis de
connectés. Un des plus célèbres est l’attaque nombreuses années dans l’aéronautique. Le
connue sous le nom de “BlackEnergy” (en 2014) principe est d’utiliser une couche logicielle
qui a gravement endommagé le système de permettant de partager l’utilisation du
fourniture électrique de l’Ukraine en utilisant un matériel entre plusieurs partitions utilisant des
malware propagé sur des systèmes industriels niveaux de criticité différents. Dans la cas de
de type SCADA (pour Supervisor Control And l’aéronautique, la norme ARINC 653 est la plus
Data Acquisition). célèbre.
12 13
De même, la société Elektrobit propose un outil
nommé EB Corbos, dédié aux applications
automobiles et conforme à AUTOSAR WiFi
Adaptive, extension du standard AUTOSAR
Ground
permettant d’exécuter du code POSIX dans un Station Link MISSION COMPUTER Camera
environnement sécurisé de type GNU/Linux
(Yocto) . Dans le monde du logiciel libre, des NET
composants comme LXC (LinuX Containers
- utilisé avec le noyau Linux) ou bien Docker
permettent d’exécuter une image de système
d’exploitation dans un conteneur au niveau Sensors FLIGHT COMPUTER Motors
Architecture
du système d’exploitation Linux hôte (et non ULB initiale
plus en bare metal). À titre d’exemple, le projet
Anbox permet d’exécuter Android dans un Un tel système peut aisément être attaqué à
conteneur LXC. Un grand groupe industriel partir du lien vers la station au sol. Le mission
français a déjà utilisé cette technique afin computer peut être infecté et éventuellement
d’intégrer des applications Android dans transmettre l’infection au flight computer via
un environnement existant sous GNU/Linux le réseau local. L’utilisation de seL4 permet de
(Debian). Dans le même ordre d’idée, le faire évoluer le logiciel vers une architecture
micro-noyau libre seL4 est utilisé dans des sécurisée dans laquelle les composants sont
applications d’aéronautique autonome ainsi séparés. La partie Linux (non sécurisée)
que sur des projets d’IoT. Cet outil est également communique avec la partie sécurisée par l’API
basé sur l’isolation de composants ayant des seL4 (voir figure ci-dessous).
niveaux de criticité différents. Une API prend
en charge le fonctionnement du micronoyau et
des différents systèmes d’exploitation hébergés
(threads, IPC, signaux, etc.) afin de produire un Radio Data Lunix VM
système hautement sécurisé. Un article cité en Driver Link
WiFi
bibliographie décrit la sécurisation du logiciel and Camera
utilisé dans un hélicoptère autonome créé sur la Crypto Non-critical
base du Boeing AH-6 (ULB pour Unnamed Little
Untrusted
Bird). La figure ci-contre décrit l’architecture
CAN Critical
initiale du système. CAN bus Driver Contained
Trusted
seL4
Architecture ULB
basée sur seL4
14 15
Norme ISO 62443 1. Processes (policies, procedures & guidelines)
Dans le cas de la sécurité de l’I-IoT nous 2. Technology
pouvons citer les normes ISO 27005 et surtout 3. Foundational requirements (FR)
IEC 62443. La norme ISO/IEC 27005 fournit 4. Zones & conduits
les éléments nécessaires à la mise en place 5. Security levels (SLs)
d’une gestion des risques liés à la sécurité de 6. Maturity
l’information (IT). La norme IEC 62443 traite de
la cybersécurité des systèmes industriels (OT) et La partie Processes est organisée selon 11
couvre les applications I-IoT. La figure suivante catégories (Security Policy, Organization of
présente assez clairement les différents niveaux Security, Asset Management, etc.). La partie
de prise en compte des contraintes de sûreté Technology utilise 7 “Foundational Requests”
et sécurité dans une approche globale de la ou FR (Identification, authentication control
gestion des risques. and access control - AC, Use control – UC, Data
Integrity - DI, etc.). Le système global à analyser
doit être divisé en Zones reliées par des
Conduits comme indiqué sur la figure suivante.
ENTERPRISE ZONE
Sécurité E-Commerce
industrielle
Enterprise Firewall Internet
Enterprise
Enterprise File Server infrastructure Web Server
Sécurité Cybersécurité
WLAN
fonctionnelle des installations Sécurité des systèmes
IEC 61508 industrielles d’information
IEC 61511 CEI 62443 ISO 27000 CONDUIT
(ISA84) (ISAA99)
INDUSTRIAL/
ENTEPRISE Router/
Sûreté de DMZ ZONE Firewall
focntionnement Inventory
Terminal Services/ Management
Data Historian Mirror Managed
switch(es)
Domain Controller, Anti-Virus, Manufacturing
Patch Management Execution System (MES)
CONDUIT
Gestion des risques Gestion
industriels (schéma de des risques INDUSTRIAL
JP Hauet) NETWORK #1 PLC Router/
Firewall Local
Switch HMI
La norme IEC 62443 étant la plus utilisée dans
notre cas, nous allons brièvement la décrire en
quelques mots en nous basant sur l’exemple de Legacy Fieldbus ... Field Devices
l’attaque BlackEnergy. Les principaux concepts
tels que décrits dans la norme sont les suivants :
Zones et conduits
16 17
La norme fournit une liste de critères techniques SRs and REs SL 1 SL 2 SL 3 SL 4
permettant d’évaluer le niveau de sécurité FR 5 - Restricted data flow (RDF)
(SL) sur une échelle de 1 à 4 à laquelle on peut
SR 5.1 RE 1 - Network segmentation 9.3 • • • •
ajouter la valeur 0 (pas de niveau de sécurité
SR 5.1 RE 1 - Physical network segmentation 9.3.3.1 • • •
constaté).
1. Protection contre une violation usuelle ou de SR 5.1 RE 2 - Independance
9.3.3.2 • • •
from non-control system network
pure coïncidence
2. Protection contre une violation intentionnelle SR 5.1 RE 3 - Logical and physical
9.3.3.3 • x
isolation of critical networks
simple
3. Protection contre une violation intentionnelle SR 5.2 - Zone boundary protection 9.4 • • • •
sophistiquée (experts) SR 5.2 RE 1 - Deny by default,
9.4.3.1 • • •
4. Protection contre une violation intentionnelle allow by exception
étendue (étatique) SR 5.2 RE 2 - Island mode 9.4.3.2 • •
SR 5.2 RE 3 - Fail close 9.4.3.3 • • N/A
Le principe de l’analyse est d’estimer pour
chaque zone le niveau de sécurité actuel de SR 5.3 - General purpose person-to-
9.5 • • • •
person communication restrictions
chaque FR (soit SL-A, où “A” vaut pour achieved)
et d’en déduire le niveau nécessaire pour éviter SR 5.3 RE 1 - Prohibit all general purpose
9.5.3.1 • • x
person-to-person communications
une attaque à un niveau donné (soit SL-T, où
“T” vaut pour pour target). Si nous prenons SR 5.4 - Application partitioning 9.6 • • • • ?
SL 1 OK SL 2 OK SL 3 NOK
l’exemple de FR 5 (ci-contre), l’audit consiste
à vérifier chaque SR (Security Requirement) En réalisant la même tâche sur tous les FR, on Evaluation FR 5
et de déterminer le SL global. Dans l’exemple en déduit un graphe correspondant au SL-A.
ci-contre (issu du cas BlackEnergy), l’audit a Dans le cas étudié, l’audit a déterminé que FR 6
identifié que le point 3 du SR 5.1 logical and était au niveau 1 et les cinq autres FR au niveau
physical isolation of critical network n’était 0 (aucun niveau de sécurité). De ce fait, la valeur
pas respecté, ce qui fait chuter le niveau de globale de SL-A est égale à 0, correspondant
sécurité à SL 3. De même, le point 1 du SR 5.3 à la valeur du maillon le plus faible. Le système
prohibit all general purpose person-to-person était donc relativement bien protégé au niveau
communication n’est pas non plus respecté, FR 5/réseau (SL 2) mais très mal protégé pour
ce qui fait chuter le niveau de sécurité à SL 2. le reste ce qui indique une absence de prise
Globalement, le niveau de la zone étudiée sur FR en compte globale des contraintes de sécurité
5 est donc au niveau SL 2. (but de la norme). Le SL-T (à atteindre) est donc
égal à 2 ce qui est un niveau relativement faible
(protection contre une violation intentionnelle
simple). La norme permet également de définir
la liste des contre-mesures à mettre en place
sur les FR incriminés.
18 19De plus, les répondants ont identifié la flexibilité
1. Identification and authentification control
4 (55 %), le coût (49 %) et le contrôle accru (41 %)
comme étant les bénéfices les plus significatifs
3
7. Resource availability 2. Use control reliés à l’emploi de l’open source.
2
1 Pour saisir tout l’impact qu’une approche
0
open source peut avoir sur un projet IoT, il est
essentiel de comprendre en quoi les projets IoT
6. Timely response to events 3. System integrity diffèrent des projets IT traditionnels. La première
différence est celle du cycle de vie. Alors que
les éditeurs logiciels nous ont habitués depuis
quelques années à des mises à jour quasi
SLT-T mensuelles, voire hebdomadaires, les solutions
5. Restricted data flow 4. Data confidentiality SLT-A
IoT s’inscrivent dans une durée mesurée en
Graphe SL-A/SL-T années ou même en décennies. Une entreprise
manufacturière, par exemple, ne révisera sa
IOT ET OPEN SOURCE chaîne de production de fond en comble que
Si l’on évoque les solutions liées au Cloud, force très occasionnellement, vu les capitaux et les
est de constater que le marché est largement risques d’affaires que cela implique. La seconde
dominé par des solutions propriétaires. La différence est l’hétérogénéité. La plupart des
domination de l’approche propriétaire n’est entreprises opèrent des infrastructures IT
pas limitée aux fournisseurs de Cloud et un largement standardisées et ne font affaire
grand nombre de frameworks, outils intégrés qu’avec un nombre restreint de fournisseurs
et périphériques matériels sont également dans le domaine. Or, dans le domaine de l’IoT,
propriétaires (même s’ils utilisent des systèmes aucun fournisseur ne peut prétendre pouvoir
d’exploitation open source). AWS utilise fournir à lui seul l’infrastructure, les logiciels, et
cependant des composants open source les dispositifs spécialisés requis qu’il s’agisse de
comme FreeRTOS et Microsoft Azure utilise le capteurs, d’actuateurs, de robots ou même de
système d’exploitation GNU/Linux et d’autres machines intelligentes. La conséquence est que
composants libres célèbres comme Kubernetes. les solutions IoT sont par définition hétérogènes.
La banalisation (commoditization) croissante Une troisième différence entre les solutions IT
du marché fait également en sorte que l’offre et IoT est que ces dernières sont soumises à un
purement open source devienne avec le temps ensemble de contraintes physiques rigoureuses.
de plus en plus complète et homogène. La consommation d’énergie est sans contredit
Ce constat explique que, dans l’édition 2019 de la plus importante, car bien des dispositifs sont
l’enquête d’opinion sur l’adoption commerciale alimentés par une batterie censée durer des
de l’IoT de la Fondation Eclipse, 60 % des mois ou mêmes des années.
répondants ont affirmé considérer l’open source
dans leurs plans de déploiement de solutions
IoT.
20 21Selon les cas d’utilisation, la résistance aux En d’autres termes : une approche open source
variations de température, aux vibrations, préserve la capacité des organisations à
aux radiations, à la poussière ou à l’humidité innover.
seront également des contraintes importantes.
Finalement, la dernière différence entre les En définitive, avoir recours à une approche
projets IT et IoT se trouve au niveau de la open source pour bâtir une solution IoT
connectivité. Toute solution IoT digne de ce affranchit les architectes et développeurs d’un
nom doit assumer que les réseaux auxquels ensemble de contraintes externes. Ils auront
elle se connecte sont susceptibles d’être donc l’entière liberté de déployer la solution
instables ou de manquer de fiabilité. Ce fait a sur les serveurs de leur choix (y compris dans
des implications profondes sur l’architecture et le Cloud) et de connecter les dispositifs à l’aide
l’implémentation de la solution. des protocoles et des technologies les plus
appropriés. Toutefois, toutes les bases de code
Une approche open source permet de mitiger open source ne se valent pas. Celles qui sont
et contrôler les problématiques liées aux sous la gouvernance de tierces parties neutres
spécificités des projets IoT. Avoir accès au code et soutenues par une communauté diverse
source fait en sorte qu’une organisation puisse sont les plus susceptibles de s’épanouir sur le
maintenir elle-même la solution si jamais les long terme. Dans ce contexte, il convient de
prestataires commerciaux se retiraient du mentionner que le groupe de travail IoT de la
marché (le cycle devenant ainsi plus prévisible). Fondation Eclipse offre sans contredit le coffre à
L’intégration de composants hétérogènes est outils open source le plus complet de l’industrie.
également plus facile lorsque les logiciels (et La majorité des projets qui lui sont rattachés
dans certains cas le matériel) utilisés sont sont d’ailleurs développés par des contributeurs
open source. Cela s’applique également aux européens; les équipes des projets Eclipse fog05
contraintes physiques. Quant à la connectivité, et Eclipse zenoh étant même basées en région
le fait de recourir à une plateforme open source parisienne.
accroît le nombre de technologies disponibles, La structure de gouvernance neutre de la
ce qui permet aux intervenants techniques Fondation assure l’égalité des chances entre les
de sélectionner celle qui convient le plus aux contributeurs et fait en sorte qu’aucun d’entre
exigences d’une implémentation donnée. eux ne puisse détourner un projet à ses propres
De plus, adopter une approche open source fins. De plus, le processus de développement
permet aux organisations d’éviter les pièges de mature offert par la Fondation fait en sorte que
certains modèles d’affaires commerciaux tels des organisations qui compétitionnent dans le
que la facturation au prorata du nombre de domaine commercial peuvent tout de même
périphériques ou de transactions. Il est en effet coopérer dans le cadre de projets open source.
fort difficile pour une organisation planifiant Mentionnons au passage que la Fondation
un déploiement d’avoir une idée précise de ces vient de déménager à Bruxelles et, à ce
métriques sur le long terme. Dans ce contexte, titre, représente l’acteur le plus important de
les directions d’entreprise auront tendance l’écosystème open source en Europe.
à favoriser la prévisibilité au détriment de
l’innovation.
22 23Inté
En ce sens l’effort d’intégration Cloud/IoT peut-
gration
être distingué en trois parties :
1. L’intégration de l’environnement d’exécution
IoT, qui spécifie la manière dont les services
s’exécutent sur les périphériques
2. L’intégration de la plateforme applicative de
pilotage Cloud, qui spécifie les solutions et la
manière dont la plateforme est gérée par les
administrateurs
3. La continuité entre les deux environnements
Du système Dans le contexte actuel, où les fournisseurs ou Continuum Edge Cloud
d’exploitation d’équipement de bordure (Edge ou Fog, lié ou
pas au développement 5G) se tournent de plus INTÉGRATION ENVIRONNEMENT
à la gestion en plus vers des approches as a service pour D’EXÉCUTION IOT
bout en bout équiper leurs clients, un équipement de gestion
centralisé, résilient et évolutif devient une
Les composants utilisés dans cette partie
se situent au niveau de la récupération des
nécessité. données (capteurs) ou bien dans la couche
Edge (gateway/filtrage). Les thématiques de ce
Les fournisseurs de Edge Cloud propriétaires document étant clairement orientées vers l’open
ont à leur catalogue des services ou grappes de source, nous avons favorisé cette approche
services unifiant cette gestion de l’infrastructure pour le logiciel (des systèmes d’exploitation -
IoT et son usage (à travers la gestion des partiellement ou totalement - open source) mais
services ou applications s’appuyant dessus). également pour le matériel car la mouvance
Au détriment de la souveraineté du SI client, et open hardware a connu un essor important ces
soumis à la politique tarifaire et technologique dernières années grâce à des produits ouverts
du fournisseur. comme la carte BeagleBone Black et plus
récemment l’architecture RISC-V.
Intégrer, déployer et gérer son parc IoT peut Dans la partie décrivant les systèmes
être réalisé de la même manière avec une série d’exploitation, nous retrouverons des standards
de solutions open source souvent présentées comme GNU/Linux ou Android dédiés à des
comme des solutions dites DevOps. Aussi architectures puissantes (x86, Cortex-A 32 ou
décliné sous les appellations ChatOps, AIOps, 64 bits). Nous citons également des systèmes
FinOps ou plus récemment EdgeOps, DevOps émergents comme Zephyr (de la fondation
rassemble des outils autour d’une technologie Linux), Contiki-ng ou RIOT utilisés sur des
de virtualisation, la conteneurisation en capteurs (Cortex-M voire des architectures 16 ou
microservices, et des principes de gestion 8 bits).
de cycle de vie projet, faisant la promotion
de l’intégration continue, qui permet de
lier l’état du code produit ou des versions
de votre application avec l’état du ou des
environnements d’exécution.
24 25Les architectures d’exécution ouvertes, Les systèmes d’exploitation embarqués
ou Open Hardware Partie 1 : langages, licences et sources
L’une des caractéristiques essentielles Cette liste non exhaustive concerne des
des solutions IoT est d’être fortement systèmes légers embarqués dans des capteurs,
personnalisable. Les contraintes de voire des gateways Edge.
consommation d’énergie et, dans certains cas,
la difficulté d’accès à l’équipement font en Langage
sorte qu’il est souvent désirable d’avoir recours Nom Date de Version de program-
à une combinaison matérielle et logicielle de l’OS creation à date mation Licence Sources
taillée sur mesure pour le cas d’utilisation Amazon https://www.freertos.
2017 10.3.x C MIT
concerné. En ce domaine, une tendance en FreeRTOS org/a00104.html
pleine croissance est le matériel open source.
Java + Kotlin
Depuis le début des années 2010, l’architecture (Android
Apache http ://source.
RISC-V offre une solution de rechange crédible Android 2008 11 SDK and
2.0 android.com
Android
aux architectures propriétaires. De nombreux
Studio)
fabricants de matériel ont conçu des plates-
formes s’en inspirant. RISC-V ne représente Apache Apache https://github.com/
2016 1.3.x C/Go
Mynewt 2.0 apache/mynewt-core
cependant qu’un jeu d’instructions et la
plupart des organisations ne disposent pas Apache https://github.com/
ARM Mbed 2009 5.15.x C/C++
des compétences requises pour concevoir des 2.0 ARMmbed/mbed-os
processeurs et microcontrôleurs l’utilisant. Cet Contiki/ BSD https://github.com/
obstacle à l’adoption a favorisé l’émergence 2002 4.x C
Contiking 3-Clause contiki-ng
d’organisations telles que le OpenHW Group, qui
Huawei 2013- BSD https://github.com/
développe une famille de processeurs RISC-V LiteOS 2018
2.x C
3-Clause LiteOS
open source appelée CORE-V. Les concepteurs
de matériel peuvent librement télécharger le Multiples
Linux/ (GPL,
code source en langage System Verilog de ces 2010 3.1 Multiples http://yoctoproject.org
Yocto LGPL,
processeurs et le modifier à leur guise. Il est etc.)
même possible de valider les designs à l’aide de
RIOT- https://github.com/
FPGAs relativement peu onéreux. L’émergence RIOT 2012 C/C++ LGPLv2.1
2020.10 RIOT-OS/RIOT
de plateformes prêtes à l’emploi telles que
CORE-V fait donc en sorte qu’il sera de plus C https://github.com/
Apache
Zephyr 2016 2.4.X (Developer zephyrproject-rtos/
en plus facile pour les organisations de toutes 2.0
Kit) zephyr
tailles de déployer des solutions taillées sur
mesure.
26 27Les systèmes d’exploitation embarqués Les orchestrateurs microservices IoT/Edge
Partie 2 : architectures, ressources Si les systèmes d’exploitation embarqués
et fonctionnalités supportent une grande partie de la couverture
fonctionnelle de votre application ou
Nom Principales architectures Ressources Fonctionnalités infrastructure applicative, ils ont besoin dans la
de l’OS supportées demandées remarquables plupart des cas d’une plateforme d’exécution
plus classique pour offrir des fonctionnalités
Intégration AWS
(Amazon) non fournies par les périphériques eux-mêmes,
ARM, x86 4 Ko RAM pour la version
FreeRTOS
Amazon mais nécessaires à leur bon fonctionnement :
health checking, centralisation et analyse de
Android x86, ARM 2 Go RAM Toutes ou presque !
données, gestion de configurations, gestion
Apache Mynewt 16 Ko RAM BLE 4.2 de politiques de sécurité, etc. (fonctionnalités
que l’on retrouvera bien évidemment dans
ARM Mbed ARM Cortex-M 64 Ko RAM BLE 4.2
le Cloud mais au prix de la distance avec les
SSL/TLS (Mbed périphériques). Dans certains cas la latence
2002 4.x C
TLS ou WolfSSL)
des traitements rendra inefficace leur réponse
Noyau préemp- aux périphériques de bordure ou offriront des
2013-2018 2.x C
tif performances dégradées.
10 Ko
Contiki/ En poursuite de la tendance DevOps, et
ARM Cortex -M, MSP430 RAM/100 Ko 6LoWPAN, RPL, CoAP
Contiking
ROM notamment à la fourniture de services
Support NB-IoT,
conteneurisés, c’est-à-dire à une approche
Huawei LiteOS ARM, RISC-V 10 Ko (noyau) Ethernet, Bluetooth, plus légère et plus dynamique que la
Wi-Fi, Zigbee virtualisation en VM, les infrastructures IoT
Linux/Yocto Toutes ou presque ! 32 Mo RAM Toutes ou presque ! se voient accompagnées par des solutions
d’orchestration microservices spécialisées
1,5 Ko RAM, Noyau temps réel, pour les couches Fog et Edge, et déclinées
RIOT Cortex-M, RISC-V, x86
5 Ko ROM support POSIX
depuis la solution Cloud, Kubernetes. Cette
Device tree support dernière ajoute toutefois une certaine
8 Ko RAM,
Zephyr ARM, RISC-V, x86 (DTS), Large set of complexité à l’infrastructure et ne s’adapte pas
30 Ko ROM
protocol stacks
nécessairement à tous les types de déploiement.
Par conséquent, ces dernières années ont vu
l’émergence d’un ensemble de plateformes
spécialisées pour assurer l’orchestration de
microservices Edge qui dans certains cas
s’intègrent à des instances Kubernetes situées
dans d’autres couches de l’infrastructure.
28 29Plusieurs projets open source permettent de qui peuvent les prendre en charge. L’outil
déployer Kubernetes lui-même dans la couche fog05 peut également déléguer l’exécution de
Edge. Certains d’entre eux, tels que Minikube certaines charges à Kubernetes, au besoin.
et Microk8s, sont surtout utiles à des fins Il convient de mentionner que les populaires
de développement puisqu’ils ne fournissent projets Eclipse Kura et Eclipse Kapua peuvent
qu’une grappe (cluster) à un seul nœud (node). également orchestrer des applications dans un
D’autres, comme K3s, tentent de réduire environnement Edge, pourvu qu’une topologie
l’empreinte de Kubernetes en remplaçant de déploiement appropriée soit employée.
certains de ses composants par des alternatives
moins consommatrices en ressources. Ceci rend INTÉGRATION PLATEFORME
toutefois impossible le déploiement en mode CLOUD DEVOPS
haute disponibilité. Finalement, des projets tels Une fois l’architecture de bordure définie se
que KubeEdge marient un composant Edge sur pose la question de sa maintenance centralisée
mesure à une grappe Kubernetes résidant dans ainsi que de la gestion de ses ressources,
une couche distante. notamment celles liées à l’exploitation des
données. Aujourd’hui ces points sont largement
Une tendance relativement récente a vu couverts par de l’outillage issu de/ou composant
l’émergence du concept de EdgeOps, qui la méthodologie DevOps, c’est-à-dire facilitant
vise à adapter les pratiques DevOps établies le rapprochement entre les métiers du
à la réalité de l’environnement Edge par développement et ceux de l’opérationnel. Nous
l’intermédiaire de plates-formes et d’outils allons aborder dans cette seconde partie
conçus à cet effet. Les projets Eclipse ioFog les différentes familles de solutions métiers
et Eclipse fog05 (qui a recours au protocole permettant la mise en place d’un socle de
Eclipse zenoh) sont des exemples représentatifs management Cloud basique et open source
de cette tendance. Eclipse ioFog a recours à un pour infrastructures IoT. Trois familles de
contrôleur centralisé qui assure l’orchestration solutions métiers ont été identifiées :
des microservices. Pour ce faire, il a recours 1. Asset management, regroupant les solutions
à une abstraction appelée Edge Compute de gestion des ressources opérationnelles,
Network qui isole les applications de la logiques (code, scripts, etc.) et physiques
complexité de l’infrastructure. L’outil ioFog (périphériques, routeur, etc.)
peut être déployé en mode autonome (il a 2. Data collection, regroupant les solutions de
alors recours à containerd) ou s’intégrer à collecte et de stockage de données, de type
Kubernetes. Eclipse fog05, quant à lui, a recours métriques ou bien de logs (traces)
à une approche totalement décentralisée. 3. Monitoring et supervision, regroupant les
Les différentes ressources d’infrastructure solutions type dashboards ou jumeaux digitaux
prises en charge par fog05 sont gérées par
l’intermédiaire d’un unified compute fabric
qui s’assure de distribuer les différents
composants d’une application aux ressources
30 31Assets management Gitlab est un exemple open source de
La gestion de l’infrastructure applicative IoT plateforme en ligne permettant de gérer
commence avec une bonne gestion des assets plusieurs aspects liés à la création de code :
logiques et physiques. Pour les premiers on peut 1. Versions et sous-versions
distinguer le code, les recettes d’intégration et 2. Niveaux de droits par utilisateurs
les bibliothèques d’artefacts. Pour les seconds, 3. Corrections ou évolutions attendues sur le code GITLAB
il s’agira d’indexer l’ensemble des périphériques En plus de gérer les différentes
versions du code, Gitlab propose
physiques présents sur votre infrastructure, Il permet également de mettre en place de un IDE Web facilitant l’édition et la
des serveurs aux capteurs en passant par les la méthodologie agile en fournissant des revue du code depuis son interface
côté client. Les fonctionnalités
éventuels équipements de routage. dashboards type Kanban directement dans les annexes sont nombreuses dans la
projets. version communautaire open source :
Wiki, Kanban, registry…
Gestion logique Source : Gitlab.com
Code source
La première étape est d’identifier une solution
de gestion de code de type SCM (Source
Code Manager). Si il y a différentes approches
disponibles (SVN, Mercurial, etc.) aujourd’hui la
tendance est à l’utilisation de solutions basées
sur le protocole Git, qui permet de gérer le code
localement. Pour passer à l’échelle collaborative,
il faut l’articuler avec une plateforme de gestion
permettant son partage et sa gestion dans le
cadre du projet ou de l’intégration.
32 33Tuleap est une alternative française à Gitlab. Pipelines d’intégration continue
La philospohie de la solution est d’offrir une La seconde étape consiste à délivrer ce
solution collaborative pour la gestion du cycle code directement ou à travers des artefacts
de vie des applications. De la description compilés, et souvent vérifiés et optimisés à
des tâches, au suivi de leur développement, travers des services de vérification (qualité,
jusqu’à la gestion du code source et son performance, compliance) ou d’analyses plus
intégration DevOps, en passant par les aspects poussées. Cette étape est celle de l’intégration
qualité comme la revue de code, les tests et continue, aussi appelée CI et plus récemment
la documentation, Tuleap couvre l’intégralité CI/CD car elle va se doubler avec une action de
des besoins liés au développement logiciel. déploiement continu. La description de pipelines
Elle regroupe donc les aspects SCM (Source d’intégration et de scénarios de déploiement
Code Management, avec une compatibilité va être nécessaire pour articuler l’évolution de
TULEAP Git et SVN) pour la partie gestion du code, les votre code avec ces actions.
Tuleap se différencie fortement
par les aspects gestion de projet aspects gestion de projet Agile avec plusieurs
et visualisation. L’outil permet de type de dashboards dont kanban, les aspects Gitlab-CI (embarqué dans Gitlab) permet la
regrouper par configuration sur un
dashboard unique l’état croisé de intégration avec le support de Jenkins, et offre description de ces pipelines, la configuration
l’avancement du code au regard
des fonctionnalités propres permettant de de projets Git avec ces descriptions, et enfin
des spécifications, les informations
relatives au backlog des incidents faciliter la traçabilité des actions menées par les leur exécution à travers des Gitlab-runners.
et une timeline des différents GITLAB-CI
évènements du projet.
équipes. Ces derniers permettent de distribuer sur Les statuts des jobs d’intégration
Source : tuleap.org l’infrastructure la gestion à proprement dite peuvent être monitorés depuis la
plateforme. Ils permettent de suivre
du code, des actions d’intégration et de le déroulé des scripts ou jeu des
recettes sur les environnements,
déploiement, parfois lourdes dans le cas de ainsi que de déboguer rapidement
compilations volumineuses ou de simulations en cas d’erreurs : un accès à la vue
terminal étant incluse dans le client
complexes dans le cadre de la vérification. front-end.
Source : Gitlab.com
34 35Images microservices Recettes d’industrialisation
La conteneurisation des microservices s’appuie Les trois points ci-dessus permettent au projet
fortement sur un concept d’images empilables. d’être prêt à être déployé sur un environnement
Techniquement il s’agit d’une spécificité au local ou distant. Cet environnement (serveur,
niveau du système de fichiers, considérant machine virtuelle, microcontrôleur, etc.)
chaque nouvelle version du code comme une nécessite d’être préparé avant d’exécuter
nouvelle couche historisée. Ces nouvelles les services ou applications IoT. On utilise le
versions du code sont rendues disponibles sous terme “installation” pour décrire cette étape de
la forme d’images, comportant un numéro de préparation de l’environnement. Aujourd’hui et
version. Par exemple, pour appeler la dernière dans la poursuite des approches DevOps, cette
version d’une image Nginx, on écrira dans son installation de l’infrastructure se fait “as code” ;
fichier de dépendance nginx : latest. plutôt que de configurer l’environnement avec
des instructions manuelles et locales, un outil va
La gestion des images se fait communément à “jouer” des recettes décrivant ces instructions et
travers une registry. Il en existe plusieurs ayant assurera que :
différentes spécificités. Gitlab embarque sa 1. Tous les environnements sont configurés de la
propre registry facilitant la mise à disposition même manière
des artefacts issus de l’intégration à travers 2. L’installation est parallélisable sur n
HARBOR Gitlab-CI, tout en limitant parfois leur accès environnements
Harbor propose un concept de extérieur. La Docker Registry est également un 3. Certaines propriétés de configuration ou de
projets au-dessus de la gestion
classique des images mlicroservices, produit officiel et qui permet de distribuer ses conformités sont respectées
afin d’offrir plus de flexibilité et de images de la manière la plus native possible (au
contrôle sur leur gestion (accès,
partage, mise à jour, etc.). Cette sens de Docker). Harbor est une alternative qui Il existe de nombreuses approches et outils
solution permettra de définir des
quotas par projets ou utilisateurs,
intègre des fonctionnalités “enterprise” : gestion pour développer ces recettes d’industrialisation,
facilitera la réplication et offrira des accès RBAC, scanner de vulnérabilité, introduisant chacune des spécificités
des fonctionnalités de tagging
automatique des images. synchronisation multi-registry, etc. liées à leurs formats de description et
Source : goharbor.io d’expression. Ansible est une solution bien
connue et qui couvre, grâce à la description
de rôles et playbooks, le provisionnement
d’environnements, leur configuration et la
gestion du déploiement d’applications sur ces
derniers. Terraform, plus moderne, s’appuie
sur des connecteurs d’infrastructures appelés
providers pour permettre aux utilisateurs de
décrire de manière unifiée, en s’appuyant sur le
DSL fourni, des configurations compatibles, hors
spécificités, avec l’ensemble des providers.
36 37Vous pouvez aussi lire
