Industrielle IoT-Entwicklung für Smart Buildings
Ein Smart Building ist selten ein einziges System; es ist eine Kälteanlage auf BACnet/IP, Zähler auf Modbus, ein Beleuchtungspaneel mit proprietärem RS-485 und ein Zutrittscontroller, der die Belegungsdaten besitzt, aber keine davon teilt. Wir bauen das IIoT-Gateway und die Integrationsschicht, die diese Protokolle in ein Tag-Modell normalisiert und die Leitlogik systemübergreifend durchsetzt, sodass das Gebäude als System läuft statt als fünf getrennte Hersteller-Inseln.
Challenges specific to Smart Buildings
BACnet/IP-Daten der Kälteanlage erreichen nie die Analyseschicht
Der Anlagencontroller stellt BACnet/IP-Objekte bereit, aber keine Historian-Bindung, sodass Kaltwasser-Vorlauftemperatur, kW und Durchfluss nur 24 Stunden lokal getrendet und dann überschrieben werden und niemand das kW/Tonne der Anlage über eine Saison nachweisen kann.
Versorger- und Mieterzähler hängen an einem verwaisten Modbus-Strang
Strom- und BTU-Zähler sitzen ohne Gateway an einer Modbus-RTU-Schleife, die Register werden einmal im Monat per Tabelle ausgelesen, und Streitfälle zur Mieter-Subzählung haben keine prüfbaren Intervalldaten zur Klärung.
Die Belegung ist im Zutrittskontrollsystem gefangen
Badge-Zählungen, die eine bedarfsgeführte Lüftung und Absenkung bei Nichtbelegung steuern sollten, bleiben in einer proprietären Zutrittsdatenbank ohne Export eingeschlossen, sodass die HLK leere Etagen unter Volllast konditioniert.
Beleuchtung und Sicherheit laufen auf Protokoll-Inseln
Ein DALI/0-10V-Beleuchtungspaneel und der Sicherheits-DVR sprechen jeweils ihren eigenen Bus, teilen keinen Zeitplan mit der HLK, und ein Feiertag oder ein Ereignis außerhalb der Betriebszeiten muss fünfmal in fünf Tools programmiert werden.
Systemübergreifende Leitlogik hat keinen Ort zur Ausführung
Es gibt keine Schicht, die Anlagenlast, Zählerbedarf und Belegung gemeinsam lesen kann, sodass Spitzenlastbegrenzung und optimaler Start/Stopp unmöglich sind und das Gebäude jede Lastspitzen-Gebühr schluckt.
How GizanTech solves them
- Multiprotokoll-Gateway und Tag-Normalisierung. 1) Ein Edge-Gateway betreibt gleichzeitig BACnet/IP-, BACnet MS/TP- und Modbus-RTU/TCP-Clients, bildet jedes Objekt und Register in ein normalisiertes Tag-Modell mit Engineering-Einheiten und Qualitäts-Flags ab und stellt es stromaufwärts als MQTT/Sparkplug B oder BACnet/IP bereit.
- Historian-Bindung der Anlage und M&V-Datenpfad. 2) Wir binden kW, Durchfluss und Vor-/Rücklauftemperaturen der Kälteanlage an einen Zeitreihen-Historian mit Minutenauflösung, berechnen kW/Tonne und Anlageneffizienz am Edge und bewahren IPMVP-gerechte Intervalldaten für Messung und Verifizierung auf.
- Abrechnungsgenaue Subzählungs-Pipeline. 3) Modbus-Strom- und BTU-Zähler werden in festem Intervall abgefragt, am Gateway mit Zeitstempel und Lücken-Flags versehen und als prüfbare 15-Minuten-Intervallwerte geliefert, sodass Mieterkostenverteilung und ENERGY-STAR-Berichte belastbar sind.
- Befreiung von Belegungs- und Zutrittsdaten. 4) Wir holen Badge- und Belegungsereignisse über dessen API oder eine OSDP/Wiegand-Brücke aus dem Zutrittskontrollsystem, normalisieren sie zu zonenbasierten Belegungs-Tags und veröffentlichen sie an HLK und Beleuchtung für DCV und Absenkung bei Nichtbelegung.
- Systemübergreifende Leitsteuerungsschicht. 5) Eine Leitengine liest Anlagen-, Zähler- und Belegungs-Tags gemeinsam, um Spitzenlastbegrenzung, optimalen Start/Stopp und Zeitpläne außerhalb der Betriebszeiten einmal auszuführen, und schreibt dann Sollwerte über BACnet an jedes Teilsystem zurück.
| Gebäudesystem | Feldbus-Protokoll | Integrationsansatz | Betriebliches / energetisches Ergebnis |
|---|---|---|---|
| HLK / Kälteanlage | BACnet/IP (Controller-Objekte) + Modbus TCP an den Frequenzumrichtern | Gateway fragt Anlagenobjekte ab, bindet kW/Durchfluss/Temperaturen an Historian, berechnet kW/Tonne am Edge | Kontinuierlicher Trend der Anlageneffizienz; optimaler Start/Stopp spart 8-15 % der Anlagenlaufzeit-Energie |
| Energie- / Mieterzählung | Modbus-RTU-Strom- und BTU-Zähler | Abfrage in festem Intervall, Gateway versieht 15-Minuten-Intervallwerte mit Zeitstempel und Lücken-Flags | Prüfbare abrechnungsgenaue Subzählung; Mieterkostenverteilung und ENERGY-STAR-Daten halten stand |
| Belegung / Raumluft | BACnet MS/TP CO2/Raumluft + Systembelegung über API/OSDP | Normalisierung von CO2 und Badge-Zählungen in zonenbasierte Belegungs-Tags für DCV und Absenkung | Bedarfsgeführte Lüftung senkt Ventilator- und Nachheizstunden auf leeren Etagen |
| Zutritt / Sicherheit | OSDP / Wiegand + proprietäre Zutritts-API | Tür- und Einbruchsereignisse in das Tag-Modell und den einheitlichen Zeitplan überführen | Ereignisse außerhalb der Betriebszeiten steuern HLK und Beleuchtung einmal statt in fünf separaten Tools |
| Beleuchtungssteuerung | DALI / 0-10V-Paneel über RS-485 zu BACnet | Beleuchtungsgruppen auf BACnet-Objekte abbilden, die den Belegungszeitplan der Leitebene teilen | Tageslicht- und Abwesenheitsnutzung senkt die Beleuchtungslast und richtet sich an der HLK-Absenkung aus |
Go deeper
Industrial IoT Development for other industries
Frequently asked questions
Ersetzen Sie unser bestehendes BMS oder integrieren Sie es?
Wir integrieren. Das IIoT-Gateway steht neben Ihren bestehenden BACnet- und Modbus-Controllern, liest deren Objekte und Register und ergänzt eine normalisierte Daten- und Leitschicht darüber, sodass Sie Ihre Anlagencontroller behalten und systemübergreifende Steuerung sowie Historian-Daten ohne kompletten Austausch gewinnen.
Wie holen Sie Belegungsdaten aus einem geschlossenen Zutrittskontrollsystem?
Wir integrieren über das, was das System bereitstellt: eine dokumentierte REST- oder Datenbank-API, sofern vorhanden, oder eine OSDP/Wiegand-Brücke auf Leseebene, wo keine besteht. Badge- und Türereignisse werden in zonenbasierte Belegungs-Tags normalisiert, die bedarfsgeführte Lüftung und Absenkung bei Nichtbelegung steuern.
Sind die Subzählungsdaten gut genug für die Mieterabrechnung?
Ja. Wir fragen die Modbus-Strom- und BTU-Zähler in festem Intervall ab, versehen jeden Wert am Gateway mit Zeitstempel, markieren Lücken und speichern prüfbare 15-Minuten-Intervalldaten, sodass Mieterkostenverteilung, Lastspitzen-Analyse und ENERGY-STAR-Einreichungen belastbar sind statt Tabellen-Schätzungen.
Kann die Integrationsschicht wirklich Energie sparen oder nur überwachen?
Sie steuert. Die Leitengine liest Anlagenlast, gemessenen Bedarf und Belegung gemeinsam, um Spitzenlastbegrenzung, optimalen Start/Stopp und Zeitpläne außerhalb der Betriebszeiten auszuführen, und schreibt dann Sollwerte über BACnet zurück, was typischerweise 8-15 % der Anlagenlaufzeit-Energie einspart und Lastspitzen kappt.
Wie sehen die Daten für unsere Cloud- oder Analyseplattform aus?
Stromaufwärts veröffentlichen wir das normalisierte Tag-Modell als MQTT mit Sparkplug B oder stellen es als BACnet/IP für ein bestehendes Head-End bereit, sodass Ihre Analyse-, Fehlererkennungs- oder Cloud-Plattform konsistente Engineering-Einheiten und Qualitäts-Flags sieht statt roher Hersteller-Register.