● SCADA / Water Treatment Plant Control System

Real-time monitoring & plant orchestration for water treatment

Event-driven SCADA prototype. Monitors process parameters across the treatment line, manages recipes and batches, raises configurable alarms, tracks maintenance tickets, and computes OEE in real time.

Open dashboard → View architecture Class diagram

CORE

SENSORS·14 UNITS·11 OEE·87.4% v0.1·alpha

Process Units

11

Across 2 lines (main + sludge)

Measured Quantities

15

Flow, pH, turbidity, pressure...

Alarm Strategies

3

Threshold · Rate · State-based

User Roles

4

Operator · Maint · Mgr · Eng

Core capabilities

// product functions

Real-time monitoring

Live trend graphs of all process parameters. Sensors stream readings, dashboard updates via observer pattern only on significant change.

FN-01

Configurable alarms

Strategy pattern selects alarm logic at runtime: fixed threshold, rate-of-change, or state-based. Bound to active recipe.

FN-02

Maintenance tickets

Operators raise tickets, engineering resolves. Auto-generated on faults. Full audit log for compliance.

FN-03

Recipe & batch control

Each recipe binds setpoints and alarm rules. Batches run on a process line; manager schedules and aborts.

FN-04

OEE & KPI snapshots

Computes Availability × Performance × Quality per batch and per line. Periodic snapshots persisted for reporting.

FN-05

Role-based access

RBAC with 11 permissions across 4 roles. Plant manager unrestricted, operator scoped to view + setpoint changes.

FN-06

Out of scope · v0.1

// explicit non-goals

Hardware integration

All sensor data is simulated. No PLC/OPC-UA driver in this iteration.

Predictive maintenance

Maintenance is reactive: triggered by tickets or fault states. No ML-based prediction.

MES / ERP integration

Production batches are mocked; no upstream job ingestion from external systems.

// HMI › LIVE OVERVIEW

Plant Dashboard

Real-time view of the active batch. KPIs refresh every second; sensor charts stream simulated readings; alarm feed driven by the rule engine. Selected unit: Filtration Unit.

OEE

87.4%

target 85+2.4

Availability

94.1%

uptime↑

Performance

96.8%

cyclenom

Quality

96.0%

specok

› FLOW RATE · m³/h

LIVE

› pH · TURBIDITY

VAR

› ACTIVE BATCH · B-2026-051

RUNNING · 02:47:18

Recipe

Standard-Soft v3.1

Line

MAIN_TREATMENT

Started by

m.cavalleri

Setpoints

12 bound

// PLANT › TOPOLOGY & FLOW

Plant Topology

Two ProcessLines: MAIN_TREATMENT (intake → distribution) and SLUDGE_HANDLING (recovers solids from sedimentation/filtration). Each ProcessUnit owns its sensors and exposes a state machine: IDLE / RUNNING / FAULT / MAINTENANCE / OFFLINE.

RUNNING

WARNING / MAINTENANCE

FAULT

IDLE / OFFLINE

Process flow

Sludge stream

// SYSTEM › ARCHITECTURE

System Architecture

Layered, event-driven architecture. Sensors push readings into the bus; the AlarmEngine and Dashboard subscribe via Observer; AlarmRule strategies are swapped at runtime per active recipe.

L4Presentation

Dashboard UIHMI · trends · KPIs

Alarm Consoleack · suppress · resolve

Recipe Editorsetpoint binding

Ticket Boardmaintenance flow

ReportsOEE snapshots

L3Application

AlarmEngineObserver · Strategy host

BatchOrchestratorstart · abort · complete

RecipeManageractive recipe binding

MaintenanceServiceticket lifecycle

KPIServiceOEE · A · P · Q

AuthServiceRBAC · sessions

L2Domain Core

ProcessUnit (abs)+ 11 concrete subclasses

Sensor / Readingquality flagging

AlarmRule (abs)Threshold · Rate · State

Recipe / Setpointparameter binding

Batch / KPISnapshotproduction state

L1Infrastructure

EventBusDomainEvent dispatch

TrendRepositorytime-series store

AuditLogappend-only

SensorFactorybuilds per unit

SensorSimulatorstubs hardware

Design patterns

// chosen for modularity

Strategy · AlarmRule

Three concrete rules — ThresholdAlarmRule, RateOfChangeAlarmRule, StateBasedRule — all share evaluate(ctx). The active Recipe selects which set is bound; the AlarmEngine stays unchanged.

Observer · Sensor → Engine/UI

Sensors implement Subject; Dashboard and AlarmEngine implement Observer. Push-based updates only on significant change — no polling, lower DB write load.

Factory · SensorFactory

buildFor(unit) instantiates the right Sensor subset for each ProcessUnit subclass — keeps unit construction declarative.

State · ProcessUnit

Each unit transitions across UnitState: IDLE → RUNNING → FAULT/MAINTENANCE → OFFLINE. State changes emit DomainEvents picked up by AuditLog and AlarmEngine.

// MODEL › CLASS DIAGRAM v8

Domain Model

UML class diagram organised in functional packages. Each box shows attributes (- private) and operations (+ public). External refs link to other packages.

› IDENTITY & ACCESS

PKG·1

User«class»

userId : UUID

username : String

role : Role

isActive : Boolean

login() : Session

hasPermission(p) : Boolean

Session«class»

sessionId : UUID

loginAt : DateTime

logoutAt : DateTime?

terminate() : void

AuditLog«class»

logId : UUID

eventType : String

oldValue / newValue

record(event) : void

› SENSORS & DATA

PKG·2

Sensor«Subject»

sensorId : UUID

tagName : String

measuredQuantity

samplingRateHz : Float

getLastReading() : Reading

attach(o) / notify(e)

Reading«value»

timestamp : DateTime

value : Float

quality : ReadingQuality

TrendRepository«repository»

query(sensorId, t1, t2)

aggregate(id, win, fn)

› ALARM MANAGEMENT

PKG·3

AlarmEngine«Observer impl»

update(event) : void

evaluate(reading) : void

raise(rule, ctx) : Alarm

AlarmRule«abstract Strategy»

ruleId : UUID

severity : AlarmSeverity

evaluate(ctx) : Boolean

Alarm«class»

triggeredAt : DateTime

status : AlarmStatus

severity : AlarmSeverity

acknowledge(u) / resolve()

› PLANT TOPOLOGY

PKG·4

ProcessLine«class»

lineId : UUID

lineType : LineType

getUnits() : ProcessUnit[*]

ProcessUnit«abstract»

unitId : UUID

state : UnitState

mode : OperatingMode

transitionTo(s) : void

getDownstream() : ProcessUnit[*]

11 concrete subclasses«inherit ProcessUnit»

Intake · Softener · Coagulation

Sedimentation · Filtration · Chlorination

Neutralization · Storage · PumpStation

SludgeHandling

› PRODUCTION

PKG·5

Recipe«class»

recipeId : UUID

version : String

isActive : Boolean

getAlarmRules() : AlarmRule[*]

getSetpoints() : Setpoint[*]

Batch«class»

batchId : UUID

status : BatchStatus

startTime / endTime

start() / abort() / complete()

Setpoint«value»

parameter : MeasuredQuantity

targetValue : Float

tolerance : Float

› KPI & MAINTENANCE

PKG·6

MaintenanceTicket«class»

ticketId : UUID

status : TicketStatus

relatedAlarmId : UUID?

assign(u) / resolve(notes)

KPISnapshot«class»

oee : Float

availability / performance / quality

timestamp : DateTime

computeOEE() : Float

// EVENTS › ALARMS & MAINTENANCE

Alarms & Maintenance

All triggered alarms over the current shift, plus active maintenance tickets. Filters apply client-side; severity and ticket status are colour-coded.

Active alarms

3

2 ack · 1 newshift

Open tickets

5

2 in-progressqueue

MTTR · 24h

42min

↓ 18%vs avg

Resolved · 24h

12

shift total↑

Time	Severity	Unit	Rule	Message	Status

Maintenance tickets

// open queue

ID	Unit	Created	Created by	Assigned to	Description	Status
`TK-1042`	Filtration U-05	2026-05-05 11:24	m.cavalleri	eng.team	Pressure drop above warning band — backwash needed	IN_PROGRESS
`TK-1041`	Softener U-02	2026-05-05 09:12	auto	maint.team	Resin saturation > 60% — schedule regeneration	ASSIGNED
`TK-1038`	Pump Station U-09	2026-05-04 22:48	s.galbiati	—	Vibration sensor flagged anomaly — visual inspection	OPEN
`TK-1036`	Chlorination U-06	2026-05-04 18:02	auto	eng.team	Dosing pump calibration drift	IN_PROGRESS
`TK-1029`	Sedimentation U-04	2026-05-03 14:30	m.cavalleri	maint.team	Sludge blanket level high — discharge cycle	RESOLVED

// PROJECT › ROADMAP & TEAM

Roadmap & Team

Three-month delivery plan aligned with SE4A guidelines: requirements analysis → design → implementation. Each milestone maps to a deliverable.

M0 · APR 2026

Project proposal · approved

1-page scope: SCADA for water treatment, OEE/KPI focus, simulated I/O. Roles, core functions, out-of-scope and design patterns identified.

SCOPE

APPROVED

M1 · MAY 2026

Deliverable 1 · RASD

Requirements Analysis and Specification Document. Domain model (UML), scenarios, functional and non-functional requirements, FSMs for unit lifecycle.

UML

SCENARIOS

FSM

M2 · JUN 2026

Deliverable 2 · Design Document

Component, class and runtime views. Selected styles: layered + event-driven. Patterns: Strategy, Observer, Factory, State. Requirements traceability matrix.

ARCHITECTURE

PATTERNS

RTM

M3 · JUL 2026

Deliverable 3 · Implementation

Working prototype with simulated sensors, alarm engine, recipe/batch flow and dashboard. Stability over feature breadth — viable prototype, not market-ready.

CODE

PROTOTYPE

DEMO

M4 · JUL 2026

Final discussion

Presentation of the three artifacts — assessment of precision, conceptual soundness, completeness, consistency, and presentation quality.

DEFENSE

The team

// SE4A · 5 CFU · Polimi

Two students, two instructors. The team behind the requirements analysis, design, and implementation of HydroCore OS.

MC PHOTO

Matteo Cavalleri

Student · Co-author

M.Sc. Automation & Control Engineering

SG PHOTO

Samuele Galbiati

Student · Co-author

M.Sc. Automation & Control Engineering

MC PHOTO

Prof. Matteo Camilli

Instructor · Course holder

DEIB · Politecnico di Milano

LL PHOTO

Prof. Livia Lestingi

Instructor · Co-holder

DEIB · Politecnico di Milano

Photo slots use <img> tags with empty src — fallback to initials. Add an image URL to each src attribute to swap in the real photo.