Be Water Core · Fonctions et spécifications
Des membres clés de l’équipe ont déployé des plateformes iDOS et des applications métier dans des projets industriels. Be Water transforme ces technologies, modèles et méthodes en produits plus faciles à déployer, mettre à jour et maintenir.
Core associe les objets industriels, la qualité des données et les calculs d’ingénierie pour servir de base aux applications. Consultez les fonctions prévues, les interfaces, les modes de déploiement et les charges de référence pour un usage avec Work, vos systèmes existants ou les applications de partenaires.
| Fonction | Capacité prévue | Limites de configuration |
|---|---|---|
| Objets industriels et faits | Objets, relations physiques, dépendances de calcul, responsabilités et faits versionnés avec leurs dates d’effet | Construire les objets et relations nécessaires à l’application choisie ; un modèle complet de l’usine n’est pas un préalable. |
| Préparation et qualité des données | Correspondances des sources, contrôles d’unités et de conditions de référence, horodatages, état d’exploitation et propagation de la qualité | Distinguer valeurs mesurées, calculées et estimées ; conserver les valeurs sources et les versions de correspondance. |
| Calculs métier | Formules et règles, méthodes statistiques et prévisionnelles, modèles dynamiques de procédés, optimisation sous contraintes | Chaque ensemble déclare ses entrées, conditions d’application, dépendances et responsable métier de maintenance. Solveurs complexes et modèles externes sont validés séparément. |
| Cycle de vie des modèles | Ensembles versionnés, réexécution sur des données historiques, évaluation des versions candidates, fonctionnement parallèle sans action, mise en service maîtrisée et retour arrière | Une version candidate peut être évaluée sans obtenir le droit d’agir sur les équipements. |
| Configuration et développement | Édition d’objets et de relations, propositions de correspondance, examen des paramètres et résultats, SDK et outils de test | Des vues de configuration stables servent le travail courant ; code et outils de débogage soutiennent le développement. |
| Accès et gouvernance | Périmètres par locataire, site, objet et action ; intégration d’identité d’entreprise ; droits d’usage des modèles et données | Lecture, calcul, simulation, publication et demande d’action ont des permissions distinctes. |
| Visibilité sur le fonctionnement | Fraîcheur des sources, défaillances des modèles, files d’attente, usage des ressources, santé des dépendances et état des versions | Examiner séparément défauts de qualité des données et défaillances des services. |
Il s’agit du périmètre logiciel prévu pour Core. La configuration livrée précise modules, ensembles de modèles, connecteurs et versions compatibles inclus ; le tableau ne liste pas des logiciels déjà disponibles.
Pour être utile, un calcul doit tenir compte de ce que représente chaque valeur et de la place de l’objet concerné dans l’exploitation. Modélisez la partie de l’installation nécessaire à l’application choisie, puis étendez ce modèle à mesure que les besoins évoluent.
Équipement · matière · procédé
Représentez approvisionnement, écoulements, conversion, emplacement et inclusion, avec leur sens et leur validité. Un réseau de vapeur, un lot de production et une hiérarchie d’équipements nécessitent des relations différentes.
Entrées · méthode · résultat
Conservez la trace des observations, paramètres et versions de modèles à l’origine d’un résultat. Représentez séparément les boucles physiques et les rétroactions de calcul.
Responsable · approbateur · exécutant
Reliez chaque objet d’exploitation aux personnes, aux rôles et aux tâches qui en sont responsables. Conservez l’historique des responsabilités lors des changements d’équipe ou de prestataire.
Les objets conservent une identité stable entre les systèmes sources. Les dates d’effet et les révisions enregistrées permettent une correction ultérieure sans effacer les preuves utilisées pour une décision antérieure.
| Contexte | Les informations à connaître | Pourquoi cela change le résultat |
|---|---|---|
| Identité et origine | Site, objet, système source et version des correspondances | Deux signaux aux noms proches peuvent appartenir à des équipements ou sites différents. |
| Grandeurs et unités | Valeur et unité d’origine, type de grandeur, conversion et conditions de référence | Pression relative et pression absolue diffèrent ; les volumes de gaz normalisés doivent préciser leur température et pression de référence. |
| Temps | Heures de source et de réception, intervalle d’échantillonnage et délai de procédé pertinent | Aligner les horloges ne supprime pas le temps de transit des matières ou de l’énergie dans un procédé. |
| Qualité et incertitude | Qualité de la source, valeurs absentes ou périmées, étalonnage et incertitude connue | Une valeur maintenue n’est pas une nouvelle mesure. Les valeurs mesurées, calculées et estimées doivent être distinguées. |
| Conditions d’exploitation | État des équipements, isolement, mode du procédé et limites applicables | Un modèle valable dans une condition d’exploitation peut ne pas convenir dans une autre. |
| Version des preuves | Instantané des entrées, version du document et exécution du modèle | La personne chargée de l’examen doit pouvoir vérifier les fondements d’un résultat et distinguer une révision ultérieure. |
L’environnement d’exécution prévu vérifie les données d’entrée nécessaires et tient compte de leur qualité dans les résultats. Si les conditions de référence manquent ou si l’état de fonctionnement ne convient pas, la méthode concernée peut être bloquée pendant que les autres travaux continuent.
Core est conçu pour exécuter des formules, des règles, des modèles statistiques, des modèles dynamiques de procédés et des calculs d’optimisation sous contraintes. Chaque méthode doit préciser où elle s’applique et qui la maintient. Un fichier de modèle ne suffit pas, à lui seul, pour réaliser un travail industriel.
Précisez les données d’entrée, les unités, les conditions de référence, la plage de fonctionnement valide, les paramètres, les résultats attendus et le spécialiste responsable de la méthode.
Choisissez une plage de données adaptée et vérifiez qualité, fraîcheur, état et relations requises avant le calcul.
Ordonnez les calculs interdépendants et gérez les états dynamiques, les rétroactions et les délais des procédés. Conservez les instantanés des entrées et les versions.
Rendez visibles hypothèses, qualité, contraintes et conditions d’échec. Une proposition d’optimisation reste distincte de l’autorisation d’agir.
Comparez aux exemples de référence et aux résultats observés, détectez les dérives, évaluez les changements proposés et approuvez leur mise en service ou le retour à la version précédente.
Les modèles des clients et partenaires peuvent rester dans leurs services existants. Les intégrations prévues incluent API, conteneurs et adaptateurs FMI/FMU validés ; compatibilité et besoins d’exécution sont déterminés pour chaque modèle.
| Interface | Spécification prévue | Conditions d’intégration |
|---|---|---|
| Entrées par fichiers et par lots | CSV, Parquet, JSON et lectures par lots depuis bases de données ou API ; Excel via un analyseur restreint | Les macros Excel ne sont pas exécutées. Périmètre initial de référence des imports : fichiers jusqu’à 1 Go et lots jusqu’à 1 million de lignes ; les entrées plus volumineuses sont traitées par blocs asynchrones. |
| Plateformes de données existantes | Requêtes vers des systèmes d’historisation ou des API, références d’objets externes, cache à la demande et synchronisation incrémentale | Les systèmes existants peuvent rester sources de référence ; limites des sources, qualité des horodatages et fraîcheur du cache sont consignées. |
| API HTTP | OpenAPI 3.1 et JSON Schema ; interfaces d’objets, d’observations, de calculs et de résultats | Distinguer lecture, simulation, enregistrement, publication et demande d’action ; les travaux asynchrones renvoient une référence d’exécution. |
| Événements | Schémas d’événements versionnés avec identité, séquence, heure de l’événement et référence de traçage | Séparation par locataire, site et type ; livraison au moins une fois, avec déduplication par le consommateur. |
| SDK de développement | Python et TypeScript ; interfaces typées, outils d’unités, exemples et outils de simulation | La compatibilité visée couvre la version majeure actuelle du SDK et la précédente. Les versions exactes d’exécution et de dépendances relèvent de la matrice de compatibilité du déploiement. |
| Modèles métier externes | Services REST/gRPC, conteneurs OCI signés et adaptateurs FMI/FMU validés | L’intégration FMI initiale se concentre sur FMI 2/3 Co-Simulation. Solveur, état, temporalité et exigences de licence sont validés pour chaque modèle. |
| Adaptateurs d’identité et d’outils | OIDC/SAML d’entreprise via un service d’identité validé ; adaptateurs MCP facultatifs sur des API soumises aux règles de gouvernance | MCP n’élargit pas les droits de l’appelant sur les données, les calculs ou les actions. |
Les interfaces et formats sont des spécifications visées. Adaptateurs de modèles, versions des systèmes sources et dépendances sont confirmés pour le déploiement choisi ; la compatibilité d’un format ne prouve pas la validité d’un modèle métier.
| Option | Organisation de l’exécution | Éléments à définir |
|---|---|---|
| SaaS régional | Services régionaux administrés et intégrations externes approuvées | Localisation des données, destinations autorisées, connexions aux sources et périmètre de service retenu. |
| Cloud privé du client | Services Core dans l’environnement cloud choisi par le client | Intégration d’identité, chemins réseau, base de données et stockage objet, sauvegardes et responsabilités d’exploitation. |
| Serveur de site | Services et stockage locaux ; Linux x86-64 est l’environnement hôte de référence | Validation de l’hôte, du stockage et du réseau pour la charge choisie, avec procédures de sauvegarde et de reprise. |
| Exécution Edge limitée | Un sous-ensemble local de services d’objets et de calcul aux côtés d’Edge | Capacités incluses et budget de ressources ; cela ne correspond pas automatiquement au profil Core complet d’un site standard. |
| Plateforme industrielle existante | Environnement d’exécution de modèles, ensembles de capacités et adaptateurs choisis avec la plateforme actuelle | Responsabilité des champs, interfaces sources, dépendances des modèles et système conservant chaque enregistrement. |
La localisation des données et les chemins vers les services externes sont choisis explicitement. Les versions de système d’exploitation, base de données, conteneurs et connecteurs sont fixées dans la matrice de compatibilité, sans être déduites de ces catégories de déploiement.
| Profil | Ressources de référence | Charge de travail à valider |
|---|---|---|
| Configuration légère pour un site | 8 vCPU, 32 Go de RAM et 1–2 To de stockage, ou un environnement local E-M validé | Périmètre d’objets ou de modèles, ou rétention, réduits, notamment lorsqu’un système d’historisation existant conserve les données. Ce n’est pas la charge CL-1 complète. |
| CL-1 · site standard | 16 vCPU, 64 Go de RAM et 8 To de stockage utilisable ; Linux x86-64 | 50 000 objets, 500 000 relations, 20 000 points et 5 000 mises à jour/s ; 100 utilisateurs inscrits, dont 30 simultanés, avec 20 requêtes API ordinaires/s et la charge déclarée de petits modèles. |
| CL-10 · déploiement régional | Dimensionnement initial : six instances de traitement, chacune avec 16 vCPU et 64 Go de RAM ; services de base de données et de stockage objet séparés, avec trois répliques | Jusqu’à dix sites CL-1, 50 000 mises à jour/s au total et 100 utilisateurs simultanés. Politique d’envoi, rétention et validation indépendante de la capacité déterminent le cluster final. |
Tous les chiffres correspondent à des charges visées ou de référence non testées. Ressources et charge doivent être validées ensemble, avec autorisations, requêtes et exécution des modèles activées. Les 8 To représentent la capacité utilisable après redondance, pas la somme de disques en miroir. Les E/S de stockage et la bande passante nécessitent une validation ; vidéos, formes d’onde brutes à haute fréquence et simulations volumineuses sont exclues de ces profils standard.
| Domaine | Comportement prévu | Détail de configuration ou de transfert |
|---|---|---|
| État des modèles et redémarrage | Enregistrer des points de reprise pour les modèles avec état ; vérifier paramètres, versions d’état et entrées manquantes avant la reprise | Réinitialisez le modèle ou observez le procédé lorsqu’un état périmé ne permet plus de représenter les conditions actuelles en toute sécurité. |
| Sauvegarde et reprise | Sauvegarde quotidienne avec options incrémentales ; restaurer configurations, objets, versions de modèles, autorisations et preuves | Hôte unique, redondance et reprise après sinistre de site sont des dispositifs distincts ; convenir du lieu de sauvegarde, de l’environnement de remplacement et du périmètre de reprise. |
| Rétention | Politique de référence : 30 jours de séries temporelles brutes du site et 13 mois d’agrégats à la minute | La rétention peut être ajustée ; modèles, configurations et preuves importantes du travail suivent la politique convenue. |
| Mises à jour et compatibilité | Versionner code, modèles, configurations, dictionnaires et connecteurs avec une matrice de compatibilité commune | Identifier les applications touchées à partir de l’impact des changements ; conserver des versions compatibles lors des mises en service et retours arrière. |
| Export des données du client | JSON, CSV et Parquet avec descriptions des schémas | Exporter objets, relations, unités, horodatages, données et configurations clients, preuves d’exécution des modèles et fichiers de modèles autorisés par les licences. |
| Éléments remis à la livraison | Manifeste de déploiement, schémas d’objets et de données, interfaces, ensembles logiciels déclarés, ressources API/SDK et matrice de compatibilité | Inclure outils de sauvegarde, de reprise et d’export, données d’exemple et responsabilités de maintenance. |
Les engagements de reprise et les périodes de maintenance sont définis pour le déploiement retenu. La rétention de référence est un choix de conception, pas une règle juridique universelle ; les licences continuent à régir les fichiers de modèles transférables.