Container das Allheilmittel oder etwa doch nicht?

Der Container-Zug ist schon einige Jahre unterwegs - aber er ist nach wie vor Lichtjahre davon entfernt , die Universal-Lösung für alle IT-Probleme und Optimierung zu sein.

Viele Beratungsunternehmen preisen das nach wie vor völlig schmerzfrei an.

Container sollen doch alles verbessern, optimieren, beschleunigen ? Oder nicht?

Allgemeingültig betrachtet ganz sicher nicht . Diese Aussagen kommen von einem Spezialisten im RZ-/Cloud-/Großkunden-Bereich für  High-availability Cluster, Software Defined Storage, Verzeichnisdienste sowie hochskalierbare und vollautomatisierte Container-Cluster-Infrastrukturen Bereich.

Wenn man sie denn irgendwie versions-übergreifend in einem Sack mit tausenden Schrauben - deren Anzahl , Größe und Form sich im schnellen Release-Zyklen-Wahnsinn  permanent verändern - auch reproduzieren könnte. Das ist in Produktivumgebungen ein relativ sinnloses Zeit- und damit Geldverbrennungunterfangen, mit dem selbst OpenShift zu kämpfen hat.

Der Container-Hype läuft ungebremst weiter. Er wächst und skaliert sich selbst in unermessliche Komplexitätsgefilde. Und vor allem bleibt er die Gelddruckmaschine Nummer 1 aktueller IT-Landschaften. 

Das Buzzword Container stellt nach wie vor allerorten einen Freibrief für Kompatibilitätsbrüche dar, für die Architekten und Entwickler noch vor wenigen Jahren geteert und gefedert worden wären- Container-„Standards“ hin oder her.

Die ganzen kleinen Blackbox-Klötzchen - sprich die Container bzw die Pods des Control Planes und weiterer Komponenten wie Pipelines - einfach irgendwie funktionieren. 

Und wenn nicht … vielleicht funktioniert ja das nächste Klötzchen. Bis zum nächsten Upgrade. Sind ja eh meist nicht mal 100 Tage bis zum nächsten Kubernetes-Major-Release und vielleicht nur die Hälfte bis zur nächsten Pipeline - oder Mesh-Release, also was soll‘s….

Ist das wirklich der richtig Ansatz für Systeme die länger bestehen sollen??

Das US-Department of Defense (DoD) hat mittlerweile erkannt , dass es dringend notwendig ist, den ständigen, agil befeuerten Renewal-Wahn und der permanenten Verkomplizierung einen Riegel vorzuschieben.

Was ist mit der UNIX Regel Keep it stupid simpel ??

Bereits Ende 2018 veröffentlichte das DoD einen Draft namens Detecting Agile Bullshit (das ist absolut kein Scherz, so lautete der offizielle Name). 

Sein Ziel: das sinnlose Verbrennen finanzieller Ressourcen (wie in den konzepbedingt stark agil-„lästigen“ DevOps-/Containerisierungsbereichen) drastisch einzuschränken.

Siehe auch:

https://thenewstack.io/the-u-s-department-of-defense-on-how-to-detect-agile-bs/

Sowie ebenfalls als Direktlink:

https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF

Im Grunde genommen spiegelt die Aufteilung in immer komplexer werdende, kleine und extrem kurzlebige Software-Häppchen auch die Entwicklung wider, die sich in unserer Gesellschaft - leider, muss man sagen - mehr und mehr erkennen lässt.

Häppchen müssen stets mundgerecht serviert werden, egal ob‘s hier und da mal nicht so schmeckt oder passt, wie es soll. 

Schnell - Schneller am Schnellsten

Das ist das Motto in der Software-Entwicklung die frage stellt sich hier ob nicht ein konzipieren und überdenken der Komponenten durchaus Sinn macht?

Aber dieser Geschwindigkeitswahn spiegelt sich in der Gesellschaft wieder , das alles so aufbereitet werden muss , dass auch Rezipienten mit einer maximalen Aufmerksamkeitsspanne von 30 Sekunden nicht sofort gelangweilt sind.

…die nach wie vor schmerzhafte Realität…

Egal , wie gut die Tools sind : Leider zeigen fast alle bisherigen Erfahrungen, dass er allerwichtigste Teil gern komplett übersprungen wird - nämlich der zwingend erforderliche und sehr sorgfältige durchzuführende Evaluierungsprozess, dessen Ergebnis darüber entscheidet, ob eine Container/Microservice-Landschaft für das eigene Unternehmen bzw bestimmte Produktionsbereiche überhaupt Sinn macht.

Oft wurden bestehende nicht Containerisierung  sehr gut funktionierende - Plattformen aufgrund von Präsentationen von Beratungsfirmen bezüglich wir skalieren mal auf Knopfdruck der kostspieligen Container-Abrissbirne übergeben.

Die traurige Bilanz, die selten in den Werbeblasen der Consulting-Unternehmen auftaucht , ist: Bis heute hat ein gutes Drittel der Firmen ihre Projekte zur Containerisierung in Teilen bzw. komplett wieder eingestellt. Und gerade mal ein Viertel der Firmen , die sich überhaupt mit Containern beschäftigen, setzen diese auch halbwegs produktiv ein. Für die anderen gilt: zu teuer, zu aufwendig, auf bestehende Strukturen nicht effizient anwendbar. Für ein zuvor gut funktionierendes Unternehmen kann eine im Vorfeld nicht sorgfältig evaluierte Umstellung auf Container das komplette finanzielle Aus bedeuten.

…und die Komplexitätsfalle

Ein zwangsläufiges Ergebnis , werden den Unternehmen doch oft - wie auch in der Vergangenheit das tolle Cloud-Thema - Technologien zu einem Zeitpunkt als reif verkauft , zu dem sie es lange noch nicht sind. Das Stichwort an dieser Stelle sei ein in einigen Unternehmen oft auf Biegen und Brechen durchgezogener Einsatz des permanently moving targets Vanilla Kubernetes . Noch dazu mit (den dann zwingend benötigten und) zahlreichen, angeflanschten 3rd-Party-Produkten wie Pipelines und Meshes. Natürlich mit - zu Kubernetes -meist völlig asynchronen Produktzyklen ebendieser Produkte.

Daher gilt nach wie vor bzw aktuell umso mehr: Der wichtigste Punkt vor jeder strategischen „Wir containerisieren jetzt einfach mal „ Entscheidung besteht darin, einfach mal das Hirn einzuschalten und dann eine sehr , sehr sorgfältige Evaluierung vorzunehmen, ob Container/Microservice-Landschaften für eine Optimierung des eigenen Unternehmens überhaupt geeignet sind.

Es sei denn, man hält sprechende Gummibärchen in der Werbung für echt.

Dann kann man sich diesen Punkt schenken.

… leider noch mal die traurige Realität

Umstrukturierungen waren in der Vergangenheit erfahrungsgemäß in den wenigsten Fällen tech-driven motiviert. Oder gar sorgfältig vorab evaluiert. Da geht es mehr um möglichst farbenfroh präsentierten Nonsens des jeweiligen Consulting-Unternehmens.

Und da wären wir wieder: Digitalisierung. Nachhaltigkeit. Container in der Cloud. Cloud-Native, KI und Machine-Learning-Systeme.

Na klar!

Irgendwann setzt die Realität und mit ihr die Ernüchterung ein. 

Und die Tech-,HR-und Buchhaltungsabteilungen stellen unter dem Strich fest, dass - neben der nach wie vor bedenklichen „Sicherheit „ von Container-Clustern in der Cloud - deutlich mehr Budget , Personal und Arbeitsstunden verpulvert wurden, als es die wunderschönen PowerPoint-Präsentationen doch ursprünglich gepriesen hatten. 

Aber dafür steckt das Unternehmen mittlerweile wenigstens im stahlharten Vendor-Lock 

des immer teurer werdenden Container-Cloud Hosters.

I-a-a-S, P-a-a-S, F-a-a-S , Serverless,NoOps Nach dem Hype ist vor dem Hype

Hey Leute wie wärs zur Abwechslung mal mit B-a-a-S: Brain as a Service?

Fazit: 

Fakt ist Conainer Cluster können mittlerweile viel . Richtig viel.

Aber eben nach wie vor nicht alles . Und sie passen nicht für jeden Einsatzzweck.

Die fünf Schlüsselworte sind und bleiben: Vorher sehr, sehr sorgfältig evaluieren . Punkt 

Meine Gedanken zum Endpoint - Schutz

 Endpunkte sind alle Elemente eines IIoT-Systems, die sowohl Rechen- als auch Kommunikationsfähigkeiten haben und funktionale Fähigkeiten zur Verfügung stellen. Dabei kann es sich um Edge-Geräte, Kommunikationsinftastruktur, Cloud-Server oder irgendwas dazwischen handeln. 

Jeder Endpunkt hat unterschiedliche Anforderungen und Hardware-Einschränkungen, die sich auf das erreichbare Schutzniveau auswirken. Die Sicherheitsmechanismen und- Techniken sollten auf die Endpunkte je nach ihren spezifischen Funktion und ihren Sicherheitsanforderungen angewendet werden.

Endpoint Protection stellt die Verfügbarkeit, Vertraulichkeit und Integrität der vom Endgerät ausgeführten Funktionen sicher.

Die Endpoint Protection sollte mindestens diese Sicherheitsfunktionen berücksichtigen:

Endpoint Physical Security bietet physischen Schutz des Endpunkts mit Mechanismen zum Schutz vor Manipulationen und Diebstahl, um unkontrollierte Änderungen oder das Entfernen des Endpunkts zu verhindern.

Endpoint Root of Trust bietet eine Grundlage für die Sicherung anderer Funktionen am Endpunkt, von der Hardware bis hin zu Anwendungen einschließlich Firmware, Virtualisierungsschicht , Betreibssystem, Ausführungsumgebung und Anwendung. Außerdem bietet sie Vertrauen in die Identität des Endpunkts.

Die Identität eines Endpunkt basiert auf den inhärenten Eigenschaften eines Endpunkts, die ihn von anderen Endpunkten unterscheiden. Die Identität muss mit Beweisen oder Zeugnissen untermauert werden, die die Identitätsbehauptung bestätigen und als Referenzen bezeichnet werden.

Endpoint Integrity Protection stellt sicher, dass sich der Endpunkt in der Konfiguration befindet, die für eine vorhersehbare Ausführung seiner Funktionen erforderlich ist.

Die Endpoint Access Control stellt sicher, dass eine ordnungsgemäße Identifizierung , Authentifizierung und Autorisierung durchgeführt wird, bevor Ressourcen oder Dienste gewährt werden.

Endpoint Secure Configuration and Management steuert die Aktualisierung von Sicherheitsrichtlinien und- Konfigurationen auf dem Endgerät, einschließlich Upgrades und Patches für bekannte Sicherheitslücken.

Die Überwachung und Analyse von Endgeräten umfasst Integritätsprüfungen, die Erkennung von bösartigen Nutzungsmustern, Denial-of-Service-Aktivitäten, die Durchsetzung von Sicherheitsrichtlinien und Analysen, die Sicherheitsleistungsindikatoren verfolgen.

Endpoint Data Protection bietet Kontrollen zum Schutz der Integrität, Vertraulichkeit und Verfügbarkeit der Daten.

Endpoint Security Model and Policy regelt die Implementierung von Sicherheitsfunktionen auf dem Endpunkt.

Sicherheitsbedrohungen und Schwachstellen auf Endgeräten

Endgeräte haben viele potenzielle Schwachstelle, die für böswillige oder unbeabsichtigte Fehler anfällig sind.

Wie in der Abbildung dargestellt gibt es in jedem der folgenden Bereiche ein breites Spektrum an Bedrohungen und Schwachstellen in verschiedenen Aspekten der Endgeräte.

1 => Änderungen an Hardwarekomponenten und Konfiguration

Die Integrität der Hardware muss während des gesamten Lebenszyklus des Endgeräts gewährleistet sein, um unkontrollierte Änderungen an den Hardwarekomponenten zu verhindern. Eine mögliche Schwachstelle der Hardware ist die Aneignung eines Teils der Hardwareressourcen. Der Endpunkt muss in der Lage sein, sich vor unbefugtem Zugriff und der Vereinnahmung von Schlüsselressourcen wie Speicher, Verarbeitungszyklen und privilegierten Verarbeitungsmodi zu schützen.

2,3 => Abfangen oder Überschreiben des System-Boot-Prozesses

Der Endpunkt-Boot-Prozess kann durch Änderung der Firmware-Schnittstelle zwischen der Hardware-Plattform-Firmware und dem Betriebssystem, wie z. B. dem Unified Extensible Firmware Interface (UEFI) oder dem Basic Input/Output System (BIOS), verändert werden. Änderungen an den Bootloads sind eine weitere Bedrohung, da sie die Integrität des Endgeräts gefährden könnten, indem sie nicht autorisierte oder unsichere Versionen des Betriebssystems starten. Angriffe auf dieser Ebene könnten auch den normalen oder sicheren Startvorgang des Endgeräts, die Erkennung aller Hardwareressourcen und die Schaffung einer soliden Vertrauensbasis für die Sicherung anderer Komponenten beeinträchtigen.

4,5 => Kompromisse bei Gastbetriebssystemen, Hypervisoren und Separationskerneln:

Diese Softwareschichten steuern die Zuweisung von Hardwareressourcen an Anwendungen. Angriffe auf diese Schichten können das Verhalten des Systems verändern, die Umgehung von Sicherheitskontrollen durch Informationsflüsse ermöglichen, das Verhalten des Systems verändern, die Umgehung von Sicherheitskontrollen durch Informationsflüsse ermöglichen und Angreifern einen privilegierten Zugriff auf Hardware- und Softwareressourcen von Endgeräten ermöglichen. Sobald der Angreifer Zugang zu dieser Ebene erlangt hat, hat er die Möglichkeit, den gesamten Software-Stack zu beeinflussen und die auf dieser Ebene eingebauten Sicherheitskontrollen weiter zu verändern.

7,8,9 => Unerlaubte Änderungen an der Anwendungssoftware oder der offengelegten Anwendungsprogrammierschnittstelle (API)

Endpunktanwendungen sind häufig das Ziel von Malware oder eines Angreifers, der versucht, den Endpunkt zu infiltrieren und zu kompromittieren. Die Ausführung bösartiger Anwendungen oder das Überschreiben von Anwendungs-APIs kann sich negativ auf die Vertrauenswürdigkeit des Endpunkts auswirken. Offengelegte APIs sollten auch gegen Denial-of-Service-Angriffe geschützt werden, bei denen der ständige Zugriff von nicht autorisierten Benutzern die Reaktionsfähigkeit und den Zugriff auf die offengelegten Funktionen einschränken könnte.

10 => Schwachstellen des Verteilungsprozesses

Fehler und potenzieller bösartiger Code können auch als Teil des Bereitstellungsprozesses in den Endpunkt eindringen, z. B. durch falsche oder bösartige Installationsskripte, abgefangene Kommunikation oder nicht autorisierte Ersetzung eines Pakets auf dem Update-Server. Die Verringerung möglicher Endpunktkonfigurationen bei umfangreichen Endpunktbereitstellungen ist wichtig, um die Komplexität und die Schwachstellen im Bereitstellungsprozess zu reduzieren.

11 => Unerwünschte Änderungen an Endpunktdaten

Daten auf dem gesamten Endpunkt, von der Low-Level-Firmware bis hinauf zum Software-Stack, stellen einen wichtigen Bereich für Schwachstellen dar. Zu diesen Schwachstellen gehört der unbefugte Zugriff auf unternehmenskritische oder private Daten. Angreifer können das Verhalten des Systems durch Einspeisung falscher Daten beeinträchtigen. Denial-of-Service-Angriffe auf den Datenzugriff können die rechtzeitige und genaue Ausführung der Endpunktfunktionalität behindern, was zu kostspieligen Ergebnissen führt.

12 => Verstoß gegen das Überwachungs- und Analysesystem

Ein Angreifer könnte sich Einblick in die Funktionen des überwachten Systems verschaffen. Beispielsweise könnte ein Angreifer Überwachungsdaten so verändern, dass es so aussieht, als ob ein bestimmtes Ereignis nicht eingetreten wäre. Die Modifizierung der Sicherheitsprotokolle und Überwachungsdaten kann zu unentdeckten Schwachstellen oder gefährdeten Zuständen führen. Infolgedessen würden Angreifer von einer Abdeckungslücke profitieren, indem sie die Hardware und Software von Endgeräten kompromittieren oder nach einem Angriff Beweise für ihre Aktivitäten vernichten.

13 => Schwachstellen in Konfiguration und Management

Eine Schwachstelle im Konfigurations- und Verwaltungssystem kann durch eine unsachgemäße Zugriffskontrolle auf das Konfigurationsverwaltungssystem, das Einfügen nicht autorisierter Änderungen in das System oder die Beschädigung von Aktualisierungsnutzdaten entstehen. Aktualisierungen der Endgeräte sollten so geplant und verwaltet werden, dass die Zahl der verschiedenen Betriebskonfigurationen begrenzt und die Fragmentierung der Flotte verringert wird.

14 => Unkontrollierte Änderungen der Sicherheitspolicy und des Modells

Änderungen der Sicherheitspolitik und der abgeleiteten Sicherheitsmodelle stellen eine ernsthafte Bedrohung für das System und seine Endpunkte dar. Ebenso sind Schwachstellen in der Sicherheitspolitik ein Bereich, der von potenziellen Angreifern ausgenutzt werden kann.

15 => Schwachstellen in der Entwicklungsumgebung

Die Einführung von Schwachstellen während des Lebenszyklus der Softwareentwicklung kann die IIoT-Systeme anfällig für Angriffe machen. Diese Schwachstellen können während der Architektur, des Entwurfs oder des Schreibens des Codes eingeführt werden. Die Verwendung anfälliger oder bösartiger Bibliotheken oder nicht vertrauenswürdiger Entwicklungs-Frameworks kann dazu führen, dass sie in den resultierenden Code des IIoT-Systems aufgenommen werden.

Meine Gedanken zum Security Framework

Industrielle Internet-of-Things-Systeme (IIoT) verbinden und integrieren verschiedene Arten von Steuerungssystemen und Sensoren mit Unternehmenssystemen, Geschäftsprozessen, Analysen und Menschen. Diese Systeme unterscheiden sich von herkömmlichen industriellen Steuerungssystemen, indem sie umfassend mit anderen Systemen und Menschen verbunden sind und so die Vielfalt und den Umfang der Systeme erhöhen.

In der Vergangenheit beruhte die Sicherheit vertrauenswürdiger Industriesysteme auf der physischen Trennung und Netzwerkisolierung anfälliger Komponenten sowie auf der Unklarheit der Entwurfs- und Zugangsregeln für kritische Kontrollsysteme. In den letzten Jahrzehnten haben die zunehmend erschwingliche Rechenleistung, die allgegenwärtige Konnektivtät und die sich entwickelnden Datenanalysetechniken die Tür zur Konvergenz von Kontrollsystemen, Geschäftssystemen und dem Internet geöffnet.  Diese Konvergenz begann im kleinen und wurde zunächst für die Fernüberwachung und -Verwaltung von Systemen genutzt, weitete sich aber schnell auf die Auswertung und Analyse von Betriebsdaten für Leistungskennzahlen zur Vorhersage von Ausfällen, die Optimierung von Flotten und die Durchführung von Software-Upgrades aus der Ferne aus. Diese Konvergenz hat die Produktivität, Effizienz und Leistung der bestehenden Betriebsprozesse erhöht und die Schaffung neuer Möglichkeiten zur Nutzung von Betriebsdaten ermöglicht, wodurch jetzt und in Zukunft ein Mehrwert für das Unternehmen entsteht.

Doch mit diesen Gewinnen sind auch Risiken verbunden. Unternehmen müssen diese Risiken ernst nehmen; um ihr IIoT-System vertrauenswürdig zu machen. Der Einsatz von Sensoren und Aktoren in einer industriellen Umgebung ist keine typische IT-Erfahrung , ebenso wenig wie Systeme, die viele Organisationen und Organisationssysteme umfassen. IT und OT priorisieren die Systemeigenschaften unterschiedlich. So ist beispielsweise die Ausfallsicherheit in der IT weniger wichtig als in der OT, und die Sicherheit ist in der OT weniger wichtig als in der IT wie in der Abbildung dargestellt.

Ein System der Industrie der Dinge (IIoT) weist durchgängige Merkmale auf, die sich aus den Eigenschaften seiner verschiedenen Komponenten und der Art ihrer Interaktionen ergeben. Die fünf Merkmale, die sich am stärksten auf die Vertrauensentscheidungen eines IIoT-Einsatzes auswirken, sind Sicherheit , Zuverlässigkeit, Widerstandsfähigkeit und Datenschutz. Diese werden als zentrale Systemmerkmale bezeichnet. Andere , z.B. Skalierbarkeit, Benutzerfreudnlichkeit, Wartungsfreundlichkeit, Übertragbarkeit oder Zusammensetzbarkeit, können im Allgemeine ebenfalls wichtig sein.

Durchgängige Sicherheit bei IIoT-Systemen

Die Implementierung eines Systems für das industrielle Internet der Dinge (IIoT) muss eine durchgängige Sicherheit vom Rand bis zur Cloud bieten. Dazu gehören die Härtung von Endgeräten, der Schutz der Kommunikation, die Verwaltung und Kontrolle von Richtlinien und Updates sowie die Nutzung von Analysen und Fernzugriff zur Verwaltung und Überwachung des gesamten Sicherheitsprozess.

Die Sicherheit von IIoT-Systemen sollte sich so weit wie möglich auf Automatisierung stützen, aber Menschen müssen in der Lage sein, mit der Sicherheitsimplementierung zu interagieren, um den Status zu überwachen, Analysen zu überprüfen, bei Bedarf Entscheidungen zu treffen und Änderungen und Verbesserungen zu planen. Brauchbare Verwaltungs- und Kontrollsysteme können zur Sicherheit beitragen, indem sie Bedienerfehler reduzieren.

Bausteine der Sicherheit

Die funktionale Sichtweise des Sicherheitrahmens umfasst sechs interagierende Bausteine. Sie sind in drei Schichten organisiert. Die oberste Schicht umfasst die vier zentralen Sicherheitsfunktionen:

Endpunktschutz

Schutz der Kommunikation und Konnektivität

Sicherheitsüberwachung und -Analyse

Verwaltung der Sicherheitskonfiguration

Diese vier Funktionen werden durch eine Datenschutzschicht und eine systemweite Sicherheitsmodell- und Richtlinienschicht unterstützt.

Diese drei Schichten bilden die funktionale Sichtweise des Sicherheitsrahmens für das industrielle Internet.

Der Endpunktschutz implementiert Verteidigungsfunktionen auf Geräten am Netzwerkrand und in der Cloud. Zu den Hauptanliegen gehören physische Sicherheitsfunktionen, Cybersicherheitstechniken und eine zuverlässige Identität. Endpunktschutz allein reicht nicht aus, da die Endpunkte miteinander kommunizieren müssen und die Kommunikation eine Quelle der Anfälligkeit sein kann.

Der Kommunikations- und Konnektivitätsschutz nutzt die autorisierende Identitätsfunktion des Endpunktschutzes, um die Authentifizierung und Autorisierung des Datenverkehrs zu Implementierung.

Kryptographische Techniken für Integrität und Vertaulichkeit sowie Techniken zur Kontrolle des Informationsflusses schützen die Kommunikation und Konnektivität.

Sobald die Endpunkte geschützt sind und die Kommunikation gesichert ist, muss der Systemzustand während des gesamten Betriebslebenszyklus durch Sicherheitsüberwachung und -Analyse und kontrolliertes Sicherheitskonfigurationsmanagement für alle Systemkomponenten aufrechterhalten werden.

Diese ersten vier Bausteine werden durch eine gemeinsame Datenschutzfunktion unterstützt, die sich von den ruhenden Daten in den Endpunkten bis zu den bewegten Daten in der Kommunikation erstreckt und auch alle im Rahmen der Überwachungs- und Analysefunktion gesammelten Daten sowie alle Systemkonfigurations- und Verwaltungsdaten umfasst.

Sicherheitsmodell und -Governance regeln, wie die Sicherheit impementiert wird, und die Richtlinien , die die Vertraulichkeit, Integrität und Verfügbarkeit des Systems während seines gesamten Lebenszyklus gewährleisten. Es regelt , wie alle Funktionselemente zusammenarbeiten , um eine durgängige Sicherheit zu gewährleisten.

In weiteren Blogs werde ich die verschiedenen Bausteine und ihr Zusammenspiel genauer beschreiben.

Meine Gedanken zur Event based Architektur

 Wie in so vielen Dingen ist die Natur ein großartiger Architekt und hat sich diese Konzepte ausgedacht, lange bevor Entwickler und Architekten überhaupt daran gedacht haben.

Spinnen nutzen seit Jahrtausenden erfolgreich ereignisbasierte Konzepte. Ereignisgesteuerte Architekturen bieten die Möglichkeit, hocheffizient und in Echtzeit über relevante Änderungen informiert zu werden und darauf zu reagieren.

Die meisten Spinnen sind sehr effiziente Räuber. Sie setzen eine Vielzahl von Strategien ein, um Beute zu fangen. Die häufigste ist das verwenden klebriger Netze. Die Methode des klebrigen Netzes zum Fangen von Beute ist diejenige, an der wir hier interessiert sind.

Nachdem die Spinne ihr Netz gesponnen hat, wartet sie darauf, dass sich die Beute darin verfängt. Die Spinne spürt den Aufprall und den Kampf eines Beutetiers durch Vibrationen, die durch das Netz übertragen werden. Nachdem sie eine Vibration wahrgenommen hat, bewertet die Spinne , ob die Vibrationen von einem Beutetier oder von etwas anderem verursacht wird, das die Spinne nicht interessier, wie z.B. ein Blatt. Wenn sich ein Blatt in einem Spinnennetz verfängt , ignoriert die Spinne diese Veränderung in ihrem Netz einfach. Wenn jedoch ein Beutetier 

Die Beute oder das Blatt im Netz ist ein Ereignis - eine bedeutende Veränderung des Zustands des Spinnennetzes.

Das Spinnennetz ist der Even-Broker, der Ereignisse über die Schwingungen des Netzes transportiert.

Die Spinne ist der Event-Consumer. Sie wird über wesentliche Änderungen des Netzstatus informiert und reagiert entsprechend den erhaltenen Informationen.

Nun zu den Bausteine Event based Architektur

Eine Event based Architecture ist eine Softwarearchitektur, die Ereignisse als zentrales Mittel für die Interaktion zwischen ihren Softkomponenten verwendet. Die umfasst die Erfassung, Kommunikation, Verarbeitung und Persistenz von Ereignissen. Bei Softwarekomponenten in ereignisgesteuerten Architekturen handelt es sich in der Regel um Microservices, aber es können auch andere arten von Software-Systemen das ist der Vorteil der event-based Architektur.

Ereignisgesteuerte Architekturen stellen einen architektonischen Ansatz dar und basieren. Nicht auf einer bestimmten Programiersprachen. Tatsächlich kann eine ereignisgesteuerte Architektur in fast jeder modernen Programmiersprache erstellt werden. Ereignisgesteuerte Architekturen eignen isch hervorragend für verteilte Softwareumgebungen und ermöglichen eine minimale Kopplung. Diese natürliche Verbreitung von ereignisgesteuerten Architekturen wird noch dadurch verstärkt, dass ein Ereignis - eine signifikante Änderung - fast alles sein kann. Daraus ergibt sich eine große Anzahl von möglichen Ereignisquellen.

Komponenten von ereignisgesteuerten Architekturen

Ereignisgesteuerte Architekturen bestehen aus einer sehr begrenzten Anzahl von Architekturkomponenten wie folgt:

Event producer

Der Eignisproduzent ist die Quelle des Ereignisses und sendet das Ereignis aus, um anzuzeigen , dass es eingetreten ist. Der Ereignisproduzent weiß nur, dass das Ereignis eingetreten ist; er weiß nicht, wer sich für das Ereignis interessiert oder wie die interessierten Parteien auf die Information über das Ereignis reagieren werden.

Event broker

Der Ereignisbroker ist ein Vermittler, der Ereignisse vermittelt und verwaltet. Wenn man es mit den Definitionen sehr genau nimmt, kann der Broker sogar als optional betrachtet werden, wenn der Produzent ein. Ereignis-Broker eingesetzt werden.

Event consumer

Ereigniskonsumenten sind Softwarekomponenten, die wissen müssen, dass ein Ereignis eingetreten ist, und sich in der Regel beim Ereignisbroker anmelden, um über Ereignisse informiert zu werden.

Die Kombination dieser begrenzten Anzahl von Komponenten kann zu hochkomplexes und leistungsfähigen Architekturen führen, die sich durch extreme Skalierbarkeit und Flexibilität auszeichnen.

Daten und Events oder Events und Daten?

Früher gab es einen klaren Fokus auf Daten, z.B. zunächst in Backend-Systemen und später in Data Lakes. Die Quelle der Wahrheit war klar: Die Daten standen im Vordergrund, und die Landschaften und Systeme folgten einem datenorierten Modell. Im Rahmen dieses Modells wurden Teilmengen von Daten gesammelt, gespeichert und so effizient wie möglich abgerufen.

Mit dem Aufkommen der ereignisgesteuerten Architekturen hat sich der Schwerpunkt von Daten auf Ereignisse verlagert. Die Frage ist nun, wie weit diese Verlagerung gehen soll. Einige sagen, dass jetzt Ereignisse am wichtigsten sind und dass die Quelle der Wahrheit in erster Linie aus Ereignissen besteht, während Daten nur die zweite Quelle sind. Es gibt zwei Schulen von ereignisgesteuerten Architekturen: die ereignisprotokollbasierten Architekturen, die bis zu einem gewissen Grad Ereignisse an die erste und Daten an die zweite Stelle setzen , und die ereignisbrokerbasierten Architekturen, die immer noch Daten an die erste und Ereignisse an die zweite Stelle setzen.

Diese beiden Ansätze beruhen auf zwei unterschiedlichen Mechanismen, nämlich Pub/Sub und Event Streaming :

Ereignis-Broker-basiertes Messaging 

Dieser Ansatz stützt sich auf ein Veröffentlichungs- und Abonnementkonzept (Pub/Sub) , das auf Abbonnements beim Ereignisbroker aufbaut. Nachdem ein Ereignis eingetreten ist, wird es veröffentlicht, und die Abonnenten werden benachrichtigt. Ein Ereignisbroker übernimmt die Rolle des Vermittlers, führt aber kein Protokoll.

Nachdem das Ereigniss konsumiert wurde, gibt es in der Regel keine Möglichkeit, das Ereignis erneut abzuspielen. Die Quelle der Wahrheit sind bei diesem Ansatz also immer noch die Daten. Ereignisse können als Echtzeit-Auslöser für die Druchführung von Aktionen mit den Daten betrachtet werden. Bei diesem Ansatz sind sowohl Benachrichtigugnsereignisse als auch Datenereignisse möglich, wenn man es genau nimmt.

Ereignisprotokoll-basiertes Messaging

Dieser Ansatz stützt sich auf ein Ereignisprotokoll und schreibt alle auftretenden Ereignisse in dieses Protokoll. Die Ereignisse werden in der Regel für einen bestimmten Zeitraum im Ereignisprotokoll gespeichert.

Ereignisprotokoll ermöglichten es Ihnen, Ereignisse auszuspielen, um den Zustand Ihrer Anwendung anhand der protokollierten Ereignisse zu reproduzieren. Dies wird als Ereignisprotokollierung bezeichnet, wenn Sie nur Ereignisse protokollieren, oder als Event Sourcing, wenn Sie in der Lage sind, den Zustand der Anwendung aus diesen protokollierten Ereignisse zu reproduzieren. Bei diesem Ansatz gilt also: Ereignisse vor Daten . Die Ereignisse sind die Quelle der Wahrheit. Ereignisse müssen bei diesem Ansatz als relevanten Daten enthalten und daher Datenereignisse sein.

Bei den Daten und Ereignissen gibt es einen höchst interessanten Unterschied in Bezug auf das Alter. Daten altern gut, aber Ereignisse nicht. Das bedeutet, dass auch alte Daten immer noch die Quelle der Wahrheit sind, so dass die höchste Priorität darin besteht, keine Daten zu verlieren. So ist beispielsweise die Adresse eines Geschäftspartners , die vor Jahrzehnten in ein ERP-System eingegeben wurde, immer noch gültig , sofern sie nicht aktualisiert wurde. Bei Ereignissen ist das anders. Je jünger ein Ereignis ist, desto wertvoller ist es; je älter es wird, desto weniger Wert hat es. Bei ereignisgesteuerten Architekturen geht es in erster Linie darum, so schnell wie möglich auf Ereignisse zu reagieren. Dies gilt sowohl für Ereignisbroker als auch für eriegnissprotokollbasierte Ansätze.

Vorteile und Herausforderungen der ereignisgesteuerten Architektur

Vorteile:

Lose Kopplung

Extreme Skalierung und hoher Durchsatz

Inkrementelles Wachstum

Fehlertoleranz

Erkenntnisse in (real)Echtzeit

Geringe Latenz

Effiziente Abläufe

Vorhersage

Herausforderungen

Überwachung und Verständnis

Verfolgung und Fehlersuche

Maskierung von Fehlern

Sicherheit der Daten

Zentraler Ereignisbroker

Synchrone Abfrage

Meine Gedanken zum Framework für die Analytik Teil 1

 Das industrielle Internet der Dinge (IIoT) zielt darauf ab, industrielle Anlagen und Maschinen - die Dinge - mit den Informationssystemen des Unternehmens, den Geschäftsprozessen und den Menschen, die sie betreiben und nutzen, zu verbinden.

Die fortschrittliche Analytik ist das Herzstück dieser nächsten Generation der Integration und bietet, wenn sie auf Maschinen- und Prozessdaten angewendet wird, neue Erkenntnisse und Intelligenz , um die Entscheidungsfindung erheblich zu optimieren und intelligente Abläufe zu ermöglichen, die zu transformative Geschäftsergebnissen und sozialem Wert führen.

Verwendung Analytics Framework

Das Analytik-Framework für das industrielle Internet der Dinge ist als Architekturvorlage für Systemarchitekten gedacht, um eine konkrete , auf die Anforderungen eines bestimmten IIoT-Systems zugeschnittene Architektur zu erstellen, das Verständis und die Kommunikation des Gesamtsystems unter den Beteiligten zu unterstützen und die Architektur so zu implementieren , dass die einzigartigen Systemanforderungen erfüllt werden.

Der Wert der industriellen Analytik

Analytik kann im weitesten Sinne als eine Disziplin definiert werden die Daten durch systematische Analyse in Informationen umwandelt.

Industrielle Analytik ist der Einsatz von Analytik in IIoT-Systemen. Sie ermöglicht ein besseres Verständnis der Betriebszustände, der Leistung und der Umgebung eines Systems. Sie identifiziert und analysiert aufkommende Informationsmuster, um Bewertungen von Industriesystemen unter verschiedenen Bedingungen zu ermöglichen. Diese Bewertungen verbessern die Funktionalität und verringern Ineffizienz und Betriebskosten. Dies wird als dynamische Betriebsoptimierung bezeichnet.

Die industrielle Analytik kann auch Systemeinsätze optimieren. So kann beispielsweise die Analyse von Verkehrsmustern in Echtzeit in einem Ballungsraum in Verbindung mit dem Straßenzustand, dem Bau und der Instandhaltung , dem Bau und der Instandhaltung von Straßen, den Wetterbedingungen , der Tageszeit , den Jahreszeiten, Unfällen und anderen Ereignissen dazu führen, dass Fahrzeugsteuerungssysteme optimale Routen zur Verringerung von Fahrzeiten, Staus , Umweltverschmutzung und Energieverbrauch ermitteln.

Industrielle Analysen können auf Maschinenstromdaten aus unterschiedlichen Quellen angewendet werden, um Ereignismuster zu erkennen, zu abstrahieren, zu filtern und zu aggregierten und sie dann zu korrelieren und zu modellieren, um Ereignisbeziehungen wie Kausalität, Zugehörigkeit und zeitliche Merkmale zu erkennen. Die Identifizierung von bedeutsamen Ereignissen und die Ableitung von Mustern kann auf größere und komplexere Zusammenhänge hinweisen, so dass auf diese Ereignisse angemessen reagiert werden kann.

Erste Schritte in der industriellen Analytik

Die Analytik lässt sich im Allgemeinen in drei große Kategorien einteilen:

Deskriptive Analysen gewinnen Einblicke aus historischen oder aktuellen Datenströmen, u.a. Für Status- und Nutzungsüberwachung , Berichterstattung, Erkennung und Diagnose von Anomalien, Modellerstellung oder Schulung.

Prädikative Analysen ermitteln erwartete Verhaltensweisen oder Ergebnisse auf der Grundlage von Vorhersagemodellen, die auf statistischen und maschinellen Lernverfahren beruhen, z.B. Vorhersage des Material- und Energieverbrauchs sowie Vorhersage. Von Komponenten- und Systemverschleiß und Fehlern.

Die präskriptive Analytik nutzt die Ergebnisse der prädikativen Analytik als Orientierungshilfe , um Betriebsänderungen zur Optimierung von Prozessen und zur Vermeidung von Ausfällen und den damit verbundenen Ausfallzeiten zu empfehlen. Ein Beispiel für präskriptive Analytik ist die On-Demand-Produktion auf Grundlage eines soliden geometrischen Montagemodells, um den optimalen Satz an Fertigungsverfahren für das Endprodukt zu finden.

Die Analyseergebnisse können automatisch auf Maschinen und Systeme angewandt oder zur Unterstützung menschlicher Entscheidungen durch Visualisierung der Analyseergebnisse verwendet werden, um das menschliche Verständnis zu verbessern und Vertrauen in eine Entscheidung zu schaffen.

Die industrielle Analytik steht vor besonderen Herausforderungen, da die Ergebnisse den Betrieb und die Sicherheit von Dingen in der physischen Welt verändern können. Diese Auswirkungen können unerwünscht oder schädlich sein und unbeabsichtigt die Sicherheit von Menschen beeinträchtigen oder Eigentum und die Umwelt schädigen. Da bei der industriellen Analytik häufig Daten von verschiedenen Sensoren und Maschinen interpretiert werden, die sich möglicherweise widersprechen, müssen wir die verschiedenen Informationsströme verstehend und zusammenführen, um zu einer korrekten Schlussfolgerung zu gelangen.

Hier sind die Anforderungen aufgeführt, die bei der Planung der industriellen Analytik zu berücksichtigen sind.

Korrektheit

Die industrielle Analytik muss Analyseergebnissen ein höheres Maß an Genauigkeit erfüllen. Jedes System, das die Ergebnisse interpretiert und in die Tat umsetzt, muss über Scherheitsvorkerherungen gegen unerwünschte und unbeabsichtigte physikalische Folgen verhindert.

Timing

Die industrielle Analytik muss bestimmten harten Termin- und Synchronisationsanforderungen genügen. Nahezu sofortige Analyseergebnisse, die innerhalb eines deterministischen Zeitfensters geliefert werden, sind für zuverlässige und qualitativ hochwertige Maßnahmen im industriellen Betrieb erforderlich.

Sicherheit

Bei der Anwendung der industriellen Analytik sowie bei der Interpretation und Umsetzung der Ergebnisse müssen strenge Sicherheitsanforderungen eingehalten werden, um das Wohlergehen von Arbeitnehmeren, Nutzern und der Umwelt zu gewährleisten.

Kontextualisiert

Die Analyse von Daten innerhalb eines industriellen Systems erfolgt nie ohne den Kontext, in dem die Aktivitäten und Beobachtungen stattfinden. Es ist nicht möglich , eine Bedeutung zu konstruieren , wenn nicht ein vollständiges Verständnis des ausgeführten Prozesses und der Zustände aller Geräte und ihrer Peripheriegeräte berücksichtigt wird, um die wahre Bedeutung der Daten abzuleiten und umsetzbare Informationen zu erstellen.

Kausalorientiert

Industrielle Abläufe haben mit der physischen Welt zu tun, und die industrielle Analytik muss mit bereichsspezifischem Fachwissen validiert werden, um die komplexen kausalen Beziehungen in den Daten zu modellieren. Die Kombination von ersten Prinzipien, z.B. der physikalischen Modelierung, mit anderen statistischen und maschinellen Lernfähigkeiten der Datenwissenschaft ist in vielen industriellen Anwendungsfällen erforderlich, um genaue Analyseergebnisse zu erzielen.

Verteilt

Viele Komplexe industrielle Systeme haben hierarchische Ebenen, die über geografische Gebiete verteilt sind. Jedes dieser Teilsysteme kann einzigartige analytische Anforderungen zur Unterstützung seiner Operationen haben. Daher muss die industrielle Analytik auf die lokalen Anforderungen der von ihr unterstützten Teilsysteme zugeschnitten sein. Die Anforderungen an das Timing (Vermeidung langer Latenzzeiten) und die Ausfallsicherheit (Vermeidung eines weitreichenden Ausfalls von Diensten aufgrund von Fehlern im Netz oder in einem zentralisierten System) erfordern ein verteiltes Muster industrieller Analysen, bei dem die Analyse in der Nähe der Datenquelle, die sie analysiert, und des Ziels , an dem die Analyseergebnisse benötigt werden, implementiert wird.

Streaming

Bei der industriellen Analytik kann es sich um kontinuierliche oder Batch-Prozesse handeln. Aufgrund der kontinuierlichen Ausführung in industriellen Systemen wir ein großer Teil der industriellen Analytik in Form von Streaming-Prozessen erfolgen, bei denen Live-Daten analysiert und ein kontinuierlicher Fluss von Analyseergebnissen zur Unterstützung des Betriebs bereitgestellt wird.

Traditionelle Batch-orientierte Analysen werden weiterhin entweder zur Erstellung oder Verbesserung von Analysemodellen oder zur menschlichen Entscheidungsfindung durchgeführt.

Automatic 

Damit die industrielle Analytik kontinuierliche Abläufe unterstützen kann, müssen die Analysen von Datenströmen und die Anwendung von Analyseergebnissen automatisch, dynamisch und kontinuierlich erfolgen. Da die Technologien in der industriellen Analytik fortschreiten, können Verbesserungen in der analytischen Modellierung, z.B. durch Lernen, auch automatisch erfolgen.

Semantics

Analytische Systeme benötigen Daten, die eine Bedeutung und einen Kontext haben. Unstrukturierte Daten, die ohne Zuordnung zum Kurs und zur Komponente oder zum System, das sie repräsentieren, gemeldet werden, machen die Ableitung von Werten komplex, da sie Analysesysteme die Bedeutung erraten oder ableiten müssen.

Unnötige Schlussfolgerungen bringen erhebliche Unsicherheiten in das System. Die meisten Daten können an der Quelle richtig zugeordnet werden, und wenn diese Information weitergegeben wird, kann sie den Erfolg und die Genauigkeit der Analysesysteme erheblich steigern.   

 

Mit den rasanten Entwicklungsstandards und Innovationen in der Sensor- und Computertechnologie ist es nur möglich, fortschrittliche Analysen auf eine große Anzahl von Maschinen weltweit auszuweiten. Fortschrittliche analysealgortihmen und -Techniken, einschließlich des maschinellen Lernens, werden jetzt zur Analyse großer Datenmengen aus industriellen Steuerungssystemen eingesetzt. Die aus der Analyse gewonnenen Erkenntnisse können automatisch angewendet werden, um die Betriebseffizienz von Maschinen zu erhöhen, indem z.B. Verbrauchsspitzen vorausgesehen werden, die Lieferketten für Teile, die für die vorbeugende Wartung benötigt werden, rationalisiert werden und die Geschäftsplanung und Entscheidungsfindung unterstützt wird.

Durch die Nutzung der aus den Maschinendaten gewonnenen Erkenntnisse zur Steuerung intelligenter Betriebs- und Geschäftsprozesse ermöglicht die industrielle Analytik die Konvergenz der Analytik in der OT- und IT.-Welt.

Meine Gedanken zur Baseline des Connectivity Framework

 Die Baseline ist eine Technologie, die alle Konnektivitätsanforderungen für einen Funktionsbereich erfüllen kann. Um die Konnektivitätsarchitektur überschaubar zu halten, wird ein Technologiestandard für die Konnektivität innerhalb einer funktionalen Domäne verwendet werden, und bilden eine Schnittstelle zu Konnektivitäts-Kernstandards in anderen funktionalen Domänen. Gateways dienen als Brücke zu anderen Konnektivitätstechnlogien innerhalb der Domäne und zu den Konnektivitäts-Kernstandards, die in anderen funktionalen Domänen verwendet werden. Die Konnektivität zwischen funktionalen Doomänen, die oft in einer abgestuften Weise implementiert ist, kann intermittierend sein. Konnektivitäts-Gateways können dazu beitragen, diese intermittierende Konnektivität zu mildern. Die Anwendungen sind einfacher und leichter zu warten, wenn keine Logik erforderlich ist, um auf einen fehlgeschlagenen Datenaustasch zu reagieren.

Endpunkte können direkt mit der Baseline verbunden werden. Andere Endpunkte und Subsysteme werden über Gateways angeschlossen. 

Konnektivitäts-Gateways ermöglichen die Einbindung neuer Konnektivitätstechnologien. Sie bieten eine stabile Grundlage , die in den heute verfügbaren „Best-of-Bred“-Technologien verankert ist, können aber in der Zukunft auf einen neuen grundlegenden Kernstandard umgestellt werden, der die Anforderungen besser erfüllt.

Meine Gedanken zum Connectivity-Framework

Das übergreifende Ziel der IIoT-Konnektivität besteht darin, Daten in diesen isolierten System („Silos“) freizulegen und den Datenaustausch und die Interoperabilitiät zwischen zuvor geschlossenen Komponenten und Subsystemen (Brownfields) und neuen Anwendungen (Greenfield) innerhalb und über Branchen hinweg zu ermöglichen.

Neue Konnektivitätstechnologien müssen während der Lebensdauer eines Systems mit bestehenden Technologien integriert werden. Eine Konnektivitätsarchitektur muss die Interoperabilität einer Vielzahl von Konnektivitätstechnoloigien innerhalb einer Branche und branchenübergreifend ermöglichen, um die Visison eines branchenübergreifenden IIoT zu unterstützen.

Eine Konnektivitäts-Kernstandardtechnologie (Baseline) ist eine Technologie, die alle Konnektivitätsanforderungen für einen Funktionsbereich erfüllen kann. 

Gateways haben zwei Funktionen: Sie integrieren andere Konnektivitätstechnologien, die innerhalb einer funktionalen Domäne verwendet werden, und bilden eine Schnittstelle zu Konnektivitäts-Kernstandards in anderen funktionalen Domänen.

Um die Konnektivitätsarchitektur überschaubar zu halten, wird ein Technologiestandard für die Konnektivität innerhalb einer funktionalen Domäne als Grundlinie gewählt und als „Kernstandard für die Konnektivität“ bezeichnet. Gateways dienen als Brücke zu anderen Konnektivitätstechnologien innerhalb der Domäne und zu den Konnektivitäts-Kernstandards, die in anderen funktionalen Domänen verwendet werden. Die Konnektivität zwischen funktionalen Domänen, die oft in einer abgestuften Weise implementiert ist, kann intermittierend sein. Konnektivitäts-Gateways können dazu beitragen, diese intermittierende Konnektivität zu mildern. Die Anwendungen sind einfacher und leichter zu warten, wenn keine Logik erforderlich ist, um auf einen fehlgeschlagenen Datenaustausch zu reagieren.

Einige Endpunkte können direkt mit einem Kernstandard verbunden werden. Andere Endpunkte und Subsysteme werden über Gateways angeschlossen. Ein Kernstandard verbindet sie dann alle miteinander und ermöglicht die Integration mehrerer Konnektivitätstechnologien, ohne dass zwischen allen möglichen Paaren eine Brücke geschlagen werden muss. Jede domänenspezifische Konnektivitätstechnologie benötigt nur ein Gateway zu einem einzigen Konnektivitäts-Kernstandard.

Konnektivitäts-Gateways ermöglichen die Einbindung neuer Konnektivitätstechnologien. Sie bieten eine stabile Grundlage, die in den heute verfügbaren „Best-of-Breed“-Technologien verankert ist, können aber in der Zukunft auf einen neuen grundlegenden Kernstandard umgestellt werden, der die Anforderungen besser erfüllt.

Es gibt verschiedene Arten von Konnektivitäts-Gateways:

Framework-Gateways erweitern die logische Spanne der Kommunikation über Connectivity Framework Technologien hinweg. Sie behalten die syntaktische Struktur der Daten bei, können aber die technische Darstellung ändern.

Transport-Gateways erweitern die logische Spanne der Kommunikation über Transporttechnologien hinweg. Sie nehmen keine logischen Änderungen an der Bytefolge (Payload) vor und sind für diese transparent.

Physikalische/Verbindungs-/Netzgetways können sich über mehrere Schichten des Konnektivitätsstapels erstrecken.

Über ein Gateway zu einem Kernkonnektivitätsstandard kann ein domänenspezifischen Endpunkt mit Endpunkten auf anderen domänenspezifischen Technologien kommunizieren, die ebenfalls über Gateways mit dem Kernkonnektivitätsstandard verbunden sind. Kernkonnektivitätsendpunkte können direkt miteinander und über Gateways mit domänenspezifischen Konnnektivitätsendpunkten kommunizieren.

Unterschiedliche Funktionsbereiche können aufgrund unterschiedlicher Prioritäten bei den technischen Anforderungen, Kompromissen und Ökosystemen unterschiedliche Kernkonnektivitätsstandards wählen. Um die Kommunikation zwischen verschiedenen Konnektivitätsgrundnormen zu ermöglichen, werden standardisierte Gateways benötigt. Ein standardisiertes Gateway zwischen grundlegenden Konnektivitätsstandards wird als Kern-Gateway bezeichnet. 

Ein Kernstandard für Konnektivität muss:

Syntaktische Interoperabilität bieten, eine offene Norm mit starker unabhängiger, internationaler Führung sein und die Zertifizierung, Validierung oder Prüfung der Interoperabilität von Implementierungen unterstützen, horizontal und neutral in seiner Anwendbarkeit über Branchen hinweg sein, stabil sein und über mehrere vertikale Branchen hinweg eingesetzt werden, über standarddefinierte Core Gateways zu allen anderen Kernstandards der Konnektivität verfügen.

Zu den wichtigsten Funktionen des Konnektivitätsrahmens gehören ein Datenressourcenmodell, Publish-Subscribe- und Request-Reply-Datenaustauschmuster, Datenqualität Datensicherheit und eine Programmier-API

Typische Erwägungen für die Auswahl eines Konnektivitätsrahmens lassen sich in System-,Daten-, Leistungs-, Skalierbarkeits-, Verfügbarkeits-, Bereitstellungs- und Betriebserwägungen unterteilen. Die Kompromisse in jedem Bereich sollten sorgfältig bewertet werden.

Es folgen einige Leitlinien, die auf dem primären Funktionsbereich der Anwendbarkeit der Verbindungstechnologie basieren.

Konnektivitätstechnologien für den Kontrollbereich unterstützen hohe Zuverlässigkeit, schnelle Echtzeitleistung, Skalierung auf eine große Anzahl von Datenobjekten und eine hohe Dienstaualität.

Konnektivitätstechnologien für den Betriebsbereich unterstützen die Überwachung und Verwaltung von Geräten und Anwendungen.

Konnektivitätstechnologien für den Informationsbereich unterstützen die selektive Übertragung große Mengen und einer Vielzahl von Echtzeitdaten für Streaming-Analysen und Entscheidungsprozesse in Echtzeit.

Konnektivitätstechnologien für den Anwendungsbereich werden externe APIs und Benutzerschnittstellen (UIs) unterstützen, einschließlich Webbrowsern und mobilen Handhelds.

Konnektivitätstechnologien für den Unternehmensbereich werden herkömmliche IT-Anwendungen und Rechenzentren unterstützen.

Wenn die Gateways  für die Konnektivitätsstandards für die Konnektivitätstechnologien vorhanden sind, ermöglicht die IIoT-Konnektivitätsarchitektur die Kommunikation zwischen bisher isolierten Endpunkten. Sie kann neue Wertströme erschließen und dazu beitragen, das volle Potenzial des IIoT auszuschöpfen.

Meine Gedanken zum Digitalen Zwilling

 Digitale Zwillinge stärken den Lebenszyklus vom Entwurf, Ausführung, Änderung und Außerbetriebnahme eines Produkts. Natürlich finden digitale Zwillinge von der Konzeption bis zur Stilllegung einen Platz im Produktlebenszyklus. Im Großen und Ganzen gibt es drei Arten von digitalen Zwillingen - Produktzwilling, Produktinszwilling und Leistungszwilling:

Produkt-Zwillinge: Die Entwicklung einer physischen Anlage ist eine komplexe und teure Phase des Produktlebenszyklus. Obwohl sich die Welt des Designs von 2D-Blaupausen zu eigenständigen 3D-Simulationen entwickelt hat, ist die Forschung und Entwicklung immer noch durch eine begrenzte Zusammenarbeit eingeschränkt.

Produktion Zwillinge: Ein reibungsloser Betriebsablauf ist für jedes Unternehmen von entscheidender Bedeutung. Trotz der digitalen Transformation sind viele Betriebs- und Produktionsprozesse immer noch in Silos untergebracht und bieten kein vollständiges Bild.

Digitale Zwillinge bieten nicht nur Einblicke in Teile und Komponenten, sondern haben auch das Potenzial , die große Verflechtung der Produktionsumgebungen sichtbar zu machen - einen ganzen Prozess, eine Fabrik oder sogar eine Stadt. Indem sie Modelle virtueller Produktionseinheiten ermöglichen , nutzen digitale Zwillinge Echtzeitdaten und -Technologien, um den Produktionsprozess für die Menschen , die die Einheit betreiben, zu optimieren.

Leistungszwillinge: Unnötige Ausfallzeiten, Störungen oder Schäden sind der Albtraum eines jeden Unternehmens. Jeder Aspekt der 5M- Mensch, Maschine, Material, Methode und Management - kann zu einem unerwünschten Ergebnis führen. 

Digitale Zwillinge kombinieren die physikalischen Eigenschaften und Daten der Sensoren und der Betriebsumgebung mit hochentwickelten Vorhersagealgorithmen. Digitale Zwillinge können Unternehmen dabei helfen, von dem, was geschehen ist, auf das zu schließen, was wahrscheinlich geschehen wird. Digitale Zwillinge dienen auch als Rahmen für das Wissensmanagement, indem sie historische Zustände und Leistungen speichern und zukünftige Zustände und Designinformationen vorhersagen. Mit digitalen Zwillingen streben Unternehmen nach starken Abfrage- (Vergangenheit) und Superlativ-Vorhersagefähigkeiten (Zukunft).

Das Ökosystem des digitalen Zwillings

Im vorherigen Abschnitt haben wir die drei Arten von digitalen Zwillingen untersucht: 

Produktzwillinge, Produktionszwillinge und Leistungszwillinge. Jetzt wollen wir eine Ebene tiefer gehen, um die Implementierungsaspekte der digitalen Zwillinge und des größeren Ökosystems zu verstehen.

Machen wir uns zunächst mal mit einigen Konzepten Vertraut , die das Ökosystem der digitalen Zwillinge betreffen.

Digitaler Zwilling-Prototyp (DTP): Ein DTP ist der Prototyp eines physischen Vermögenswerts verbunden. Die DTI enthält in der Regel Daten zu den von den Sensoren erfassten Betriebsbedingungen, zum historischen Zustand, zum voraussichtlichen Zustand, zu Anlagen-und Gewährleistungsinformationen, zu Serviceaufzeichnungen usw. Während ein DTI mit den Anfangsinformationen seines Prototyps beginnt, wird das DTI im Laufe des Lebenszyklus mit Betriebsdaten angereichert.

Digitale Zwillingsinstanz (DTI): Eine DTI (erstellt aus dem DTP) ist der Zwilling eines physischen Assets. Die DTI bleibt während ihres Lebenszyklus mit dem physischen Vermögenswert verbunden. Die DTI enthält in der Regel Daten zu den von den Sensoren erfassten Betriebsbedingungen, zum historischen Zustand, zum voraussichtlichen Zustand, zu Anlagen- und Gewährleisutngsinformationen, zu Serviceaufzeichnungen usw. Während ein DTI mit den Anfangsinformationen eines Prototyps beginnt, wird das DTI im Laufe des Lebenszyklus mit Betriebsdaten angereichert.

Die digitale Zwillingsumgebung (DTE) ist eine Sammlung der oben genannten Komponenten, die digitalen Zwillingsarena für die prädikativen und die abfragenden Operationen.

Meine Gedanken zum CPS und Digital Twin

 Ich beschäftige mich ja schon einige Zeit mit Cyber-Physical-Systeme und natürlich taucht das Thema Digital Twins immer wieder auf.

Jetzt mal zum Digitalen Zwilling :

Der digitale Zwilling ist ein Konzept, kein einzelnes Produkt oder ein Stück Technologie. Mehrere Technologien - 3D Simulation, IoT/IIoT, 4G/5G, Big Data, Blockchain, Edge & Cloud Computing und künstliche Intelligenz - kommen zusammen, um das Konzept Wirklichkeit werden zu lassen.

Die ReferenzArchitektur teilt sich in eine Logische Architektur und Physical Architektur

Logische Architektur

Logische Architektur teilt sich in folgende Bereiche:

Model: Die Reise zum digitalen Zwilling beginnt mit der Modellierung der physischen Assets. Die Konvertierung vorhandener 2D-Modelle ist eine Möglichkeit. Eine andere Möglichkeit besteht darin , in Ermangelung vorhandener Modelle neu zu beginnen. Zu diesem Zweck steht eine Vielzahl von Modellierungswerkzeugen zur Verfügung.

Kommunikation: Sobald das Model steht, ermöglicht das IoT die Kommunikation zwischen der physischen und der digitalen Welt. Die Sensoren und Technologien variieren je nach Zwilling.

Assimilate: Assimilatinsschichten reichern die Daten der Anlagen mit Daten aus anderen Systemen an, um ein verbessertes Bild der physischen Welt zu erhalten. Dabei kann es sich beispielsweise um Informationen wie Teilenummern, Ersatzteile im Bestand usw. Handeln.

Action: Die Aktionsschicht ermöglicht prognostische und diagnostische Fähigkeiten. Diese Schicht stellt eine Vorwärts - (Prognose) und Rückwärts- (Diagnose) Verbindung zwischen der physischen und der digitalen Welt her.

Physikalische Architektur

Sensoren und Aktuatoren

Sensoren erfassen die Zustandsinformationen und Eigenschaften eines physischen Objekts. Welche IoT-Sensoren eingesetzt werden, hängt vom Bedarf und den zu erfassenden Daten ab. Erfassen Sie z.B,die Temperatur des Motors.

Aktoren nehmen Eingaben von den digitalen Zwillingen entgegen und führen eine Aktion am physischen Asset aus. Zum Beispiel, die Geschwindigkeit des Motors zu reduzieren.

Gerade hier sehe ich eben Überschneidungen zu CPS 

Operative Systeme & Master-Entry-Systeme

Neben den Sensordaten werden auch Informationen aus operativen Systemen wie Trouble Ticketing, SCADA-Steuerungen und Master-Entry-Systemen wie Asset- und Inventory Management die digitale Darstellung des Zwillings verbessern.

Parsing und Verarbbeitung von Daten

Die Schicht für die Datenanalyse und -Verarbeitung empfängt die Daten, analysiert sie, bereinigt sie und normalisiert sie für die weitere Verarbeitung IoT-Plattformen verwalten die Geräte, die Daten aus der physischen Welt sammeln.

Simulation und Modellierung

Das Herzstück eines digitalen Zwillingsprogramms, die Simulation und Modellierung , ist der Ort, an dem alle Informationen und Erkenntnisse für Diagnose- und Prognosezwecke zusammenlaufen. Bei der Modellierung kommen einfache Regeln bis hin zu komplexen KI-Algorithmen zum Einsatz. Die modellierten Informationen werden dann - unter Verwendung von 3D-Simulatinstechniken - simuliert, damit der Benutzer sie nutzen und handeln kann.

Case Management

Basierend auf dem Zweck der digitalen Zwillinge kann das Fallmanagement eine kollaborative Umgebung für verschiedene Interessengruppen und Nutzer ermöglichen, die an der Eingabe und Ausgabe arbeiten.

Dashboarding und Berichterstattung

Die Präsentationsschicht mit Dashboards und Berichten für die Benutzer.

Gedanken zur Referenz-Architektur des IIoT

Referenzarchitekturen bilden die Grundlage für Best Practices und die Wiederverwendung der Architekturmuster.  Das Industrial Internet Consortium (IIC) hat die Notwendigkeit der Referenzarchitektur erkannt und die Industrial Internet Reference Architecture (IIRA) veröffentlicht. Diese dreistufige Architekutr bietet verschiedene Standpunkte, die auf die verschiedenen Interessensgruppen ausgerichtet sind. IIC definiert die Referenzarchitektur als das Ergebnis der Anwendung von Architekturprinzipien auf eine Klasse von Systemen.

Dies dient als Orientierungshilfe , da die Architekten die gemeinsamen architektonischen Probleme analysieren und lösen. Der daraus resultierende IIRA stellt dann eine Vorlage für die Verwendung in der konkreten Architektur von industriellen Internet-Systemen dar.

IIoT-Projekte und Architekturlösungen können sehr komplex sein. Ein bewährter Ansatz zu Lösung komplexer Problemstellungen ist die Zerlegung in seine Subsysteme. 

Die IIRA ist eine auf Standards basierende offene Architektur für IIoT-Systeme. Die IIRA maximiert ihren Wert durch die breite Anwendbarkeit in der Branche , um die Interoperabilität voranzutreiben, anwendbare Technologien abzubilden und die Technologie - und Standardentwicklung zu lenken. Die Beschreibung und Darstellung der Architektur ist generisch und auf einen hohen Abstraktionsniveau, um die erforderliche breite Anwendbarkeit in der Industrie zu unterstützen.

Bei der Betrachtung komplexer Systeme, wie sie von IIoT-Systemen erwartet werden, sind viele Akteure beteiligt. Die Systemkomplexität erfordert einen Rahmen , um die Anliegen der Stakeholder zu ermitteln und in geeignete Kategorien einzuordnen. Ein solcher Rahmen ermöglicht eine systematische Bewertung solcher Systeme sowie die für die Planung und den Aufbau solcher Systeme erforderliche Lösung.

Vergleich von RAMI 4.0 mit IIRA

Die Referenzarchitekturen RAMI 4.0 und IIRA beschreiben den logischen Aufbau von Gesamtsystemen und Prozessen im Umfeld des IIoT. Der Fokus liegt dabei auf der einheitlichen Definition von Abstraktionsebenen und semantischen Zusammenhängen. Beide Architekturen berücksichtigen dabei verschiedene Aspekte und strukturieren des Gesamtsystem hierarchisch mit Schichten.

Es gibt darüber hinaus zwischen den beiden Architekturen in Teilbereichen vielfach Gemeinsamkeiten , aber von Grundsatz her unterscheiden sich beide Architekturen doch erheblich. In der Tabelle sind die wesentlichen Unterschiede zwischen den beiden Referenzarchitekturen aufgeführt.

Meine Gedanken zur Trinität - Authentisierung - Authentifizierung - Authorisierung

 Authentisierung;     „Wer bin ich?“

 Authentifizierung:  “Wer sind Sie?“

Authorisierung;       “Was darf ich?“

Das Bezeichne ich als die Trinität, ich werde versuchen diese drei wichtigen Teile zu beschreiben.

Authentisierung

Unter Authentisierung versteht man den Nachweis der eigenen Identität. Dabei kann es sich um die Identität einer Person oder auch um die eines Computerprogramms handeln.

Im Allgemeinen kann man Authentisierungsmerkmalen in folgende drei Kategorien einteilen:

1. persönliches Wissen

2. persönlicher Besitz

3. biometrisches Merkmal

Unter 1 fallen die im Computerumfeld üblichen Passwörter , aber auch die Persönliche Identifikationsnummer (PIN) , Diese Merkmale haben mehrer Nachteile: So eignen sie sich beispielsweise nicht für sehr vergessliche Menschen. Außerdem können sie ausspioniert werden, auch ohne dass das Opfer es bemerkt.

Zu den Authentisierungsmerkmalen , die man besitzt (2) , zählen solche Dinge wie Fido Hardware Token , SSL - Zertifikate, JSON Web Token usw.

Der Nachteil der Merkmale der Kategorie 2 ist, dass man sie entwenden kann.

Die biometrischen Merkmale (3) gehören eigentlich auch zu den Dingen, die man besitzt. Sie haben aber den Vorteil, dass sie nicht so leicht zu entwenden sind. Zu diesen Merkmalen zählt man z.B. Aussehen,Stimme, Fingerabdruck, Augenhintergrund oder Unterschrift. Der Nachteil der biometrischen Merkmale liegt darin, dass Computer sie nicht besonders gut erkennen und verarbeiten können und dass die Authentisierung über diese Merkmale daher unter Umständen fehleranfällig ist.

Verwendung 

Alle drei Kategorien von Authentisierungsmerkmalen haben ihre Vor- und Nachteile . Idealerweise kombiniert man daher Merkmale verschiedener Kategorien, um die einzelnen Nachteile auszugleichen. Beispielsweise sind Geldgeschäfte mit einer EC-Karte (Merkmaltyp 2) nur durch zusätzliche Kenntnis einer PIN (Merkmaltyp 1) der durch leisten einer Unterschrift (Merkmaltyp 3) möglich. Auch die üblichen Token (Merkmaltyp 2) können nur in Kombination mit einer PIN (Merkmaltyp 1) benutzt werden.

Authentifizierung

Der Austausch der Informationen zwischen Benutzer und Webanwendung (Credentials der Session Token) erfolgt jeweils verschlüsselt und ist vor Manipulation geschützt. Jede Webanwendung welche eine vorherige Authentifizierung verlangt (Login) , hat auch ein Logout . 

Die Schritte sind im Einzelnen:

1. Der Benutzer möchte sich auf eine geschützte Webseite verbinden.

2. Die Anwendung stellt fest, dass für die geschützte Webseite eine Authentifizierung notwendig ist. Sie sendet dem Benutzer ein Formular zur Eingabe der Credentials.

3. Der Benutzer füllt das Formular aus (bei MFA können dies auch mehrere Formulare sein) und sendet es an die Anwendung.

4. Die Anwendung prüft gegen eine Verzeichnis, ob der Benutzer vorhanden , ob er für die entsprechenden Webseiten berechtigt ist (Authorisierung) und ob seine Credentials stimmen (Authentifizierung),

5. Ist soweit alles in Ordnung, wird dem Benutzer ein Session Token gesendet, welches für die aktuelle Session gültig ist.

6. Mithilfe des Session Token wird die Authentifizierung aufrechterhalten, ohne der Benutzer für jede Anfrage , welche er zur Webanwendung sendet, wieder authentifizieren muss.

Authorisierung

Die Autorisierung ist ein Synonym für die Zugriffskontrolle. Eng mit der Autorisierung verknüpft ist die Autditierbarkeit,mit deren Hilfe die Nutzung einer Ressource im Nachhinein überprüft werden kann. Eine Ressource kann im Kontext der Softwarearchitektur Daten meinen wie beispielsweise ein Dokument. Es kann sich aber auch um eine Geschäftsfunktion handeln, die geschützt werden soll. Es gibt hierfür zwei verschiedene Ansätze: den klassischen rollenbasierten Ansatz sowie die neuere , attributbasierte Ansätze ; den klassischen rollenbasierten Ansatz sowie die neuere , attributbasierte Authorisierung deren Vor- und Nachteile wie besprechen werden. Ein gängiges Dokument im Zusammenhang mit der Autorisierung ist das sogenannte Berechtigungskonzept , in dem sowohl die zu schützenden Ressourcen als auch die technische Strategie des Schutzes beschrieben stehen. Das Berechtigungskonzept heißt manchmal auch Rechte- und - Rollen-Konzept oder Access Control Policy. Die verschiedenen Konzepte und Prozesse rund um die Autorisierung stehen.

RBAC

Vorteile von RBAC

Der große Vorteil von RBAC ist der Determinismus; Man kann jederzeit leicht feststellen, wer auf welchen Ressourcen welche Berechtigungen besitzt. Dies macht das Berechtigungskonzept einfacher anpassbar und auch transparenter , da sich die Zusammenhänge leicht visualisierung lassen. Der Vorteil, die Auswirkungen von Änderungen im Vorfeld erkennen zu können, darf nicht unterschätzt werden. Daraus ergibt sich eine gute Auditierbarkeit des Systems auch für Business Owner. Für sie ist es einfach nachvollziehbar, welche Berechtigung er vergeben hat oder attestieren soll, da die Rollen klare Namen haben, die leicht verständlich sind. Generell gibt RBAC als einfacher als das ABAC-Modell, das wir weiter unten beschreiben.

Nachteile von RBAC

Der Nachteil von RBAC ist, dass die Rollen und Ressourcen bekannt sein müssen , um Entscheidungen im Kontext fällen zu können. Dies ist insbesondere für einen Administrator bei der Verwaltung schwierig , aber auch für einen Business Owner, der nur seine Ressourcen kennt, aber nicht die Rollen. Zudem kann die Anzahl der Rollen schnell explodieren, wenn zu feingranular berechtigt werden soll. Es besteht hier insbesondere das substanzielle Risiko dass Servicesemantik in das Rollenkonzept auf Geschäftsebene schwappt und dieses komplizierter als nötig macht.

Häufig wird bei RBAC die Verwaltung von Subdomänen delegiert. Die Delegation ist für Stellvertreterregelungen im IAM zwar sehr wichtig , aber das Rollenmodell läuft dann Gefahr , sich an der Delegatinsstruktur zu orientieren und nicht am Geschäft . Wenn viele Rollen im Einsatz sind, so muss auch eine große Anzahl von Delegationene in der Rollenverwaltung erstellt und gewartet werden. Dies bedeutet schlicht Overhead und kostet Geld. Es gibt zu RBAC diverse Zusätze , welche die Delegation erleichtern (PBDM, CRBAC).

ABAC

ABAC erlaubt den Zugriff auf Ressourcen über domänenspezufischer Attribute beispielsweise die Funktion im Unternehmen oder das Alter. Diese können dann für die Autorisierung verwendet werden. Wichtig bei diesem Konzept ist, dass nicht nur der Nutzer diese Attibute hat, sondern auch die Resource , auf die zugegriffen werden soll. Mittels einfacher mathematischer Funktionen kann ein ABAC-System dann entscheiden, ob der Zugriff erlaubt ist oder nicht. Bei diesem Verfahren kann etwa ein Dokument mit dem Attribut „Finance“ versehen werden. Hat ein Benutzer dann das Attribut „Controller“, greift eine Regel, die den Zugriff erlaubt.

Vorteile ABAC

Der größte Vorteil der attributbasierte Zugriffskontrolle ist, dass einfache Regeln definiert werden können. Diese können sehr feingranular und kontextbezogen sein, was bei RBAC schwierig ist. Zudem können die Regeln durch die Architektur auch Attribute von Ressourcen und Benutzern auswerten, die gar nicht im IDM-System vorhanden sind., sondern über den PIP provisioning werden. Es hat sich außerdem gezeigt, dass die Regeln wenig Pflege benötigen, da sie keine Struktur brauchen. Dies ist bei RBAC anders, da sich die Struktur durch die Rollen auch ändern können, wenn sich die Organisation verändert.

Nachteile von RBAC

ABAC kann auch zu einer Regelexplosion führen, ähnlich wie die Rollenexplosion beim RBAC. Hierdurch ist es auch schwierig , die Symmetrie herzustellen und so herauszufinden, welche Berechtigungen ein Benutzer hat. Hier muss gegebenenfalls eine große Anzahl von Regeln ausgeführt werden. Und dies in der exakt gleichen Reihenfolge , wie es für den Benutzer selbst erfolgt. In der Folge kann es unmöglich sein, Risiken bei Zugriffen festzustellen.

ABAC-Systeme können auch langsam in der Durchführung von Authorisationen sein, da Daten von mehreren anderen Services zur Berechnung benötigt werden. Da diese Berechnungen durch das ABAC-System nicht kontrolliert werden können, können sie auch nicht vorberechnet oder zwischengespeichert werden.

Neben der Authentisierung sind auch die Begriffe Authorisierung und Zugriffskontrolle (Access Control) wesentlich für jedes Sicherheitskonzept.

Beim Vorgang der Authorisierung wird festgelegt, mit welchen Berechtigung User auf Ressourcen im Netzwerk zugreifen dürfen. 

Meine Gedanken zu CPS und das IIoT

… Ein Cyber-Physical System (CPS) ist ein System, das reale (physische) Objekte und Prozesse verknüpft mit informationsverarbeitenden (virtuellen) Objekten und Prozessen über offene , teilweise globale und jederzeit miteinander verbundene Informationsnetze. Optional nutzt ein CPS lokal oder entfernt verfügbare Dienste, verfügt über Mensch-Maschine-Schnittstelle und bietet die Möglichkeit zur dynamischen Anpassung des Systems zur Laufzeit.

Für mich wird das CPS immer wichtiger werden um die Verbindung zwischen realen (physischen) Objekte und deren (virtuellen) Darstellungen immer wichtiger wird. Weiters die Verbindung eines Solchen Systems und eines HMI das ich weiterhin als wichtig erachte ,  nur die Aufgaben werden sich ändern bzw, anders gestalten. Der Mensch wird als Controller auftreten und weniger in den Standard Prozess eingreifen. 

Meine Gedanken werden in drei Abschnitten aufgeteilt werden:

Referenz-Architektur

Connectivity Framework

Security Framework

Diese drei Säulen bilden für mich den Ausgangspunkt meiner Betrachtung dienen , und werden in weiteren Blogs weiter betrachtet werden.

 Cyber-Physical Systems sind permanent vernetzt. Damit wird ermöglicht, eine Information für unterschiedlichste Anwendungen un in unterschiedlichsten Organisations- und Bereichsgrenzen verfügbar zu machen. Ein CPS ist in zwei Richtungen vernetzt horizontal und vertical.

Auf der horizontalen Ebene kommuniziert es mit Systemen auf der gleichen Ebene. Hierbei werden z.B. in einem Produktionssystem die nächsten Fertigungsschritte ausgehandelt oder Daten zum aktuellen Bearbeitungsstand eines Produkt ausgetauscht.Die horizontale Kommunikation kann jedoch auch zwischen Organisationsbereichen, wie beispielsweise zwischen Produktion und Konstruktion , erfolgen.

In vertikaler Richtung kommunizieren CPS mit über- oder untergeordneten Systemen. Dieser Aufbau spiegelt den zentralen Gedanken der verteilten Intelligenz wider: Die Produktion wird nicht länger durch eine zentrale Instanz gesteuert, sondern durch viele kleine Einheiten.

Es gibt folgende Funktionen eines CPS

Sensorik: Mittels Sensoren erfassen CPS die Realität. Dies ist die Basis für ein umfassendes Prozess - Monitoring

Aktorik: CPS können über Aktoren verfügen und Prozesse aktiv beeinflussen. Von besonderer Bedeutung ist dies in Robotikanwendungen.

Steuerung und Kontrolle: Durch eine gewisse Intelligenz können CPS autonom und ohne zentrale Instanzen Entscheidungen treffen und so Prozesse der realen Welt beeinflussen.

Vernetzung: CPS kommunizieren mit anderen CPS , mit Menschen (Bediener) und mit in den Unternehmen und Werschöpfungsketten bereits vorhandene IT-Systemen.

Daten- und Informations-Verarbeitung: CPS können Daten und Informationen verarbeiten. Microcontroller oder Mikroprozessoren sind ein essenzieller Bestandteil eines CPS.

Integration: CPS integrieren die reale und die virtuelle Welt sowohl innerhalb eines Unternehmens als auch unternehmensübergreifend. Basis dazu ist die automatische Identifikation von Objekten.

Anpassungs-Fähigkeit: CPS sollen das eigene Verhalten abhängig vom jeweiligen Kontext auf Basis von gelernten Wissen anpassen und die eigenen Fähigkeiten weiterentwickeln.