HydroCore OS SCADA · SE4A PoliMi
Progetti
Politecnico di Milano · SE4A · 2025–2026

HydroCore OS

Dal trattamento dell'acqua
al controllo del processo.

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.

Esplora il sistema Repository GitHub Diagrammi UML
.NET 10 · REST + JWT React HMI SQLite historian PLC simulato · TCP 4840 RBAC · 4 ruoli
Il processo di potabilizzazione Telemetria simulata
5
Processi applicativi
15
Tabelle DB
9
Sensori
9
Viste KPI
4
Ruoli RBAC
3
Deliverable
Il team

Gli autori del progetto

Software Engineering for Automation · Politecnico di Milano · A.A. 2025–2026.

Autore del progetto

Matteo Cavalleri

Matricola 10768765

Autore del progetto

Samuele Galbiati

Matricola 10773862

01 · Architettura

Architettura a livelli, orientata agli eventi

Quattro eseguibili .NET e una HMI React compongono il prototipo. Il simulatore genera le letture, il runtime SCADA le storicizza e valuta gli allarmi, l'API le espone e l'HMI le mostra. API, runtime e simulatore MES condividono SQLite.

L4Presentazione
HMI React (SPA · 5500)Login · JWTSynopticTrends & KPIAlarm console
L3Applicazione / Controllo
HydroCore.Api (REST · 5080)Alarm EngineSetpoint BridgeHistorianCommsWatchdog
L2Dominio
ProcessUnitSensor · ReadingAlarm · RecipeBatch · TicketRBAC
L1Campo / Infrastruttura
PLC Simulator (TCP · 4840)Repository EF CoreSQLite (WAL)Audit log

Percorso di lettura

PLC SimulatorValori di campo · TCP 4840
↓readings
HydroCore.ServerHistorian · Alarm Engine
↓insert
SQLitePersistenza condivisa
↓EF Core
HydroCore.ApiREST · JWT · RBAC · 5080
↓polling
HMI browserReact · porta 5500

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.

HydroCore.Api:5080

API REST, autenticazione JWT, ruoli e permessi, endpoint applicativi (sensori, allarmi, batch, ticket, utenti).

C# · ASP.NET Core · EF Core
HydroCore.Serverruntime

Ingestione sensori, historian, motore allarmi e bridge dei setpoint. Il watchdog rileva l'assenza di nuove letture; una coda separa le scritture degli allarmi dall'acquisizione.

C# · Repository · Watchdog
HydroCore.PlcSimulator:4840

Simulatore di impianto e PLC: genera letture e riceve setpoint con messaggi testuali su TCP. Gli identificatori dei nodi richiamano OPC UA; il prototipo non usa uno stack OPC UA completo.

C# · Protocollo TCP locale
HydroCore.BatchMES

Simulatore MES: inserisce ordini PENDING nel database condiviso. L'operatore li attiva dall'HMI; il prototipo non invia richieste di ripianificazione a un MES esterno.

C# · scheduled_batches
frontend:5500

HMI statica React, compilata nel browser con runtime Babel vendorizzato. Nessuno step di build.

React · Babel · vanilla
02 · Modello di dominio

Un dominio industriale, modellato con cura

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.

ProcessUnit

Unità di processo con stato operativo e sensori. Il prototipo semplifica la macchina a stati del modello UML.

Sensor · Reading

9 sensori: portata, pH, torbidità, cloro, durezza, livello, pressione.

Alarm

Stato ACTIVE / ACKNOWLEDGED / CLEARED e severità INFO / WARNING / CRITICAL.

Recipe · Setpoint

Target di processo e bande ottimali di pH e cloro visualizzate nei trend. Le soglie del motore allarmi sono definite nel Server.

Batch · ScheduledBatch

Ordini in coda PENDING / STARTED / CANCELLED e batch RUNNING / COMPLETED / ABORTED. Un solo batch può essere in esecuzione.

Ticket

Manutenzione OPEN → ASSIGNED → IN_PROGRESS → RESOLVED → CLOSED.

PlantComponent

Pompe, filtri, dosatori con ore di esercizio e soglie di manutenzione.

User · Role

Utenti, ruoli e permessi con audit log delle operazioni.

03 · Design pattern

Pattern che rendono il sistema estensibile

Dal Design Document al codice: regole d'allarme intercambiabili, eventi dei sensori e persistenza astratta. State e Factory restano semplificati nel prototipo a topologia fissa.

Strategy implementato

IAlarmStrategy è implementata da HighThresholdStrategy e LowThresholdStrategy. Un sensore può avere più regole; una banda di isteresi evita aperture e chiusure ripetute vicino alla soglia.

State semplificato

ProcessUnit.TransitionTo() aggiorna uno stato enumerato. La macchina a stati completa è descritta nei diagrammi; nel codice non sono implementate classi di stato né guardie sulle transizioni.

Observer implementato

Nel Server, l'evento Sensor.OnNewReading notifica motore allarmi, historian e watchdog. L'HMI è in un processo separato e aggiorna i dati interrogando periodicamente l'API REST.

Repository verificato

Persistenza astratta dietro IAlarmRepository, IHistorianRepository, ISetpointRepository; QueuedAlarmRepository accoda le scritture.

Factory design

SensorFactory è un punto di estensione del modello. Nel prototipo i nove sensori sono creati esplicitamente all'avvio e associati ai nodi del simulatore.

HydroCore.Server / Logic / IAlarmStrategy.cs
namespace HydroCore.Logic{
  // Strategy pattern: interchangeable rules
  // decide 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; }
  }
}
04 · Diagrammi UML

I diagrammi del Design Document

Gli 11 SVG del Deliverable 2: modello complessivo, vista dei componenti e pacchetti di dominio. I diagrammi includono anche concetti progettuali semplificati nel codice, come SensorFactory e KPISnapshot. Clicca per ingrandire.

05 · Funzionamento

I flussi principali del sistema

Dai casi d'uso della RASD ai flussi del Deliverable 3: allarmi, produzione a batch, manutenzione e indicatori di prestazione, con i vincoli effettivamente implementati.

UC · Allarmi

Ciclo di vita dell'allarme

Le regole valutano soglia e isteresi. I WARNING si chiudono al rientro; i CRITICAL restano aperti e richiedono riconoscimento, ticket risolto e reset da un ruolo autorizzato.

ReadingCheck()ACTIVEACKNOWLEDGEDCLEARED
UC · Produzione

Ricette & batch

L'ordine MES è in coda finché un operatore lo attiva. L'avvio applica i setpoint validi della ricetta; un allarme critico non risolto blocca nuovi batch con HTTP 423 Locked. I setpoint correttivi restano modificabili.

Ordine PENDINGAttivazioneBatch RUNNINGCOMPLETED / ABORTED423 se critico
UC · Manutenzione

Ticket di manutenzione

Dalla vista Allarmi si aprono e gestiscono ticket con priorità, assegnazione e audit log. La valutazione dell'usura dei componenti può creare ticket preventivi quando la manutenzione è dovuta, evitando duplicati aperti.

OPENASSIGNEDIN_PROGRESSRESOLVEDCLOSED
UC · Analitica

KPI di processo & manutenzione

Nove viste SQLite: sette analizzano le ultime 24 ore, con OEE = Disponibilità × Prestazione × Qualità, resa idrica, stress idraulico e stabilità. Il MTTR usa lo storico degli allarmi chiusi; la salute dei componenti usa il registro corrente.

AvailabilityPerformanceQualityOEE 24h
Modello UML · Stati delle unità di processo
IDLE→ RUNNING→ FAULT→ MAINTENANCE↺ IDLE
Controllo d'accesso · 4 ruoli
OPERATOR

Conduzione dell'impianto: monitoraggio, riconoscimento allarmi, setpoint consentiti e avvio dei batch. Non può resettare un allarme critico.

VIEW_DASHBOARDACK_ALARMMODIFY_SETPOINTSTART_BATCHCREATE_TICKET
MAINTENANCE

Ciclo di vita dei ticket: creazione, assegnazione e risoluzione dei guasti. Può consultare ricette, batch e setpoint, senza modificarli o avviare la produzione.

VIEW_DASHBOARDACK_ALARMCREATE_TICKETASSIGN_TICKETRESOLVE_TICKET
PLANT_MANAGER

Ruolo più ampio: produzione, ricette, reset degli allarmi, manutenzione e gestione degli utenti.

CHANGE_RECIPESTART_BATCHABORT_BATCHRESET_ALARMRESOLVE_TICKETMANAGE_USERS
ENGINEERING

Taratura di ricette e setpoint, reset degli allarmi e gestione dei ticket. Come il plant manager, ma senza gestione utenti.

MODIFY_SETPOINTCHANGE_RECIPESTART_BATCHABORT_BATCHRESET_ALARMRESOLVE_TICKET

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.

06 · Deliverable

Tre consegne.
Un progetto da 30/30.

Dalla proposta di supervisione di un impianto di potabilizzazione a requisiti, design e prototipo locale. Tre deliverable consegnati e una valutazione finale di 30/30.

01

RASD

Requirements Analysis and Specification, Release 2.0: 19 pagine su obiettivi, processo, quattro profili utente, scenari, requisiti e vincoli. Include sequenze e macchine a stati.

Consegnato
02

Design Document

Release 2.0, 43 pagine: componenti, classi, runtime, interfaccia HMI, tracciabilità dei requisiti e piano di test. Le note di implementazione spiegano le differenze rispetto al modello iniziale.

Consegnato
03

Implementazione

Quattro eseguibili .NET, HMI React, schema e seed SQLite, nove viste analitiche e 14 classi di test xUnit. Il runbook descrive avvio, reset del database e scenari dimostrativi.

Consegnato

Documentazione e sorgenti. La repository del progetto SE4A raccoglie la proposta iniziale, i PDF di RASD e Design Document e, nel Deliverable 3, il runbook instruction.md e la guida tests.md.

Dalla documentazione alla demo locale
Avvio del prototipo
  • Con .NET 10 e Python 3, dalla cartella Deliverable_3: python setup.py, poi python run.py.
  • setup.py ricrea il database: per conservare dati esistenti occorre prima copiarli. L'HMI si apre su http://localhost:5500/login.html e richiede il cambio password al primo accesso.
Percorso dimostrativo
  • Confrontare sinottico e letture, modificare un setpoint e seguirne la propagazione al simulatore.
  • Gestire un allarme critico con ACK, ticket e Reset; verificare il blocco dei nuovi batch e attivare un ordine dalla coda MES.
  • Consultare trend, bande ottimali della ricetta, KPI e dati esportabili in CSV.
Perimetro accademico
  • PLC e MES sono simulati; hardware reale, integrazione ERP e ripianificazione verso un MES esterno restano fuori dal prototipo.
  • I target RASD di latenza, scalabilità e disponibilità sono requisiti progettuali, senza risultati prestazionali verificati qui. HTTP locale e TCP del simulatore non implementano TLS o uno stack OPC UA completo.
Verifica · Suite xUnit
Coperto dai test
  • Login, utenti disabilitati, cambio password, logout e revoca dei token
  • Registrazione delle regole, raise e clear idempotenti del motore allarmi
  • Auto-clear dei WARNING e latch dei CRITICAL
  • Lock del batch su allarme critico e setpoint di ricetta all'avvio
  • Chiavi ammesse, range numerici e banda pH nella validazione dei setpoint
  • Ticket, coda dei batch schedulati e audit log
Verifiche con lo stack avviato
  • /api/analytics/kpis, che legge le viste SQLite con SQL raw
  • Il loop completo fra SCADA Server e simulatore
  • Convergenza randomizzata del processo e iniezione dei guasti
  • HMI statica e interazioni nel browser
  • Flusso HTTP completo di login e RBAC
Come si esegue
  • dotnet test HydroCore_System.slnx dalla cartella del Deliverable 3
  • I test chiamano direttamente i controller con EF Core InMemory: non eseguono il middleware HTTP di autorizzazione
  • Allarmi e setpoint esercitano direttamente i servizi
  • Gli scenari che richiedono lo stack avviato seguono la checklist manuale del runbook

Privacy e Cookie Policy

Premi Esc per chiudere · Apri il diagramma originale ↗