Internet des objets : l’essentiel sur Swim.ai

C’est en 2015 que Rusty Cumpston a créé, avec Chris Sachs et Rao Arimilli, Swim.ai, une jeune pousse spécialisée dans l’Internet des objets. Rusty Crumpston n’en était pas à ses premiers pas dans le domaine. En parallèle, il avait siégé au directoire de Secure Thingz, racheté depuis par IAR Systems. Mais déjà en 2010, il avait participé à la création de Sensity Systems, devenu fin 2016 Verizon Smart Communities.

C’est au moins d’avril que Swim.ai a recruté Simon Crosby, fondateur de Bromium et ancien directeur technique de Citrix, à l’occasion de la révélation publique de ses activités. Dans le cadre d’un entretien téléphonique avec la rédaction, il explique l’idée de base de la jeune pousse : « mettre en place une infrastructure en bordure capable d’informer de manière sémantiquement enrichie sur ce qui s’y passe et qui importe à l’opérateur ».

Ainsi, la plateforme EDX développée par Swim.ai construit dynamiquement des jumeaux numériques pour chaque entité physique de l’infrastructure, le tout selon un modèle d’acteurs distribué. Chaque jumeau reçoit des données de son pendant physique et en assure le traitement pour entraîner un modèle du comportement de l’ensemble du système considéré. De quoi permettre de prédire son comportement futur à partir d’un état considéré. Et le tout à très grande échelle.

Pour illustrer ce point, Simon Crosby prend l’exemple d’une extension Chrome développée pour « surveiller qui distribue des cookies à qui » : « nous avons construit, sur deux instances AWS, un modèle s’auto-entraînant en temps réel de plus de 300 millions de sites Web, avec leurs visiteurs et les cookies. Quand je parle d’échelle, je parle donc de grande échelle ». Une chose rendue possible par l’absence de base de données centralisée et par le recours au modèle d’acteurs distribué – « que l’on retrouve pour Erlang ou encore le projet Orleans », qui a notamment retenu l’attention d’Honeywell.

Ces jumeaux numériques ne se contentent pas d’une connaissance isolée de leur état et du passé de celui-ci. Simon Crosby prend ainsi l’exemple de la prédiction du trafic par le jumeau virtuel d’une intersection : « il est utile de savoir ce qui passe autour de cette intersection. Et nous avons réduit cette question à deux paramètres : le rayon à prendre en considération autour de l’intersection, et la quantité de données nécessaire à une prédiction efficace ». A travers cet exercice, il s’agit de permettre une coopération entre les jumeaux virtuels pour la résolution de vastes problèmes. Accessoirement, début avril, Swim.ai s’est associé à Trafficware pour lancer TidalWave, un service d’information trafic en temps réel aux Etats-Unis.

Simon Crosby revendique en outre une empreinte matérielle très réduite, avec des besoins en ressources de calcul hautement limités, du fait de la nature distribuée de l’architecture : « le modèle n’a besoin que de quelques cycles CPU, Arm ou x86, pour s’entraîner, à la périphérie. Et l’on y dispose de données bien plus contextualisées. […] Le modèle sans état cher au cloud et au Big Data n’est tout simplement pas adapté ces problèmes, basés sur des données à forte temporalité. L’entraînement de modèles de manière centralisée, dans le cloud, est très sensible à la sous ou sur-alimentation du modèle. Et en travaillant à l’extrémité, je gagne également en confidentialité ; les données utiles au modèle ne s’éloignent pas de son point d’application ». La pile logicielle à installer sur les systèmes de périphérie est finalement très légère : 2 Mo, rien de plus.

Plus loin, les systèmes connectés de périphérie devraient-ils réfléchir à leurs propres paramètres pour, le cas, échéant, les ajuster, les affiner, et gagner en efficacité par rapport à leur conception initiale ? D’une certaine façon, les équipes de Swim.ai avancent déjà dans cette direction. Ainsi, Simon Crosby relève que les modèles ne peuvent pas prédire ce qu’ils n’ont jamais vu. Dès lors, « nous donnons des cauchemars aux réseaux de neurones. Nous les faisons travailler sur des données fictives potentiellement utiles au traitement ultérieur de causalités ». En outre, il est possibilité d’utiliser les cycles CPU libres durant la nuit pour faire travailler les modèles, et éventuellement pré-établir des réponses à d’éventuelles situations futures : « il s’agit de leur poser des questions, comme ‘si cette entrée change, qu’est-ce que cela donne pour toi ?’ ».