Un’integrazione tra sistemi non è completa solo perché due piattaforme riescono a scambiarsi un valore. Per essere progettata e verificata deve chiarire che cosa viene tradotto, quale significato mantiene il dato, chi può comandare e quale sistema conserva l’autorità sulla funzione.
Livello tecnico · Avanzato
Riferimenti tecnici e verifiche dipendenti dal progetto: KNX Specifications V3 e 03_07_02 Datapoint Types v02.02.01; ANSI/ASHRAE Standard 135-2024 come baseline documentale BACnet; addenda pubblicati da selezionare in funzione della versione adottata nel progetto; PICS del prodotto da acquisire e confrontare con le capacità effettivamente configurate; DALI Alliance, specifiche applicabili e stato di certificazione dei prodotti; MQTT Version 5.0 — OASIS Standard del 7 marzo 2019
Verifica delle fonti: 13 ottobre 2026
Version-sensitive: sìI testi integrali soggetti a licenza e la documentazione della specifica implementazione devono essere verificati nel progetto. Connettività, interoperabilità e responsabilità funzionale sono livelli distinti: un gateway può trasferire informazioni, ma mapping, capacità implementate e comportamento applicativo devono essere verificati nella configurazione reale.
Gateway, mapping e ownership in breve
Un gateway collega domini o protocolli differenti. Può tradurre messaggi, oggetti, registri, datapoint o funzioni, ma non garantisce automaticamente che i due sistemi condividano la stessa semantica o lo stesso comportamento operativo.
Il mapping stabilisce quali informazioni attraversano l’interfaccia e come vengono rappresentate nel sistema di destinazione. L’ownership chiarisce invece quale sistema mantiene l’autorità sulla funzione, sulla configurazione e sul comportamento in caso di errore o perdita della comunicazione.
La catena da verificare
FUNZIONE → DATO SORGENTE → MAPPING → GATEWAY / INTERFACCIA → DATO DESTINAZIONE → LOGICA → COMANDO → FEEDBACK → FUNZIONE VERIFICATA
Se uno di questi passaggi non è definito, la connettività può esistere senza produrre un’integrazione affidabile.
Il gateway non elimina i due sistemi
Un gateway non trasforma automaticamente un protocollo nell’altro. Un dispositivo KNX continua a utilizzare il proprio modello di comunicazione; un impianto DALI conserva il proprio indirizzamento, i gruppi e le scene e, quando supportati dai dispositivi e dalle parti applicabili, i relativi dati diagnostici; BACnet mantiene oggetti, proprietà e servizi; MQTT continua a trasportare messaggi publish/subscribe senza imporre da solo il significato applicativo del payload.
La traduzione e il mapping avvengono nell’architettura di interfaccia, che può comprendere uno o più componenti. Per questo occorre documentare ciò che passa e ciò che invece rimane nel dominio originale.
Mapping: non basta associare due indirizzi
Un mapping può dover conservare o trasformare tipo di dato, unità, range, stato, qualità, timestamp, priorità, eventi, allarmi, comandi e feedback.
Nel mondo KNX i Datapoint Type definiscono, per i tipi standardizzati, formato e codifica e, quando applicabili, range e unità utilizzati nell’interworking. In BACnet oggetti, proprietà e servizi disponibili devono essere confrontati con il PICS della specifica implementazione e verificati nella configurazione di progetto. In MQTT topic e payload restano invece definiti dall’applicazione. Queste differenze rendono necessaria una verifica esplicita del mapping.
Read, write e command sono cose diverse
Una variabile visibile nel sistema di supervisione può essere soltanto letta, può essere scrivibile oppure può rappresentare un vero comando con logiche e priorità proprie.
La matrice di integrazione dovrebbe distinguere almeno: read / write / command / alarm / event / trend / configuration / ownership.
Chi mantiene l’autorità sulla funzione?
L’ownership funzionale deve essere definita prima di implementare il gateway. Se una temperatura viene letta da un BMS, questo non significa che il BMS debba anche controllare il regolatore locale. Se una scena DALI è richiamata da un altro sistema, occorre chiarire dove risiede la logica della scena e come viene gestito il feedback.
Due sistemi che possono entrambi comandare la stessa funzione senza una regola di autorità possono produrre conflitti, override non visibili o comportamenti difficili da diagnosticare.
Feedback e stato reale
Inviare un comando non dimostra che la funzione sia stata eseguita. Una buona integrazione distingue almeno tra comando inviato, comando accettato, stato applicato e misura reale quando disponibile.
Il progetto deve stabilire quale feedback è necessario e con quale latenza, soprattutto per allarmi, comandi operativi e funzioni che influenzano comfort, energia o continuità di servizio.
Cosa succede quando il gateway non è disponibile
Il gateway è un possibile failure domain. La perdita dell’interfaccia non dovrebbe produrre conseguenze impreviste sulle logiche locali.
Per ogni funzione occorre specificare cosa continua a funzionare localmente, quali dati smettono di essere disponibili, quali comandi non possono più essere trasferiti e quale stato assume il sistema durante il fault e dopo il recovery.
Commissioning dell’integrazione
Il commissioning non deve limitarsi a verificare che il gateway sia online. Deve provare la funzione completa, dal dato sorgente al comportamento finale.
- coerenza di tipo, unità e range;
- read e write autorizzati;
- priorità e override;
- feedback e aggiornamento dello stato;
- allarmi ed eventi;
- timestamp e sincronizzazione;
- comportamento in fault;
- recovery dopo perdita della comunicazione;
- persistenza delle configurazioni;
- tracciabilità del mapping.
Documentazione e handover
La documentazione dovrebbe includere almeno matrice di mapping, naming convention, direzione dei dati, proprietà scrivibili, ownership, dipendenze, configurazione del gateway, backup, credenziali, versioni software e procedura di sostituzione.
Una integrazione non documentata può funzionare al collaudo e diventare molto difficile da mantenere quando cambia un controller, un gateway o una piattaforma.
Checklist professionale
- quale funzione deve attraversare l’interfaccia;
- qual è il dato sorgente;
- quale rappresentazione assume nel sistema di destinazione;
- quali unità e range sono utilizzati;
- chi può leggere;
- chi può scrivere o comandare;
- quale sistema mantiene l’ownership e chi ne assume la responsabilità operativa;
- come viene gestito il feedback;
- quali priorità o override esistono;
- quali allarmi ed eventi vengono trasferiti;
- quale latenza è accettabile;
- come vengono gestiti timestamp e qualità del dato;
- cosa accade in caso di perdita del gateway;
- come avviene il recovery;
- come viene verificata la funzione reale;
- quale documentazione viene consegnata;
- chi può modificare il mapping;
- come vengono gestiti backup e versioni;
- quanto è sostituibile il gateway.
Riferimenti tecnici correlati
Per approfondire i domini trattati vedi BMS e BACS, BACnet, DALI e MQTT.
Per il quadro generale torna a Integrazione e interoperabilità o passa a Progettazione e requisiti dei sistemi.