BACnet, KNX of Modbus: een protocol kiezen waar u over tien jaar geen spijt van heeft

Deze vraag komt in vrijwel elk project langs, meestal geformuleerd als een keuze uit drie. Dat is de verkeerde vorm. Bijna elk niet-triviaal gebouw draait uiteindelijk op ten minste twee van deze protocollen, en de ontwerpbeslissing die werkelijk telt is waar de grenzen ertussen liggen en wie eigenaar is van de vertaling.

Toch kunt u die beslissing niet nemen zonder te weten waar elk protocol echt goed in is.

De drie, kort en eerlijk

BACnet

Een open protocol voor gebouwautomatisering, genormeerd als ASHRAE 135 en internationaal als ISO 16484-5. Het onderscheidende kenmerk is dat het objectgeoriënteerd en semantisch is: een punt is niet zomaar een getal op een adres, maar een object met een type, eenheden, actuele waarde, prioriteitsmatrix en eigenschappen voor alarm en trend. Twee apparaten van verschillende fabrikanten kunnen daardoor een zinnig gesprek voeren over wat een waarde betekent.

Het draait over IP (BACnet/IP) en over RS-485 (BACnet MS/TP). Het past van nature op installatie- en supervisieniveau: luchtbehandelingskasten, koelmachines, ketels, en het hoofdstation dat ze bewaakt. Voor het schakelen van een lamp is het betrekkelijk zwaar.

KNX

Een decentrale veldbus, genormeerd als EN 50090 en ISO/IEC 14543-3, met een zeer sterke positie in Europese ruimteautomatisering. Het onderscheidende kenmerk is gecertificeerde interoperabiliteit: apparaten worden tegen een gemeenschappelijk model beproefd, in één tool geconfigureerd, en er is geen centrale regelaar die overeind moet blijven om de ruimte te laten werken.

Die decentralisatie is het echte argument. Verlichting, zonwering en afgifteregeling blijven functioneren wanneer de supervisielaag uit staat of wordt vervangen. Uitstekend op ruimteniveau, en niet waar u een koelmachinesequentie op wilt draaien.

Modbus

Eigenlijk geen gelijke van de andere twee, en het is helderder om dat ook niet te doen alsof. Modbus is een eenvoudig, oud, registergebaseerd protocol — RTU over serieel, TCP over ethernet — zonder enige semantische laag. U leest een getal van een adres. Wat dat getal betekent staat in een pdf van de fabrikant, en mogelijk in een schaalfactor verstopt in een voetnoot.

Dat klinkt als kritiek. Dat is het niet helemaal. Modbus is hoe de meters, frequentieregelaars, omvormers, koelmachines en compacte installaties van deze wereld met u praten, of u er nu voor gekozen hebt of niet. Het is het universele oplosmiddel van gebouwintegratie, en juist die eenvoud is waarom het overal nog draait.

De architectuur die er meestal uit rolt

Voor een middelgroot tot groot utiliteitsgebouw is de vorm die het vaakst standhoudt in de praktijk:

• KNX op ruimteniveau — verlichting, zonwering, aanwezigheid, afgifte-units, lokale setpointverstelling.
• BACnet op installatie- en supervisieniveau — luchtbehandeling, opwekking, distributie, hoofdstation, trending en alarmering.
• Modbus op apparaatniveau — meters, frequentieregelaars, compacte installaties, alles wat met een integratiedocument kwam in plaats van een profiel.
• Gedefinieerde gateways op elke grens, met een expliciete, vastgelegde lijst van wat er overheen gaat.

Dat laatste punt is waar projecten worden gewonnen of verloren.

Het gatewayprobleem

Elke gateway is drie risico's tegelijk: een vertaling die fout kan zijn, een apparaat dat kan uitvallen, en een commerciële afhankelijkheid die gelicentieerd, uitgefaseerd of bij verlenging gegijzeld kan worden. Een gebouw dat zijn gateways integratie voor integratie heeft verzameld, zonder sturende architectuur, houdt een regelsysteem over dat niemand volledig kan beschrijven — en dus niemand veilig kan wijzigen.

Twee regels houden dit beheersbaar:

1. Specificeer wát de grens overgaat, niet alleen dát er een grens is. Een puntenlijst die precies aangeeft welke waarden tussen KNX en BACnet passeren, in welke richting, met welke verversingssnelheid en met welk gedrag bij storing. Wat niet op de lijst staat, gaat er niet overheen.
2. Houd het aantal bewust. Elke extra gateway heeft een reden nodig die overeind blijft als je haar hardop uitspreekt. "De apparatuur van de onderaannemer spreekt alleen hun eigen protocol" is geen reden; dat is een inkoopbeslissing die bij verstek wordt genomen.

De criteria die het werkelijk bepalen

Vergelijkingstabellen richten zich op technische mogelijkheden, en die zijn zelden de bindende beperking. In de praktijk zijn de beslissingen die over de levensduur van een gebouw tellen commercieel en organisatorisch:

• Kunt u het onderhoud opnieuw aanbesteden? Als precies één integrator bij de configuratie kan, hebt u een abonnement gekocht, geen systeem. Dit is de duurste fout in dit vakgebied.
• Wie beheert de configuratiebestanden, en zitten ze in de oplevering? Benoem ze in het bestek. Neem ze in ontvangst. Controleer of ze openen.
• Hoe ziet de lokale integratormarkt eruit? Een protocol met drie capabele bedrijven op een uur rijden wint van een technisch superieur protocol met geen enkele.
• Wat gebeurt er als de supervisielaag uit staat? Bepaal bewust welke functies moeten doordraaien, en breng die omlaag naar een laag die blijft werken.
• Kunt u de punten uitlezen met iets dat u zelf schrijft? Wilt u ooit analyse, storingsdetectie of een eigen dashboard, dan is open leestoegang wat dat mogelijk maakt.

Wat specificeren wij dan?

Open protocollen op elke laag, grenzen die met opzet zijn getrokken, een vastgelegde puntenlijst over elke grens, en configuratiebestanden benoemd als contractueel opleverproduct. En daarna laten we meer dan één integrator inschrijven.

Het doel is geen protocolzuiverheid. Het doel is dat over tien jaar, wanneer het hoofdstation wordt vervangen en de oorspronkelijke integrator is overgenomen, iemand het systeem nog steeds kan openen, kan begrijpen wat het doet, en het kan wijzigen — zonder reddingsproject.