Event-Sourced Digital Twin Platform | Dweve Twin

Twin is an event-sourced digital twin platform with three clocks on every event, branching scenarios and self-hosted operation. Publishing in round nine.

Twin ist eine event-sourced Digital-Twin-Plattform. Sie hält die operative Aufzeichnung in deinem Umfeld, damit du die Historie abspielen und nach einer Änderung Fragen beantworten kannst. Sie ist Open Source unter Apache-2.0 und erscheint in der neunten Runde von Dweves Foundation-Release-Programm, mit der Dokumentation unter docs.dweve.com am selben Tag.

Twin ist ein digitaler Zwilling für die Dinge, auf die Menschen sich verlassen: Jede Änderung bekommt eine Zeile, und die alten Zeilen bleiben erhalten.

Self-hosted auf betreiberkontrollierter Infrastruktur

Ein ereignisbasiertes digitales Abbild, bei dem das Protokoll die Aufzeichnung ist und jeder aktuelle Zustand aus der Historie abgeleitet wird.

Twin ist Open Source unter Apache-2.0. Es erscheint in der neunten Runde des Foundation-Release-Programms; sobald es das tut, betreiben Sie es auf Infrastruktur, die Sie kontrollieren, und fragen Sie die Vergangenheit direkt.

Behalten Sie die Aufzeichnung ab dem ersten Ereignis

Strukturierte operative Aufzeichnungen für verantwortungsvolle Systeme.

Simulationsmodelle, die mit dem operativen Zustand verbunden sind.

Eine Richtlinienoberfläche für den realen Betrieb.

Eine Zeit- oder Beziehungsabfrage ersetzt die Ereignishistorie nicht durch eine bequeme Antwort. Twin leitet die angeforderte Ansicht aus dieser Historie ab und macht den Weg durch Projektionen, Beziehungen und Zeit explizit.

Diese Trennung ist wichtig, wenn eine Projektion neu aufgebaut wird oder ein spätes Ereignis eintrifft. Dieselbe Frage kann erneut gegen die geänderte Historie ausgeführt werden, während die frühere Antwort an das gebunden bleibt, was zum Zeitpunkt ihrer Erstellung bekannt war.

Behalten Sie ihre Herkunft zu Ereignissen bei

Die Ansicht kann sich ändern, wenn sich die Historie ändert, ohne selbst zur Aufzeichnung zu werden.

Eine schnelle Antwort bleibt eine Lesart der Historie, niemals ein Ersatz für sie.

Dieselbe Person darf ein Asset möglicherweise während der Schicht sehen und nach Schichtende nicht mehr. Zuweisung, Standort und Zustand des Assets können neben der Rolle eine Rolle spielen, daher kann eine statische Berechtigungsliste nicht jede legitime Entscheidung beschreiben.

Twin bewertet diese Bedingungen gegen den aufgezeichneten operativen Zustand und behält die Entscheidung mit ihren Eingaben bei. Ein Prüfer kann sehen, wer gefragt hat, was zugewiesen war, welche Bedingungen galten und warum der Zugriff zu diesem Zeitpunkt erlaubt oder verweigert wurde.

Berechtigung ist ein bewertetes Ereignis, kein Schlüssel, der für immer hält.

Eine spätere Prüfung verwendet die Bedingungen, die mit der ursprünglichen Entscheidung aufgezeichnet wurden.

Twin hält sein Ereignis- und Beziehungsmodell getrennt von jedem einzelnen Industriestandard. Adapter können die bereits verwendeten Modelle lesen und schreiben, während der Kern eine konsistente Darstellung von Zeit, Herkunft und Änderung beibehält.

Nicht jedes Konstrukt hat eine exakte Entsprechung. Die Übergabe enthält daher einen Verlustbericht, der identifiziert, was dargestellt, was transformiert und was nicht übertragen werden konnte.

Die Interoperabilität bleibt überprüfbar, weil die Übersetzungsnachweise mit der Übergabe mitwandern.

Der Adapter macht den Unterschied explizit, statt ihn hinter einem erfolgreichen Export zu verstecken.

Ein Asset-, klinisches oder Prozessmodell bleibt Eigentum seiner Domäne. Twin akzeptiert es über einen Adapter und ergänzt Betriebshistorie, ohne dass die Organisation zuerst jedes bestehende Modell ersetzen muss.

Wenn Informationen wieder hinausgehen, erhält der Empfänger die Abbildung und ihre Grenzen. Ein Prüfer kann sehen, was in Twin eingegangen ist, was seine Form geändert hat und was ausgelassen wurde, bevor er die Übergabe genehmigt.

Die Domäne behält ihr Modell, während die Übergabe einen überprüfbaren Nachweis erhält.

Die Einführung beginnt bei den Modellen, die die Arbeit bereits tragen.

zwei erlaubt, drei abgelehnt mit Begründung

gleiche Identität, neue Entscheidung, veranschaulichend

Dem Wartungsvertrag pump-4471 an einem Standort zugewiesen

eine Identität, bei jeder Anfrage bewertet

Innerhalb des Vertrags, innerhalb der Schicht und am genehmigten Standort: Der Pumpenverlauf öffnet sich.

Ein zweiter Besuch unter denselben Bedingungen: Die Entscheidung wird erneut getroffen und das Ergebnis ist dasselbe, weil jede Bedingung weiterhin gilt.

Dieselbe Identität außerhalb der eingeteilten Schicht: abgelehnt. Nichts wurde widerrufen und niemand musste sich etwas merken; die Zeitbedingung schlug fehl, und die Ablehnung nennt das nächste gültige Zeitfenster.

{ "outcome": "refused", "policy": "next valid window", "severity": "warning" }

Anfrage nach dem Pumpenverlauf eines anderen Standorts

Der Pumpenverlauf des Nachbarstandorts liegt außerhalb des zugewiesenen Vertrags: abgelehnt, wobei die Grenze benannt wird statt eines stillen leeren Ergebnisses.

{ "outcome": "refused", "policy": "asset outside grant", "severity": "warning" }

Die Anfrage kommt von einem nicht genehmigten Standort: abgelehnt, und die Herkunft wird protokolliert, damit das Sicherheitsteam sie mit dem zugegriffenen Anlagenverlauf korrelieren kann.

{ "outcome": "refused", "policy": "request origin rejected", "severity": "warning" }

jede Ablehnung nennt die Bedingung, die fehlgeschlagen ist

Der Zugriff hängt von der Anfrage sowie von der Person ab. Twin bewertet Rolle, Zuweisung, Zeit und Standort gemeinsam und zeichnet den Grund auf, wenn eine Anfrage abgelehnt wird. Dieselbe Person kann unterschiedliche Antworten erhalten, wenn sich Schicht, Standort oder Asset ändern, ohne dauerhafte Rollenänderung. Die Entscheidung bleibt mit Subjekt, Ressource und fehlgeschlagener Bedingung für die spätere Überprüfung verbunden. Eine gewährte Überschreitung ist durch die Beziehung und das Zeitfenster begrenzt, die sie gerechtfertigt haben, und wird nicht zu einer breiten Rolle, die die ursprüngliche Aufgabe überdauert. Eine Ablehnung ist nützlicher Beleg, weil sie die Bedingung benennt, die ein Bediener korrigieren oder anfechten kann. Für eine Änderung der Antwort muss keine dauerhafte Rolle geändert werden.

Behalte den Datensatz. Leite den Zustand ab. Frag die Vergangenheit direkt.

Identität und Rolle sind nur ein Teil der Frage. Twin kann auch Zuweisung, Zeit, Standort, Gerät und Richtlinienbedingungen bewerten, wenn eine Person eine Seite oder einen Asset-Verlauf anfordert. Jede dieser Bedingungen wird im Moment der Anfrage geprüft.

Dieselbe Person kann in der Schicht zugelassen und später abgelehnt werden, ohne dass sich eine dauerhafte Rolle ändert. Die Entscheidung zeichnet Subjekt, Ressource, Zeit und fehlgeschlagene Regel auf, sodass eine abgelehnte Anfrage keine unerklärte Sackgasse darstellt. Ein späterer Prüfer kann daher die Schicht sehen, die den Unterschied ausgemacht hat.

Eine Ablehnung erklärt die fehlgeschlagene Bedingung

Der Datensatz behält die Änderung, ihren Kontext und die darauf folgende Entscheidung.

Historie am Tag geschrieben, illustrativ

nachträglich zusammengesetzt, aus dem, was übrig ist, von wem auch immer

Was hat das Asset im März getan, und was war damals bekannt?

dasselbe Intervall, Befehl mit Ergebnis verknüpft

eine Historie, mehrere zeitliche Lesarten

Wenn jemand im Juli fragt, warum eine Entscheidung im März getroffen wurde, muss die Antwort der März-Verlauf sein, nicht eine Rekonstruktion aus heutigen Exporten. Twin bewahrt den relevanten Nachweissatz zusammen mit der Entscheidung auf. Die Frage kann auswählen, was damals bekannt war, welche Regel damals galt und welche Korrektur später eintraf. So verhindert eine faire Prüfung, dass heutiges Wissen zu gestriger Gewissheit wird. Die Antwort trägt ihre Quellereignisse und Herkunft neben der Schlussfolgerung, sodass ein anderer Prüfer die Frage wiederholen kann, statt der ersten Erklärung zu vertrauen. Eine spätere Korrektur bleibt sichtbar, ohne die März-Entscheidung aus dem Kontext zu reißen.

Verlauf bewahren. Zustand ableiten. Vergangenheit direkt fragen.

Eine Prüfungsfrage kann nach dem Stand von März fragen, nach den Informationen, die an einem bestimmten Tag bekannt waren, oder nach der damals geltenden Regel. Twin erstellt die passende Lesart aus beibehaltenen Ereignissen, statt Menschen zu bitten, sie aus Exporten zu rekonstruieren.

Die Antwort behält ihre zeitliche Form, Quellereignisse und Herkunft sichtbar neben der Schlussfolgerung. Ein Prüfer kann die Frage wiederholen und verstehen, warum eine spätere Korrektur in eine Antwort gehört, in eine andere jedoch nicht.