Livello tecnico · Intermedio
Baseline tecnica verificata: ISO 16484-2:2025; ISO 52120-1:2021 / EN ISO 52120-1:2022; ISO 52127-1:2021; ASHRAE Guideline 13-2024
Verifica delle fonti: 10 ottobre 2026
Version-sensitive: sìLa terminologia e le versioni normative possono evolvere. Questa pagina distingue l’uso normativo di BACS dall’uso più ampio dei termini BMS, BAS e BEMS nel mercato e nella pratica professionale.
BMS e BACS in breve
BMS, BAS e BACS sono termini usati per descrivere sistemi che monitorano, controllano e coordinano gli impianti tecnici di un edificio. Nella pratica commerciale vengono spesso utilizzati come sinonimi, ma non indicano sempre esattamente lo stesso perimetro.
BACS, Building Automation and Control System, è il termine tecnico e normativo principale utilizzato per descrivere l’insieme di automazione e controllo dell’edificio: dispositivi di campo, controllori, infrastrutture di comunicazione, stazioni di gestione e componenti software possono tutti farne parte.
BMS, Building Management System, è un termine molto diffuso nell’industria e nella pratica professionale per indicare soprattutto funzioni di supervisione, gestione, monitoraggio, allarmi, trend, reporting e ottimizzazione. Non va considerato perfettamente equivalente a BACS in ogni contesto.
BAS, Building Automation System, è un termine di settore ampiamente usato, soprattutto in ambito internazionale, con un significato spesso vicino a BACS.
BEMS, Building Energy Management System, identifica invece un perimetro orientato in modo specifico alla gestione energetica.
Il punto fondamentale è che un edificio automatizzato non coincide necessariamente con “un computer centrale chiamato BMS”. Le funzioni possono essere distribuite tra dispositivi, controllori, reti, server e applicazioni.
Una distinzione utile: automazione e gestione
L’automazione riguarda principalmente la capacità del sistema di misurare, decidere e comandare. Un sensore misura una temperatura. Un controllore confronta il valore con un setpoint. Una logica determina se aprire una valvola o modificare la velocità di un ventilatore. Questa funzione può continuare anche senza una supervisione grafica centrale.
La gestione riguarda invece visualizzazione, supervisione, allarmi, trend, report, analisi, configurazione operativa, ottimizzazione e gestione energetica.
In molti sistemi commerciali queste funzioni convivono nella stessa piattaforma. Tecnicamente, però, è utile mantenerle distinte.
La perdita del server BMS non deve essere interpretata automaticamente come perdita dell’intero controllo locale. Se una funzione critica dipende dal server di supervisione per essere eseguita, tale dipendenza deve essere documentata e valutata.
L’architettura non è necessariamente centralizzata
Per leggere un BACS in modo pratico, Building Reference utilizza questa articolazione editoriale:
FIELD → CONTROL → COMMUNICATION → SUPERVISION → MANAGEMENT / DATA → EXTERNAL SERVICES
Questa è una rappresentazione funzionale di Building Reference, utile a leggere l’architettura; non è una classificazione normativa rigida.
Al livello FIELD troviamo sensori, attuatori, valvole, serrande, dispositivi di misura e apparecchiature. Al livello CONTROL operano automation station, controller programmabili e controllori applicativi. Il livello COMMUNICATION permette ai dispositivi e ai controllori di scambiare dati. Il livello SUPERVISION raccoglie stati, allarmi, trend e comandi destinati all’operatore. Il livello MANAGEMENT / DATA comprende analytics, reporting, performance management, gestione energetica, storicizzazione, fault detection e integrazione di dati. Gli EXTERNAL SERVICES possono includere cloud, applicazioni remote, sistemi aziendali, piattaforme di manutenzione o servizi di analisi.
Questi livelli possono essere implementati con prodotti differenti o concentrati nello stesso apparato.
Architettura BMS/BACS
FIELD → CONTROL → COMMUNICATION → SUPERVISION → MANAGEMENT / DATA → EXTERNAL SERVICES
I livelli rappresentano una lettura funzionale dell’architettura. Non impongono che ogni funzione risieda in un sistema o prodotto separato.
Il BMS non è necessariamente il controllore
Uno degli errori più frequenti è immaginare il BMS come un unico “cervello” dell’edificio. In realtà, molte funzioni possono e spesso devono essere eseguite localmente da controllori distribuiti.
Una UTA può avere il proprio controllore. Una centrale termica può continuare a eseguire le sequenze previste anche se il server di supervisione non è disponibile. Un sistema KNX può mantenere le proprie logiche sul bus. Un impianto DALI può continuare a controllare l’illuminazione attraverso i dispositivi previsti.
Il BMS può coordinare, visualizzare o modificare setpoint, ma questo non implica che ogni decisione debba transitare attraverso il server centrale. La verifica professionale deve quindi identificare dove viene eseguita ogni funzione.
BMS e protocolli
Un BMS non è un protocollo.
BACnet è un protocollo di comunicazione progettato specificamente per building automation and control networks. KNX definisce un sistema di automazione con propri datapoint, dispositivi e strumenti di engineering. DALI è focalizzato sul controllo dell’illuminazione. Modbus permette lo scambio di dati attraverso registri. MQTT implementa un modello di messaggistica publish/subscribe. Thread fornisce una rete IPv6 mesh. Matter definisce un modello applicativo per categorie di dispositivi connessi.
Un BMS può interagire con molti di questi sistemi, ma non li rende equivalenti.
L’integrazione richiede di definire quali dati sono disponibili, quali comandi possono essere inviati, quali allarmi vengono trasferiti, con quale frequenza, in quale direzione e quale sistema mantiene l’autorità sulla funzione.
Per ogni integrazione è utile distinguere almeno: read / write / alarm / trend / configuration / ownership.
BACnet e BMS non sono la stessa cosa
BACnet nasce come standard di comunicazione per building automation and control networks. Può consentire a dispositivi di produttori differenti di rappresentare e scambiare oggetti e servizi attraverso un modello comune. Questo facilita l’integrazione, ma non significa che ogni funzione del sistema sia standardizzata.
Un controller BACnet può esporre temperature, setpoint, stati, allarmi o comandi. Il BMS può utilizzare queste informazioni per supervisione e gestione.
- oggetti implementati;
- proprietà;
- servizi supportati;
- writable points;
- alarm management;
- trend;
- priorità;
- interoperabilità reale;
- eventuali estensioni proprietarie.
L’esistenza dell’interfaccia BACnet non dimostra quindi da sola l’integrazione completa.
BACS ed efficienza energetica
ISO 52120-1 definisce una struttura di funzioni di controllo, building automation e technical building management che contribuiscono alla prestazione energetica dell’edificio.
La versione europea EN ISO 52120-1:2022 ha sostituito EN 15232-1:2017. È quindi improprio presentare EN 15232 come standard corrente senza precisare il passaggio alla nuova numerazione.
La norma considera funzioni relative, tra gli altri ambiti, a riscaldamento, raffrescamento, ventilazione, illuminazione, schermature, produzione energetica e gestione tecnica.
La classificazione energetica delle funzioni BACS non significa che un determinato progetto risparmi automaticamente una percentuale specifica. Il risultato dipende da edificio, uso, impianti, orari, clima, tarature, funzionamento effettivo e manutenzione.
BEMS: quando l’energia diventa il focus
BEMS significa Building Energy Management System. Nel linguaggio di mercato può essere usato in modo ampio, ma è utile considerarlo come la parte del sistema di gestione dedicata in modo specifico alle prestazioni energetiche.
Un BEMS può utilizzare dati provenienti da contatori, HVAC, illuminazione, produzione fotovoltaica, accumulo, ricarica EV, condizioni ambientali e occupazione.
La disponibilità di una dashboard energetica non dimostra che il sistema sia in grado di controllare efficacemente i carichi.
monitoraggio → analisi → decisione → comando → verifica
Supervisione non significa integrazione completa
Due sistemi possono essere visibili nella stessa interfaccia senza essere realmente coordinati. Il fatto che una schermata mostri temperatura, illuminazione, energia, accessi e allarmi non significa che le relative funzioni condividano lo stesso modello dati o la stessa logica operativa.
Una supervisione può limitarsi alla lettura. Un’altra può consentire anche il comando. Un’altra ancora può implementare logiche trasversali. La documentazione deve quindi specificare per ogni integrazione almeno: read / write / alarm / trend / configuration / ownership.
Controllo locale, supervisione e cloud
Le architetture moderne possono includere edge server e cloud server. Questo non significa che il cloud debba essere obbligatorio.
- cosa funziona localmente;
- cosa richiede la LAN;
- cosa richiede Internet;
- cosa richiede il cloud;
- cosa accade durante una perdita di connettività;
- come avviene il ripristino.
Le funzioni critiche non dovrebbero dipendere inconsapevolmente da servizi esterni non controllabili.
Allarmi, diagnostica e fault detection
Il valore di un BMS non consiste soltanto nel mostrare dati. Un sistema ben progettato deve evitare due estremi: l’assenza di allarmi utili e l’alarm flooding, nel quale molte segnalazioni prive di priorità rendono difficile identificare i problemi reali.
- origine;
- condizione;
- priorità;
- timestamp;
- acknowledgement;
- eventuale causa;
- azione prevista.
Anche la fault detection deve distinguere tra un dato anomalo e una diagnosi affidabile.
Cybersecurity e ownership
Un BACS collega dispositivi che possono avere una vita utile molto lunga. Per questo sicurezza e lifecycle devono essere progettati insieme.
- account amministrativi;
- identità;
- certificati;
- password;
- porte e servizi;
- accesso remoto;
- segmentazione;
- aggiornamenti;
- backup;
- configurazioni;
- licensing;
- proprietà dei database;
- dipendenze dal vendor.
L’handover non dovrebbe limitarsi a consegnare una password. Deve rendere il proprietario capace di capire chi controlla il sistema e come recuperarlo.
Il problema del vendor lock-in
Un sistema può usare protocolli standard e rimanere comunque fortemente dipendente dal fornitore.
- software di engineering;
- licenze;
- file di configurazione;
- database;
- gateway;
- applicazioni cloud;
- tool diagnostici;
- controller programmabili;
- contratti di aggiornamento.
Un progetto open-protocol non è automaticamente un progetto open-management.
La domanda corretta è: quali parti del sistema possono essere mantenute, sostituite o estese da un soggetto diverso?
Lifecycle e handover
Un BMS deve essere progettato per durare più del ciclo commerciale di molte piattaforme software.
- architettura;
- schema di rete;
- indirizzamento;
- protocolli;
- point list;
- sequence of operation;
- alarm matrix;
- trend;
- backup;
- database;
- credenziali;
- firmware;
- licenze;
- software di engineering;
- procedure di restore;
- responsabilità.
Questi elementi devono essere definiti già in fase di progettazione e verificati nel ciclo di vita, non ricostruiti soltanto a guasto avvenuto.
Resilience by Design
La resilienza non dipende dalla semplice presenza di un BMS. Dipende dal modo in cui le funzioni sono distribuite.
Una funzione essenziale può essere progettata per continuare localmente anche durante la perdita della supervisione. Al contrario, una funzione apparentemente semplice può dipendere da:
sensore → controller → rete → server → cloud → account
La progettazione deve rendere visibile questa catena. Ridondare il server non risolve necessariamente il guasto della rete. Ridondare la rete non risolve il problema di una licenza scaduta. Usare un protocollo aperto non elimina la dipendenza dal software di engineering.
La resilienza richiede quindi la mappatura dei failure domain e delle dipendenze operative.
Dove vive la funzione
REQUISITO → SENSORE → CONTROLLO LOCALE → RETE → SUPERVISIONE → SERVIZI AGGIUNTIVI
Le frecce rappresentano dipendenze da verificare, non garanzie di continuità o di failover automatico.
Rapporto con KNX, DALI, Matter e Thread
KNX può mantenere proprie logiche, datapoint e strumenti di engineering anche quando viene integrato o supervisionato da un BMS.
DALI mantiene il proprio ruolo specifico nel controllo dell’illuminazione e nella relativa diagnostica. Un’integrazione verso il BMS non rende il BMS sostitutivo delle funzioni native DALI.
Matter definisce un modello applicativo per dispositivi connessi; Thread fornisce una rete IPv6 mesh. Possono entrare in architetture più ampie, ma non vanno descritti come “tecnologie BMS”.
Il compito del progetto è quindi chiarire quale livello svolge ciascuna tecnologia, quali funzioni vengono integrate e quale sistema mantiene l’autorità operativa.
Checklist professionale
- quali funzioni devono essere controllate;
- dove viene eseguita ogni logica;
- quali funzioni rimangono operative senza server;
- quali protocolli vengono utilizzati;
- quali dati sono leggibili;
- quali punti sono comandabili;
- gestione degli allarmi;
- trend e storico;
- sincronizzazione temporale;
- ridondanza;
- failure domain;
- segmentazione IT/OT;
- accesso remoto;
- aggiornamenti;
- backup e restore;
- ownership delle configurazioni;
- strumenti di engineering;
- licensing;
- documentazione;
- possibilità di sostituire componenti e fornitori.
Versioni e baseline
- ISO 16484-2:2025;
- ISO 52120-1:2021 / EN ISO 52120-1:2022;
- ISO 52127-1:2021;
- ASHRAE Guideline 13-2024.
Stato revisione normativa al 10 ottobre 2026: ISO 52120-1:2021 e ISO 52127-1:2021 restano le edizioni pubblicate considerate da questa pagina. Per entrambe è stato avviato nel 2026 un processo di revisione; eventuali nuove edizioni richiederanno una nuova verifica di questa Reference.
La pagina è version-sensitive e deve essere riesaminata quando nuove edizioni o revisioni modificheranno terminologia, perimetro o requisiti applicabili.
Verifiche prima dell’uso in un progetto
Prima di adottare o specificare una soluzione BMS/BACS occorre verificare almeno funzioni richieste e realmente implementate, distribuzione delle logiche, comportamento in assenza di supervisione o connettività, protocolli e mapping disponibili, gestione di allarmi e trend, accesso agli strumenti di engineering, backup e restore, ownership di database e configurazioni, lifecycle di firmware, licenze e servizi, responsabilità operative e interoperabilità reale con i sistemi adiacenti.
La presenza di un’unica interfaccia grafica, di un protocollo standard o di un server centrale non sostituisce questa verifica.
Per il quadro metodologico generale vedi anche Integrazione e interoperabilità.