Begriffe des Technikleitfadens
Services
Asset Repository Service
Der Asset Repository Service ist eine zentrale Komponente der Data-Mesh-Architektur, die das Datenmanagement verbessert, indem sie Datenprodukte und Ressourcen organisiert, beschreibt und auffindbar macht. Er vereinfacht die Arbeitsabläufe von Datenteams, indem er logische Gruppierungen von Daten-Assets – darunter Datensätze, Code und andere Artefakte – kuratiert, die auf spezifische geschäftliche Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie hier
Identity Service
Der Identity Service von OctoMesh bietet zentralisierte Authentifizierung und Autorisierung für den Bereich Industrial IoT (IIoT) und ermöglicht sichere Konnektivität über Geräte, Anwendungen und Systeme hinweg. Er integriert sich mit mehreren Identity Providern, darunter OpenLDAP, Microsoft Active Directory, Entra ID, Google, Meta und Microsoft Authentication. Weitere Informationen finden Sie hier
Bot Service
Der Bot Service von OctoMesh bietet Octo Bots, automatisierte Assistenten, die routinemäßige und komplexe Aufgaben optimieren, um die Effizienz innerhalb der Plattform zu steigern. Sie übernehmen Datenaufbereitung, -bereinigung, -aggregation, Anonymisierung, Benutzerverwaltung, Berichtswesen, Benachrichtigungen und mehr und reduzieren so den manuellen Aufwand und automatisieren zentrale Prozesse. Weitere Informationen finden Sie hier
Communication Controller Service
Der Communication Service von OctoMesh, angetrieben vom Octo Communication Controller, fungiert als zentrale Drehscheibe für die Verwaltung und Absicherung der Kommunikation über Geräte und Anwendungen hinweg. Er regelt den Nachrichtenfluss, sorgt für verschlüsselte Übertragungen, unterstützt massive Konnektivität und ermöglicht die nahtlose Integration mit Octo Plugs und Sockets für skalierbare, sichere IoT-Kommunikation. Weitere Informationen finden Sie hier
Refinery Studio
Refinery Studio ist die Webanwendung zum Erkunden, Visualisieren und Verwalten des OctoMesh-Systems. Es ersetzt das eingestellte Admin Panel und ermöglicht die Verwaltung von:
Weitere Informationen finden Sie hier
Platform Services
Platform Services ist der Backend-Dienst, der den _configuration-Discovery-Endpunkt hostet, über den Clients die OctoMesh-Dienste finden, und der das zentral verwaltete System.UI-Construction-Kit-Modell sowie dessen dienstverwaltete Blueprints (cockpit, tenant mode) besitzt.
Communication
Deployment Sites
Ein Deployment Site ist ein Ort, an den Workloads ausgerollt werden — ein zentrales Cluster oder ein benanntes Edge-Cluster — bedient vom OctoMesh Communication Operator, der die dort gehosteten Adapter verwaltet. Hieß vor System.Communication 4.0.0 Pool.
Communication Operator
Der Communication Operator wird auf einem Kubernetes-Cluster installiert. Er verwaltet das Deployment von Adaptern.
Adapters
Adapter führen Pipelines aus. Adapter können mit anwendungs- oder protokollspezifischer Funktionalität ausgestattet sein, zum Beispiel zur Verbindung mit OPC-UA-Servern.
Nodes
Nodes werden innerhalb einer Pipeline ausgeführt. Manche Nodes sind für alle Adapter gleich, während andere adapterspezifisch sind.
Zum Beispiel:
- Der Modbus Adapter enthält Modbus Nodes
- Der OPC UA Adapter enthält OPC UA Nodes
Plugs
Adapter, die Daten aus anderen Systemen abrufen, werden Plugs genannt. Typischerweise verbinden sich Plugs als Client mit Servern.
Sockets
Adapter, die anderen Systemen Daten bereitstellen, werden Sockets genannt. Typischerweise sind Sockets Server, damit sich andere mit ihnen verbinden können.
Construction Kits
Construction Kit
Construction Kits sind in Bibliotheken organisiert. Jede Bibliothek kann auf anderen Construction-Kit-Bibliotheken basieren. Die Sammlung von Construction-Kit-Bibliotheken wird Construction Kit genannt.
Association Roles
Definiert Rollen innerhalb von Beziehungen zwischen Datenentitäten.
Association Types
Legt Typen von Beziehungen zwischen verschiedenen Entitäten fest.
Enums
Vordefinierte Wertelisten, die in Construction-Kit-Modellen verwendet werden.
Types
Definiert die in Construction Kits verwendeten Datentypen.
Records
Strukturierte Datensätze, die Informationen speichern und darstellen. Ein dokumentiertes Beispiel finden Sie hier
Attributes
Eigenschaften, die mit Construction-Kit-Typen verknüpft sind.
Construction Kit Libraries
Ein Satz vordefinierter, standardisierter Datenmodelle (Libraries). Die aktuell dokumentierten Modelle finden Sie hier
Construction Kit Repository
Construction Kit Repositories sind eine Sammlung von Bibliotheken, die lokal, in einer Datenbank oder auf GitHub gespeichert werden.
System Construction Kit Library
OctoMesh-Dienste verwenden Construction Kit Libraries für ihre Daten.
Bibliotheken, deren Namen mit "System" beginnen, definieren Kern-Datenstrukturen, z. B.:
System.Identity(beschreibt Identity-Server-Benutzer und -Rollen).
Standard Construction Kit Libraries
OctoMesh stellt eine Vielzahl standardisierter Construction Kit Libraries für verschiedene Branchen und Anwendungsfälle bereit, zum Beispiel für Wartungs-Dashboards. Weitere Informationen und die Dokumentation der verfügbaren Libraries finden Sie hier
Custom Construction Kit Libraries
Anpassungen von Datenmodellen für einzelne Anwendungsfälle oder Organisationen.
Construction Kit Dependencies
Construction Kit Libraries können von anderen Construction-Kit-Bibliotheken abhängen. Mindestens muss ein Construction Kit von der System Construction Kit Library abhängen.
Runtime Model
Ein Runtime Model besteht aus Entitäten, die Instanzen von Construction Kit-Typen sind. Runtime Entities (RtEntities) bestehen aus:
- einem eindeutigen Bezeichner, dem Runtime Identifier (RtId)
- einem Construction Kit Type Identifier (CkTypeId)
- Attributen
- Assoziationen
Runtime Entity
Instanzen von Construction-Kit-Typen werden Runtime Entities genannt, und die Sammlung von Runtime Entities wird Runtime Model genannt.
Stream Data
Stream Data bezeichnet objektorientierte Zeitreihendaten, die sowohl vergangene als auch zukünftige Ereignisse darstellen können. Diese Datenströme werden kontinuierlich erzeugt, erfassen den Zustand und das Verhalten von Objekten im Zeitverlauf und können für Echtzeitanalysen oder historische Einblicke genutzt werden. Streamdaten ermöglichen dynamisches Tracking und Prognosen, sodass Systeme sowohl rückblickende Auswertungen als auch prädiktive Modellierung durchführen können. Streamdaten werden in OctoMesh auch als Zeitreihendaten bezeichnet. Zeitreihendaten enthalten in ihrem Datenformat üblicherweise einen Zeitstempel. Sie können über GraphQL-Abfragen abgefragt werden.
Stream Data
Vokabular für Streamdaten-Archive und die Neuberechnung von Rollups. Diese Begriffe werden durchgängig in How archives work und Rollups & recompute verwendet. Sie mischen zwei Vokabulare: Scheduler-Begriffe (wie die Hintergrundschleifen laufen) und Domänen-Begriffe (was ein Rollup bedeutet).
Tick
Eine geplante Iteration der Schleife eines Hintergrund-Orchestrators (Standardintervall 60 s). Bei jedem Tick verrichtet der Orchestrator seine Arbeit: Die Vorwärtsaggregation schließt alle fälligen Buckets, der Recompute-Orchestrator arbeitet Dirty Windows ab. Dies ist Scheduler-Terminologie – es handelt sich nicht um ein Domänenkonzept und hat nichts mit der Bucket-Größe zu tun.
Bucket
Das feste Zeitintervall, in das ein Rollup Quell-Datenpunkte aggregiert; es gibt genau eine aggregierte Ausgabezeile pro Bucket und pro Entität (rtId). Beispiel: Ein tägliches Rollup über 15-minütige Quelldaten fasst die 96 Quellpunkte eines Tages zu einer Zeile zusammen (z. B. amountvalue_sum, dataquality_max).
Bucket size
(BucketSizeMs) Die Bucket-Breite – die Länge eines Buckets. Bei einem täglichen Rollup ist dies ein Tag, ausgedrückt in Millisekunden.
Bucket alignment
(BucketAlignment) Wo die Bucket-Grenzen liegen:
FixedSize– Grenzen im konstanten Abstand von einer festen Anzahl Millisekunden.- Calendar-aware –
CalendarDay/Iso8601Week/CalendarMonth/CalendarYear, sodass Monate mit 28–31 Tagen und Schaltjahre auf den korrekten Grenzen liegen.
Bei kalenderbasierter Ausrichtung ist BucketSizeMs eine informative Untergrenze, nicht die exakte Breite (ein Kalendermonat ist keine feste Anzahl von Millisekunden).
Watermark
(LastAggregatedBucketEnd) Das exklusive Ende des zuletzt festgeschriebenen Vorwärts-Buckets. Der Orchestrator aggregiert von hier aus vorwärts, Bucket für Bucket – die Watermark ist die Grenze zwischen „bereits aggregiert" und „noch nicht aggregiert".
Watermark lag
(WatermarkLagMs) Wie weit hinter „jetzt" der Orchestrator bewusst zurückbleibt, bevor er einen Bucket schließt, um leicht verspätete Vorwärtsdaten aufzufangen. Ein Bucket wird erst aggregiert, sobald now - watermarkLag über sein Ende hinausgewandert ist.
Consumed watermark
Die maximale Watermark (LastAggregatedBucketEnd) über die nicht gelöschten abhängigen Rollups eines Quellarchivs – der am weitesten fortgeschrittene Punkt, über den irgendein abhängiges Rollup bereits hinaus aggregiert hat. Sie ist die Grenze, anhand derer entschieden wird, ob ein eingehender Schreibvorgang rückwirkend ist. Das Maximum (nicht das Minimum) zu nehmen ist eine bewusste, sichere Überapproximation (AB#4288): Sie kennzeichnet einen Schreibvorgang, der im Band zwischen einem langsamen und einem schnellen abhängigen Rollup landet, als rückwirkend, und der Neuberechnungsbereich jedes abhängigen Rollups wird anschließend auf dessen eigene Watermark begrenzt.
Dirty window
Eine Zeitspanne auf einem Basis-/Quellarchiv, die zur Neuberechnung markiert ist, weil ein rückwirkender Schreibvorgang innerhalb eines bereits verbrauchten Fensters gelandet ist. Wird als CkArchiveDirtyWindow festgehalten; es erfasst die Absicht und schreibt selbst keine Zeilen um.
Bounded retro reach
Die archivbezogene Obergrenze (Archive.MaxRetroactiveReachMs, seit System.StreamData 1.6.8; null = unbegrenzt) dafür, wie weit vor der verbrauchten Watermark ein einzelner rückwirkender Schreibvorgang eine automatische Neuberechnung abhängiger Rollups zurückziehen darf. Der Detector begrenzt das automatische Dirty Window nach unten auf consumedWatermark - min(perArchiveCap, fleetCeiling); die flottenweite Obergrenze ist StreamData:Recompute:MaxRetroactiveReachHardLimitMs. Nur der automatische Pfad ist gedeckelt – manuelles recomputeArchive / rewindRollupWatermark bleiben unbegrenzt (AB#4196).
Generation
Die fensterbezogene Versionsnummer, die für den optimistischen atomaren Austausch verwendet wird. Vorwärts-Schreibvorgänge verwenden Generation 0; eine Neuberechnung berechnet in Generation N+1 und schwenkt anschließend den genmap-Zeiger darauf um. Die Spalte generation ist Teil des Primärschlüssels der CrateDB-Tabelle.
Source vs rollup archive
Ein Rollup-Archiv aggregiert aus einem Quellarchiv (auch Basisarchiv genannt) – entweder einem Raw- oder Time-Range-Archiv oder einem weiteren Rollup. Da ein Rollup selbst die Quelle für weitere Rollups sein kann, bilden diese Ketten (Rollup-of-Rollup).
Forward aggregation, Recompute, Rewind
Die drei Code-Pfade, die Rollup-Zeilen erzeugen oder ersetzen. Forward aggregation schließt den nächsten Bucket an der Watermark (eingeschwungener Zustand, append-only). Recompute aggregiert einen begrenzten [from, to)-Bereich als leser-sicheren atomaren Austausch neu. Rewind verschiebt die Watermark rückwärts, sodass der Vorwärtspfad erneut läuft (destruktiv).
Chain propagation
Nachdem die Neuberechnung eines Rollups erfolgreich war, werden die direkten abhängigen Rollups dieses Rollups als dirty markiert und neu berechnet, mit dem Trigger ChainPropagation. Dadurch wird eine Korrektur durch eine Rollup-of-Rollup-Kette vorwärts propagiert.
Coalesce
Überlappende Recompute-Trigger für dasselbe Archiv werden zu einem einzigen aktiven Job zusammengeführt; der verdrängte Trigger wird als Coalesced erfasst. Pro Archiv gibt es zu jedem Zeitpunkt höchstens eine aktive Neuberechnung.