Il y a quelques jours, j'ai lu un excellent article, "Le manifeste des développeurs de systèmes intelligents: 15 principes"

J'ai décidé de partager mes réflexions sur la couche ci-dessous, à savoir les principes de base de l'architecture, qui correspondraient essentiellement aux principes proposés.

En raison de la nature du jeûne, il sera encore plus subjectif que le Manifeste.

Tout d'abord, examinons plusieurs termes, par exemple, le développeur et l'utilisateur de systèmes intelligents. Qui est-ce et où a lieu la séparation?

Il y a 2 extrêmes évidents: le fabricant de l'interrupteur intelligent acheté et ma femme, qui allume la lumière. Mais à qui dois-je emmener mon ou mon fils, qui prend occasionnellement et obtient un ESP32 pour souder une paire de capteurs, boutons et autres bandes LED, qui interagissent également avec le même interrupteur?

Mais même si nous tournons nos yeux vers le vendeur, ce n'est pas tout à fait clair. Je vais vous expliquer. Extrême évident: tous les appareils d'un même fabricant, le hub est aussi le sien, l'application dans ses smartphones est le développeur d'un système intelligent. Mais que se passe-t-il si plusieurs fournisseurs sur le même réseau? Mais que se passe-t-il si Apple est le hub central de l'un, l'appareil d'un autre et le cloud avec lequel j'interagis, disons Siri? À qui s'adresse le Manifeste, lequel est le même développeur? Je pense qu'en descendant un peu en dessous du niveau des abstractions globales du Manifeste, que je partage d'ailleurs presque complètement, une séparation fonctionnelle plus profonde devrait être introduite, sinon la responsabilité collective de l'expérience utilisateur entraînera soit l'irresponsabilité collective que nous observons à un degré ou un autre, ou dans une enceinte rigide d'écosystèmes avec intégration au niveau de l'utilisateur: lequel d'entre vous a plus d'une application pour gérer une maison intelligente sur son téléphone?

Je propose la séparation d'objets suivante: terminaux, hubs, passerelles, clouds de données, services d'intégration, interfaces utilisateurs.

Les sujets (comme les rôles), par exemple, les utilisateurs, les personnalisateurs, les développeurs, les fabricants ou les fournisseurs, existent dans le contexte de ces objets.

Ensemble, ils créent et constituent un système qui, par l'échange de données, remplit ses fonctions.

Dans un peu plus de détails dans ce post, je me concentrerai uniquement sur les objets.

Appareils terminaux

Oui, et voici une question plutôt amusante. Quel est l'appareil final, c'est-à-dire la «chose» même de l'Internet des objets?

Avec un aspirateur intelligent, tout est clair: ils sont sortis de la boîte et ont branché sa base dans une prise de courant, il s'est habillé, est parti et a fait une superposition de tapis blancs avec la créativité gratuite de vos animaux de compagnie et est allé charger. Mais déjà avec une ampoule, curieusement, ce n'est pas si simple.

Maintenant, je regarde mon lustre avec plusieurs lampes, que j'allume avec 3 interrupteurs différents (séparément, et non comme l'activation d'ogives nucléaires), en fait, le gradateur sur le rail DIN dans le panneau fonctionne. Ici, par "chose", il semblerait, nous entendons l'actionneur final, mais ce qui est drôle, c'est que ce gradateur est multicanal et je ne me souviens même pas lequel des autres lustres il contrôle également, donc ici c'est l'appareil, mais pas tous, mais seulement une partie. Mais en même temps, la phrase de la femme «allumer la lumière» est intuitive.

Je conseille aux lecteurs de trouver la «chose» dans un autre bundle: un contrôleur d'ambiance (thermostat), qui contrôle les têtes de radiateur (chauffage) via 1 canal du PWM 8 canaux, et le refroidissement via 1 des canaux 4 de l'actionneur 0-10V du canal, qui définit déjà le réglage de l'obturateur constant circulation d'air dans le conduit.

J'ai eu l'idée de me heurter à un bureau de bureau brutal et d'introduire une définition exacte des «choses» dans ce contexte, mais parlons des appareils finaux en termes de leur fonction , et combien d'entre eux et comment ils interagissent seront laissés de côté pour l'instant.

Ensuite, l'intuition «réchauffer» ou «activer le mode économie lorsque nous partons» est assez évidente.

Hubs

Au vu des réflexions précédentes sur ce que sont les choses, les hubs sont essentiellement une usine de choses encore plus virtuelles. C'est le hub qui peut créer un thermostat quand il y a déjà des capteurs de température et des têtes sur les radiateurs. Il peut créer un appareil "tout le monde", qui peut être éteint. C'est drôle, mais le hub peut être absolument virtuel, par exemple, en EIB ou KNX, le concept fondamental est une adresse de groupe: le capteur lui envoie des données et l'actionneur reçoit une ou plusieurs adresses de groupe pour chaque fonction. Ainsi, si à la sortie de l'appartement, vous avez un interrupteur qui envoie à un état 1/1/1 0, et dans chacun des actionneurs responsables de la lumière, il est présent (avec plus individuel, disons, 1/0 / 11, 1/0/12, etc.) vous aurez un tel appareil "éteignez le monde entier" sans appareils physiques supplémentaires.

Dans cet exemple, le concentrateur est le réseau lui-même, dans d'autres cas, le concentrateur existe souvent dans le monde physique en tant que périphérique physique séparé, mais vous pouvez donner un autre bon exemple de concentrateur "pas très physique" - c'est Node-RED.

Je vous demande de prêter une attention particulière au fait que je ne dis pas intentionnellement comment les flux de données provenant d'appareils déjà existants entrent dans ce hub même et comment ils en découlent vers d'autres parties du système. D'autres objets système - passerelles - sont responsables de cette fonction.

Passerelles

Il se trouve que, au cours des 40 à 50 dernières années, de nombreux réseaux avec différentes topologies et niveaux d'abstraction (avec leurs propres protocoles) ont été créés et peuvent en quelque sorte faire partie du système Internet des objets. Pour connecter 2 réseaux, un nœud d'échange de trafic est créé, si un tel nœud emballe toutes les données d'un protocole dans un autre, il est habituel de l'appeler un tunnel, car d'autre part vous pouvez complètement faire fonctionner le flux entier avec lui comme s'il était local, si le remplacement se produit abstractions, alors un tel nœud est appelé une passerelle.

Étant donné que nous parlons couramment la terminologie dans cet article, utilisons le terme passerelle et passons un peu plus de temps à analyser d'où et où les périphériques existants sont réellement des passerelles. Tous ceux qui travaillaient avec des systèmes de contrôle de processus ont tôt ou tard élargi les réseaux "centraux" avec des réseaux supplémentaires, par exemple, de nombreux compteurs étaient connectés à Profibus sur Modbus.

Tout cela est un cas assez élaboré et vous ne pouvez pas trop vous arrêter, mais où se verrouille la passerelle multifonctionnelle Xiaomi Mijia? Je voudrais dire cela de ZigBee au Wi-Fi, mais ce n'est pas tout à fait vrai. Oui, d'un côté de la passerelle se trouve un réseau ZigBee, mais même si vous connectez un appareil tiers, vous ne pourrez pas y accéder via cette passerelle. Il y a du Wi-Fi de l'autre côté de la passerelle, mais la passerelle fournit non seulement la communication sur le réseau local via le protocole (qui a été appelé protocole miIO par les pirates), mais aussi avec le cloud Xiaomi, qui garantit le fonctionnement de l'application Mi Home lorsque vous quittez le réseau local. Une autre passerelle très intéressante est Samsung SmartThings, mais il y a des difficultés.

Si auparavant il y avait une question pourquoi Groovy avec toute sa diversité, maintenant j'appellerais la difficulté de soumissionner à la nébulosité.

Je vais expliquer ma position, en espérant que je me trompe. Lors de la création d'un nouvel appareil compatible avec l'écosystème Samsung SmartThings, vous pouvez choisir 2 options: vous connecter à un concentrateur, ou directement au cloud, si vous souhaitez créer une automatisation, celle que j'ai nommée ci-dessus comme périphérique généré par le concentrateur, elle s'est déplacée vers le cloud. Le point. Autrement dit, il y a une violation du Manifeste. Vous n'allumerez pas la lumière dans les toilettes si Internet ne fonctionne pas pour vous, que ce soit via l'application (apparemment, il n'y a plus d'espoir localement, sur la base du schéma de l'article IoT et Tizen IoT ), ni localement depuis le capteur de mouvement d'un autre réseau, car vous devez intégrer l'appareil et non un réseau - sinon à travers le cloud.

Ceux qui ont réussi à travailler avec Tizen IoT, corrigez-moi, s'il vous plaît.

Une situation similaire se produit avec Logitech Harmony, qui a interrompu l'automatisation locale après la mise à jour.

Si nous éliminons les passerelles du type «réseau d'automatisation - réseau d'automatisation», la chose la plus importante dans le fonctionnement de la passerelle est l'abstraction cible, dans laquelle elle traduit la présentation des appareils du réseau central, et cela est déjà déterminé par les nuages ​​de données.

Nuages ​​de données

C'est à la fois l'objet le plus évident et le moins évident du système. Ses fonctions et son besoin sont évidents, mais la façon dont ce composant est implémenté est tout simplement la moins évidente et ne dépend pas des désirs de l'utilisateur final.

Par conséquent, je remplis plutôt cette partie de ma liste de souhaits et de mes pensées personnelles.

C'est bien quand il y a une API compréhensible et simple, c'est encore mieux quand cette API est ouverte et il est facile de s'y connecter.

Ici, je ferai une réserve sur la simplicité. La simplicité, pour ne pas parler des mathématiques, est en principe subjective. Mon opinion personnelle est basée sur mon expérience et mes envies. Bien sûr, pour une entreprise qui va lancer un certain produit à hauteur de plusieurs centaines de milliers, la simplicité est complètement différente.

Je veux que je puisse tisser les résultats de mon passe-temps dans le monde qui m'entoure. Que faut-il pour cela?

La principale ressource limitante est le temps, la seconde est la connaissance, la troisième est l'argent. Si je ne peux pas créer un appareil qui fonctionne d'une manière ou d'une autre à travers le cloud en une seule journée, alors cela sera fait «plus tard», tant qu'il est synonyme de «Mayy Chumorrow» et «Magnyana». Maintenant, si cela fonctionne d'une manière ou d'une autre, après quelques jours de repos, cela fonctionnera peut-être comme il se doit. L'IoT est de nature interdisciplinaire, et ici vous devez augmenter un serveur OAuth2, y ajouter des certificats, implémenter l'API, et tout cela est fait pour fabriquer mon petit microcontrôleur fait maison avec assistant vocal, dont je parlerai dans la partie suivante.

Les pensées précédentes portaient davantage sur «Comment?», Mais un problème non moins important (ce n'est pas un défi, à savoir le problème) réside dans «Quoi?».

Je diviserais tous les principaux nuages ​​de données qui peuvent être utilisés pour l'IoT en deux classes: les points de données et les capacités.

Nuage de points de données . Il s'agit soit d'une évolution parallèle avec le monde SCADA, soit d'un descendant direct.

Ici, vous avez les lectures du capteur de température - eh bien, écrivons-le quelque part dans le nuage, où celui qui a besoin de le lire. Le capteur de température se trouve sur la batterie, ce qui signifie que vous devez toujours maintenir le niveau de charge - peu importe, voir ci-dessus. Il existe des classes entières de nuages ​​qui vous permettent de le faire. Ils peuvent être facilement reconnus si le protocole principal est MQTT (mais il peut être à la fois CoAP et STOMP). Une chose merveilleuse - je l'utilise moi-même et pas seulement dans l'IoT, le qualifiant de "triomphe de la liberté sur le bon sens". C'est juste que les protocoles sont si flexibles que chacun résout le même problème à sa manière.

Un nuage de données sous forme d'opportunités . J'avoue, il y a environ 8 à 9 ans, lorsque j'écrivais la prochaine version de ma plate-forme domestique, je voulais prendre et classer des objets dans le système. Pour que le système comprenne que c'est une ampoule, et ceci est un interrupteur, et ceci est une valve. La première itération évidente: une liste de types (mais en fait des classes, car la POO est la même). Ensuite, un interrupteur apparaît, mais sur la batterie, la puissance de la POO est en action - nous avons donc hérité et obtenu un nouveau. Et puis il s'est avéré que la batterie pouvait être n'importe quoi. Ensuite, il a fallu couper non pas dans une arborescence de classes de périphériques, mais se diviser en "capacités" de périphériques, combinant ce que nous obtenons un commutateur.

C'est ainsi que fonctionnent Apple HomeKit, Alexa, Google et d'autres écosystèmes cloud des maisons intelligentes. Il semblerait que ce soit le bonheur.

Mais, comme je l'ai dit plus haut, j'ai utilisé cette approche il y a 8-9 ans. Et j'ai déterminé ces fonctionnalités moi-même, je voulais ajouter une caméra IP ou un PBX Asterisk? Super. J'ai fini et travaille.

Mais voici le malheur, les écosystèmes cloud des maisons intelligentes énumérés ci-dessus sont en fait des écosystèmes non pas de l'IoT, mais des écosystèmes d'assistants vocaux, dont les capacités devraient être universelles pour le monde entier et pour tous les appareils. L'ajout de nouvelles fonctionnalités au processus est très différent de mon "Ajout et fonctionne". Nous nous souvenons tous comment, à l'aube de ces écosystèmes, il a fallu "ouvrir la porte". La situation est similaire avec SmartThings.

Aucun fabricant ne peut fournir une liste claire et exhaustive des capacités des appareils pouvant être commercialisés et intégrés à l'écosystème IoT. C'est pourquoi des systèmes tels que le pourcentage de graisse viscérale, de sucre dans le sang ou d'acétone n'ont pas la capacité de savoir quoi? Pourquoi la maison ne peut-elle pas vous soutenir avec des illusions joyeuses quand tout va bien ou attirer votre attention quand quelque chose a mal tourné?

D'un autre côté, comment créer des interfaces utilisateur sans comprendre ce qu'un appareil peut faire? L'approche par points de données dans SCADA était pratique pour masquer les caractéristiques topologiques et protocolaires. Obtenez des données (liste horizontale) avec quelques propriétés supplémentaires, par exemple, la fiabilité (s'il y avait une déconnexion en cours de route) ou les niveaux d'accès, mais leur présentation principale était sous la forme de diagrammes mnémoniques.

Mais les utilisateurs de l'IoT vivent à l'ère Post-PC et les circuits mnémoniques ne sont pas pratiques sur les écrans de téléphone, et leur configuration est impardonnablement longue.

Je pense qu'il devrait y avoir une certaine hybridation. Tout d'abord, le système doit savoir ce qu'est le périphérique et il doit avoir des points de données. Cependant, il n'est pas moins important qu'il y ait également des méta-informations supplémentaires qui devraient être fournies à un cloud spécialisé, par exemple, votre assistant vocal préféré. Ces informations, en particulier, peuvent inclure à la fois le profil (ensemble de capacités) de l'appareil, dans la compréhension du cloud externe, et ses identifiants.

La fonction du fabricant de l'appareil sera de décrire, entre autres, les vues souhaitées pour ce produit, à la fois pour les interfaces visuelles et pour d'autres types: interaction vocale, AR / VR, etc. Mais, même si le fabricant ne l'a pas fait, à contrecœur et submergé par la paresse, l'utilisateur peut toujours choisir ce que cet appareil Google peut désormais appeler «Smart Home Kettle» et il dispose désormais de telles fonctionnalités: TemperatureControl, OnOff, Modes et Bascule Oui, j'ai abandonné action.devices.traits pour plus de compacité.

C'est pour assurer l'interopérabilité devrait déjà les services d'intégration.

Services d'intégration

Il s'agit de la même passerelle, mais entre les nuages. Certaines abstractions doivent être remplacées par d'autres.

La base de l'interaction est un événement. Il existe à la fois des modèles de requête et des publications. Le sujet est si vaste que vous pouvez tomber dans le piège de Bollywood en le décrivant. Là, comme vous le savez, plus de films sont produits par an que physiquement une personne peut regarder,
par conséquent, à la fin de l'article, je serai encore plus éloigné de la réalité qu'au moment où la description commence.

J'ai déjà mentionné de nombreux systèmes domestiques, vous pouvez vous rappeler LoRaWAN (et TheThingsNetwork), IFTTT, OpenStreetMap, AWS IoT, Azure IoT, les services météorologiques, oui, en fait, presque tous les services Internet ou Intranet (existe-t-il un autre terme?), Si les données de l'appareil doit entrer dans les systèmes d'entreprise.

Interfaces utilisateurs

Je ne décrirai pas profondément cette partie, mais je veux déplorer, à mon avis, à tort, contourné par les systèmes IoT domestiques, les ordinateurs de bureau. Seulement dans Mojave HomeKit est finalement sorti - pour moi, c'est déconcertant. Pourquoi la bouilloire est-elle plus compliquée que les feuilles de calcul dans lesquelles je peux calculer les flux de trésorerie d'une entreprise? Après tout, avec Numbers, je peux travailler dans un navigateur, mais je n'ai pas à éteindre un fer oublié, dans la compréhension d'Apple. En bref, donnez PWA!

Les interfaces utilisateur sont principalement des commutateurs physiques pratiques, mais elles sont peu nombreuses.

AR, VR, réalité mixte, assistants vocaux, téléviseurs intelligents, applications pour smartphones et tablettes, les interfaces neuronales EEG sont les cerises sur le gâteau, avec lesquelles nous, les geeks, sommes très amusants à jouer.

Postface

Il semblerait, qu'est-ce que Docker et les microservices ont à voir avec cela? Si cela peut intéresser les lecteurs, je partagerai volontiers mes réflexions et développements dans la mise en œuvre de l'architecture du système IoT basée sur cette classification des objets.

Je l'utilise moi-même.