Be Water Core · Funzionalità e specifiche
Membri chiave del team hanno realizzato piattaforme iDOS e applicazioni specialistiche in progetti industriali. Be Water sviluppa queste tecnologie, modelli ed esperienze in prodotti più facili da installare, aggiornare e mantenere.
Core collega gli oggetti industriali ai relativi dati e ai calcoli ingegneristici, tenendo conto della qualità dei dati. Questi elementi permettono alle applicazioni di lavorare su una base coerente. Esaminate le funzioni previste, le interfacce, le opzioni di installazione e i carichi di riferimento per l’uso con Work, sistemi esistenti o applicazioni dei partner.
| Funzione | Capacità prevista | Limiti di configurazione |
|---|---|---|
| Oggetti e fatti industriali | Oggetti, relazioni fisiche, dipendenze tra calcoli, responsabilità e informazioni versionate con date di validità | Costruite oggetti e relazioni richiesti dall’applicazione scelta; un modello completo della fabbrica non è un prerequisito. |
| Preparazione e qualità dei dati | Mappatura delle fonti, verifiche di unità e condizioni di riferimento, orari, stato operativo e propagazione della qualità | Distinguete valori misurati, calcolati e stimati; conservate valori sorgente e versioni delle mappature. |
| Calcolo specialistico | Formule e regole, metodi statistici e previsionali, modelli dinamici di processo, ottimizzazione vincolata | Ogni pacchetto specifica dati in ingresso, condizioni di applicabilità, dipendenze e un responsabile della manutenzione con le competenze necessarie. I solutori complessi e i modelli esterni richiedono verifiche separate. |
| Ciclo di vita dei modelli | Pacchetti versionati, riproduzione dello storico, valutazione di candidati, esecuzione in ombra, messa in uso controllata e ripristino | Un candidato può essere valutato senza ottenere l’autorizzazione ad agire sulle apparecchiature. |
| Configurazione e sviluppo | Modifica di oggetti e relazioni, proposte di mappatura, esame di parametri e risultati, SDK e strumenti di prova | Le interfacce di configurazione stabili servono per le attività ordinarie; codice e strumenti di debug supportano lo sviluppo. |
| Accesso e governance | Ambiti di tenant, sito, oggetto e azione; integrazione delle identità aziendali; autorizzazioni d’uso di modelli e dati | Le autorizzazioni a leggere, calcolare, simulare, pubblicare e richiedere azioni sono distinte. |
| Visibilità operativa | Aggiornamento delle fonti, errori dei modelli, code, uso delle risorse, stato delle dipendenze e delle versioni | Esaminate separatamente errori di qualità dei dati e guasti dei servizi. |
Questo è l’ambito previsto del software Core. La configurazione di fornitura identifica moduli, pacchetti di modelli, connettori e versioni di compatibilità inclusi; la tabella non elenca software già rilasciato.
Per eseguire un calcolo utile occorre sapere che cosa descrive ogni valore e come l’oggetto corrispondente si collega all’attività. Modellate la parte dell’impianto o del processo necessaria al lavoro scelto, poi ampliatela quando le attività lo richiedono.
Apparecchiatura · materiale · processo
Rappresentate fornitura, flusso, conversione, ubicazione e contenimento, incluse direzione e validità. Una rete vapore, un lotto produttivo e una gerarchia di apparecchiature richiedono relazioni diverse.
Input · metodo · risultato
Tracciate osservazioni, parametri e versioni dei modelli che hanno prodotto un risultato. Circuiti fisici e retroazioni di calcolo sono rappresentati separatamente.
Responsabile · approvatore · esecutore
Associate a ogni oggetto operativo le persone responsabili, i ruoli e le attività pertinenti. Conservate lo storico delle responsabilità quando cambiano turni o fornitori.
Gli oggetti mantengono identità stabili tra i sistemi sorgente. Date di validità e revisioni registrate consentono correzioni successive senza cancellare le evidenze utilizzate per una decisione precedente.
| Contesto | Cosa occorre sapere | Perché cambia il risultato |
|---|---|---|
| Identità e origine | Sito, oggetto, sistema sorgente e versione della mappatura | Due segnali con nomi simili possono appartenere ad apparecchiature o siti diversi. |
| Grandezze e unità | Valore e unità originali, tipo di grandezza, conversione e condizioni di riferimento | Pressione relativa e assoluta differiscono; i volumi standard di gas richiedono la propria base di temperatura e pressione. |
| Tempo | Orari di origine e ricezione, intervallo di campionamento e ritardo di processo pertinente | L’allineamento degli orologi non elimina il tempo necessario a materiali o energia per attraversare un processo. |
| Qualità e incertezza | Qualità alla fonte, valori mancanti o obsoleti, calibrazione e incertezza nota | Riproporre l’ultimo valore disponibile non equivale a una nuova misurazione. Valori misurati, calcolati e stimati richiedono trattamenti distinti. |
| Condizioni operative | Stato dell’apparecchiatura, isolamento, modalità di processo e limiti applicabili | Un modello valido in una condizione operativa può non essere adatto in un’altra. |
| Versione delle evidenze | Istantanea degli input, versione del documento ed esecuzione del modello | Chi verifica deve poter esaminare le basi di un risultato e distinguere una revisione successiva. |
L’ambiente di esecuzione previsto controlla gli input necessari e mantiene nei risultati le indicazioni sulla loro qualità. Se mancano le condizioni di riferimento o lo stato operativo non è adatto, può bloccare il metodo interessato lasciando proseguire le attività non coinvolte.
Core è progettato per eseguire formule e regole, modelli statistici, modelli dinamici di processo e ottimizzazioni con vincoli. Per ogni metodo occorre definire dove si applica e chi ne cura la manutenzione: il solo file del modello non basta per usarlo in un’attività industriale.
Specificate input, unità, condizioni di riferimento, intervallo operativo valido, parametri, output e responsabilità professionale.
Scegliete un intervallo di dati appropriato e verificate qualità, aggiornamento, stato e relazioni necessarie prima del calcolo.
Ordinate i calcoli dipendenti e gestite stato dinamico, retroazioni e ritardi di processo. Conservate istantanee degli input e versioni.
Esponete ipotesi, qualità, vincoli e condizioni di errore. Una proposta di ottimizzazione resta distinta dall’autorizzazione ad agire.
Confrontate con esempi di riferimento e risultati osservati, rilevate deviazioni, valutate modifiche candidate e approvate la messa in uso o il ripristino.
I modelli di clienti e partner possono restare nei servizi esistenti. I percorsi di integrazione previsti comprendono API, container e adattatori FMI/FMU verificati; compatibilità e requisiti di esecuzione si definiscono per ciascun modello.
| Tipo di interfaccia o integrazione | Specifica prevista | Condizioni di integrazione |
|---|---|---|
| Input da file e batch | CSV, Parquet, JSON e letture batch da database/API; Excel tramite parser con restrizioni | Le macro Excel non vengono eseguite. Ambito iniziale di importazione di riferimento: file fino a 1 GB e lotti fino a 1 milione di righe; input maggiori utilizzano elaborazione asincrona per blocchi. |
| Piattaforme dati esistenti | Query su archivi storici/API, riferimenti a oggetti esterni, cache su richiesta e sincronizzazione incrementale | I sistemi esistenti possono restare le fonti ufficiali; si registrano i limiti delle fonti, la qualità dei riferimenti temporali e il grado di aggiornamento della cache. |
| API HTTP | OpenAPI 3.1 e JSON Schema; interfacce per oggetti, osservazioni, calcolo e risultati | Separate operazioni di lettura, simulazione, registrazione, pubblicazione e richiesta di azione; il lavoro asincrono restituisce un riferimento all’esecuzione. |
| Eventi | Schemi di eventi versionati con identità, sequenza, orario dell’evento e riferimento di tracciamento | Separazione per tenant/sito/tipo; consegna almeno una volta con deduplicazione da parte del consumatore. |
| SDK per sviluppatori | Python e TypeScript; interfacce tipizzate, utilità per le unità, esempi e strumenti di simulazione | La compatibilità prevista copre la versione principale attuale e precedente dell’SDK. Versioni esatte dell’ambiente di esecuzione e delle dipendenze appartengono alla matrice di compatibilità dell’installazione. |
| Modelli professionali esterni | Servizi REST/gRPC, container OCI firmati e adattatori FMI/FMU verificati | L’integrazione FMI iniziale si concentra su FMI 2/3 Co-Simulation. Requisiti di solutore, stato, tempi e licenza si verificano per ciascun modello. |
| Adattatori di identità e strumenti | OIDC/SAML aziendali tramite un servizio di identità verificato; adattatori MCP facoltativi su API governate | MCP non amplia l’autorità del chiamante su dati, calcolo o azioni. |
Interfacce e formati sono specifiche obiettivo. Adattatori dei modelli, versioni dei sistemi sorgente e dipendenze si confermano per l’installazione scelta; la compatibilità del formato non dimostra la validità di un modello professionale.
| Opzione | Organizzazione dell’ambiente di esecuzione | Cosa stabilire |
|---|---|---|
| SaaS regionale | Servizi regionali gestiti e integrazioni esterne approvate | Ubicazione dei dati, destinazioni consentite, connettività delle fonti e ambito di servizio scelto. |
| Cloud privato del cliente | Servizi Core nell’ambiente cloud scelto dal cliente | Integrazione delle identità, percorsi di rete, database/archiviazione oggetti, backup e responsabilità operative. |
| Server di sito | Servizi e archiviazione locali; Linux x86-64 è l’ambiente host di riferimento | Verifica di host, archiviazione e rete per il carico scelto, con modalità di backup e ripristino. |
| Ambiente di esecuzione Edge limitato | Un sottoinsieme locale di servizi di oggetti e calcolo accanto a Edge | Capacità incluse e budget di risorse; non corrisponde automaticamente al profilo Core completo di un sito standard. |
| Piattaforma industriale esistente | Ambiente di esecuzione dei modelli, pacchetti di capacità e adattatori scelti accanto alla piattaforma attuale | Responsabilità sui campi, interfacce sorgente, dipendenze dei modelli e sistema che conserva ciascun registro. |
Residenza dei dati e percorsi verso servizi esterni si scelgono esplicitamente. Versioni di sistema operativo, database, container e connettori si fissano nella matrice di compatibilità della configurazione, senza dedurle da queste categorie di installazione.
| Profilo | Risorse di riferimento | Carico per la verifica d’idoneità |
|---|---|---|
| Sito leggero | 8 vCPU, 32 GB RAM e 1–2 TB di archiviazione, oppure ambiente di esecuzione locale E-M verificato | Ambito di oggetti/modelli o conservazione ridotti, soprattutto se un archivio storico esistente conserva i dati. Non è il carico CL-1 completo. |
| CL-1 · sito standard | 16 vCPU, 64 GB RAM e 8 TB di archiviazione utilizzabile; Linux x86-64 | 50.000 oggetti, 500.000 relazioni, 20.000 punti e 5.000 aggiornamenti/s; 100 utenti registrati e 30 simultanei, con 20 richieste API ordinarie/s e lavoro dichiarato con modelli piccoli. |
| CL-10 · installazione regionale | Dimensionamento iniziale: sei worker, ciascuno con 16 vCPU e 64 GB RAM; servizi separati di database/archiviazione oggetti con tre repliche | Fino a dieci siti CL-1, un totale di 50.000 aggiornamenti/s e 100 utenti simultanei. Regole di caricamento, conservazione e verifica indipendente della capacità determinano il cluster finale. |
Tutti i valori sono carichi obiettivo o di riferimento non sottoposti a prove. Risorse e carico devono essere verificati insieme, con autorizzazioni, query ed esecuzione dei modelli attive. Gli 8 TB indicano capacità utilizzabile dopo la ridondanza, non la somma dei dischi in mirroring. I/O di archiviazione e banda richiedono verifica; video, forme d’onda grezze ad alta frequenza e grandi simulazioni esulano da questi profili standard.
| Area | Comportamento previsto | Dettagli di configurazione o consegna |
|---|---|---|
| Stato dei modelli e riavvio | Salvate punti di ripristino dei modelli con stato; verificate parametri, versioni dello stato e input mancanti prima della ripresa | Reinizializzate il modello oppure osservate il processo quando uno stato non aggiornato non può rappresentare in sicurezza le condizioni attuali. |
| Backup e ripristino | Backup giornaliero con opzioni incrementali; ripristino di configurazioni, oggetti, versioni dei modelli, autorizzazioni ed evidenze | Installazioni su singolo host, ridondanti e di ripristino del sito dopo un disastro sono distinte; concordate posizione del backup, ambiente sostitutivo e ambito di ripristino. |
| Conservazione | Regola di riferimento: 30 giorni di serie temporali grezze di sito e 13 mesi di aggregati al minuto | La conservazione può essere adattata; modelli, configurazioni ed evidenze di lavoro importanti seguono la regola concordata. |
| Aggiornamenti e compatibilità | Versionate codice, modelli, configurazioni, dizionari e connettori con una matrice di compatibilità condivisa | Individuate le applicazioni interessate da ogni modifica e mantenete versioni compatibili sia quando la mettete in uso sia quando ripristinate la precedente. |
| Esportazione del cliente | JSON, CSV e Parquet con descrizioni degli schemi | Esportate oggetti, relazioni, unità, orari, dati/configurazioni del cliente, evidenze delle esecuzioni dei modelli e file dei modelli consentiti dalle licenze. |
| Materiali di consegna | Manifest di installazione, schemi degli oggetti e dei dati, interfacce, pacchetti dichiarati, materiali API/SDK e matrice di compatibilità | Includete strumenti di backup/ripristino ed esportazione, dati campione e responsabilità di manutenzione. |
Impegni di ripristino e periodi di manutenzione si definiscono per l’installazione scelta. La conservazione di riferimento è una scelta progettuale, non una regola legale universale; le licenze continuano a disciplinare i file dei modelli trasferibili.