Je suis à la fois d'accord et pas complètement d'accord.
Oui, on est tous d'accord : une partie des "objets connectés" intègreront de la complexité, de l'intelligence. Et eux nécessitent des mises à jour. Les technos actuelles (GPRS, 3G) répondent déjà en grande partie à ces besoins dans le monde industriel. Et LoRa va juste permettre de réduire les couts pour la masse.
Je travaille dans l'électronique embarquée automobile. Et je fais facilement le parallèle en terme de besoin de connectivité et de mise à jour.
Il y a 2 type de "calculateurs multiplexés" dans une bagnole : d'un côté ceux qui embarquent beaucoup d'intelligence, et ont besoin d'être mis à jour (100ko à 1Mo à télécharger), d'être configurés; et de l'autre côté une tonne d'équipements bêtes, qui ne sont que des "esclaves" des premiers, qui ne font que envoyer de l'info d'un capteur, d'un bouton, piloter un moteur, ou embarquer une intelligence très basique (petite machine d'état). La plupart des calculateurs de cette 2ieme catégorie sont conçu pour ne nécessiter aucune mise à jour soft, et certains ne savent même pas le faire (OTPROM); tout au plus on peut les configurer (quelques dizaines d'octets) mais c'est tout.
Et bien évidemment, les calculateurs de cette 2ieme catégorie sont plus nombreux (moins chers).
Alors pour faire le parallèle avec les objets connectés, je pense, contrairement à toi, que la majorité des objects connectés (en nombre), tous les capteurs, stations météo, thermostat, etc... n'auront aucun besoin de mise à jour à distance, n'auront aucun besoin d'embarquer une intelligence complexe. Plus ils sont bêtes, simples, et mieux c'est, car moins ils consomment, et moins ils coutent cher. Tout au plus ils ont besoin d'une reconfiguration régulière. C'est bien le marché visé par Sigfox.
La part des équipements bêtes (aucun besoin d'évolution ni de configuration) va diminuer avec le temps : à tarif égal autant avoir un truc évolutif pour le cas où.
Une reconfiguration c'est déjà une mise à jour.
Regarde le modem SigFox, c'est un ordinateur (ARM) et pour 20 euros (prix public) on peut lui injecter des applications, lui faire jouer le rôle de passerelle pour d'autres capteurs et même l'adapter pour d'autres bandes de fréquence.
Observe une cryptopuce (carte bancaire, USIM, badge de contrôle d'accès) c'est un ordinateur (8 bits, 16 bits et même 32 bits) pour lequel, depuis plus de 20 ans, on développe des applications (Javacard depuis 20 ans, propriétaire avant et un peu toujours aujourd'hui).
Dans les 2 cas, si on découvre une faille dans le code (de l'OS ou des applications) que fait-on ? On laisse pisser ?
Dans une politique de sécurité le patch management est un processus essentiel.
Si une vulnérabilité est découverte (ou annoncée) dans un firmware il est nécessaire de le mettre à jour (si tant est qu'il existe une mise à jour) ou, au pire, de l'isoler afin qu'il ne deviennent pas un vecteur de compromission de l'ensemble.
S'il y a des clés, il est nécessaire de les renouveler régulièrement toujours pour le cas où elles seraient compromises.
Cela fait partie des bonnes pratiques dans le monde tertiaire et cela fait partie des bonnes pratiques en devenir dans le monde industriel.
Dans une bagnole il y a des clés également (protégeant l'accès aux fonctions des terminaux des bus CAN). Elles sont permanentes.
La recherche est en cours sur le fonctionnement d'un certain nombre de véhicules (US mais également allemands).
Peu de documentation publique existe sur le sujet donc c'est essentiellement de la rétro-ingénierie. Ça prend du temps.
Les codes tournants de blips ont déjà été cassés pour un certain nombre de véhicules.
Il ne faudra pas longtemps pour que les clés en question se mettent à circuler et/ou que des failles soient mises en évidence. Cela fait 4 ans que les failles des automates Siemens et Schneider sont publiées et la recherche sur le bus CAN commence tout juste.
Il a déjà été démontré que l'on pouvait piloter un véhicule à distance en plaçant un Raspberry Pi communiquant branché sur un bus CAN.
Que feront les constructeurs automobiles lorsque le pilotage à distance, la casse moteur ou la casse d'un véhicule par écrasement des valeurs des consignes aura causé quelques morts ?
Que tu le veuilles ou non, une voiture est un système d'information et, à ce titre, il faudra bien le traiter en tant que tel.
Par ailleurs, la présence des bus dans un véhicule (ainsi que dans un avion et un navire, c'est pareil) répond à plusieurs besoins :
- réduire la longueur des câbles en multiplexant les communications (d'où le bus) ;
- renforcer la sécurité de l'ensemble en doublonnant ces bus, cela ne réclame qu'une duplication du multipaires véhiculant le bus là où il aurait fallu doubler la forêt de câbles en l'absence de bus ;
- offrir de nouveaux services (confort audio/video/clim, verrouillage centralisé, etc).
L'idée est d'aller plus loin encore en permettant à chaque équipement de communiquer par lui-même renforçant ainsi la résistance (résilience) de l'ensemble (aujourd'hui si un multiplexeur lâche, une partie du véhicule ne répond plus), la sécurité et offrir toujours plus de services.
Par exemple, on évoque à ce jour des véhicules autonomes (Google Car) ou, plus concrètement, des véhicules semi-autonomes (sur le dernier km) capables de dialoguer avec un gestionnaire de parkings par exemple afin d'y trouver une place, de payer et d'y aller. Tout cela sans son conducteur.
On est très proche de cette implantation (5 ans).
Cela peut parfaitement se faire avec un véhicule actuel mais c'est plus facile avec un véhicule où l'intelligence est distribuée.
Ensuite observons les différences de ce point de vue entre une Telsa par exemple et une Renault ou une Peugeot
C'est une évolution inéluctable de pousser l'intelligence toujours plus loin dans les équipements.
Et oui, je suis d'accord, il y aura une partie d'objets connectés plus "commerciaux", gadgets bling bling, à destination notamment des particuliers (frigo connectés), qui nécessiteront une meilleure connectivité. De même que la gestion d'installations plus complexes (domotique, énergies renouvelables).
Quand je parle d'intelligence dans le cloud, je parle juste de serveurs. Que ces serveurs soient privés ou dans un "cloud public", peu importe, là n'est pas le débat.
5 ans seulement?
Ah, mince ! J'aurais du écrire au moins 5 ans
Il y a 18 ans, quand j'étais étudiant, je jouais déjà avec un automate industriel Schneider (pas un PC industriel, entendons nous bien) à base de 486SX, donc archi x86. Sans parler des PC104 de l'époque. Donc le x86 dans les automates, ça doit dater d'encore plus vieux que ça.
En effet, historiquement, dans les automates on a trouvé pas mal de proc Intel (des 80xx) puis on est passé au 6800x (Motorola). Y'a eu du Rockwell aussi.
Tout ça ce sont des microprocesseurs (4 bits, 8 bits, 16 bits puis 32 bits).
Il y a l'architecture PC/104 également effectivement.
Là je parle des années 70 et 80 (ces dernières pour le règne de Motorola).
L'intérêt du microcontrôleur c'est qu'il embarque tout (CPU, mémoire, stockage) en un seul SoC et qu'il coute moins cher qu'un proc.
Mais c'est comme tout. Si les fournisseurs de processeurs se mettent à filer des SoC (Intel, AMD, Broadcom, TI, etc), forcèment on en revient au processeur.
Je n'ai pas fait d'enquête (ce serait pertinent d'ailleurs) sur la part de SoC processeurs, de processeurs et de microcontrôleurs que l'on trouve dans les équipements industriels (automates et autres).
Instinctivement je pense que les microcontrôleurs sont plus répandus pour des raisons de coûts.
Mais je peux me tromper car ça dépend de l'âge.
Leon.
Merci Léon pour ces échanges.
db
Internet des objets