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 to platforma cyfrowych bliźniaków oparta na zdarzeniach. Przechowuje rejestr operacyjny w Twoim środowisku, dzięki czemu możesz odtwarzać historię i odpowiadać na pytania po zmianie. Jest open source na licencji Apache-2.0 i publikuje w dziewiątej rundzie programu wydań fundamentowych Dweve, z dokumentacją na docs.dweve.com tego samego dnia.
Twin to cyfrowy bliźniak rzeczy, na których ludzie polegają: każda zmiana dostaje linię, a stare linie pozostają.
Hostowane samodzielnie na infrastrukturze kontrolowanej przez operatora
Cyfrowy bliźniak oparty na zdarzeniach, gdzie dziennik jest rejestrem, a każdy bieżący stan jest wyprowadzany z historii.
Bliźniak jest open source na licencji Apache-2.0. Publikuje w dziewiątej rundzie programu wydawniczego fundacji; gdy to nastąpi, uruchom go na infrastrukturze, którą kontrolujesz, i pytaj przeszłość bezpośrednio.
Zachowaj rejestr od pierwszego zdarzenia
Strukturalne rejestry operacyjne dla systemów odpowiedzialnych.
Modele symulacyjne, które łączą się ze stanem operacyjnym.
Powierzchnia polityki dla rzeczywistych operacji.
Zapytanie czasowe lub relacyjne nie zastępuje historii zdarzeń wygodną odpowiedzią. Bliźniak wyprowadza żądany widok z tej historii i utrzymuje jawną ścieżkę przez projekcje, relacje i czas.
To rozróżnienie ma znaczenie, gdy projekcja jest przebudowywana lub nadchodzi późne zdarzenie. To samo pytanie można uruchomić ponownie wobec zmienionej historii, podczas gdy wcześniejsza odpowiedź pozostaje powiązana z tym, co było znane w momencie jej tworzenia.
Możliwa do sprawdzenia ścieżka zapytania
Widok może się zmienić, gdy zmienia się historia, bez stawania się samym rejestrem.
Szybka odpowiedź pozostaje odczytem historii, nigdy jej zastępstwem.
Ta sama osoba może mieć pozwolenie na widzenie zasobu podczas zmiany i odmowę po jej zakończeniu. Przydział, lokalizacja i stan zasobu mogą mieć znaczenie obok roli, więc statyczna lista uprawnień nie może opisać każdej uzasadnionej decyzji.
Bliźniak ocenia te warunki wobec zarejestrowanego stanu operacyjnego i przechowuje decyzję wraz z jej danymi wejściowymi. Recenzent może zobaczyć, kto pytał, co było mu przydzielone, które warunki miały zastosowanie i dlaczego dostęp został przyznany lub odmówiony w danym czasie.
Uprawnienie to ocenione zdarzenie, nie klucz, który trwa wiecznie.
Późniejszy audyt używa warunków zarejestrowanych z pierwotną decyzją.
Bliźniak utrzymuje swój model zdarzeń i relacji oddzielnie od jakiegokolwiek standardu branżowego. Adaptery mogą czytać i zapisywać modele już używane, podczas gdy jądro zachowuje jeden spójny zapis czasu, pochodzenia i zmian.
Nie każda konstrukcja ma dokładny odpowiednik. Przekazanie obejmuje zatem raport strat, który identyfikuje, co było reprezentowane, co zostało przekształcone, a czego nie można było przenieść.
Interoperacyjność pozostaje możliwa do przeglądu, ponieważ dowody tłumaczenia podróżują wraz z przekazaniem.
Adapter czyni różnicę jawną zamiast ukrywać ją za udanym eksportem.
Uczyń przekazanie możliwym do sprawdzenia.
Model zasobu, kliniczny lub procesowy pozostaje własnością swojej domeny. Twin przyjmuje go przez adapter i dodaje historię operacyjną, nie wymagając od organizacji zastąpienia wszystkich istniejących modeli.
Gdy informacje wracają, odbiorca otrzymuje odwzorowanie i jego ograniczenia. Osoba przeglądająca może zobaczyć, co weszło do Twin, co zmieniło formę, a co zostało pominięte, zanim zatwierdzi przekazanie.
Domena zachowuje swój model, a przekazanie zyskuje możliwy do przeglądu zapis.
Wdrożenie zaczyna się od modeli, które już niosą pracę.
dwa dozwolone, trzy odmowy z podaniem przyczyn
ta sama tożsamość, świeża decyzja, poglądowo
Przypisany do umowy serwisowej pompy-4471 w jednym obiekcie
jedna tożsamość, oceniana przy każdym żądaniu
W ramach umowy, w trakcie zmiany i w zatwierdzonym obiekcie: historia pompy się otwiera.
Druga wizyta na tych samych warunkach: decyzja jest podejmowana ponownie i odpowiedź jest taka sama, bo każdy warunek nadal obowiązuje.
Ta sama tożsamość poza zaplanowaną zmianą: odmowa. Nic nie zostało cofnięte i nikt nie musiał niczego pamiętać; warunek czasu nie został spełniony, a odmowa wskazuje następny ważny przedział.
CEF:0|Dweve|Twin|access|refused|warning|subject=maintenance contractor resource=pump-4471 history policy=next valid window
LEEF:2.0|Dweve|Twin|access|refused|subject=maintenance contractor|resource=pump-4471 history|policy=next valid window
{ "outcome": "refused", "policy": "next valid window", "severity": "warning" }
prośba o historię pompy z innego obiektu
Historia pompy z sąsiedniego obiektu leży poza przypisaną umową: odmowa, z nazwaną granicą zamiast cichego pustego wyniku.
CEF:0|Dweve|Twin|access|refused|warning|subject=maintenance contractor resource=pump-2210 history policy=asset outside grant
LEEF:2.0|Dweve|Twin|access|refused|subject=maintenance contractor|resource=pump-2210 history|policy=asset outside grant
{ "outcome": "refused", "policy": "asset outside grant", "severity": "warning" }
Żądanie przychodzi z niezatwierdzonej lokalizacji: odmowa, a źródło jest rejestrowane, aby zespół bezpieczeństwa mógł je skorelować z dostępowaną historią zasobu.
CEF:0|Dweve|Twin|access|refused|warning|subject=maintenance contractor source=external gateway policy=request origin rejected
LEEF:2.0|Dweve|Twin|access|refused|subject=maintenance contractor|source=external gateway|policy=request origin rejected
{ "outcome": "refused", "policy": "request origin rejected", "severity": "warning" }
każda odmowa wskazuje warunek, który nie został spełniony
dopuszczenie na poziomie wartości lub wyższym
Dostęp zależy zarówno od żądania, jak i od osoby. Twin ocenia rolę, przypisanie, czas i lokalizację łącznie, a następnie rejestruje powód odmowy żądania. Ta sama osoba może otrzymać różne odpowiedzi w zależności od zmiany zmiany, lokalizacji lub zasobu, bez trwałej zmiany roli. Decyzja pozostaje powiązana z podmiotem, zasobem i niespełnionym warunkiem do późniejszego przeglądu. Przyznane przejście jest ograniczone relacją i oknem czasowym, które je uzasadniły, zamiast stawać się szeroką rolą wykraczającą poza pierwotne zadanie. Odmowa jest wartościowym dowodem, ponieważ wskazuje warunek, który operator może skorygować lub zakwestionować. Żadna stała rola nie musi się zmienić, aby odpowiedź się zmieniła.
Zachowaj zapis. Wyprowadź stan. Pytaj przeszłość bezpośrednio.
Tożsamość i rola to tylko część zagadnienia. Twin może również oceniać warunki przypisania, czasu, lokalizacji, urządzenia i polityki, gdy osoba prosi o stronę lub historię zasobu. Każdy z tych warunków jest sprawdzany w momencie żądania.
Ta sama osoba może mieć dostęp podczas zmiany, a później zostać odrzucona bez żadnej trwałej zmiany roli. Decyzja rejestruje podmiot, zasób, czas i niespełnioną regułę, więc odrzucone żądanie nie staje się niewyjaśnionym ślepym zaułkiem. Późniejszy recenzent może zatem zobaczyć zmianę, która miała znaczenie.
Rekord zachowuje zmianę, jej kontekst i decyzję, która po niej nastąpiła.
historia zapisana w dniu zdarzenia, poglądowa
złożona później, z tego, co i kto pozostał
co robił zasób w marcu i co wtedy było wiadomo
ten sam przedział, polecenie powiązane z wynikiem
jedna historia, kilka odczytów czasowych
nic nie musi być najpierw rekonstruowane
Gdy ktoś w lipcu pyta, dlaczego w marcu podjęto decyzję, odpowiedzią musi być zapis z marca, a nie rekonstrukcja z dzisiejszych eksportów. Twin zachowuje odpowiedni zestaw dowodów wraz z decyzją. Pytanie może wybrać, co było wtedy znane, która reguła obowiązywała wtedy i która korekta nadeszła później. To sprawia, że rzetelna kontrola nie zamienia dzisiejszej wiedzy w wczorajszą pewność. Odpowiedź niesie ze sobą źródłowe zdarzenia i pochodzenie obok wniosku, więc inny recenzent może powtórzyć pytanie zamiast ufać pierwszemu wyjaśnieniu. Późniejsza korekta pozostaje widoczna bez wyrywania marcowej decyzji z kontekstu.
Zachowaj zapis. Wyprowadź stan. Pytaj o przeszłość bezpośrednio.
Pytanie audytowe może dotyczyć stanu z marca, informacji znanych w danym dniu lub reguły obowiązującej wtedy. Twin odtwarza właściwe odczytanie z zachowanych zdarzeń zamiast prosić ludzi o rekonstrukcję z eksportów.
Odpowiedź zachowuje swoją formę czasową, źródłowe zdarzenia i pochodzenie widoczne obok wniosku. Recenzent może powtórzyć pytanie i zrozumieć, dlaczego późniejsza korekta należy do jednej odpowiedzi, a nie do drugiej.
Twin zachowuje zdarzenie, jego kontekst i decyzję, którą wspierał, w jednym rekordzie operacyjnym.
Zachowaj rekord. Wyprowadź stan. Pytaj przeszłość bezpośrednio.
Dziennik zdarzeń zachowuje fakt i czas, w którym nastąpił.
Widok wyprowadzony może pozostać szybki, a każda historyczna odpowiedź pozostaje możliwa do prześledzenia.
Zapisane zdarzenie może odpowiedzieć na pytanie, którego nikt nie wiedział, że zada w dniu jego zapisu. Odpowiedź nadal pokazuje, co się wydarzyło, co było wiadome w danym czasie oraz kto lub która reguła ukształtowała wynik.
Ta sama pamięć operacyjna wspiera przegląd, decyzję o dostępie, kontrolę pochodzenia i scenariusz. Te zastosowania współdzielą rekord; nie przepisują go dla każdego odbiorcy.