Entwicklung von EIB-Geräten, Teil 1

Technik Entwicklung von EIB-Geräten, Teil 1 Von der Idee zum fertigen Produkt Klaus Adler / Petar Tomic Tapko Technologies GmbH, Regensburg Wenn Sie mit der Idee spielen, Ihr erstes EIB-Produkt zu entwickeln, stehen am Anfang eine Reihe von Fragen: Was bedeutet es, ein EIB-Gerät zu entwickeln? Welche Softwareanforderungen stellt der EIB? Welche Kommunikationsobjekte - Datenformate muss ich verwenden, wie werden diese programmiert? Welche Hardwareanforderungen muss mein Gerät erfüllen? Gibt es Standardkomponenten? Wie wird das Gerät in Betrieb genommen? Gibt es Jemanden, den ich fragen kann der mich bei der Entwicklung unterstützt? Wie geht das mit der Zertifizierung?... Die Liste der Fragen, die ein EIB- Einsteiger bei der Realisierung seines ersten EIB-Gerätes hat, kann sehr umfangreich sein. Wir erleben dies in unserer täglichen Arbeit als EIB-Entwicklungsdienstleister immer wieder. Ich möchte hier Antworten auf die häufigsten Fragen zusammenfassen. Eine der ersten Fragen, ist die Entwicklungsidee. Was soll das Gerät können? Es mag seltsam wirken: Sie wollen wissen, wie man ein Gerät entwickelt und erhalten gleich eine Gegenfrage. Das kommt nicht von ungefähr. Wir bekommen immer wieder Anfragen in der Art Wir haben ein Gerät und der Markt verlangt eine EIB-Ankopplung. Was müssen wir machen? Um einschätzen zu können, welche Lösung für die Realisierung Ihres Gerätes am besten geeignet ist, hilft es, die Funktionalität des Gerätes zu verstehen. Die eigentliche Funktionalität des Geräts dürfte klar sein hier geht es um die Funktionalität, die den EIB betrifft und wie sich das Gerät zum EIB präsentiert. Dazu sind einige Grundkenntnisse über EIB sehr hilfreich. Am einfachsten ist es, wir betrachten den EIB aus der Sicht des Installateurs. Für die Inbetriebnahme der EIB-Anlage benützt der Installateur die EIB Tool Software (ETS). Mit Hilfe der ETS kann der Installateur die Anlage planen, die Geräte anlegen, Gruppen- Kommunikations-Objekte mit Gruppenadressen versehen und verbinden und auch die Geräteparameter verändern. Das Applikationsprogramm in der ETS spiegelt dabei wider, wie sich ein Gerät zum EIB darstellt. Als erstes haben wir die Gruppen-Kommunikations-Objekte auch Gruppenobjekte genannt. Diese Gruppenobjekte dienen beim EIB der Laufzeit- Kommunikation, d.h. über sie werden im normalen Betrieb Kommandos verschickt, bzw. Daten ausgetauscht. Dazu ordnet der Anwender den Gruppenobjekten sogenannte Gruppenadressen zu. Alle Gruppen- Dipl. Ing. (FH) Klaus Adler ist seit 1999 Geschäftsführer von Tapko Technologies GmbH zusammen mit Dipl. Ing. Petar Tomic. Vor dieser Zeit war er seit den ersten Anfängen des EIB in der EIB-Systementwicklung tätig, schwerpunktmäßig zuständig für die Entwicklung von PC-Tools und der Spezifikation neuer Systemgeräte und zuständig auch für Schulungenvon EIB-Entwicklern, abgehalten. www.tapko.de 80 BUS SYSTEME Berlin, 13. Jg./2006, Heft 2

Technik objekte mit der gleichen Adresse sind somit eine Gruppe, und wie Sie wissen, können das mehr als zwei sein. Umgekehrt kann ein Gruppenobjekt mehrere Gruppenadressen haben: Jedes Gruppenobjekt hat eine Adresse unter der es Daten absenden kann. Die Anzahl der Gruppenadressen unter der es Daten empfangen kann, ist abhängig davon, wie viel Speicherplatz der Applikationsentwickler vorgesehen hat. In einer Gruppe können mehrere Gruppen Objekte senden und auch empfangen. Welche Daten können übertragen werden? Gruppenobjekte können Daten von 1 Bit bis hin zu 14 Byte beinhalten. Die Reihe der Daten, die übertragen werden, reicht vom simplen ein/aus über Temperaturund Messwerte bis zu komplexen Datentypen. Welche Daten für eine konkrete Anwendung verwendet werden müssen, ist in den EIB Interworking Standards (EIS) festgelegt. Einfache Datentypen sind z.b. EIS 1 (DPT 1) zum ein/aus Schalten. Hierbei ist festgelegt, dass dieser Datentyp 1 Bit lang ist und 1 für ein steht und 0 für aus. Das ist soweit logisch, aber bereits bei einer Jalousie stellte sich bei der Definition die Frage was ist jetzt nach offen 0 oder 1?. (Bei EIB hat man sich für 0 entschieden.) Die gängigsten Datentypen bei EIB sind Schalten, Jalousie, Dimmen, Temperatur, Wert 0-100%. In den EIS sind aber noch eine Vielzahl weiterer Datentypen definiert. Wann werden die Daten übertragen? Nur dann, wenn sich der Wert wirklich ändert. Abweichend davon gibt es Ausnahmen bei Geräten, die einen Lifecheck erfordern, wird der Wert auch zyklisch gesendet, z.b. bei Windsensoren. Wie viele Gruppenobjekte kann nun Ihr Gerät enthalten? Die heutigen, von der ETS direkt unterstützten Gerätemodelle haben eine maximale Anzahl von ca. 250 Gruppenobjekten. Beenden wir den Ausflug zu den Gruppenobjekten und ihren Funktionen und wenden uns dem zweiten, nicht weniger wichtigen Teil zu, den der Installateur in der ETS sieht den Parametern. Wozu sind Parameter da, und was können Sie damit machen? Die Parameter bestimmen das Verhalten des Gerätes. Mit ihrer Hilfe kann der Anwender z.b. Verzögerungszeiten, das Verhalten auf Eingangsänderungen oder auch das komplette Verhalten der Applikation verändern. Über Parameter können auch andere Parameter und Gruppenobjekte ein- oder ausgeblendet werden. Hinter einem einzelnen Parameter kann sich dann eine ganz andere Funktionalität verstecken. Intern sind Parameter als Baum aufgebaut, wobei sich die Abhängigkeit eines Parameters von einem übergeordneten Parameter einstellen lässt. Während des Downloads werden die Parameter von der ETS in den nicht flüchtigen Speicher des Gerätes geladen und im Normalfall nicht weiter verändert. Die Informationen für die einzelnen Geräte kommen hierbei vom Hersteller des EIB-Gerätes. Er erstellt die einzelnen Datenbankeinträge für die Produkte und fasst diese zu seiner Produktdatenbank zusammen. Diese Produktdatenbank verteilt er an seine Kunden, die diese in die ETS importieren können. Zur Orientierung bezüglich der obenstehenden Fragen nach Parametern und Gruppenobjekten ist auch ein Blick auf bereits existierende Geräte hilfreich. Mit welchen Geräten soll Ihr neues Gerät zusammenarbeiten? Gibt es bereits ähnliche EIB-Geräte auf dem Markt? Soweit zu den Softwareaspekten. Leisten wir uns einen Blick auf die Hardware. Stromverbrauch und Versorgung des Gerätes Betrachten wir als erstes den Stromverbrauch. Der EIB bietet die Möglichkeit, Geräte aus den Busleitungen zu versorgen. Die maximale Leistung, die dem EIB entnommen werden kann, hängt von den angebotenen Lösungen ab. Der TPUART stellt bis zu 50mW zur Verfügung. Über den FZE1066 oder die TAPKO- TP1-Speiseschaltung können auch weitaus höhere Leistungen aus dem EIB entnommen werden. Dies hat logischerweise den Nachteil, dass nicht mehr so viele Geräte an eine EIB-Linie angeschlossen werden können. Hat das geplante Gerät einen höheren Stromhunger oder die Anforderung, dass es auch bei Ausfall des EIB weiterhin funktionieren muss, kommt eine externe Versorgung für Ihr Gerät zum Einsatz. Somit bin ich bei einem weiteren wichtigen Punkt angelangt. Welche Isolierung ist gegenüber dem EIB notwendig? Ist eine galvanische Trennung notwendig? Grundsätzlich gilt: Der EIB und auch die angeschlossenen Geräte müssen den SELV- Kriterien entsprechen. Das heißt, es muss gegen alle angeschlossenen Geräte oder Netzwerke die entsprechende Trennung eingehalten werden. Diese Trennung kann an unterschiedlichen Stellen erfolgen: Entweder zwischen dem EIB-Transceiver und dem Mikrocontroller oder auch zu den anderen Anschlüssen. Meistens erfolgt sie dort, wo es von den Kosten und dem Aufwand am günstigsten ist. Weitere Randbedingungen Um die optimale Realisierung für Ihr Gerät zu finden, gibt es noch ein Reihe von anderen Randbedingungen zu berücksichtigen. Welche Anforderungen stellt die Applikation an den benötigten Speicherbedarf oder an andere Prozessorressourcen wie Interrupts, serielle Schnittstellen, Timer, usw.? Hierzu gehört auch die Frage, wo das Gerät eingebaut werden soll und welche mechanischen Abmessungen sich daraus ergeben. Die geplante Stückzahl gibt zusätzliche Information, ob es sinnvoller ist, auf eine teurere Standardkomponente aufzusetzen, oder ob eine integrierte Lösung kostengünstiger ist. Wir haben jetzt die Anforderungen an das neue Gerät zusammengetragen. Im zweiten Teil befassen wir uns mit dem nächsten Schritt. Fortsetzung in Bussysteme 3/2006 BUS SYSTEME Berlin, 13. Jg./2006, Heft 2 81

Technik / Innovation Entwicklung von KNX-Geräten Von der Idee zum fertigen Produkt (Teil 2) Klaus Adler / Petar Tomic Tapko Technologies GmbH, Regensburg Wir hatten in Bus Systeme 2/2006 die Anforderungen an das neue Gerät zusammengetragen und können uns mit dem nächsten Schritt befassen. Realisierungsmöglichkeiten Wie können Sie das Gerät realisieren? Welche Möglichkeiten bieten sich Ihnen? Wenn Sie sich auf dem Markt umsehen, begegnen Ihnen eine Reihe von Begriffen wie BIM, BCU, TP- UART, chipset und Kommunikations-Stack. Diese Begriffe repräsentieren verschiedene Möglichkeiten, ein KNX-Gerät zu realisieren. Zunächst einmal gibt es die Möglichkeit, auf bestehende Software- und Hardwarekomponenten aufzusetzen. Aus der Historie betrachtet, war dies auch die erste Möglichkeit, ein KNX- Gerät zu bauen. Auf dem Markt gibt es hierzu als erstes die Busankoppler oder auch bus coupling units (BCU). Dies sind komplette Systemgeräte, die eine KNX-Ankopplungsschaltung und einen Mikrokontroller enthalten und komplett mit Gehäuse geliefert werden. Von dem Geräteentwickler muss dann noch die Applikationshardware und Software entwickelt werden. Durch die mechanische Ausführung und den dadurch resultierenden Preis hat die Bedeutung der BCUs im Laufe der Zeit immer mehr abgenommen. Zudem sind die Möglichkeiten auf Grund der kleinen Mikrokontroller und geringen I/O-Leitungen eingeschränkt. Dipl. Ing. (FH) Klaus Adler ist Geschäftsführer von Tapko Technologies GmbH, die er zusammen mit Dipl. Ing. Petar Tomic 1999 gegründet hat. Vor dieser Zeit war er seit den ersten Anfängen des EIB bei Siemens in der EIB-Systementwicklung tätig. Schwerpunktmäßig war er dort zuständig für die Entwicklung von PC-Tools und der Spezifikation von neuen Systemgeräten. Zudem hat er Schulungen, unter anderem für EIB-Entwickler, abgehalten. Kontakt: Tapko Technologies GmbH, Yorckstr. 22, D-93049 Regensburg, www.tapko.de Als nächstes wurden dann die Bus Interface Module (BIM) auf den Markt gebracht. Diese bestehen im wesentlichen aus dem Innenleben der BCUs, mit zusätzlichen I/O-Ports. Die BIMs werden als Module verkauft, die direkt auf die Leiterplatte eingelötet werden. Um die mechanischen Einschränkungen der BIM zu umgehen, wurden die Chipsets der BIMs auf dem Markt gebracht. Bezüglich der Software besteht kein Unterschied zwischen BIMs und Chipsets. Weiterhin gibt es noch den TP- UART. Er ist nicht direkt vergleichbar mit den BCUs oder auch BIMs. Der TPUART beinhaltet nur die eigentliche Ankopplung an den KNX. Die Kommunikationssoftware wird von einem an ihm angeschlossenen Mikrocontroller bereitgestellt. Der TPUART wurde entwickelt, um einerseits die Mikrokontroller 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. 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 Sie sich nicht im Detail in die KNX-Kommunikation einarbeiten müssen, bieten wir einen KNX-Kommunikations-Stack an. Dieser ist in ANSI-C geschrieben und somit auf verschiedenen Mikrokontrollern lauffähig (und selbstverständlich zertifiziert). Eine detaillierte Beschreibung können Sie von unserer Homepage herunterladen, oder direkt bei uns anfordern. Zusammenfassend versteht man unter dem Kommunikations-Stack die KNX-Systemsoftware. Die Ankopplung an den 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. Vor- und Nachteile Welche Lösung ist jetzt am besten für Ihr Gerät geeignet? Betrachten wir zunächst die Anzahl der Gruppenobjekte und die Komplexität der Anwendung: Bei den kleinen Varianten der BIMs, BCUs oder Chipsets (BCU1, BIM M111,...) ist diese sehr eingeschränkt. Hier müssen ca. 200 Byte für die Gruppenobjekte, die Parameter und die Applikation ausreichen. Bei der BCU2 bzw. BIM M113 steht hierfür schon etwas mehr Speicher zur Verfügung. Die Anzahl der Gruppenobjekte bei der BIM M112, bzw. bei unserem KNX Kommunikationsstack, liegt bei ca. 250. Die Beschränkung wird durch das von der ETS unterstützte Gerätemodell vorgegeben. Bei den Parametern ist die Begrenzung nur durch den verfügbaren Speicherplatz gegeben. Auch bei der möglichen Komplexität der Applikation hat die BIM M112 bzw. der Kommunikationsstack ganz klare Vorteile. Wenden wir uns jetzt der Spannungsversorgung der unterschiedlichen Realisierungsmöglichkeiten zu. Die BCUs und die BIM sind darauf ausgelegt, aus dem Bus versorgt zu werden. Eine eventuell notwendige galvanische Trennung kann nur nach dem Mikrokontroller realisiert werden. Wird bei diesen Bausteinen ein erhöhter Strom benötigt, so muss dies über eine zusätzliche Spannungsversorgung erfolgen. Bei Verwendung der Chipsets kann die galvanische Trennung auch zwischen KNX-Ankopplung und Mikrocontroller erfolgen. Auch in diesem Punkt ist die Verwendung eines KNX-Kommunikations-Stacks am flexibelsten. Eine galvanische Trennung kann wahlweise zur Anwendungsschaltung oder zum KNX hin erfolgen. Ein erhöhter Stromverbrauch aus dem KNX lässt sich über unsere TP1-Speiseschaltung realisieren. Werfen wir noch einen Blick auf die Möglichkeiten des Speichers und die verfügbaren Prozessorressourcen: Auch in diesem Punkt hat der KNX- 160 BUS SYSTEME Berlin, 13. Jg./2006, Heft 3

Kommunikations-Stack ganz klare Vorteile. Während bei den BCUs, BIMs und chipsets die KNX-Kommunikationssoftware fest im ROM verankert ist, kann der Kommunikations-Stack an die Anforderungen der Applikation angepasst werden. So können zum Beispiel bei unserem Kommunikation-Stack fast alle verfügbaren Interruptquellen für die Applikation verwendet werden. Inbetriebnahme der Geräte Wie wird ein KNX-Gerät vom Installateur in Betrieb genommen? In der Praxis gibt es hierzu verschiedene Ansätze: Betrachten wir zuerst die klassische KNX-Inbetriebnahme mit der ETS. Hier verwendet der Installateur die von der Konnex Association entwickelte KNX Tool Software (ETS). Die ETS ist so konzipiert, dass herstellerübergreifend die KNX-Geräte projektiert und in Betrieb genommen werden können. Die einzelnen Gerätehersteller liefern für ihre Geräte jeweils die Datenbankeinträge in einer Produktdatenbank. Diese Datenbankeinträge enthalten eine Beschreibung des Gerätes mit all Ihren Gruppenobjekten und Parametern. Die eigentliche Programmierung des Gerätes und die Buskommunikation bringt die ETS bereits mit. Anhand des Gerätetyps, des so genannten Gerätemodells, entscheidet die ETS, welche KNX-Features das Gerät hat und wie es zu bedienen ist. In der dritten Generation der ETS bietet sie weitere Flexibilität und Variationen durch die unterschiedlichen Pakete Starter / Tester und Professional. Zudem gibt es zusätzlich die Möglichkeit, ein Plug-In zu schreiben. Plug-Ins sind Erweiterungen der ETS, die die Handhabung / Konfiguration Ihres Gerätes erleichtern. Dies kann z.b. die Benutzeroberfläche oder auch die Kommunikation mit dem Bus, sowie erweiterte Diagnose-/ Einstellmöglichkeiten betreffen. Plug-Ins werden vom jeweiligen Gerätehersteller geschrieben und zusammen mit der Produktdatenbank ausgeliefert. Bei der ETS liegt das Wissen über das Gerät/Applikation in den ETS Datenbankeinträgen. Es gibt hier auch keine strikten Profile für die Anwendung. Aus den Geräten allein kann man diese Information normalerweise nicht auslesen. Diese Art der Inbetriebnahme bietet die größte Flexibilität, sowohl von den Möglichkeiten, die die Applikation bieten kann, als auch den Möglichkeiten, die der Anwender daraus zieht. Diese Art der Inbetriebnahme ist die klassische KNX-Inbetriebnahme und wird auch Systemmode oder S-mode genannt. Inzwischen hat sich auch eine weitere Art der Inbetriebnahme auf dem Markt durchgesetzt der Easymode oder auch E-mode. In der Konnex-Spezifikation sind verschiedene Easymodes definiert auf dem Markt sind bis dato nur zwei Varianten relevant logical tag extended (LTE) und der Controllermode. Beim Controllermode wird die Inbetriebnahme wie der Name schon sagt über einen Kontroller durchgeführt. Dieser Kontroller ist so konzipiert, dass er nicht die Details aller Geräte kennen muss. Er kennt aber funktionale Kanäle. Die Funktionen und Einstellmöglichkeiten der einzelnen Kanäle sind standardisiert. Das Gerät wiederum stellt die Information bereit, welche Kanäle es besitzt. Aus der Information der Kanaldefinition und der in der Installation vorhandenen Kanäle kann der Kontroller die Kanäle konfigurieren und die Gruppenobjekte verbinden. Der Anwender sieht hierbei nur noch die Kanäle und deren Einstellmöglichkeiten. Durch die Standardisierung der Kanäle ergibt sich logischerweise eine Einschränkung der Möglichkeiten, sowohl für den Gerätehersteller als auch für den Anwender. Der S- und der E-mode sind aber keine unabhängigen Lösungen. Was die Buskommunikation betrifft, verwenden beide die selben Mechanismen. Alle bekannten, auf dem Markt befindlichen E-mode-Geräte können auch mit der ETS konfiguriert werden. Soweit die Vorüberlegungen zum KNX allgemein sehen wir uns jetzt die eigentliche Entwicklung an. Leider sprengt es den Rahmen dieses Textes, detailliert auf die Entwicklung einzugehen, aber einige Anmerkungen seien erlaubt. Als erstes ein Blick auf die Hardware. Neben der eigentlichen Schaltungsentwicklung ist vor allem die Schutzklasse des KNX einzuhalten. Der KNX erfüllt SELV-Kriterien, das heißt, auch jedes KNX-Gerät muss diese Kriterien einhalten und die notwendige Trennung zu anderen Netzen sicherstellen. Zur Ankopplung an den KNX ist es am sinnvollsten, fertige Bausteine oder unsere fertigen Lösungen einzusetzen. Was die Software betrifft, geht es zunächst um die Software im Gerät. Diese besteht aus zwei Teilen der Kommunikationssoftware und der eigentlichen Anwendung. Die Kommunikationssoftware beinhaltet die Kommunikation zum KNX, die Mechanismen um das Gerät zu konfigurieren und die Schnittstelle zur eigentlichen Anwendung. Unser KNX-Konnex-Stack beinhaltet diesen Teil der Software. Applikationssoftware Die Anwendung bestimmt das eigentliche Verhalten des Gerätes. Sie bestimmt, ob das Gerät z. B. ein Taster oder ein Heizungsregler ist. Die Applikation wertet die Gruppenobjekte aus und führt darauf hin die entsprechende Aktion durch. Ebenso initiiert sie das Senden von Gruppentelegrammen. Indem Ihre Applikation die Interworkingstandards einhält, wird gewährleistet, dass sie mit Geräten von anderen Herstellern zusammenspielen kann. Ein weiterer Teil der Applikation ist der ETS Datenbankeintrag. Dieser wird mit Hilfe des Herstellertools der ETS erstellt. Diese Variante der ETS stellt alle Möglichkeiten zur Verfügung, um die Repräsentation der Anwendung in der ETS festzulegen. Dies sind die Gruppenobjekte, die Parameter mit ihren Einstellmöglichkeiten, die dazugehörigen Texte in den verschiedenen Sprachen. Zudem kann man in diesem Tool die Abhängigkeiten von Parametern und Gruppenobjekten definieren. Zertifizierung Jetzt haben Sie ein fertig entwickeltes Gerät wie geht es nun weiter? Wie kommt Ihr Gerät zu einen KNX- Logo? An die Verwendung des Logos werden bestimmte Anforderungen geknüpft. Diese Regeln werden in einem Zertifizierungsverfahren überprüft. Viele stellen sich unter der Zertifizierung ein sehr kompliziertes Verfahren vor, das eine Unmenge an Forderungen an das Gerät stellt. Das entspricht aber nicht unbedingt den Tatsachen. Hintergrund der Zertifizierung ist, das Interworking und die störungsfreie Funktion des Bussystems in der Praxis zu gewährleisten. Bevor ich auf die Anforderungen der Zertifizierung eingehe, möchte ich auf die Phasen der Zertifizierung eingehen. Die Zertifizierung bei KNX ist in zwei Teile aufgeteilt. Als erster Schritt gibt es die Registrierung. Bei der Registrierung melden Sie als KNX- Mitglied Ihr Gerät bei der Konnex Association an. Mit der Registrierung wird der ETS-Datenbankeintrag für die Endbenutzer freigeschaltet und Sie können mit dem Logo werben. BUS SYSTEME Berlin, 13. Jg./2006, Heft 3 161

Technik / Innovation Was brauchen Sie für die Registrierung? Ich möchte hier von dem Fall ausgehen, dass Sie bei der Entwicklung eine bereits zertifizierte Ankopplung, sowie einen zertifizierten KNX- Kommunikationsstack verwenden. Bezüglich der Hardware benötigen Sie dann nur eine Herstellererklärung wie die CE-Konformitätserklärung. Damit bestätigen Sie, dass das Produkt den geforderten Produktnormen und somit auch den EMV-Richtlinien entspricht. Bei der Software benötigt die Konnex Association eine Beschreibung des Gerätes, sowie die Deklaration der Gruppenobjekte und Parameter mit den jeweils verwendeten Datentypen sowie deren Verwendung und logischerweise den ETS- Datenbankeintrag. Nach erfolgter Registrierung bleibt Ihnen ein halbes Jahr Zeit, um den zweiten Schritt die eigentliche Zertifizierung abzuschließen. Die Zertifizierungsprüfung wird von einer akkreditierten Prüfstelle durchgeführt. Diese überprüft Ihr Gerät auf KNX-Konformität. Es wird dabei unter anderem überprüft, ob die Gruppenobjekte bezüglich der Datenformate und des Verhaltens entsprechend der Interworking-Standards implementiert wurden. Damit die Tests reproduzierbar sind, werden sie mit dem Testtool EITT durchgeführt. Daher ist es schon während der Entwicklung empfehlenswert, die Tests mit diesem Tool durchzuführen. Wenn Sie nun den positiven Testbericht in Händen halten, können Sie die Entwicklung als abgeschlossen betrachten. Wie sieht es aber aus, wenn während der Entwicklung Schwierigkeiten auftreten, oder Sie sich nicht mit der Entwicklung beschäftigen und die Entwicklung außer Haus geben möchten? Als dienstleistungsorientiertes Unternehmen bieten wir die TAP- KO Technologies GmbH- ein breites Spektrum an Möglichkeiten, speziell im Bereich KNX, um Sie zu unterstützen. Zum einen haben wir in unserem Portfolio eine Reihe fertiger Lösungen, die Sie bei der Entwicklung verwenden können, wie z.b. unseren KNX-Kommunikations- Stack oder auch TP1-Speiseschaltung. Diese vorgefertigten Lösungen entsprechen den aktuellen Anforderungen der Konnex-Spezifikation und sind somit zertifizierbar. Zudem bieten wir eine Palette von Dienstleistungen an. Diese reicht von der Unterstützung bei der Produktspezifikation, Entwicklung und Zertifizierung über die Durchführung von Teilen der Entwicklung bis hin zur Komplettentwicklung von KNX-Geräten. Es befinden sich bereits eine Reihe von Geräten auf dem Markt, die wir entwickelt haben, bzw. bei denen Teile von uns stammen. Auf unserer Webseite finden Sie einige unserer Referenzen. Aus Gründen der Vertraulichkeit ist dies nur ein kleiner Ausschnitt unseres Spektrums. Weitere Informationen finden Sie diese unter www.tapko.de. 162 BUS SYSTEME Berlin, 13. Jg./2006, Heft 3