Clicca fuori o premi ESC per chiudere
HydroCore OS è un prototipo SCADA per un impianto di potabilizzazione: legge un simulatore PLC, storicizza le misure, valuta gli allarmi, rimanda i setpoint all'impianto ed espone lo stato del processo tramite un'interfaccia HMI nel browser.
Cinque processi collaborano attraverso un database SQLite condiviso. Il campo pubblica letture, il runtime SCADA le storicizza e valuta gli allarmi, l'API le espone e l'HMI le mostra. I setpoint viaggiano in senso opposto.
I setpoint percorrono la catena inversa: HMI → API → DB → Setpoint Bridge → PLC. Il browser dialoga solo con l'API, mai col Server o col simulatore.
API REST, autenticazione JWT, ruoli e permessi, endpoint applicativi (sensori, allarmi, batch, ticket, utenti).
Ingestione sensori, historian, motore allarmi con strategie e bridge dei setpoint verso il campo.
Simulatore di impianto e PLC su TCP. Genera i valori di campo e riceve i target dei setpoint.
Simulatore MES: inserisce ordini di produzione pianificati nella coda dei batch.
HMI statica React, compilata nel browser con runtime Babel vendorizzato. Nessuno step di build.
Il nucleo di dominio ruota attorno alle unità di processo, ai sensori, agli allarmi, alle ricette, ai batch di produzione, ai ticket di manutenzione e al controllo d'accesso basato sui ruoli.
Unità di processo con macchina a stati e sensori collegati.
9 sensori: portata, pH, torbidità, cloro, durezza, livello, pressione.
Stato ACTIVE/ACK/CLEARED e severità INFO/WARNING/CRITICAL.
Setpoint e bande di allarme legate alla ricetta attiva.
Produzione RUNNING → COMPLETED/ABORTED, con KPI associati.
Manutenzione OPEN → ASSIGNED → IN_PROGRESS → RESOLVED → CLOSED.
Pompe, filtri, dosatori con ore di esercizio e soglie di manutenzione.
Utenti, ruoli e permessi con audit log delle operazioni.
Le scelte progettuali seguono pattern classici, applicati dove aggiungono valore reale: regole d'allarme intercambiabili, ciclo di vita esplicito delle unità, persistenza astratta.
Ogni sensore possiede una regola che decide se un valore è in allarme. IAlarmStrategy è implementata da HighThresholdStrategy e LowThresholdStrategy: il motore non cambia al variare della regola.
ProcessUnit gestisce il proprio ciclo di vita con TransitionTo() tra gli stati IDLE, RUNNING, FAULT e MAINTENANCE.
Le letture dei sensori si propagano ai consumatori — motore allarmi, historian, HMI — che reagiscono solo agli eventi rilevanti.
Persistenza astratta dietro IAlarmRepository, IHistorianRepository, ISetpointRepository; QueuedAlarmRepository accoda le scritture.
namespace HydroCore.Logic{ // Strategy pattern: each sensor owns a rule // deciding whether a value is in alarm. public interface IAlarmStrategy{ // True if the value is outside the bounds. bool Check(double value); string GetAlarmMessage(string sensorId, double value); // Metadata for DB persistence. string Severity { get; } // INFO|WARNING|CRITICAL double Threshold { get; } } }
Artefatti reali del Deliverable 2: class diagram, vista dei componenti, sequenze e sinottici. Clicca per ingrandire.
Dai casi d'uso della RASD: allarmi, produzione a batch, manutenzione e indicatori di prestazione, con i vincoli operativi che li legano.
Una lettura fuori soglia genera un allarme. L'operatore lo riconosce; per una severità critica occorre completare la manutenzione prima del reset.
La ricetta definisce setpoint e bande d'allarme. Un allarme critico attivo blocca l'avvio di un nuovo batch con HTTP 423 Locked.
Ticket manuali o generati da un guasto, con priorità, assegnazione e audit log fino alla chiusura.
OEE = Disponibilità × Prestazione × Qualità. Nove viste analitiche: resa idrica, stress idraulico, stabilità di processo, MTTR, salute componenti.
Monitoraggio impianto, riconoscimento allarmi, modifica dei setpoint consentiti.
Gestione dei ticket di manutenzione e risoluzione dei guasti alle unità.
Gestione di batch, ricette, utenti e decisioni operative.
Analisi dei dati di processo, taratura delle ricette e ispezione del sistema.
Prototipo accademico. HydroCore usa un PLC simulato e un database SQLite locale. Non è pensato per un impianto reale né per un'esposizione su Internet: questa pagina ne è la vetrina, non l'istanza in esecuzione.
Dal documento dei requisiti all'implementazione con test, seguendo il percorso del corso Software Engineering for Automation.
Requirements Analysis and Specification Document: obiettivi, requisiti, casi d'uso e modello del mondo.
ConsegnatoArchitettura, viste a componenti, class diagram, sequenze e macchine a stati.
ConsegnatoCodice sorgente .NET + React, schema e seed del database, KPI view e test xUnit.
Consegnato