KNX Stacks für Linux
Software Verwendung
Der überwiegende Teil heutiger KNX Geräte basiert auf kleinen Hardwareplattformen mit 8- oder 16-bit Mikrocontrollern. Zunehmend halten aber komplexe Geräte Einzug in die Gebäudeautomatisierung, die in das KNX System eingebunden werden müssen.
In der Regel basieren diese Geräte auf 32-Bit Mikrocontrollern und nutzen ein Betriebssystem wie z.B. Linux. Der Vorteil liegt in einer hohen Leistungsfähigkeit und der Unterstützung vieler Hardware Schnittstellen z.B. für Displays oder Speicherkarten.
Der KNX Stack für Linux ist eine Implementierung der KNX System Software für Geräte mit dem Betriebssystem Linux. Der Stack kapselt die gesamte KNX Kommunikation sowohl zur Laufzeit als auch für die Gerätekonfiguration. Ein Anwendungsprogramm auf dem Gerät hat somit Zugriff auf die Gruppenobjekte und Parameter des KNX Systems.
Der KNX Stack ist als embedded Software für Linux ohne eigene grafische Oberfläche implementiert (Konsolenanwendung) und läuft ausschließlich im User-Mode. Der KNX Stack wird vom Anwendungsprogramm (Client) gestartet und übernimmt die Rolle eines Kommunikations-Servers zum KNX System. Die Konfiguration des KNX Stacks kann vom Client über das Konfigurations-Interface der API (siehe unten) geladen werden. Die Stack Applikation wird in der Regel erst beim Ausschalten des Gerätes beendet.
Die Verbindung zum KNX Netzwerk
Ein KNX Gerät mit Linux benötigt eine physikalische Verbindung zum verwendeten KNX Medium. Die Anbindung über Twisted Pair (TP) ist bei kleineren Installationen ohne IP Backbone die bevorzugte Wahl. Bei komplexeren Netzwerken, die normalerweise mit Ethernet/IP Backbone realisiert werden, erreicht man mit einer direkten IP Verbindung eine optimale Performanz bei gleichzeitig niedrigen Kosten.
Die Verbindung zu KNX TP
Da eine typische Linux Plattform nicht über eine direkte Anschlussmöglichkeit an KNX TP verfügt, ist ein Hardware Interface erforderlich. Prinzipiell kann jedes PC Interface für KNX verwendet werden, das einen Bus-Zugriff auf Data Link Layer Ebene unterstützt. Möglich sind zum Beispiel Schnittstellen für RS-232, USB oder IP. Für eine Lösung ohne zusätzliches Schnittstellengerät und um die Kosten zu reduzieren, ist jedoch eine integrierte Lösung vorzuziehen.
Eine einfache und kostengünstige Lösung ist das KNX TinySerial Interface 810 Modul von Weinzierl Engineering.
Dieses Interface bietet einen seriellen Buszugriff basierend auf dem TP-UART Protokoll und übernimmt zudem die automatische Generierung des Bus-Acknowledge. Dadurch entfällt der zeitkritische Pfad zwischen der Hardware und dem KNX Stack. Es kann somit der vorhandene serielle Treiber von Linux verwendet werden. Es wird kein dedizierter Kernel-Mode Treiber benötigt. Das Hardware Interface kann als kleine Platine mit KNX Bit-Tranceiver, einem kleinen Mikroprozessor mit UART Interface und galvanischer Trennung realisiert werden.
Die Verbindung zu KNX IP
Um eine Verbindung zum KNX Netzwerk über das Medium KNX IP herzustellen, wird kein spezielles Hardware Interface benötigt. Die Stack Software verwendet das KNXnet/IP Protokoll welches auf UDP/IP basiert. Die Kommunikation zur Laufzeit benutzt Multicast Adressierung. Da Linux Plattformen in der Regel Ethernet und TCP/UDP/IP Protokolle unterstützen, ist - hinsichtlich Entwicklungsaufwand und Kosten - die Anbindung an das KNX System über IP die effizienteste Methode.
Die Gerätekonfiguration
KNX Netzwerke werden überwiegend im sogenannten System Mode (S-Mode) mit dem Programm ETS (KNX Engineering Tool Software) konfiguriert. Die Inbetriebnahme eines Gerätes mit Linux unterscheidet sich in der Handhabung in der ETS nicht von der anderer KNX Geräte. Jedes KNX Gerät muss über einen Programmiermodus verfügen, der über einen Taster, oder alternativ über eine Funktion auf einem Display, angewählt werden kann. Die Konfigurationsdaten werden über das KNX Netzwerk in das Gerät geladen.
Die Konfigurationsdaten des Gerätes werden im Stack in einem Datenpuffer gespeichert. Um eine persistente Konfiguration zu erreichen, können die Gerätedaten unter Verwendung der Stack API gelesen und geschrieben werden. Die Aufgabe des Client ist es, die Daten zu lesen und z.B. auf der Festplatte beim Herunterfahren zu speichern. Beim Hochfahren startet der Client den KNX Stack Prozess und kopiert die Konfigurationsdaten vom nicht flüchtigen Speicher in den KNX Stack.
Gerätemodelle
Für ein KNX konformes Gerät werden nicht nur die einzelnen Schichten des KNX Stack nach dem OSI/ISO Referenz Modells benötigt. Insbesondere für die Kompatibilität mit der ETS Software muss jedes Gerät einem sogenannten Gerätemodell entsprechen. Ein KNX Gerätemodell spezifiziert, welche Services von einem Gerät unterstützt werden und welche Funktion diese ausführen. Es beschreibt sowohl das Speicherabbild als auch die Ladeprozeduren. Das heißt, welche Telegramm-Sequenzen für die Konfiguration eines Gerätes verwendet werden.
Die KNX Spezifikation definiert unterschiedliche Geräte-Modelle für die jeweiligen Medien. Für auf Linux basierende Geräte besteht hierbei kein Unterschied aus Sicht der Spezifikation.
Die KNX Stacks für Linux von Weinzierl Engineering entsprechen einem dieser Gerätemodelle und wurden entsprechend durch die KNX Association zertifiziert.
API über Socket Verbindung
Die KNX Stack Software läuft als Server Anwendung und hält eine Anwendungs-Schnittstelle (API) bereit, die über eine TCP/IP Socket Verbindung erreicht werden kann. Die Stack Software wird typischerweise von einer Client Anwendung gestartet und gesteuert. Für den Datenaustausch zwischen dem Server und einem Client auf demselben Gerät wird eine Socket Verbindung über localhost verwendet. Es ist natürlich auch möglich, den Client auf einem anderen Gerät im Netzwerk zu betreiben.
Das RPC Protokoll
Die Kommunikation zwischen Client (Anwender Applikation) und Server (KNX Stack) wird über ein Request/Response Protokoll ausgeführt. Dieses Protokoll ist in einer Client Bibliothek (RPC-Client-API) gekapselt. Die API beinhaltet zum Beispiel:
- BOOL RPC_KnxAl_SetValue(UINT nCoNo, UCHAR* pBuffer, UINT nDataLength);
- BOOL RPC_KnxAl_GetValue(UINT nCoNo, UCHAR* pBuffer);
- BOOL RPC_KnxMem_GetData(UINT nAddr, UCHAR* pData, UINT nCount);
- BOOL RPC_KnxMem_SetData(UINT nAddr, UCHAR* pData, UINT nCount);
Eine Kommunikation wird stets vom Client aus eingeleitet. Das folgende Diagramm beschreibt einen RPC Aufruf der Client Applikation.
Das Anwender Programm aktiviert eine der RPC Funktionen in der RPC-Client-API und übermittelt die entsprechenden Parameter. Der RPC Client ist für das Zusammenstellen des Datenpaketes und das richtige Einfügen der Parameter zuständig. Innerhalb des RPC Client wird dann die Sendefunktion des Socket aufgerufen, die die Anfrage an den Server übermittelt (Request). Der Server entpackt diese, ruft seine lokale API auf und generiert eine Antwort (Response). Der RPC Client ruft die Empfangs-Funktion des Sockets auf, um die Antwort vom Server zu erhalten. Sobald das Paket empfangen ist, wird der entsprechende Rückgabewert an die aufrufende Funktion zurück gegeben.
Für die clientseitige Anbindung über das RPC Protokolls auf Socket Level ist eine vollständige Referenz-Implementierung, sowohl für Linux als auch für Windows Umgebungen, vorhanden. Eine eigene Implementierung ist aber ebenso möglich.
Server Meldungen
Zusätzlich zur RPC API beinhaltet der KNX Stack ein Benachrichtigungs-System für folgende asynchrone Ereignisse:
- CONNECT
- DISCONNECT
- MGM_WRITE
- RESET
- GROUP_OBJ
Diese Ereignis-Nachrichten (Indication) werden über eine zweite TCP Verbindung übermittelt. Der Server wartet bzw. horcht auf eine Verbindung. Sobald der Client die Verbindung öffnet, werden die Server Meldungen getrennt vom RPC Request/Response Protokoll gesendet. Ein Beispiel zu Empfang und Auswertung von Meldungen ist im Softwarepaket enthalten.