Grundsätzlich kann so eine Steuerung zentral oder dezentral arbeiten (wobei natürlich auch Mischformen denkbar sind).
Beim zentralen Ansatz gibt es einen Master, der zyklisch alle Sensoren (Thermometer, Lichtschalter, usw.) abfragt und dann die entsprechenden Aktionen auslöst.
- + wenig Intelligenz bei den Sensoren/Aktoren nötig
- + bei Konfigurationsänderungen keine Änderungen bei den Sensoren/Aktoren nötig.
- + keine Multimasterfähigkeit nötig
- - je mehr Sensoren vorhanden sind, desto länger dauert ein Abfragezyklus. Da so ein selbst gebauter Hausbus ja auch Raum für Erweiterungen bieten soll, sollte man schon mit 100-200 Sensoren rechnen (Lichtschalter, Thermometer, Glasbruchsensoren, Rauchmelder usw. usf)
- - Wenn die Zentrale ausfällt, dann fällt die gesamte Steuerung auf einmal aus
Anmerkung: Falls, wie im dezentralen Fall die Sensoren von sich aus Zustandsänderungen melden, aber die Nachrichten nur an den Master schicken, entfällt der Nachteil durch das Polling. Dafür muss der Master allerdings asynchron eintreffende Nachrichten verarbeiten können (das kommt dann als Erschwernis dazu).
Beim dezentralen Ansatz senden die Sensoren (z. B. Lichtschalter) Botschaften an die Aktoren (z. B. die Glühlampe).
- + Die Buslast hängt von der Anzahl Ereignisse ab und nicht von der Anzahl Sensoren. Ein Glasbruchsensor, der nie aktiv wird, verursacht auch keine Buslast.
- + Keine Schaltzentrale nötig (also kein Single Point of Failure)
- - Multimasterfähigkeit bei allen Sendern (also allen Sensoren) nötig.
- - Konfigurationsänderungen müssen immer an den entsprechenden Aktoren/Sensoren gemacht werden. Dazu muss man sie entweder fernkonfigurieren können oder mit dem Konfigurationsgerät direkt an die jeweiligen Geräte.
Solange man nur ein einzelnes Wohnhaus (und nicht etwa eine Schule oder eine Fabrik) ausrüsten will und nur die üblichen Sensoren/Aktoren hat, ist praktisch jeder Bus schnell genug. Andererseits erlauben RS485 und der CAN-Bus bei den in einem Haus vorkommenden Kabellängen auch durchaus Geschwindigkeiten von 1 MBit/s, wodurch man auch andere Anwendungen damit realisieren könnte.
--> Hohe Geschwindigkeit heißt höherer Aufwand und höhere Kosten <--
Ein Hausbus sollte deshalb in der Geschwindigkeit auf die notwendigen Bedürfnisse abgestimmt sein. Folgende Rechnung lässt sich aufmachen:
Ein Frame mit einem einfachen Event z. B. "Taste 4 des Moduls 0x2007 gedrückt" lässt sich mit allem Nötigen wie Priorität, Parity-Bits Anzahl Datenbytes und Checksumme in 6 "Byte" à 10 Bit verpacken. Bei einer Geschwindigkeit von nur 10 kHz dauert die Übertragung ca. 6 ms. Erlaubt man pro Frame max. 12 Datenbyte, ergeben sich 18 ms. Wobei 12 Datenbyte eigentlich nur zur Konfiguration der Knoten nötig sind. Uhrzeit, Datum, Temperaturen usw. kann man meistens mit 2 - 4 Datenbyte melden. Da mit der CAN-Topologie kollisionsfrei Daten übertragen werden und ein Hausbus im Allgemeinen keiner hohen Belastung unterliegt, ist es realistisch sonstige Verzögerungen zu vernachlässigen. Ich habe in meinem Fünf-Personen-Haushalt den Bus nach "Bus-belegt-Verzögerungen" gescannt und in drei Monaten vier dieser Ereignisse festgestellt. Das bedeutete 12 ms anstatt der erwähnten 6 ms.
Warum sollte man schneller werden, wenn eine Verzögerung von 200 ms in der Realität nicht festgestellt wird. Die Verzögerung einer Leuchtstofflampe empfinde ich da schon eher als störend.
Sollten wir eine Schule mit solch einem Bus betreiben und 166 Kinder stürmen in die Pause und betätigen dann alle einen Taster, verzögert sich das letzte Ereignis um nicht ganz eine Sekunde.
[Bearbeiten] Vergleich von Hausbussystemen
(es gibt auch noch DALI für Lichtsteuerung epanorama)
- + nur 2 Leitungen für Daten, Power und GND
- + kein Abschluss-R nötig, alle Bustopologien
- + multimasterfähig
- + übertragungssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
- + Herstellerunabhängig (eine Vielzahl von Herstellern bieten Komponenten für alle erdenklichen Anwendungen)
- - Chips nur schwer erhältlich und teuer
- - nur industrielle Module erhältlich, kein Selbstbau
- + Freebus als Selbstbauvariante? Freebus Homepage (Deutsch)
- + Protokoll bereits im Chip
- + multimasterfähig
- + übertragungssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
- + hohe Störsicherheit durch differentielle Übertragung
- O Preis ist ausgewogen
- - es werden 2 Leitungen Daten + Power + GND benötigt
- - Abzweigungen vom Bus sind problematisch (max. 1 m?)
- - Abschluss-R notwendig
- + sehr günstig
- + Schnittstellenbausteine können direkt an den USART eines Mikrocontrollers angeschlossen werden
- + Buslänge von 1200 m möglich
- + hohe Störsicherheit durch differentielle Übertragung
- - Abzweigungen vom Bus sind problematisch (max. 1 m?)
- - Abschluss-R notwendig
- - von Haus aus nicht multimasterfähig, muss per Software realisiert werden
- +/- zentrales System
- + sehr günstig
- + sehr einfache Verdrahtung
- + integrierte Peripheriebausteine erhältlich (Thermometer, I/O-Bausteine, etc.)
- + über einfaches Selbstbauinterface vom PC ansteuerbar
- + Bus kann mit Pullup-Widerstand direkt von einem bidirektionalen Microcontrollerpin angesteuert werden
- + professionelle Softwareinterface frei erhältlich (unterstützt bis zu acht Busleitungen)
- + mit einfachem Pullup-Widerstand maximal 200 m Buslänge zulässig
- + mit aufwendigerem aktiven Pullup maximal 500 m Buslänge zulässig
- + integrierte Interfaceschaltungen für I²C, USB und Serielle Schnittstelle erhältlich
- + ausführliche Darstellung zur Buslänge in Appnote 148 verfügbar
- + Peripherie ohne separate Spannungsversorgung möglich
- + umfangreiche Herstellerunterstützung durch technische Dokumente
- - nicht multimasterfähig
- - max. 75 Bausteinabfragen/s
- - Peripherieschaltungen nur als integrierte Bausteine erhältlich
- - in Software realisierte Peripherie verstößt gegen US-Patente
- - keine differentielle Übertragung, dadurch deutlich störanfälliger
- - keine genormte Kabel- und Steckerbelegung
- + billig
- + multimasterfähig
- + viele direkt anschließbare Slave-Bausteine vorhanden
- + mit Treiber IC Kabellängen von 100m und mehr möglich
- - differentielle Übertragung nur mit Mehraufwand möglich
- - ohne differentielle Übertragung störanfällig
- - ohne Treiber IC nur Kabellängen unter 10 m möglich
- - als "Inter-IC-Bus" zur Anwendung innerhalb von Geräten konzipiert
- + multimasterfähig
- + sehr schnell
- +/- mit TP-Kabel (100Base-T) Sternstruktur, Leitungslänge bis 100 m
- +/- mit Koaxkabel (10Base-2) Busstruktur, Leitungslänge bis 185 m
- + Verkabelung und Stecker sind genormt
- - aufwändig anzusteuern (hoher Hardware- und Softwareaufwand)
- - (teuer) d.h. für Selbstbau aufwendig
- - (hoher Stromverbrauch des TCP/IP Treibers/PHY-ICs)
- + Nachrüstbar (keine zusätzliche Verdrahtung erforderlich)
- + nutzt vorhandene Netzinstallation
- - erzeugt ein breitbandiges Störspektrum (nur bei dLan), das über die Netzinstallation unkontrolliert abgestrahlt wird
- - kann Funkbetrieb, insbesondere im Kurzwellenbereich, stören (bei Powerline im 125kHz-Bereich sind Störungen des Kurzwellenfunks ausgeschlossen)
- - funktioniert ohne Phasenkoppler nur auf gleichen Phasen (Phasenkoppler besteht aus drei Kondensatoren)
- - Netzteile mit vernünftigen EMI-Filter filtern auch das PL-Signal (hinter Netzteilfiltern wird meist kein Bus-Signal mehr benötigt)
- - geringe Übertragungsrate (ohne breitbandige Störspektren zu erzeugen)
- - Modems werden im Störungsfall von der RegTP außer Betrieb genommen und werden dadurch wertlos (VDE Konformität erforderlich, Layout anspruchsvoll - Labortests?)
- - Kann von Energiesparlampen bzw von deren Vorschaltgeräte gestört werden (moderne Transceiver ICs sind relativ störsicher. Aber: Kosten)
- - Netzspannung! (es gelten nicht mehr allein Niederspannungsrichtlinien)