Vor einigen Tagen las ich einen ausgezeichneten Artikel mit dem Titel „Das Manifest für Entwickler intelligenter Systeme: 15 Prinzipien“.

Ich beschloss, meine Gedanken über die darunter liegende Schicht zu teilen, nämlich die Grundprinzipien der Architektur, die im Wesentlichen den vorgeschlagenen Prinzipien entsprechen würden.

Aufgrund der Natur des Fastens wird es noch subjektiver sein als das Manifest.

Lassen Sie uns zunächst einige Begriffe behandeln, zum Beispiel den Entwickler und Benutzer intelligenter Systeme. Wer ist das und wo findet die Trennung statt?

Es gibt zwei offensichtliche Extreme: den Hersteller des gekauften Smart Switch und meine Frau, die das Licht anmacht. Aber zu wem nehme ich meinen oder meinen Sohn, der gelegentlich einen ESP32 nimmt und erhält, um ein Paar Sensoren, Tasten und andere LED-Streifen zu löten, die dann auch mit demselben Schalter interagieren?

Aber selbst wenn wir den Blick auf den Verkäufer richten, ist dies nicht ganz klar. Ich werde es erklären. Offensichtliches Extrem: Alle Geräte des gleichen Herstellers, der Hub ist auch sein, die Anwendung in seinen Smartphones ist der Entwickler eines intelligenten Systems. Was aber, wenn mehrere Anbieter im selben Netzwerk sind? Aber was ist, wenn der zentrale Hub eines, das Gerät eines anderen und die Cloud, mit der ich interagiere, beispielsweise Siri, überhaupt Apple ist? An welchen von ihnen ist das Manifest gerichtet, welcher von ihnen ist der gleiche Entwickler? Ich denke, dass ein tieferes Absinken unter die Ebene der globalen Abstraktionen des Manifests, die ich übrigens fast vollständig teile, eine tiefere funktionale Trennung einführen sollte, da sonst die kollektive Verantwortung für die Benutzererfahrung entweder zu der kollektiven Verantwortungslosigkeit führt, die wir jetzt bis zu dem einen oder anderen Grad beobachten. oder in einem starren Gehege von Ökosystemen mit Integration auf Benutzerebene: Wer von Ihnen hat mehr als eine Anwendung zum Verwalten eines Smart Homes auf Ihrem Telefon?

Ich schlage die folgende Trennung von Objekten vor: Endgeräte, Hubs, Gateways, Datenwolken, Integrationsdienste, Benutzeroberflächen.

Im Kontext dieser Objekte existieren Themen (wie Rollen), z. B. Benutzer, Customizer, Entwickler, Hersteller oder Lieferanten.

Zusammen bilden und bilden sie ein System, das durch den Datenaustausch seine Funktionen erfüllt.

In diesem Beitrag werde ich mich etwas genauer auf Objekte konzentrieren.

Endgeräte

Ja, und hier ist eine ziemlich lustige Frage. Was ist das Endgerät, das heißt das „Ding“ des Internet der Dinge?

Mit einem intelligenten Staubsauger ist alles klar: Sie zogen aus der Schachtel und steckten den Sockel in eine Steckdose, er entfernte ihn, machte eine Überlagerung von weißen Teppichen mit der freien Kreativität Ihrer Haustiere und ging aufladen. Aber schon mit einer Glühbirne ist es seltsamerweise nicht so einfach.

Jetzt betrachte ich meinen Kronleuchter mit mehreren Lampen, die ich mit 3 verschiedenen Schaltern einschalte (separat und nicht als Aktivierung von Atomsprengköpfen), tatsächlich funktioniert der Dimmer auf der DIN-Schiene im Panel. Hier meinen wir mit "Ding" den letzten Aktuator, aber das Lustige ist, dass dieser Dimmer mehrkanalig ist und ich mich nicht einmal daran erinnere, welchen der anderen Kronleuchter er ebenfalls steuert. Hier ist es also das Gerät, aber nicht alle, sondern nur ein Teil. Gleichzeitig ist der Satz der Frau "Mach das Licht an" intuitiv.

Ich rate den Lesern, das „Ding“ in einem anderen Bündel zu finden: einem Raumregler (Thermostat), der die Kühlerköpfe (Heizung) über 1 Kanal der 8-Kanal-PWM steuert, und der Kühlung über 1 der Kanäle 4 des Kanal-0-10-V-Aktuators, der bereits die Einstellung für den konstanten Verschluss festlegt Luftstrom im Kanal.

Ich hatte den Gedanken, in diesem Zusammenhang auf eine grausame Kanzlei zu stoßen und eine genaue Definition von „Dingen“ einzuführen, aber lassen Sie uns über die Endgeräte in Bezug auf ihre Funktion sprechen und wie viele von ihnen und wie sie interagieren, werden vorerst aus den Klammern herausgelassen.

Dann ist das intuitive „Erwärmen“ oder „Aktivieren des Sparmodus beim Verlassen“ ganz offensichtlich.

Hubs

In Anbetracht der bisherigen Überlegungen zu den Dingen sind Hubs im Wesentlichen eine Fabrik für noch virtuellere Dinge. Es ist die Nabe, die einen Thermostat erzeugen kann, wenn bereits Temperatursensoren und Köpfe an Heizkörpern vorhanden sind. Er kann ein Gerät "die ganze Welt" erstellen, das ausgeschaltet werden kann. Es ist lustig, aber der Hub kann absolut virtuell sein, zum Beispiel in EIB oder KNX. Das grundlegende Konzept ist eine Gruppenadresse: Der Sensor sendet Daten an ihn und der Aktor empfängt eine oder mehrere Gruppenadressen für jede Funktion. Wenn Sie also am Ausgang der Wohnung einen Schalter haben, der in einen 1/1/1 Zustand 0 sendet, und in jedem der Aktuatoren, die für das Licht verantwortlich sind, vorhanden ist (zusammen mit mehr Individuum, z. B. 1/0 /). 11, 1/0/12 usw.) Sie haben ein solches Gerät "die ganze Welt ausschalten" ohne zusätzliche physische Geräte.

In diesem Beispiel ist der Hub das Netzwerk selbst. In anderen Fällen existiert der Hub in der physischen Welt häufig als separates physisches Gerät. Sie können jedoch ein weiteres gutes Beispiel für einen "nicht sehr physischen" Hub nennen - dies ist Node-RED.

Ich bitte Sie, besonders darauf zu achten, dass ich absichtlich nicht sage, wie Datenströme von bereits vorhandenen Geräten in diesen Hub gelangen und wie sie von diesem zu anderen Teilen des Systems fließen. Andere Systemobjekte - Gateways - sind für diese Funktion verantwortlich.

Gateways

Es ist einfach so passiert, dass in den letzten 40-50 Jahren viele Netzwerke geschaffen wurden, die sich in Topologie und Abstraktionsebene (mit ihren eigenen Protokollen) unterscheiden und auf die eine oder andere Weise Teil des Internet der Dinge-Systems sein können. Um zwei Netzwerke zu verbinden, wird ein Verkehrsaustauschknoten erstellt. Wenn ein solcher Knoten alle Daten eines Protokolls in ein anderes packt, ist es üblich, ihn als Tunnel zu bezeichnen, da andererseits der gesamte Stream vollständig mit ihm arbeiten kann, als wäre er lokal, wenn ein Austausch erfolgt Abstraktionen, dann wird ein solcher Knoten als Gateway bezeichnet.

Da wir in diesem Beitrag die Terminologie ziemlich fließend beherrschen, verwenden wir den Begriff Gateway und verbringen etwas mehr Zeit damit, zu analysieren, von wo und wo tatsächlich vorhandene Geräte tatsächlich Gateway sind. Jeder, der früher oder später mit Prozessleitsystemen arbeitete, erweiterte die "zentralen" Netze um zusätzliche, zum Beispiel viele Zähler, die über Modbus mit Profibus verbunden waren.

Dies ist alles ein ziemlich ausgefeilter Fall, und Sie können nicht zu viel aufhören, aber wohin sperrt sich das Xiaomi Mijia Multifunctional Gateway? Ich möchte das von ZigBee zu Wi-Fi sagen, aber das ist nicht ganz richtig. Ja, auf einer Seite des Gateways befindet sich ein ZigBee-Netzwerk. Selbst wenn Sie ein Gerät eines Drittanbieters anschließen, können Sie es nicht über dieses Gateway erreichen. Auf der anderen Seite des Gateways befindet sich WLAN. Das Gateway bietet jedoch nicht nur die Kommunikation über das lokale Netzwerk über das Protokoll (das von den Hackern als miIO-Protokoll bezeichnet wurde), sondern auch über die Xiaomi-Cloud, die den Betrieb der Mi Home-Anwendung beim Verlassen des lokalen Netzwerks sicherstellt. Ein weiteres sehr interessantes Gateway ist Samsung SmartThings, aber es gibt Schwierigkeiten.

Wenn es vorher eine Frage gab, warum Groovy mit all seiner Vielfalt, würde ich jetzt die Schwierigkeit, Ausschreibungen durchzuführen, als Trübung bezeichnen.

Ich werde meine Position erklären, in der Hoffnung, dass ich mich irre. Wenn Sie ein neues Gerät erstellen, das mit dem Samsung SmartThings-Ökosystem kompatibel ist, können Sie zwei Optionen auswählen: Verbindung zu einem Hub herstellen oder direkt mit der Cloud. Wenn Sie eine Automatisierung erstellen möchten, die ich als das vom Hub oben generierte Gerät bezeichnet habe, wurde sie in die Cloud verschoben. Der Punkt. Das heißt, es liegt eine Verletzung des Manifests vor. Sie werden das Licht in der Toilette nicht einschalten, wenn das Internet für Sie nicht funktioniert, weder über die Anwendung (anscheinend gibt es lokal keine Hoffnungen mehr, basierend auf dem Diagramm im IoT- und Tizen IoT- Artikel), noch lokal über den Bewegungssensor eines anderen Netzwerks, da Sie das Gerät integrieren müssen und kein Netzwerk - sonst über die Cloud.

Diejenigen, die es geschafft haben, mit Tizen IoT zu arbeiten, korrigieren mich bitte.

Eine ähnliche Situation ist bei Logitech Harmony, bei dem die lokale Automatisierung nach dem Update unterbrochen wurde.

Wenn wir die Gateways vom Typ „Automatisierungsnetzwerk - Automatisierungsnetzwerk“ verwerfen, ist das Wichtigste beim Betrieb des Gateways die Zielabstraktion, in die die Darstellung von Geräten aus dem Kernnetzwerk übersetzt wird, und dies wird bereits durch Datenwolken bestimmt.

Datenwolken

Dies ist gleichzeitig das offensichtlichste und nicht offensichtlichste Objekt des Systems. Seine Funktionen und die Notwendigkeit dafür sind offensichtlich, aber wie genau diese Komponente implementiert ist, ist nur am wenigsten offensichtlich und hängt nicht von den Wünschen des Endbenutzers ab.

Deshalb fülle ich lieber diesen Teil meiner persönlichen Wunschliste und Gedanken aus.

Es ist gut, wenn es eine verständliche und einfache API gibt. Es ist sogar noch besser, wenn diese API geöffnet ist und es einfach ist, eine Verbindung zu ihr herzustellen.

Hier werde ich einen Vorbehalt zur Einfachheit machen. Einfachheit, wenn nicht von Mathematik gesprochen wird, ist im Prinzip subjektiv. Meine persönliche Meinung basiert auf meiner Erfahrung und meinen Wünschen. Für ein Unternehmen, das ein bestimmtes Produkt in Höhe von mehreren hunderttausend einfach auf den Markt bringen wird, ist die Einfachheit natürlich völlig anders.

Ich möchte, dass ich die Ergebnisse meines Hobbys in die Welt um mich herum einbinden kann. Was ist dafür erforderlich?

Die wichtigste einschränkende Ressource ist Zeit, die zweite ist Wissen, die dritte ist Geld. Wenn ich an einem Tag kein Gerät herstellen kann, das irgendwie über die Cloud funktioniert, wird dies "später" durchgeführt, sofern dies ein Synonym für "Mayy Chumorrow" und "Magnyana" ist. Wenn es irgendwie funktioniert, dann funktioniert es nach ein paar freien Tagen vielleicht so, wie es sollte. IoT ist interdisziplinärer Natur, und hier müssen Sie einen OAuth2-Server hochfahren, Zertifikate hinzufügen, die API implementieren und all dies geschieht, um meinen kleinen hausgemachten Mikrocontroller mit Sprachassistent zu erstellen, über den ich im nächsten Teil schreiben werde.

Frühere Gedanken waren mehr über "Wie?", Aber kein weniger wichtiges Problem (dies ist keine Herausforderung, nämlich das Problem) liegt in "Was?".

Ich würde alle Hauptdatenwolken, die für IoT verwendet werden können, in zwei Klassen unterteilen: Datenpunkte und Funktionen.

Wolke von Datenpunkten . Dies ist entweder eine parallele Entwicklung zur SCADA-Welt oder ein direkter Nachkomme.

Hier haben Sie die Messwerte des Temperatursensors - nun, schreiben wir ihn irgendwo in die Cloud, wo derjenige, der ihn lesen muss. Der Temperatursensor befindet sich an der Batterie, was bedeutet, dass Sie den Ladezustand noch beibehalten müssen - es spielt keine Rolle, siehe oben. Es gibt ganze Klassen von Wolken, mit denen Sie dies tun können. Sie können leicht erkannt werden, wenn das Hauptprotokoll MQTT ist (es kann jedoch sowohl CoAP als auch STOMP sein). Eine wunderbare Sache - ich selbst benutze sie und nicht nur im Internet der Dinge, sondern nenne sie den "Triumph der Freiheit über den gesunden Menschenverstand". Es ist nur so, dass die Protokolle so flexibel sind, dass jeder das gleiche Problem auf seine eigene Weise löst.

Eine Datenwolke in Form von Chancen . Ich gebe zu, vor ungefähr 8-9 Jahren, als ich die nächste Version meiner Heimplattform schrieb, wollte ich Objekte im System nehmen und klassifizieren. Damit das System versteht, dass dies eine Glühbirne ist, und dies ist ein Schalter, und dies ist ein Ventil. Die offensichtliche erste Iteration: eine Liste von Typen (aber tatsächlich Klassen, weil OOP gleich ist). Dann erscheint ein Schalter, aber auf der Batterie ist die Leistung von OOP in Aktion - also haben wir geerbt und einen neuen bekommen. Und dann stellte sich heraus, dass die Batterie alles sein könnte. Dann war es notwendig, nicht in einen Baum von Geräteklassen zu schneiden, sondern in die „Fähigkeiten“ von Geräten zu unterteilen, die wir kombinieren, um einen Schalter zu erhalten.

So funktionieren Apple HomeKit, Alexa, Google und andere Cloud-Ökosysteme von Smart Homes. Es scheint, dass es Glück ist.

Aber wie ich oben sagte, habe ich diesen Ansatz vor 8-9 Jahren verwendet. Und ich habe genau diese Funktionen selbst festgelegt. Ich wollte eine IP-Kamera oder eine Asterisk-Telefonanlage hinzufügen. Großartig. Ich bin fertig und arbeite.

Aber hier ist das Unglück: Die oben aufgeführten Cloud-Ökosysteme von Smart Homes sind eigentlich Ökosysteme nicht des IoT, sondern Ökosysteme von Sprachassistenten, deren Funktionen für die ganze Welt und für alle Geräte universell sein sollten. Das Hinzufügen neuer Funktionen zum Prozess unterscheidet sich erheblich von meinem "Angehängt und funktioniert". Wir alle erinnern uns, wie diese Ökosysteme zu Beginn "das Tor einschalten" mussten. Ähnlich ist die Situation bei SmartThings.

Kein Hersteller kann eine klare, vollständige Liste der Funktionen für Geräte bereitstellen, die freigegeben werden und Teil des IoT-Ökosystems werden können. Deshalb können Systeme wie der Prozentsatz an viszeralem Fett, Blutzucker oder Aceton nicht wissen, was? Warum kann das Haus Sie nicht mit freudigen Illusionen unterstützen, wenn alles in Ordnung ist, oder Ihre Aufmerksamkeit auf sich ziehen, wenn etwas schief gelaufen ist?

Auf der anderen Seite, wie man Benutzeroberflächen erstellt, ohne zu verstehen, was ein Gerät kann? Der Datenpunktansatz in SCADA war praktisch, um topologische und Protokollmerkmale zu verbergen. Abrufen von Daten (horizontale Liste) mit einigen zusätzlichen Eigenschaften, z. B. Zuverlässigkeit (unabhängig davon, ob auf dem Weg eine Unterbrechung aufgetreten ist) oder Zugriffsebenen. Die Hauptdarstellung erfolgte jedoch in Form von Mnemonikdiagrammen.

IoT-Benutzer leben jedoch in der Post-PC-Ära, und Gedächtnisschaltungen sind auf Telefonbildschirmen unpraktisch, und ihre Einrichtung ist unverzeihlich lang.

Ich denke, dass es eine gewisse Hybridisierung geben sollte. Erstens muss das System wissen, was das Gerät ist, und es muss Datenpunkte haben. Nicht weniger wichtig ist jedoch, dass es auch zusätzliche Metainformationen gibt, die an eine spezialisierte Cloud geliefert werden sollten, z. B. Ihren bevorzugten Sprachassistenten. Zu diesen Informationen können insbesondere sowohl das Profil (Satz von Funktionen) des Geräts zum Verständnis der externen Cloud als auch deren Kennungen gehören.

Die Funktion des Geräteherstellers besteht darin, unter anderem die gewünschten Ansichten für dieses Produkt sowohl für visuelle Schnittstellen als auch für andere Typen zu beschreiben: Sprachinteraktion, AR / VR und dergleichen. Aber selbst wenn der Hersteller dies nicht tat, widerstrebend und von Faulheit überwältigt, kann der Nutzer dennoch auswählen, was dieses Google-Gerät von nun an als „Smart Home Kettle“ bezeichnen kann, und verfügt nun über folgende Funktionen: TemperatureControl, OnOff, Modes und Schaltet um Ja, ich habe action.devices.traits aus Gründen der Kompaktheit gelöscht.

Das soll sicherstellen, dass die Interoperabilität bereits Integrationsdienste sollte.

Integration Services

Dies ist das gleiche Gateway, aber zwischen den Wolken. Einige Abstraktionen sollten durch andere ersetzt werden.

Die Basis der Interaktion ist ein Ereignis. Es gibt sowohl Abfragemodelle als auch Veröffentlichungen. Das Thema ist so umfangreich, dass Sie bei der Beschreibung in die Bollywood-Falle tappen können. Wie Sie wissen, werden dort pro Jahr mehr Filme produziert, als eine Person physisch sehen kann.
Daher werde ich am Ende des Artikels noch weiter von der Realität entfernt sein als zu dem Zeitpunkt, an dem die Beschreibung beginnt.

Ich habe bereits viele Haushaltssysteme erwähnt. Sie können LoRaWAN (und TheThingsNetwork), IFTTT, OpenStreetMap, AWS IoT, Azure IoT, Wetterdienste, ja, fast jeden Internet- oder Intranetdienst (gibt es einen anderen Begriff?) Abrufen, wenn die Gerätedaten muss in Unternehmenssysteme gelangen.

Benutzeroberflächen

Ich werde diesen Teil nicht ausführlich beschreiben, aber ich möchte über die meiner Meinung nach unverdiente Umgehung von IoT-Systemen und Desktops im Haushalt klagen. Erst in Mojave kam endlich HomeKit heraus - für mich ist das verwirrend. Warum ist der Wasserkocher komplizierter als Tabellenkalkulationen, in denen ich den Cashflow eines Unternehmens berechnen kann? Mit Numbers kann ich zwar in einem Browser arbeiten, muss aber nach dem Verständnis von Apple kein vergessenes Bügeleisen ausschalten. Kurz gesagt, geben Sie PWA!

Benutzeroberflächen sind in erster Linie bequeme physische Schalter, aber es gibt unverzeihlich wenige.

AR, VR, Mixed Reality, Sprachassistenten, Smart-TVs, Anwendungen für Smartphones und Tablets sowie neuronale EEG-Schnittstellen sind Kirschen auf dem Kuchen, mit denen wir Geeks sehr viel Spaß haben.

Nachwort

Es scheint, was haben Docker und Microservices damit zu tun? Wenn es für die Leser interessant sein wird, teile ich gerne meine Gedanken und Entwicklungen bei der Implementierung der Architektur des IoT-Systems auf der Grundlage dieser Klassifizierung von Objekten.

Ich benutze es selbst.