Stack Implementierung für KNX-RF

Transkript

1 WEINZIERL ENGINEERING GmbH WEINZIERL ENGINEERING GMBH Dr.-Ing. Thomas Weinzierl Bahnhofstr Tyrlaching Tel. +49 (0) 8623 / Fax +49 (0) 8623 / info@weinzierl.de Web: Stack Implementierung für KNX-RF Abstract KNX ist die Abkürzung für Konnex, ein offener Standard für die Vernetzung und Steuerung von Gebäudetechnik. Konnex ist im Wesentlichen eine Weiterentwicklung des bekannten EIB-Systems (Europäischer Installationsbus), der mit seinen Medien Twisted Pair und Powerline bereits eine starke Verbreitung gefunden hat. Eine entscheidende Erweiterung von Konnex ist die drahtlose Alternative KNX-RF (Konnex Funk). Dieser Beitrag gibt einen kurzen Überblick über Anwendungsmöglichkeiten, technische Eigenschaften und über verfügbare Lösungen. 1 Anwendungsbereich Wie bei den etablierten Konnex Medien konzentriert sich auch bei Konnex-RF der Anwendungsbereich auf Steuerungsaufgaben. KNX-RF ist unter anderem geeignet, die Beleuchtung, Jalousien oder auch das Raumklima zu steuern. An Installationsorten, an denen weder Twisted Pair noch Powerline eingesetzt werden können, bietet KNX-RF die Möglichkeit, Daten innerhalb eines Gebäudes drahtlos zu übertragen. Wie der gesamte Konnex Standard ist auch die Funkkommunikation KNX-RF herstellerunabhängig. Die Konfiguration der KNX-RF Geräte kann ohne PC oder Laptop für die Inbetriebnahme erfolgen. Im Handel sind bereits Geräte der Firma Siemens (Gamma wave) und von Hager (Tebis TX). 2 Protokoll 2.1 Adressierung Die Adressierung im KNX-RF System baut auf das Verfahren bei Twisted Pair auf. Hier wird unterschieden in Individuelle Adresse und Gruppenadresse (jeweils 2 Byte). Die individuelle Weinzierl Engineering GmbH, Juli 2005 Seite 1/10

2 Adresse dient in erster Linie für die Konfiguration einzelner Geräte (Singlecast), während die Gruppenadressen für die Runtime-Kommunikation verwendet werden. Das heißt, im Betrieb ist die Standard-Adressierung immer Multicast. Die Gruppenadresse 0x0000 dient als Broadcast-Adresse. Da RF ein offenes Medium ist, wurde ähnlich wie bei Powerline eine Domain-Adresse hinzugefügt (6 Byte, programmierbar). Um die Gruppen-Telegramme von verschiedenen unidirektionalen Geräten, die nicht konfiguriert werden können, unterscheiden zu können, wird die Seriennummer des Absenders zur Zieladresse hinzugezogen. Zusammen mit der Gruppenadresse ergibt sich die so genannte erweiterte Gruppenadresse. Während bei Twisted Pair und Powerline sowohl Sender als auch Empfänger auf die jeweilige Adresse programmiert werden, wird bei Konnex Funk nur der Empfänger konfiguriert. 2.2 Physical Layer Die Funkschnittstelle von Konnex-RF entspricht den gesetzlichen Vorgaben für Short Range Devices. Die Spezifikation ist hardware-unabhängig. Derzeit gibt es verschiedene Chips am Markt, die für KNX-RF geeignet sind. Technische Daten: Mittenfrequenz: 868,3 MHz FSK Abweichung: +-50 khz Duty cycle: <1 % Modulation: FSK Codierung: Manchester Chip Rate: cps Sendeleistung: 1-25 mw Das Medium von KNX-RF ist sehr zuverlässig. Die gewählte Frequenz von 868 MHz ist aufgrund gesetzlicher Regelungen im Vergleich zu alternativen Bändern (z. B. 433 MHz) nur wenig gestört. Gegenüber den neuen Bändern im Bereich 2,4 GHz besitzen Geräte bei 868 MHz günstigere Ausbreitungseigenschaften. 2.3 Link Layer Das Frame-Format für KNX-RF besteht aus mehreren Elementen. Jedes Telegram startet mit einem Preheader, auf den sich der Empfänger synchronisiert. Preheader KNX-RF Preheader Preamble 15x 01 chip Manchester violation Sync word Nach dem Preheader folgt der erste Block mit einigen Kontroll-Informationen und der Serien- Nummer des Absenders. Der erste Block besteht immer aus 10 Datenbytes und besitzt eine eigene Checksumme mit 2 Bytes. Weinzierl Engineering GmbH, Juli 2005 Seite 2/10

3 Block 1 Length C-Field Esc Ctrl SN SN SN SN SN SN CRC hi CRC lo 0x11 0x44 0xFF 0x03 KNX-RF Datenblock 1 Die Nutzdaten folgen im Block 2, der maximal eine Länge von 16 Bytes plus 2 Bytes Checksumme haben kann. Bei längeren Telegrammen folgen weitere Datenblöcke. Die Codierung der Daten ab Block 2 entspricht im Wesentlichen dem KNX Telegrammformat wie es auch für Twisted Pair und für Powerline definiert ist. Block 2 KNX-Ctrl Src hi Src lo Dst hi Dst lo L/NPCI TPCI APCI Data... CRC hi CRC lo 0x00 0x05 0xFF 0x00 0x01 0xE6 0x00 0x81 KNX-RF Datenblock 2 Bemerkenswert sind die getrennten Checksummen für jeden Block. Durch das Generator- Polynom erhält man eine Hamming-Distanz von 6. Trotz der knappen Zeit, die dem Controller für die Auswertung zur Verfügung steht, ist es möglich, mindestens ein Bit pro Block zu korrigieren. Bei einer angenommenen Bit Error Rate (hier Chip Error Rate) von 10-4 kann die Telegramm-Erfolgsrate mit Hilfe der Korrektur von 96,31 % auf 99,97 % erhöht werden. 2.4 Network Layer Die Network Layer für Endgeräte (Sensoren und Aktoren) ist sehr einfach gehalten. In der Empfangsrichtung wird nur die Adressierungsart ausgewertet. Im Sendefall führt die Network Layer die verschiedenen Kommunikationsarten zu einheitlichen Link Layer Requests zusammen. 2.5 Transport Layer Derzeit wird für KNX-RF nur die verbindungslose Kommunikation verwendet. Die verbindungs-orientierte Kommunikation wie sie für das Management bei Twisted Pair und Powerline zum Einsatz kommt, ist bisher für Funk nicht vorgesehen. 2.6 Session und Presentation Layer Wie bei Twisted Pair und Powerline sind auch bei KNX-RF Session und Presentation Layer nicht definiert. Die entsprechende Funktionalität nach dem OSI/ISO Referenzmodell ist der Applikation Layer zugeordnet. 2.7 Application Layer Die Application Layer teilt sich auf in einen Service für die Runtime-Kommunikation, das heißt für die eigentlichen Steuerungsaufgaben, und in das Geräte-Management für die Konfiguration. Für die Runtime-Kommunikation wird folgender APCI-Service (Application Protocol Control Information) verwendet: Weinzierl Engineering GmbH, Juli 2005 Seite 3/10

4 APCI_VALUE_WRITE Das komplexe Management für KNX-RF bei bidirektionalen Geräten umfasst wesentlich mehr Services: APCI_PHYS_ADDR_WRITE APCI_PHYS_ADDR_READ APCI_PHYS_ADDR_RESP APCI_PHYS_ADDR_SER_NUM_READ APCI_PHYS_ADDR_SER_NUM_WRITE APCI_PHYS_ADDR_SER_NUM_RESP APCI_DOMAINADDRESS_WRITE APCI_DOMAINADDRESS_READ APCI_DOMAINADDRESS_SER_NUM_WRITE APCI_DOMAINADDRESS_SER_NUM_READ APCI_DOMAINADDRESS_SER_NUM_RESP APCI_NETWORK_PARAM_WRITE APCI_DEVICE_DESC_READ APCI_DEVICE_DESC_RESP APCI_PROP_VALUE_READ APCI_PROP_VALUE_RESP APCI_PROP_VALUE_WRITE APCI_PROP_DESC_READ APCI_PROP_DESC_RESP APCI_FNCT_PROP_CMD APCI_FNCT_PROP_STATE_READ APCI_FNCT_PROP_STATE_RESP Damit ergibt sich bei der Implementierung von bidirektionalen Geräten ein erheblicher Code- Umfang für die Management-Funktionen. Bei unidirektionalen Geräten ist der Umfang stark reduziert, da diese Geräte ohnehin über den Bus nicht angesprochen werden können. 3 Konfigurations-Modi Konnex beinhaltet nicht nur verschiedene Medien, sondern auch verschiedene Konfigurations-Modi. Prinzipiell sind alle Kombinationen aus Medien und Modi denkbar. Für KNX-RF wird bisher der Easy Mode verwendet, der System-Mode ist aber bereits in den Geräten implementiert. 3.1 System Mode (S-Mode) Der System Mode beschreibt die Konfiguration eines Systems mit Hilfe eines PCs. Aufgrund des leistungsfähigen User-Interfaces eines PC bietet dieser Modus die meisten Möglichkeiten für den Anwender. Die Komplexität der Funktionen fordert als Zielgruppe den geschulten Weinzierl Engineering GmbH, Juli 2005 Seite 4/10

5 Handwerker. Für KNX-RF ist noch kein Programm für den PC verfügbar, eine Einbindung in die ETS ist geplant. 3.2 Easy Mode (E-Mode) Der Easy Mode erlaubt die Konfiguration ohne PC. Es ist keine Produktdatenbank erforderlich. Alle für die Konfiguration benötigten Informationen sind bereits in den Geräten gespeichert. Der Easy Mode spaltet sich auf in verschiedene Unter-Modi. Siemens verwendet für die KNX-RF Geräte den Push Button Mode, der Controller von Hager ist an den Controller Mode angelehnt. Ch1 Switch PB On/Off CC01 GA1 Ch50 Binary switch no delay On/Off CC01 Status On/Off CC02 Ch05 Dimming PB On/Off CC01 Bight/Dark CC06 Ch = Channel Code CC = Connection Code GA = Group Address GA1 GA2 GA1 GA2 Ch55 Dimming Actuator On/Off CC01 Bight/Dark CC06 Value CC07 Status On/Off CC02 Status Value CC 08 Beispiel einer Easy-Mode Installation 4 Gerätemodelle Für ein Interworking von Geräten verschiedener Hersteller ist es erforderlich, dass die Geräte nicht nur dasselbe Protokoll verwenden, sondern auch eine bestimmte Menge an Funktionen bereitstellen. Dazu wurden in Konnex verschiedene Gerätemodelle als Profiles definiert. Der KNX-RF Standard unterscheidet zwischen unidirektionalen Geräten, die nur senden können und bidirektionalen Geräten, die auch einen Empfänger besitzen. Da unidirektionale Geräte nicht permanent empfangsbereit sein müssen, können sie sehr stromsparend realisiert werden und eignen sich für Batterie betriebene Sensoren. Aktoren müssen natürlich bidirektional ausgeführt werden und werden in der Regel aus dem Stromnetz versorgt. Derzeit sind für Funk folgende Gerätemodelle definiert: 2010 (bidirektional) 2011 (unidirektional) Die derzeit am Markt verfügbaren Geräte werden im so genannten Easy-Mode konfiguriert. Das heißt, es ist kein PC oder Laptop erforderlich. Allerdings wird unterschieden zwischen dem Push-Button Mode und dem Controller Mode. Im Push Button Mode können zwei Busteilnehmer, zum Beispiel ein Sensor und ein Aktor, ohne weitere Hilfsmittel verbunden wer- Weinzierl Engineering GmbH, Juli 2005 Seite 5/10

6 den. Sie werden nur gleichzeitig im Lernmodus aktiviert. Für den Controller Mode ist, wie der Name schon sagt, ein zusätzliches Gerät erforderlich, das die Verknüpfungen programmiert. Bei komplexen Installationen stoßen allerdings beide Easy Modi aufgrund des eingeschränkten User-Interfaces an ihre Grenzen. Als Alternative bietet sich in diesem Fall der System Mode, das heißt die Konfiguration mittels eines PCs, an. Da die am Markt verfügbaren Geräte bereits für den System Mode vorbereitet sind, ist es nur noch eine Frage der Zeit, bis eine entsprechende Software verfügbar sein wird. Geplant ist auch die Unterstützung von KNX-RF durch die ETS (EIB Tools Software). 5 Hardware-Architektur Der KNX-RF Standard schreibt keine bestimmten Bauelemente vor. Bereits jetzt kann die Konformität mit verschiedenen Architekturen erreicht werden. In der Regel werden Prozessoren eingesetzt, die sich durch eine geringe Stromaufnahme auszeichnen. Für die Funk- Kommunikation dient ein Transmitter bzw. Transceiver. Spezielle Chips für KNX-RF sind noch nicht verfügbar, aber bereits in Planung. Die Einführung entsprechender Bauteile ist für Ende 2006 geplant und wird zu einer deutlichen Reduzierung der Entwicklungs- und Produktionskosten führen. KNX-RF Device Application-HW Inputs Outputs Sensors Aktuators I/O Microcontroller CPU RAM, Flash USART, SPI PDATA PALE PCLK DIO DCLK Prog. Interface Data Interface RF Transceiver Analog Part Typische Hardware-Architektur für KNX-RF Evaluation-Boards bidirektional 6 Verfügbare Implementierungen Derzeit bieten die Firmen Siemens und Hager diverse Endgeräte für KNX-RF an. Als erste Firma bietet die Weinzierl Engineering GmbH eine Stack Implementierung für KNX RF an. Weinzierl Engineering GmbH, Juli 2005 Seite 6/10

7 Verschiedene Geräte für KNX-RF (Siemens und Hager) 6.1 Stack-Implementierung der Weinzierl Engineering GmbH Basierend auf der breiten Erfahrung in der Entwicklung von KNX System-Software für Twisted Pair und Powerline, hat die Weinzierl Engineering GmbH jetzt auch einen Stack für KNX-RF entwickelt. Während die oberen Schichten des Protokolls zahlreiche Parallelen zu den drahtgebundenen KNX-Geräten aufweisen, wurde die Funkkommunikation in Konnex neu definiert. Somit wurden bewährte Module aus anderen Gerätemodellen adaptiert und mit einer neu entwickelten Übertragungsschicht für KNX-RF kombiniert. Wie der KNX-RF Standard unterscheidet auch unsere Implementierung zwischen unidirektionalen und bidirektionalen Geräten. Unidirektionale Geräte enthalten nur die Funktionen für das Senden und einen stark vereinfachten Kommunikations-Stack. Die Software unterstützt einen Stromspar-Modus, um eine hohe Lebensdauer der Batterie zu erreichen. Da die unidirektionale Software eine Code-Größe von nur wenigen kbytes aufweist, können sehr preiswerte Controller eingesetzt werden. Unsere bidirektionale Implementierung beinhaltet neben dem Sender auch einen Empfangsteil. Obwohl die Verarbeitung der empfangenden Daten aufgrund der relativ hohen Datenrate zeitkritisch ist, ist es möglich, noch während des Empfangs einzelne Bitfehler zu erkennen und zu korrigieren. Dadurch erreicht man auch bei ungünstigen Übertragungsverhältnissen eine sehr hohe Qualität der Kommunikation. Bidirektionale Geräte enthalten einen vollständigen Kommunikations-Stack, der auch den Link-Mechanismus für die Inbetriebnahme mit einschließt. Weinzierl Engineering GmbH, Juli 2005 Seite 7/10

8 Comm- Object- Table Assoc- Table Address- Table Application Layer Management Comm.- Objects Properties, Link Mgm. Transport Layer Connection-Less Network Layer Link Layer Physikal Layer Application KNX-RF-Stack Transceiver KNX-RF Stack-Architektur Sowohl unsere unidirektionale als auch unsere bidirektionale Implementierung bieten die Möglichkeit der Integration der Applikationssoftware in den Controller. Unsere Stack- Implementierung ist kompatibel mit dem Konnex Standard und damit mit KNX-Geräten anderer Hersteller. 6.2 Hardware Zur Evaluierung und Entwicklung mit unserer Lösung für KNX-RF stehen vier verschiedene Hardware-Plattformen zur Verfügung: KNX-RF Entwicklungshardware (Bidirektional) KNX-RF Sensor (Evaluierungshardware unidirektional) KNX-RF Aktor (Evaluierungshardware bidirektional) KNX-RF UART (Evaluierungshardware bidirektional mit RS-232 Interface für PC) Entwicklungsplatine für KNX-RF Aufgrund der Forderung nach einem geringen Stromverbrauch, wurde als Controller die MSP430 Familie von Texas Instruments ausgewählt. Für die Funk-Schnittstelle kommen Komponenten der Firma Chipcon zum Einsatz. Diese Kombination erlaubt die Realisierung von leistungsfähigen Geräten zu geringen Kosten bei sehr niedrigem Stromverbrauch. Besonders unidirektionale Geräte können äußerst preisgünstig hergestellt werden. Der Einsatz alternativer Bauelemente ist natürlich ebenfalls möglich. Spezielle KNX-RF-Chips, die Weinzierl Engineering GmbH, Juli 2005 Seite 8/10

9 voraussichtlich Ende 2006 verfügbar sein werden, werden in Abstimmung mit unserer Stack- Implementierung entwickelt. 6.3 Entwicklungs-Tools Die Qualität jeder Entwicklung ist abhängig von der Qualität der benutzten Werkzeuge. Bei der Entwicklung eines Geräts für KNX-RF ist es sehr wichtig, das Verhalten des Geräts am Bus genau analysieren zu können. Zu diesem Zweck ist ein Busmonitor erforderlich, der die Telegramme, die auf dem Bus ausgetauscht werden, sichtbar macht. Bildschirmphoto Net n Node Zur effektiven Entwicklung von KNX-RF Systemen haben wir unsere bewährte EIB/KNX Analysesoftware für KNX-RF erweitert. kann Funktelegramme sowohl senden, als auch empfangen. Für alle Services von KNX-RF stehen Eingabedialoge zur Verfügung, die das Zusammenstellen von Telegrammen vereinfachen. Sendedialog für ein Gruppentelegramm Sendedialog für ein Managementtelegramm Weinzierl Engineering GmbH, Juli 2005 Seite 9/10

10 Die Anzeige erfolgt im cemi-format. Zum Zugriff auf das Medium ist ein USB-Interface für KNX-RF verfügbar. USB-Interface für KNX-RF 7 Zusammenfassung Mit der Funklösung KNX-RF hat die Konnex Association einen entscheidenden Schritt für den weiteren Erfolg des Konnex Standards vollzogen. KNX-RF vervollständigt die verfügbaren Medien und eröffnet neue Anwendungsbereiche. Durch die drahtlose Kommunikation können gerade im Wohnbau neue Märkte erschlossen werden. Für Hersteller von besonderer Bedeutung ist die Tatsache, dass KNX-RF ab sofort verfügbar ist. Dazu ist Konnex ein offener Standard. Konnex wurde in der EN50090 als Europäische Norm bestätigt. Die Integration von KNX RF unter EN ist bereits in Bearbeitung. Mit der Stack Implementierung und den Entwicklungstools der Weinzierl Engineering GmbH ist darüber hinaus ein leistungsfähiges Gesamtpaket verfügbar, um effizient und kostengünstig Geräte zu entwickeln. 8 Literatur [1] Konnex Association: KNX standard (Version 1.1), Brussels, February 2004; CD-ROM [2] Weinzierl, Thomas: A new development kit for EIB/KNX devices based on TP-UART chip; Proceedings KNX Scientific Conference 2002, TU-München October 2002 [3] Weinzierl, Thomas: EIB-USB Data Interface; Proceedings EIB Scientific Conference 2001, TU-München October 2001 [4] Weinzierl, Thomas: Integriertes Managementkonzept für die Gebäudesystemtechnik; Pflaum Verlag München 2001; ISBN [5] More Information at Weinzierl Engineering GmbH, Juli 2005 Seite 10/10