Eine Taxonomie für das IIoT

Könige spielen Schach auf edlen Glashockern. Erinnert sich noch jemand daran?

Für die meisten ist das wahrscheinlich Kauderwelsch. Aber nicht für mich. Diese Gedächtnisstütze hilft mir, mich an die Taxonomie des Lebens zu erinnern:Königreich, Stamm, Klasse, Ordnung, Familie, Gattung, Art.

Die Breite und Tiefe und Vielfalt des Lebens auf der Erde ist überwältigend. Eine Taxonomie unterteilt Systemtypen logisch nach ihren Eigenschaften. Die Wissenschaft der Biologie wäre ohne eine gute Taxonomie unmöglich. Es ermöglicht Wissenschaftlern, Pflanzen und Tiere in logische Typen zu klassifizieren, Gemeinsamkeiten zu identifizieren und Regeln zum Verständnis ganzer Klassen lebender Systeme aufzustellen.

Auch die Breite und Tiefe und Vielfalt des Industrial Internet of Things (IIoT) ist überwältigend. Die Wissenschaft der IIoT-Systeme benötigt eine ähnlich organisierte Taxonomie von Anwendungstypen. Erst dann können wir über geeignete Architekturen und Technologien zur Implementierung von Systemen diskutieren.

Das erste Problem besteht darin, Abteilungen auf höchster Ebene zu wählen. Im Tierreich können Sie die meisten Tiere entweder als "Land-, See- oder Lufttiere" bezeichnen. Diese Umgebungsbeschreibungen helfen jedoch nicht viel beim Verständnis des Tieres. Die „Architektur“ eines Wals ist nicht viel wie ein Oktopus, aber sehr wie ein Bär. Um verstanden zu werden, müssen Tiere nach ihren Eigenschaften und ihrer Architektur unterteilt werden.

Es ist auch nicht sinnvoll, Anwendungen nach Branchen wie „Medizin, Transport und Energie“ zu unterteilen. Obwohl diese Umgebungen wichtig sind, lassen sich die anwendbaren Architekturen und Technologien einfach nicht entlang der Branchengrenzen aufteilen. Auch hier brauchen wir ein tieferes Verständnis der Eigenschaften, die die größten Herausforderungen definieren, und diese Herausforderungen werden die Architektur bestimmen.

Mir ist klar, dass dies eine mächtige, sogar schockierende Behauptung ist. Dies impliziert zum Beispiel, dass die maßgeschneiderten Standards, Protokolle und Architekturen in jeder Branche keine nützlichen Wege sind, um die zukünftigen Architekturen von IIoT-Systemen zu entwerfen . Nichtsdestotrotz ist dies eine klare Tatsache der Systeme im Feld. Wie bei der Transformation, die zum Enterprise Internet wurde, werden generische Technologien spezielle Ansätze ersetzen. Um unser Verständnis zu erweitern und das Versprechen des IIoT zu verwirklichen, müssen wir unser altes branchenspezifisches Denken aufgeben.

Was können wir also für Divisionen verwenden? Welche definierenden Merkmale können wir verwenden, um die Säugetiere von den Reptilien von den Insekten des IIoT zu trennen?

Es gibt Tausende und Abertausende von Anforderungen, sowohl funktionale als auch nicht-funktionale, die verwendet werden könnten. Wie bei Tieren müssen wir diese wenigen Anforderungen finden, die den Raum in nützliche Hauptkategorien einteilen.

Die Aufgabe wird durch die Erkenntnis vereinfacht, dass das Ziel darin besteht, den Raum aufzuteilen, damit wir die Systemarchitektur bestimmen können . Somit sind gute Aufteilungskriterien a) eindeutig und b) architekturwirksam. Das mag einfach klingen, ist aber eigentlich nicht trivial. Der einzige Weg, dies zu tun, ist durch Erfahrung. Wir sind früh auf unserer Suche. Allerdings sind bedeutende Fortschritte in unserer gemeinsamen Reichweite.

Ausgehend von der umfangreichen Erfahrung von RTI mit fast 1000 realen IIoT-Anwendungen schlage ich im Folgenden einige frühe Unterteilungen vor. Um so knackig wie möglich zu sein, habe ich auch „Metriken“ für jede Abteilung gewählt. Die Linien sind natürlich nicht so scharf. Aber die Zahlen erzwingen Klarheit, und das ist entscheidend; ohne numerische Maßstäbe (Meterstöcke?), geht die Bedeutung zu oft verloren.

IIoT-Taxonomievorschlag

Zuverlässigkeit [Messwert:Kontinuierliche Verfügbarkeit muss besser als "99,999 %" sein]

Mit der Plattitüde „sehr zuverlässig“ können wir uns nicht zufrieden geben. Fast alles „braucht“ das. Um aussagekräftig zu sein, müssen wir die architektonischen Anforderungen genauer festlegen, um diese Zuverlässigkeit zu erreichen. Das erfordert ein Verständnis dafür, wie schnell ein Fehler Probleme verursacht und wie schlimm diese Probleme sind.

Wir haben festgestellt, dass die einfachste und nützlichste Methode zur Kategorisierung der Zuverlässigkeit darin besteht, sich zu fragen:„Was sind die Folgen eines unerwarteten Ausfalls für 5 Minuten pro Jahr?“ (Wir wählen hier nur 5 min/Jahr, weil dies die goldene „5-9s“-Spezifikation für Server der Enterprise-Klasse ist. Viele Industriesysteme tolerieren nicht einmal ein paar Millisekunden unerwarteter Ausfallzeiten.)

Dies ist ein wichtiges Merkmal, da es die Systemarchitektur stark beeinflusst. Ein System, das auch für kurze Zeit nicht ausfallen kann, muss redundante Computer, Sensoren, Netzwerke und mehr unterstützen. Wenn Zuverlässigkeit wirklich entscheidend ist, wird sie schnell zu einem – oder vielleicht – wichtigsten Architekturtreiber.

Echtzeit [Metrik:Antwort <100ms]

Es gibt Tausende von Möglichkeiten, „Echtzeit“ zu charakterisieren. Alle Systeme sollten „schnell“ sein. Um jedoch nützlich zu sein, müssen wir genau verstehen, welche Geschwindigkeitsanforderungen die Architektur antreiben.

Eine Architektur, die einen menschlichen Benutzer zufrieden stellen kann, der nicht bereit ist, länger als 8 Sekunden auf eine Website zu warten, wird niemals eine industrielle Steuerung erfüllen, die in 2 ms reagieren muss. Wir finden, dass das „Knie in der Kurve“, das das Design stark beeinflusst, auftritt, wenn die Reaktionsgeschwindigkeit in einigen zehn Millisekunden (ms) oder sogar Mikrosekunden (µs) gemessen wird. Wir werden 100 ms wählen, einfach weil es sich um den potenziellen Jitter (maximale Latenz) handelt, der von einem Server oder Broker im Datenpfad verursacht wird. Systeme, die viel schneller reagieren, müssen normalerweise Peer-to-Peer sein, und das ist eine enorme Auswirkung auf die Architektur.

Datensatzskalierung [Metrik:Datensatzgröße> 10.000 Elemente]

Auch hier sind Tausende von Dimensionen zu skalieren, darunter die Anzahl der „Knoten“, die Anzahl der Anwendungen, die Anzahl der Datenelemente und mehr. Wir können den Raum nicht durch all diese Parameter teilen. In der Praxis hängen sie zusammen. Zum Beispiel hat ein System mit vielen Datenelementen wahrscheinlich viele Knoten.

Trotz des weiten Raums haben wir festgestellt, dass zwei einfache Fragen mit architektonischen Anforderungen korrelieren. Die erste ist „Datensatzgröße“, und das Knie in der Kurve umfasst etwa 10.000 Elemente. Wenn Systeme so groß werden, ist es nicht mehr praktikabel, jedes Datenupdate an jeden möglichen Empfänger zu senden. Daher wird die Verwaltung der Daten selbst zu einem wichtigen Architekturerfordernis. Diese Systeme benötigen ein „datenzentriertes“ Design, das die Daten explizit modelliert und dadurch eine selektive Filterung und Bereitstellung ermöglicht.

Team- oder Anwendungsskala [Messwert:Anzahl der Teams oder interagierenden Anwendungen>10]

Der zweite von uns gewählte Skalenparameter ist die Anzahl der Teams oder unabhängig entwickelten Anwendungen im „Projekt“, mit einem Breakpoint um 10. Wenn viele unabhängige Gruppen von Entwicklern Anwendungen erstellen, die interagieren müssen, dominiert die Datenschnittstellensteuerung die Interoperabilitätsherausforderung. Auch dies weist häufig auf die Notwendigkeit eines datenzentrierten Designs hin, das diese Schnittstellen explizit modelliert und verwaltet.

Device Data Discovery Challenge [Metrik:>20 Gerätetypen mit Datensätzen mit mehreren Variablen]

Einige IIoT-Systeme können (oder müssen sogar) vor der Laufzeit konfiguriert und verstanden werden. Dies bedeutet nicht, dass jede Datenquelle und -senke bekannt ist, sondern nur, dass diese Konfiguration relativ statisch ist.

Wenn IIoT-Systeme jedoch Racks und Racks von Maschinen oder Geräten integrieren, müssen diese oft im laufenden Betrieb konfiguriert und verstanden werden. Beispielsweise muss eine HMI einer Anlagensteuerung möglicherweise die Geräteeigenschaften eines installierten Geräts oder Racks ermitteln, damit ein Benutzer die zu überwachenden Daten auswählen kann. Die Auswahl von „20“ verschiedenen Geräten ist willkürlich. Der Punkt:Bei vielen unterschiedlichen Konfigurationen der Geräte in einem Rack wird diese „Selbstbeobachtung“ zu einem wichtigen architektonischen Bedürfnis, um manuelle Gymnastik zu vermeiden. Die meisten Systeme mit dieser Eigenschaft haben weit mehr als 20 Gerätetypen.

Vertriebsfokus [Messwert:Auffächern> 10]

„Fan-Out“ definieren wir als die Anzahl der Datenempfänger, die bei Änderung eines einzelnen Datenelements informiert werden müssen. Dies wirkt sich auf die Architektur aus, da viele Protokolle über einzelne 1:1-Verbindungen funktionieren. Der Großteil der Unternehmenswelt arbeitet auf diese Weise, oft mit TCP, einem 1:1-Sitzungsprotokoll. Beispiele hierfür sind die Verbindung eines Browsers mit einem Webserver, einer Telefon-App mit einem Back-End oder einer Bank mit einem Kreditkartenunternehmen.

Allerdings müssen IIoT-Systeme oft Informationen an viel mehr Ziele verteilen. Wenn ein einzelnes Datenelement zu vielen Zielen gehen muss, muss die Architektur mehrere effiziente Aktualisierungen unterstützen. Wenn die Auffächerung 10 oder mehr überschreitet, wird es unpraktisch, diese Verzweigung durch die Verwaltung einer Reihe von 1:1-Verbindungen durchzuführen.

Sammlungsfokus [Messwert:Einseitiger Datenfluss mit Lüfter in> 100]

[1] [2] 下一页

Architektur-Mapping im industriellen Internet Datenkonnektivität in der Industrial Internet Reference Architecture