KNX bietet als weltweit einziges Bussystem den kompletten Satz an Übertragungsmedien für die Gebäudessteuerung: Leitungsgebunden (Twisted Pair), Stromleitung (Powerline), Funk (Radio Frequency) und Ethernet/IP. Über KNX Medienkoppler können die Übertragungsmedien miteinander problemlos gekoppelt werden. Mit der ETS als hersteller-, produkt- und gewerkeunabhängigem Tool werden die KNX Anwendungen in Betrieb genommen.

 

Von der Idee zum fertigen Produkt, die Liste der Fragen, die ein KNX Einsteiger bei der Realisierung seines ersten KNX Gerätes hat, kann sehr umfangreich sein:

• Welches KNX Medium (z.B. Twisted Pair oder Funk) soll verwendet werden?
• Welche Softwareanforderungen stellt KNX?
• Welche Kommunikationsobjekte – Datenformate – muss ich verwenden, wie werden diese programmiert?
• Welche Hardwareanforderungen muss das Gerät erfüllen?
• Gibt es Standardkomponenten?
• Wie wird das Gerät in Betrieb genommen, das heißt, welche Konfigurationsmodi sollen unterstützt werden?
• Gibt es jemanden, den ich fragen kann – der mich bei der Entwicklung unterstützt?
• Wie geht das mit der Zertifizierung?

Um einschätzen zu können, welche Lösung für die Realisierung Ihres Gerätes am besten geeignet ist, hilft es, die am Markt vorhandenen KNX Standardkomponenten für die unterschiedlichen Medien kennen zu lernen.

 

Mehr Informationen zu den verfügbaren KNX Komponenten erhalten Sie bei nachfolgenden KNX Mitgliedsfirmen

 

 

Eelectron srl	Opternus Components GmbH	Tapko Technologies GmbH	Weinzierl Engineering GmbH
www.eelectron.com	www.opternus.com	www.tapko.de	www.weinzierl.de

 

 

Realisierungsaspekte für KNX TP

 

Wenn man sich auf dem Markt umsieht, begegnet man einer Reihe von Begriffen wie „BIM“, „BCU“, „SIM“, „TPUART“, „Chipset“ und „Kommunikations- Stack“. Diese Begriffe repräsentieren verschiedene Möglichkeiten, ein KNX TP Gerät zu realisieren.

 

BCU „Bus Coupling Units“, Busankoppler oder auch

Dies sind komplette Systemgeräte, die eine KNX Ankopplungschaltung und einen Mikrokontroller enthalten und komplett mit Gehäuse geliefert werden. Vom Geräteentwickler muss dann noch das Applikationsmodul, die Applikationshardware und Software entwickelt werden.

 

BIM, „Bus Interface Module“

Diese bestehen im Wesentlichen aus dem Innenleben der BCU, mit zusätzlichen I/O-Ports. Die BIM werden als Module verkauft, die direkt auf die Leiterplatte eingelötet werden.

Angeboten werden Versionen mit 8Kbyte bis 48Kbyte Flashspeicher für die Applikationssoftware. Die Softwareentwicklung erfolgt mit einer Entwicklungsumgebung, bestehend aus „Evaluationboard“, „On-Chip Debug Emulator“ und C-Compiler.

 

SIM, „Serial Interface Module“

Diese beinhalten das komplette Kommunikationssystem ohne Applikation. Der Applikationsteil Hardware sowie Software wird mit dem Kommunikationsteil über eine serielle Schnittstelle verbunden. Die SIM werden als Module verkauft, die direkt auf die Leiterplatte eingelötet werden.

 

BAOS, „Bus Access Object Server“

Das BAOS-Modul dient als Schnittstelle zum KNX sowohl auf Telegrammebene (KNX Link Layer) als auch auf Datenpunktebene (KNX Application Layer). Das Telegrammformat entspricht FT1.2. Für die Kommunikation auf Datenpunktebene steht ein optimiertes serielles Protokoll zur Verfügung.

 

Chipset

Um die mechanischen Einschränkungen der BIM zu umgehen, wurden die Chipsets der BIM angeboten. Bezüglich der Software besteht  kein Unterschied zwischen BIM und Chipsets.

 

TPUART

Der TPUART beinhaltet nur die eigentliche Ankopplung an den KNX. Die Kommunikationssoftware wird von einem an ihn angeschlossenen Mikrocontroller bereitgestellt. Der TPUART wurde entwickelt, um einerseits die Mikrocontroller von der Aufgabe der Bit-Codierung und Decodierung zu entlasten, andererseits um die Ankopplung an den KNX durch die unterschiedlichsten Mikrocontroller durchführen zu können.

 

Kommunikations-Stack

Um mit dem TPUART ein KNX Gerät zu entwickeln, benötigen Sie noch einen Kommunikations-Stack. Diese Art der Ankopplung ist die effektivste, flexibelste und auch eine kostengünstige Art, ein KNX Gerät zu entwickeln. Damit man sich nicht im Detail in die KNX Kommunikation einarbeiten muss, bieten KNX Systemhäuser KNX Kommunikations-Stacks an. Die Ankopplung an KNX erfolgt über eine externe KNX Ankopplung wie z.B. TPUART, FZE1066. Außerdem bietet der KNX Kommunikations-Stack Schnittstellen für die Programmierung der eigentlichen Applikation.

 

Wann empfiehlt sich welche Lösung?

Bei geringen Stückzahlen sind Module (BIM, SIM, BAOS) empfehlenswert. Sie zeichnen sich durch niedrige Entwicklungs- und Zertifizierungskosten aus und eignen sich gut, um in die KNX Entwicklung einzusteigen. Wenn der verfügbare Platz nicht ausreicht oder die Stückzahlen steigen, ist der Chipsatz eine interessante Alternative. Die Initialkosten sind nur geringfügighöher im Vergleich zum BIM. Der TPUART ist die meistverwendete Lösung für Seriengeräte mit hohen Stückzahlen. Der TPUART zeichnet sich durch geringe Stückkosten aus, erfordert allerdings einen höheren Entwicklungsund Zertifikationsaufwand. In bestimmten Fällen kann auch der Einsatz eines Bittransceiver (FZE1066) sinnvoll sein

 

Realisierungsaspekte für KNX PL

 

Ähnlich wie für Twisted Pair sind auch für KNX PL (PL110) standardisierte BCU und Module (PIM) erhältlich.

 

BCU, „Bus Coupling Units“, Busankoppler oder auch

Dies sind komplette Systemgeräte, die eine KNX Ankopplungschaltung und einen Mikrokontroller enthalten und komplett mit Gehäuse geliefert werden. Vom Geräteentwickler muss dann noch das Applikationsmodul, die Applikationshardware und Software entwickelt werden.

 

PIM, „Powerline Interface Module“

Diese bestehen im Wesentlichen aus dem Niederspannungsteil der BCU. PIM sind Module, die zusammen mit den Bauteilen zur Netzankopplung auf die Leiterplatte gelötet werden.

 

ASIC mit Kommunikations-Stack

Ein ASIC für PL110 übernimmt das Senden und Empfangen von Bits. Um auf Basis eines solchen ASICs ein KNX Gerät zu bauen, ist ein KNX Stack für Powerline (Kommunikationssoftware) erforderlich. Ein Kommunikations-Stack beinhaltet Schnittstellen für die Programmierung der Applikation.

 

Wann empfiehlt sich welche Lösung?

Im UP-Bereich und bei kleinen Stückzahlen eignen sich BCUs, um kostengünstig Geräte zu entwickeln. Bei mittleren Stückzahlen bietet sich die PIM an, ein entsprechender Schaltplan ist erhältlich. Die Entwicklung von PL-Geräten mit ASIC und Kommunikations- Stack erfordert im Vergleich zu BCU und PIM deutlich höhere Einstiegsinvestitionen und eignet sich somit in der Regel nur für Hersteller mit hohen Stückzahlen.

 

Realisierungsaspekte für KNX RF

 

Für die Entwicklung von KNX RF Geräten sind keine speziellen KNX Bauteile erforderlich. Um allerdings Entwicklungszeiten und -kosten zu reduzieren, kann der Einsatz von fertigen Funkmodulen sinnvoll sein. Dies ist in der Regel bei kleineren Stückzahlen der Fall. Im Wesentlichen besteht ein KNX RF Knoten aus folgenden Elementen:

 

Transceiver Chip

Für KNX RF ist kein bestimmter Chip notwendig. Heutzutage sind einige Chips verfügbar, die für die Realisierung von KNX RF Knoten verwendet werden können. Für einseitig gerichtete Geräte gibt es kostengünstige Chips nur mit Sendefunktion.

 

Funkschaltkreis

Der Funkschaltkreis setzt sich aus Transceiver und einigen passiven Komponenten zusammen. Ein Schaltkreis kann nach einem Referenzdesign eines Chipherstellers realisiert werden und nach den KNX RF Anforderungen optimiert werden.

 

Mikrocontroller

Der Kern eines KNX Gerätes ist ein Mikrocontroller, der die Kommunikation und die Anwendung steuert. Für die Funkübertragung ist die wichtigste Anforderung ein geringer Stromverbrauch. Die Schnittstellenlogik für die Ankopplung an den Transceiver sollte in den meisten der heutigen Controller vorhanden sein.

 

Kommunikations-Stack

Der KNX Standard definiert ein komplexes Protokoll, welches zu einem hohen Einführungs- und Zertifizierungsaufwand führt. Der Kommunikations-Stack ist die Systemsoftware für ein KNX RF Gerät. Es kontrolliert den Transceiver und steuert die komplette Kommunikation inklusive der Konfigurationsprozedur. Der Kommunikations-Stack stellt eine Schnittstelle (API) für die Anwendungsentwicklung bereit.

 

Realisierungsaspekte für KNX IP

 

Die Übertragung von KNX Telegrammen über das Ethernet ist als KNXnet/IP Protokollreihe definiert und Teil des KNX Standards. Der bisherige Stand der Spezifikation umfasste die Nutzung dieses Mediums für PC-Schnittstellen und für Router. IP Router sind vergleichbar mit Linienkopplern, nutzen aber für die Hauptlinie das Ethernet. Jetzt ist es zudem möglich, KNX Endgeräte direkt über IP in das KNX Netz einzubinden. Damit wird Ethernet bzw. IP (Internet Protokoll) ein vollwertiges KNX Medium.

Für die Entwicklung von KNX IP Geräten sind keine speziellen KNX Bauteile erforderlich. Im Wesentlichen besteht ein KNX IP Knoten aus folgenden Elementen:

 

Ethernetcontroller

Ethernetcontroller sind von verschiedenen Halbleiterherstellern verfügbar. Die Anforderungen von KNX IP werden in der Regel problemlos erfüllt. Meist sind Controller mit einer Datenrate von 10 MBit/s ausreichend.

 

Mikrocontroller

Die Wahl des Mikrocontrollers hängt im Wesentlichen von der erforderlichen Rechenleistung für das Gerät ab. Prinzipiell kann das KNXnet/ IP Protokoll sogar auf einem 8-Bit Controller implementiert werden. Je nach Anwendung können aber auch leistungsfähigere Controller erforderlich sein. Zahlreiche Controller bieten bereits ein Interface für Ethernet auf dem Chip, so dass nur noch der Physical Layer ergänzt werden muss.

 

Kommunikations-Stack

Die Systemsoftware für ein KNX IP Gerät besteht aus zwei Protokoll-Stacks. Für die Kommunikation über Ethernet ist ein IP-Stack mit UDP (User Datagram Protocol) erforderlich, da KNXnet/IP auf verbindungsloser Kommunikation basiert. Es werden sowohl Unicast als auch Multicast Telegramme über UDP verwendet. Auf den IP/UDP Stack wird der KNX Stack aufgesetzt. Dies ist der KNX Common Kernel, der natürlich je nach Gerätemodell speziell ausgeführt werden muss. Der KNX Stack nutzt den IP/ UDP Stack als Schnittstelle der KNX-Telegramme auf UDP-Telegramme ist durch KNXnet/IP festgelegt. Die KNX-Anwendung greift auf die API (Application Programming Interface) des KNXStacks zu, um mit dem Gesamtsystem zu kommunizieren.

 

Wann empfiehlt sich welche Lösung?

Die Wahl der richtigen Hardware ist wesentlich von der Anwendung abhängig. Hardwareimplementierungen speziell für KNX-IP Geräte sind bereits im Markt verfügbar. Hierfür werden auch entsprechende Stacks angeboten. Für komplexe Geräte können auch leistungsfähige Betriebssysteme wie zum Beispiel Linux eingesetzt werden, die in der Regel einen IP-Stack mit UDP beinhalten. In diesem Fall sind nur noch der KNX Stack und natürlich das entsprechende Anwendungsprogramm erforderlich.