Eine KNX Entwicklung starten KNX Systemkomponente

Transkript

1 Eine KNX Entwicklung starten KNX Systemkomponente

2 Eine KNX Entwicklung starten KNX Systemkomponente Einführung Seit 2006 ist KNX ein weltweiter Standard und im ISO/IEC Standard verankert. Dadurch ist es ein offen beschriebenes Protokoll für Heim- und Gebäudeautomation und kann somit von jedem verwendet werden, der eine Kopie der jeweiligen Teile der obigen Norm in seinem Land erwirbt. Da Zeit ein bedeutender Faktor ist, ist es vielleicht nicht immer eine richtige Entscheidung um bei einer KNX Entwicklung von null anzufangen, d.h. mit nur dem internationalen Standard oder den KNX Spezifikationen als Basis. Dies gilt besonders, wenn man die Infrastruktur verwenden möchte, was KNX in der Welt der Heim- und Gebäudeautomation so einzigartig macht, d.h. das herstellerunabhängiges und anwendungsübergreifendes Werkzeug, ETS. Eine große Anzahl aller KNX Geräte wird durch die ETS in Betrieb genommen. Diese Geräte werden als S-Mode (System Mode) Geräte bezeichnet. Die ETS ist auch eins der wichtigsten Themen während den standardisierten KNX Grundkursen, die in mehr als 200 unabhängigen Schulungsstätten der Welt angeboten werden. Aus diesem Grund erklärt diese Broschüre zuerst welche Schritte notwendig sind, um ein KNX S-Mode Produkt zu entwickeln. In einem zweiten Teil, werden die verschiedenen Typen der verfügbaren KNX TP (Twisted Pair) Systemkomponente bzw. Kommunikationsstacks für einen schnellen Markteintritt aufgelistet. In einem dritten Teil wird erklärt, wie Geräte auf Basis anderer Medien wie Funk, Powerline und IP entwickelt werden. Schließlich gibt die Broschüre auch Hintergrundinformation, was bei der Entwicklung einer ETS APP oder ETS Plug-in Software berücksichtigt werden sollte. Schritte für die Markteinführung eines KNX S-Mode Gerätes Die folgenden Schritte sollen bei der Entwicklung eines KNX S-Mode Gerätes berücksichtigt werden: 1. Der KNX Standard sieht eine Anzahl von KNX Systemausprägungen vor, die unter anderem die Konfigurationsart des Gerätes bestimmen sowie den Umfang der Funktionalität im laufenden Betrieb. Diese sogenannten Profile sind im Kapitel 6 der KNX Spezifikationen beschrieben. Der Hersteller muss somit eine Auswahl des passenden Profils vornehmen, je nach gewünschter Funktionalität und wie das Gerät konfiguriert werden sollte. Das ausgewählte Profil bestimmt dann wieder den Typ des Mikrokontroller-Plattform, das man für die Entwicklung seines Kommunikationsstacks einsetzen kann. 2. Wenn das Profil festliegt, kann die Entwicklung der Hardware des Gerätes starten, sowie ebenfalls die Software, die man Anwendungsprogramm nennt. Man benötigt dann die passenden Entwicklungswerkzeuge zum ausgewählten Mikrokontroller (z.b. Compiler). Der Entwickler wird sich ebenfalls dafür entscheiden müssen, über welches KNX Medium das Gerät kommunizieren wird, d.h. Twisted Pair, Powerline, Funk oder IP, eins der vier verfügbaren KNX Medien. 3. Da die binären Daten des sich aus der Entwicklung ergebenen Anwendungsprogrammes nicht von einem Endkunden (typisch einem Installateur) gehandhabt werden können, müssen die Daten in ein Format verpackt werden, das vom Endkunden sowie von der ETS gelesen werden kann. Für dieses, braucht der Hersteller eine Lizenz des KNX Herstellerwerkzeuges, erhältlich über den KNX Online Shop ( Da jedes Gerät, das von der ETS geladen werden kann, zur Zertifikation vorgelegt werden muss, wird sehr empfohlen, dass während der Entwicklungsphase den notwendigen Input für die spätere Testphase der Zertifikation vorbereitet wird. Dafür bietet KNX das KNX Interworking Testwerkzeug an, ebenfalls über den KNX Online Shop erhältlich. 4. Sobald die Konformität ausrei- Serial Interface Module BOAS Module Bus Interface Module

3 chend vom Hersteller selber verifiziert wurde, kann das Anwendungsprogramm KNX zur Registrierung vorgelegt werden. Wenn die Anwendung registriert wird, wird sie von KNX signiert. Nur signierte Daten können in die ETS eingelesen werden und den KNX akkreditierten Prüfstellen für die formalen KNX Zertifikationskonformitätsprüfungen vorgelegt werden. Ab Registrierung ist ein Hersteller in der Lage, die Produkte mit KNX Logo zu versehen und zu vermarkten. 5. Wenn das Applikationsprogramm positiv getestet wurde, wird die KNX akkreditierte Prüfstelle sowohl KNX als dem Hersteller einen elektronischen Prüfbericht zusenden. Sobald eine CE-Erklärung für die jeweilige Hardware KNX vorliegt, wird KNX das KNX Zertifikat ausstellen. 6. Nachdem es zertifiziert wurde, wird KNX helfen, das Produkt zu vermarkten, indem Produkte im ETS Produktinformationsfenster gezeigt werden, einen Artikel im zwei Mal pro Jahr veröffentlichte KNX Journal aufgenommen werden oder die Produktbeschreibung auf den KNX Webseiten eingesehen werden können. Von Null anfangen oder verfügbare Systemkomponente verwenden? Wenn eine Entwicklung gestartet wird, hat ein KNX Hersteller folgende Optionen: 1. Der Hersteller entscheidet sich, das KNX Produkt komplett eigenständig zu entwickeln. Dies bedeutet, dass die einzige Basis für die Entwicklung die KNX Spezifikationen sind und alle Teile des Produktes (Physical Layer, Kommunikationsstack, Anwendungsprogramm und ETS Datenbankeintrag) entwickelt und zertifiziert werden müssen. Dies ist keine Option, wenn man mit dem Produkt schnell auf dem Markt sein möchte. Es hat jedoch den Vorteil, dass man von jeglichem Lieferant unabhängig ist. Dieses Szenario ist deshalb für größere Firmen mit einer großen Entwicklungskapazität geeignet, die eine größere Produktpalette vor Augen haben. 2. Der Hersteller entscheidet sich, existierende KNX Geräte eines anderen KNX Mitglieds in seinem eigenen Namen zu verkaufen. Der Entwicklungsaufwand dafür ist nahezu null, da sie auf eine erneute Registrierung des bestehenden ETS Anwendungsprogrammes im Namen des wiederverkaufenden Herstellers beschränkt ist. Dies ist ein administratives Verfahren, wobei die Produkte nicht erneut getestet werden müssen. 3. Der meistgeeignete Fall für Hersteller, die mit neuen Produkten anfangen, ist dass man existierende KNX zertifizierte Systemkomponente und/ oder Stacks einsetzt. Auf dieser Weise beschränkt sich die Entwicklung auf das Anwendungsprogramm und dessen Integrierung in die ETS Datenbank. Nur diese Teile sind Bestandteil der Zertifikation. KNX bietet sogar eine Unterstützung bei der Entwicklung ( KNX Cookbook ) mit Beispielen basierend auf existierenden Systemkomponenten, als Bestandteil des KNX Standards Kapitel zwei. Existierende TP Systembauteile Man unterscheidet vier Arten TP Systembauteile: 1. Buszugriffsmodule (abgekürzt BAU) 2. Bus Interface Module (abgekürzt BIM) 3. UART Übertrager 4. Bit Schnittstellen Wo BAUs den Vorteil haben, dass die Entwicklung minimal ist, ist deren Kost sicherlich die höchste. Die Kosten für eine Bit Schnittstelle sind zwar niedrig, der Entwicklungsaufwand und Zertifikation eines Produktes, das es einsetzt, ist höher. Mit anderen Worten, je höher das beabsichtigte Volumen, je mehr man eine Lösung aussuchen wird, bei der der erforderliche Entwicklungs- oder Fertigungsaufwand höher sein darf, jedoch über ein größeres Verkaufsvolumen verteilt werden kann. Ein anderer Faktor, der berücksichtigt werden sollte, ist der Mehrpreis für das Erzielen der KNX Kompatibilität im Vergleich zu den Kosten der restlichen Hardware. TP Buszugriffsmodule Zwei Firmen bieten Buszugriffsmodule an, auf deren Basis Geräte entwickelt werden können. Dabei muss nur eine Kommunikation über serielle Hostprotokolle vom Applikationsmodul zum BAU auf bereits implementierte KNX Gruppenobjekten hergestellt werden. Im Falle der SIM Lösung von Tapko 1, basiert das serielle Hostprotokoll auf ASCII oder I 2 C; im Falle des Weinzierl BAOS mit FT 1.2 Meldungen über eine UART Schnittstelle. Mikrokontoller mit embedded KNX Systemsoftware TP UART Übertrager TP Bus Transceiver Module

4 Für beide Lösungen, stehen generische oder spezifische ETS Datenbankeinträge zur Verfügung bzw. können entwickelt werden, neben der Entwicklung der eigentlichen Anwendungshardware, die auf den vorgenannten Plattformen läuft. TP Bus Interface Module Bus Interface Module sind Leiterplatten, bei denen die wichtigsten Bauteile die TP Physical Layer Implementierung bzw. der Mikrokontroller mit integriertem Kommunikationsstack sind. Die Module können in entwickelte Applikationshardware über binäre oder analoge Ein/Ausgangspins integriert werden und werden von SIEMENS 1 sowie von Tapko 1 angeboten. Im Falle von SIEMENS, werden die wichtigsten Bauteile ebenfalls als Chipsatz angeboten, z.b. für den Fall, dass der Aufbau des Applikationsmoduls die Verwendung eines BIMs nicht erlauben würde. Entwicklung auf Basis dieser BIM Module erfordert nur das Erzeugen eines Applikationsprogrammes passend zu dem integrierten Mikrokontroller und dessen Integrierung in die ETS Datenbank. TP UART Übertrager Ein UART Übertrager lässt eine Kopplung mit dem TP Bus zu: der Kommunikationsstack muss jedoch auf dem Mikrokontroller entwickelt werden, der zusammen mit diesem UART Übertrager eingesetzt wird. Auf dieser Weise kann man jeder Mikrokontroller mit KNX koppeln, der über eine UART Schnittstelle verfügt, ohne jedoch selbst eine Lösung für das Kodieren und Dekodieren von TP Bits entwickeln zu müssen. Solche Lösungen werden von EL- MOS, ON Semiconductor und SIE- MENS 1 angeboten. Weil der Kommunikationsstack neu entwickelt werden muss, hat man die Wahl, dies selbst zu erledigen, oder sich auf einem Mikrokontroller mit integriertem Stack zu basieren (wie von SIEMENS 1 angeboten). Oder man lizenziert einen der Stacks, die von den Firmen Tapko und Weinzierl angeboten werden. SIEMENS bietet darüber hinaus Unterputz Bus Transceiver Module an. Diese sind Endgeräte, die nur den TP-UART beinhalten und erlauben, Anwendungsmodule darauf zu montieren. Diese Module beinhalten dann den notwendigen Mikrokontroller mit Systemstack und Anwendungsprogramm. TP Bit Schnittstellen Bit Schnittstellen werden entweder angeboten auf der Basis diskreter Komponente oder als ASIC (Application Specific Integrated Circuits). Letzterer wird von SIEMENS 1 angeboten, ersterer wird von den Firmen Tapko/ Gira 1 lizenziert. Die Anforderungen bzgl. Timing am verwendeten Kommunikationsstack sind etwas höher als wenn man UART Übertrager einsetzt. 1 through the distributor Opternus Entwicklung von KNX Funkgeräten Der KNX RF Physical Layer ist als ein Band/ein Kanal oder als Mehrkanal- Lösung im 868 MHz Band spezifiziert. Dank eines festgelegten Kompatibilitätsschemas sind Ein- oder Mehrkanal-Funkgeräte völlig miteinander kompatibel. Multikanal RF Lösungen haben den Vorteil, dass sie in einen anderen Kanal wechseln können, wenn sie mit Störungen konfrontiert werden. Multikanal-Geräte können über bis zu fünf Kanäle verfügen, drei schnelle und zwei langsame. Multikanal-Geräte haben auch die Möglichkeit, in Schlafmodus zu gehen, um so ihren Stromverbrauch zu begrenzen. Sie können optional zulassen, den korrekten Empfang von Daten durch bis zu 64 KNX Funkempfängern mit einem Fast Immediate Acknowledge bestätigen zu lassen. Dies ist sogar in einer Anlage mit bis zu zwei Repeatern bei KNX Multi möglich. Wenn ein Fast Immediate Acknowledge nicht vorhanden ist, werden Telegramme automatisch wiederholt. Schließlich wird bei KNX Funk vor dem Start der eigenen Übertragung überprüft, ob bereits eine KNX Funkübertragung läuft, um so die Anzahl von Kollisionen zu verringern. Wie bei TP, können Lösungen selbst entwickelt werden. Für KNX Funk sind keine speziellen Chips notwendig. Basierend auf der Referenzimplementierung vom Chiphersteller, kann eine Schaltung bestehend aus dem ausgewählten Chip und einer Anzahl passiver Komponente entworfen werden und für die KNX Funkanforderungen optimiert werden. Auch für KNX Funk existieren zerti- TP Bit-Übertrager TP Bit Interface mit diskreten Komponenten Funk Multi-Kanal Implementierung

5 fizierte Physical Layer Lösungen bzw. Systemstacks von Radiocrafts, Texas Instruments, Tapko und Weinzierl. Im Vergleich zu anderen KNX Medien verwenden die jetzigen Lösungen KNX Easy Konfigurationsmodus (meistens das Push Button Mode Verfahren) zum Verbinden von und Setzen von Parametern in Geräten. ETS Unterstützung des Mediums Funk ist noch in der Vorbereitung. Entwicklung von KNX PL Geräten Erneut existieren zwei Physical Layer Profile, die historische PL110 FSK (Frequency Shift Keying) Ausprägung und die aufwärtskompatible Erweiterung PL110+, die OFDM (Orthogonal Frequency Division Multiplexing) verwendet. Letzteres erlaubt einen Datendurchsatz, der bis zu 22 Mal höher als die historische PL110 FSK ist. Auf dieser Weise ist das PL110+ Medium für Anwendungen geeignet, die z.b. Verschlüsselung benötigen, wie die Kommunikation zwischen dem intelligenten Zähler (im Keller) und dem Energiemanagementgateway (im Wohnzimmer), dies im Rahmen des intelligenten Stromnetzes. Kommunikationsstacks für KNX PL Geräte können bei Kellendonk und Weinzierl lizenziert werden, während Physical Layer Lösungen auf DSP (Digital Signaling Processors) Prozessoren von Texas Instruments realisiert werden können. KNX RF Ein-Kanal Implementierung Entwicklung von KNX IP Geräten Die Übertragung von KNX Telegrammen über Ethernet ist in den KNXnet/IP Spezifikationen festgelegt. Diese Spezifikationen erlauben die Verwendung des Mediums für PC Schnittstellen sowie für Router. IP Router sind ähnlich wie TP Linienkoppler, bis auf die Tatsache, dass sie Ethernet auf der Hauptlinie verwenden. Es ist jedoch auch möglich, direkt KNX Endgeräte über IP zu integrieren. Dadurch wird Ethernet bzw. IP (Internet Protocol) ein eigenständiges KNX Medium. Bei der Entwicklung von KNX IP Geräten werden keine besonderen KNX Komponente benötigt. Sie können auf Ethernet oder WIFI Kontrollern basieren, die von verschiedenen Halbleiterherstellern verfügbar sind. Kontroller mit einer Bitrate von 10 MBits sind in der Regel ausreichend um die KNXnet/IP Anforderungen zu erfüllen. Die Systemsoftware eines KNX IP Gerätes besteht aus zwei Protokollstacks. Kommunikation über Ethernet benötigt einen IP Stack mit UDP, da KNXnet/IP auf verbindungsloser Kommunikation basiert. KNX Unicast als auch Multicast Telegramme werden über UDP übertragen. Der KNX Stack sitzt oberhalb des IP/ UDP Stacks. Entweder werden diese Stacks komplett neu entwickelt oder man basiert sich auf verfügbaren und zertifizierten Lösungen von Tapko oder Weinzierl. Für den IP Stack kann man sich auch überlegen, leistungsfähigere Betriebssysteme wie Linux zu verwenden, die prinzipiell einen IP Stack mit UDP beinhalten. KNX IP Platform Entwicklung einer ETS APP oder Plug-in Eine ETS APP ist eine Projektierungsoder Diagnoseerweiterung zum ETS Werkzeug, während eine ETS Plug-in eine produktspezifische Konfigurationserweiterung in der ETS ist. In beiden Fällen muss man zwingend KNX Mitglied werden, um eine Entwicklung starten zu können. Nachdem ein entsprechender Vertrag unterschrieben wurde, bekommen die KNX Mitglieder Zugang zu der ETS APP Entwicklungsdokumentation und zu einem Administratorkonto im KNX Online Shop. Nachdem die Entwicklung der ETS APP abgeschlossen wurde und über das ETS APP Validierungswerkzeug verifiziert wurde, muss die APP nochmal von KNX validiert werden, bevor sie vermarktet werden kann, jedoch exklusiv über den KNX Online Shop. Die Dokumentation für eine ETS Plug-in ist Bestandteil des KNX Herstellerwerkzeuges. Entwickelte ETS Plug ins werden zusammen mit dem jeweiligen KNX Produkt den KNX Zertifikationsprüfungen unterworfen. Kontaktinformation ELMOS Semiconductor AG Kellendonk Elektronik ON Semiconductor Opternus Components GmbH Radiocrafts AS SIEMENS AG Tapko Technologies GmbH Texas Instruments Weinzierl Engineering GmbH

6 Der weltweite Standard für Haus- und Gebäudesystemtechnik KNX Mitglieder I N T E L L I G E N T AU T O M AT I O N YTE H DELTA DORE Deutsche Gebäude Automation functi ON GEVA automation HunterDouglas VENTILATION SUNPROTECTION WEINZIERL