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.

Groupes d'algorithmes par type de données

Twin est une plateforme de jumeaux numériques à source d'événements. Elle conserve le registre opérationnel sur votre infrastructure afin que vous puissiez rejouer l'historique et répondre aux questions après un changement. Elle est open source sous licence Apache-2.0 et est publiée dans le neuvième cycle du programme de publication de la fondation Dweve, avec sa documentation sur docs.dweve.com le même jour.

Twin est un jumeau numérique pour les choses dont les gens dépendent : chaque changement reçoit une ligne et les anciennes lignes restent.

Auto-hébergé sur une infrastructure contrôlée par l'opérateur

Un jumeau numérique à base d'événements où le journal est la référence et où chaque état actuel est dérivé de l'historique.

Twin est open source sous licence Apache-2.0. Il sera publié lors du neuvième cycle du programme de publication de la fondation ; une fois publié, exécutez-le sur une infrastructure que vous contrôlez et interrogez directement le passé.

Conserver l'enregistrement dès le premier événement

Enregistrements opérationnels structurés pour des systèmes responsables.

Modèles de simulation connectés à l'état opérationnel.

Une surface de politique pour les opérations réelles.

Une requête temporelle ou relationnelle ne remplace pas l'historique des événements par une réponse pratique. Twin dérive la vue demandée de cet historique et rend explicite le chemin à travers les projections, les relations et le temps.

Cette séparation compte lorsqu'une projection est reconstruite ou qu'un événement tardif arrive. La même question peut être relancée sur l'historique modifié, tandis que la réponse précédente reste liée à ce qui était connu au moment où elle a été produite.

conserver sa lignée jusqu'aux événements

La vue peut changer lorsque l'historique change sans devenir elle-même l'enregistrement.

Une réponse rapide reste une lecture de l'historique, jamais un remplacement.

La même personne peut être autorisée à voir un actif pendant son service et refusée après la fin de celui-ci. L'affectation, la localisation et l'état de l'actif peuvent compter en plus du rôle, donc une liste de permissions statique ne peut pas décrire chaque décision légitime.

Twin évalue ces conditions par rapport à l'état opérationnel enregistré et conserve la décision avec ses entrées. Un réviseur peut voir qui a demandé, ce qui lui était affecté, quelles conditions s'appliquaient et pourquoi l'accès a été autorisé ou refusé à ce moment-là.

La permission est un événement évalué, pas une clé qui dure éternellement.

Un audit ultérieur utilise les conditions enregistrées avec la décision d'origine.

Twin maintient son modèle d'événements et de relations séparé de toute norme industrielle particulière. Les adaptateurs peuvent lire et écrire les modèles déjà utilisés, tandis que le noyau conserve un compte cohérent du temps, de la provenance et des changements.

Tous les concepts n'ont pas d'équivalent exact. Le transfert inclut donc un rapport de perte qui identifie ce qui a été représenté, ce qui a été transformé et ce qui n'a pas pu être conservé.

L'interopérabilité reste vérifiable car les preuves de traduction accompagnent le transfert.

L'adaptateur rend la différence explicite au lieu de la cacher derrière une exportation réussie.

Un actif, un modèle clinique ou de processus reste la propriété de son domaine. Twin l'accepte via un adaptateur et ajoute un historique opérationnel sans demander à l'organisation de remplacer d'abord tous ses modèles existants.

Lorsque l'information ressort, le destinataire obtient le mapping et ses limites. Un réviseur peut voir ce qui est entré dans Twin, ce qui a changé de forme et ce qui a été omis avant d'approuver le transfert.

Le domaine conserve son modèle tandis que le transfert gagne un enregistrement vérifiable.

L'adoption commence à partir des modèles qui portent déjà le travail.

deux autorisés, trois refusés avec motifs

même identité, nouvelle décision, illustratif

Affecté au contrat de maintenance de la pompe-4471 sur un site

depuis le bureau du site, dans le créneau

Dans le contrat, dans le créneau et sur le site approuvé : l'historique de la pompe s'ouvre.

Une deuxième visite dans les mêmes conditions : la décision est prise à nouveau et la réponse est identique, car toutes les conditions sont toujours remplies.

La même identité hors du créneau planifié : refusé. Rien n'a été révoqué et personne n'a eu à se souvenir de quoi que ce soit ; la condition de temps a échoué, et le refus indique la prochaine fenêtre valide.

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

demande de l'historique de la pompe d'un autre site

historique de la pompe-2210, deuxième site

L'historique de la pompe du site voisin est hors du contrat assigné : refusé, avec la limite nommée plutôt qu'un résultat vide silencieux.

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

La demande provient d'un emplacement non approuvé : refusé, et l'origine est enregistrée pour que l'équipe de sécurité puisse la corréler avec l'historique de l'actif consulté.

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

chaque refus indique la condition qui a échoué

habilitation au niveau ou au-dessus de la valeur

L'accès dépend de la demande ainsi que de la personne. Twin évalue le rôle, l'assignation, le temps et la localisation ensemble, puis enregistre la raison lorsqu'une demande est refusée. La même personne peut recevoir des réponses différentes selon le créneau, le site ou l'actif, sans mutation permanente de rôle. La décision reste attachée au sujet, à la ressource et à la condition non satisfaite pour un examen ultérieur. Une traversée accordée est bornée par la relation et la fenêtre temporelle qui l'ont justifiée, plutôt que de devenir un rôle large qui survit à la tâche d'origine. Un refus est une preuve utile car il nomme la condition qu'un opérateur peut corriger ou contester. Aucun rôle permanent ne doit changer pour que la réponse change.

Conservez l'enregistrement. Déduisez l'état. Interrogez le passé directement.

Uniquement en service, uniquement sur site

L'identité et le rôle ne sont qu'une partie de la question. Twin peut également évaluer les conditions d'assignation, de temps, de localisation, d'appareil et de politique lorsqu'une personne demande une page ou un historique d'actif. Chacune de ces conditions est vérifiée au moment de la demande.

La même personne peut être autorisée en service et refusée plus tard sans qu'aucun rôle permanent ne change. La décision enregistre le sujet, la ressource, le temps et la règle non satisfaite, de sorte qu'une demande refusée ne devient pas une impasse inexpliquée. Un examinateur ultérieur peut donc voir le créneau qui a fait la différence.

Un refus explique la condition non satisfaite

L'enregistrement conserve le changement, son contexte et la décision qui a suivi.

historique écrit le jour même, à titre illustratif

assemblé après coup, à partir de qui et de ce qui reste

qu'a fait l'actif en mars, et que savait-on alors

le même intervalle, commande liée au résultat

un historique, plusieurs lectures temporelles

Quand quelqu'un demande en juillet pourquoi une décision de mars a été prise, la réponse doit être le registre de mars, pas une reconstruction à partir des exports d'aujourd'hui. Twin préserve l'ensemble de preuves pertinent avec la décision. La question peut sélectionner ce qui était connu alors, quelle règle s'appliquait alors et quelle correction est arrivée plus tard. Cela évite qu'un examen équitable transforme les connaissances d'aujourd'hui en certitude d'hier. La réponse porte ses événements sources et sa lignée à côté de la conclusion, afin qu'un autre examinateur puisse répéter la question au lieu de se fier à la première explication. Une correction ultérieure reste visible sans sortir la décision de mars de son contexte.

Conservez le registre. Déduisez l'état. Interrogez le passé directement.

Une question d'audit peut demander l'état de mars, les informations connues à une date donnée ou la règle alors en vigueur. Twin reconstruit la lecture appropriée à partir des événements conservés au lieu de demander aux gens de la reconstruire à partir des exports.

La réponse garde sa forme temporelle, ses événements sources et sa lignée visibles à côté de la conclusion. Un examinateur peut répéter la question et comprendre pourquoi une correction ultérieure appartient à une réponse mais pas à une autre.