Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe. Dokumentversion:

Mitglied der: KNX Association OPC Foundation BACnet Interest Group Europe Dokumentversion: 3.5.10

Inhaltsverzeichnis 1 Produktbeschreibung 5 1.1 Hauptmerkmale............................................. 6 1.2 Begriffsklärung............................................. 7 1.2.1 Projekt/Workspace....................................... 7 1.2.2 Datenpunkt........................................... 7 1.2.3 Server Item........................................... 7 1.2.4 Serverinformationsmodell/Informationsmodell......................... 7 1.2.5 Server Item Tree........................................ 7 1.2.6 BMS Client........................................... 7 1.2.7 VNET.............................................. 7 1.2.8 NETx BMS Client........................................ 8 1.3 System Überblick............................................ 9 1.3.1 Systemarchitektur....................................... 9 2 Schnelleinstieg 11 2.1 Installation................................................ 11 2.2 Erste Schritte.............................................. 11 3 NETx KNX OPC Server Studio 12 3.1 Menü.................................................. 12 3.1.1 Workspace........................................... 12 3.1.2 Edit............................................... 13 3.1.3 Server.............................................. 14 3.1.4 File............................................... 18 3.1.5 Tools.............................................. 20 3.1.6 Windows............................................ 20 3.1.7 Info............................................... 21 3.2 Toolbar................................................. 21 3.3 Windows................................................ 23 3.3.1 System Messages....................................... 23 3.3.2 Telegram Monitor........................................ 23 3.3.3 Cell Monitor........................................... 24 3.3.4 Gateway Monitor........................................ 24 3.3.5 Gateway Info.......................................... 25 3.3.6 Telegram Definition Table................................... 25 3.3.7 Gateway Definition Table.................................... 26 3.3.8 System log file......................................... 27 3.3.9 Link Manager.......................................... 27 3.3.10 Event Processor........................................ 29 3.3.11 Info Desk............................................ 36 4 NETx KNX OPC Server 37 4.1 Arbeitsweise Dienst / Server...................................... 37 4.2 Konfiguration.............................................. 37 4.2.1 Verzeichnisse.......................................... 37 4.3 Router configuration: nxaopcrouter.35.cfg.............................. 37 2

4.4 System configuration: nxaopcsystem.35.cfg............................. 39 4.5 Telegram definitions: nxatelegramdefinitions.35.dat......................... 46 4.6 Gateway definitions: nxagatewaydefinitions.35.dat.......................... 47 4.7 Device definitions: nxadevicedefinitions.35.dat............................ 48 4.8 N-Mesh Subsystem Config File: nxanmesh.35.cfg.......................... 49 4.9 N-Mesh Routing definitions: nxanmeshroutingdefinitions.35.dat................... 50 4.10 [Live] Task definitions: nxataskdefinitions.35.dat........................... 51 4.11 LUA script file: nxadefinitions.lua.................................... 52 4.11.1 Die nxa Library Funktionen................................... 52 4.11.2 NXA Library Funktionen für Task Definitonen......................... 53 4.11.3 NXA Library Funktionen um Custom Items zu erstellen.................... 55 4.11.4 Global Event functions..................................... 56 4.12 System - Protokolldatei: nxaopcsystem.35.log............................ 57 4.13 Datenaufzeichnung: nxaopcdata.35.log............................... 57 4.14 Telegramm-Protokolldatei: nxaopctelegram.35.log.......................... 57 5 OPC Item Eigenschaften 58 6 Aufbau der OPC Strukturen 59 7 Anbindung von OPC Clients 60 8 Unterstützte Datentypen 61 9 NETx KNX OPC Server Direct(KNX) Version 64 10 Das Konvertierungstool: NETxKNXConvertETS 65 A Anhang 67 A.1 Acronyme................................................ 67 A.2 Lizenzierung.............................................. 68 A.2.1 Hardlock............................................ 68 A.2.2 Softlock............................................. 68 A.2.2.1 Softwarelizenzierung................................ 68 A.2.2.2 Entfernen und Übertragen einer Softwarelizenz.................. 69 A.3 Support und Kontakt.......................................... 71 A.4 Systemanforderungen......................................... 71 A.4.1 Hardware............................................ 71 A.4.2 Unterstützte Betriebssysteme................................. 71 A.4.3 Andere............................................. 71 A.5 Upgrade von NETx KNX OPC Server 3.0 nach NETx KNX OPC Server 3.5............. 72 A.5.1 Wichtige Information...................................... 72 A.5.2 Durchführung des Upgrades.................................. 72 NETx KNX OPC Server 3.5.10 Seite 3 von 74

Copyright Diese Veröffentlichung bezieht sich auf NETx KNX OPC Server 3.5. Dies wird herausgegeben von NETxAutomation Software GmbH, Maria Theresia Straße 41, Top 10, 4600 Wels, Österreich. Copyright by NETxAutomation Software GmbH, 2013. Gewährleistung für die Richtigkeit, Anwendbarkeit und Brauchbarkeit dieser Dokumentation kann nur im Rahmen der Bestimmungen des Software Überlassungsvertrages übernommen werden. Änderungen am Funktionsumfang der beschriebenen Software sind jederzeit vorbehalten und müssen keine Änderungen der diesbezüglichen Dokumentation nach sich ziehen. Alle Rechte vorbehalten. Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Einspeicherung und Verarbeitung in elektronischen Systemen sind urheberrechtlich geschützt. Nachdruck nur mit schriftlicher Genehmigung von NETxAutomation Software GmbH. NETx KNX OPC Server 3.5.10 Seite 4 von 74

1. Produktbeschreibung NETx KNX OPC Server 3.5 Das System ermöglicht in Verbindung mit einem geeigneten OPC Client, die Steuerung und die Visualisierung von KNX-Anlagen. Es stellt eine Brücke zwischen der KNX-Welt und anderen Systemen dar, die über die OPC- Schnittstelle einen direkten Einfluss auf das Geschehen in dieser Welt nehmen können. Die Erfahrung, das Know-How, das bei großen Projekten gewonnen wurde, konnte bei der Entwicklung einer ganzen Reihe von neuen Systemen optimal eingesetzt werden. So ist auch dieses System als ein zuverlässiges, offenes und benutzerfreundliches konzipiert und realisiert worden. NETx KNX OPC Server 3.5.10 Seite 5 von 74

1.1. Hauptmerkmale Bis zu 1000 Gateways können verwaltet werden UnifiedDriver unterschiedliche Gateway Typen können gemeinsam verwendet werden. ABB IG/S 1.1, KNX NetIP Gateways oder eibnode können zusammen in einem Arbeitsbereich verwendet werden, unterstützt ebenso Windows Server Betriebssysteme. mehrere OPC Clients können parallel angeschlossen werden Alle offiziellen EIS-Datentypen werden unterstützt 100.000 und mehr Telegrammdefinitionen Enormer Datentransfer VNET Schnittstelle für OPC Tunneling zwischen NETx Voyager OPC und NETx KNX OPC Server 3.5 Redundanz mit Main- and Backup Server Konfiguration Clustering von NETx KNX OPC Server mit N-Mesh Konfiguration KNX Geräte Erreichbarkeit Überprüfung (nur in UnifiedDriver Version) MultiProject Kern Workspace Management - mehrere Arbeitsbereiche können bequem verwaltet werden LUA Skript Sprachen Engine um eigene Logik mit dem Skript Editor zu programmieren Event Processor zyklische, zeitbezogene und ereignisbezogene Aktionen können im OPC Server definiert werden Link Manager - das Verwalten von verlinkten Gruppenadressen kann jetzt direkt im OPC Server realisiert werden Task Definition Tabelle um OPC Items zu verlinken und LUA Skripts in Live Modus ausführen KNX Telegram Overflow Manager ein erweiterter Schutz vor Überlastung des KNX Real Database Refresh - die Updates der OPC Server Datenbank erfolgen automatisch Direkte Wertabfragen von KNX-Geräten für Initialisierung des virtuellen Models der Anlage NETx KNX OPC Server Studio 3.5 Erweiterter Adressraum die reale Adresse des Datenpunktes besteht aus der logischen KNX-Adresse und der IP-Adresse Virtuelle OPC Items für erweiterten Adressraum 16/0/0 bis 32/0/0 Custom Items die mit LUA Skript erstellt werden für Projekt Strukturen z.b.: Hotel/Gebäude/Stockwerk/Zimmer Datenaufzeichnung im Ringspeicher eine große Anzahl an gesendeten/empfangenen Telegrammen kann gespeichert werden. Prozesszustand des gesamten Systems kann ebenfalls gespeichert und automatisch beim Starten wieder geladen werden. Online-Überprüfung des Zustandes aller angeschlossenen Gateways Echtzeit-Anzeige des Telegrammverkehrs mit Klartext-Beschreibung und erweiterten Informationen Geo Data Interface für Sonnenposition, Zeitpunkt Sonnenaufgang, Zeitpunkt Sonnenuntergang, Alter des Mondes Verschiedene Erweiterungsmodule verfügbar wie z.b.: SQL Schnittstelle für Microsoft SQL Datenbanken, Micros Fidelio Hotel Management System Schnittstelle... NETx KNX OPC Server 3.5.10 Seite 6 von 74

1.2. Begriffsklärung 1.2.1. Projekt/Workspace Ein NETx KNX OPC Server Projekt enthält sämtliche Informationen, welche für das Sammeln der Daten und Informationen vom Gebäudeautomationssystems notwendig sind. Dies inkludiert auf der einen Seite die Konfiguration, welche benötigt wird, um die Daten von den Feldbussystemen zu erhalten, und auf der anderen Seite Laufzeitinformationen wie Loggingdaten. Die Summe aller Konfigurations- und Laufzeitdateien sowie die Verzeichnisse, welche diese Dateien inkludierten und welche einen bestimmen Projekt zugeordnet sind werden Workspace genannt. Die Workspaces befinden sich im folgenden Verzeichnis: <Install Directory>\NETxAutomation\NETx.Voyager.Server.2.0.UD\Workspaces Zum Beispiel in Windows 7 64 Bit ist der Standardpfad: C:\Program Files (x86)\netxautomation\netx.voyager.server.2.0.ud\workspaces! Es wird empfohlen, die Workspaces regelmäßig zu sichern. Um dies zu tun muss der gesamte Inhalt des oben genannten Workspace-Verzeichnisses auf das Backup-Medium kopiert werden. 1.2.2. Datenpunkt Ein Datenpunkt ist ein einzelnes Datenelement in der Feldebene des Gebäudeautomationssystems. Dies können Sensorwerte (z.b. Status eines Lichtschalter, Temperaturwert), Aktuatorwerte (z.b. Sollwert einer Jalousie, Stellwert eines Heizungssystems) aber auch so genannte virtuelle Datenpunkte, welche nur im Server existieren (z.b. ein Sollwert für eine Raumtemperatur, das momentane Datum, die momentane Sonnenposition) sein. 1.2.3. Server Item Ein Server Item repräsentiert einen Datenpunkt im NETx KNX OPC Server. Ein Server Item enthält mehrere Properties, welche den Datenpunkt beschreiben. Wichtige Beispiele sind der Wert des Datenpunkts, die Qualität sowie die Einheit. Zusätzlich können noch weitere Meta-Daten inkludiert sein (z.b. Bereich des Datenpunkts, Alarmstatus). 1.2.4. Serverinformationsmodell/Informationsmodell Das Serverinformationsmodell ist die interne Sichtweise der Daten und Informationen des Gebäudeautomationssystems. Das Serverinformationsmodell ist hierarchisch organisiert und besteht aus allen Server Items sowie zusätzlicher Information (z.b. Typeninformation). 1.2.5. Server Item Tree Die Repräsentation des Serverinformationsmodell wird Server Item Tree genannt. 1.2.6. BMS Client Ein BMS Client bezieht sich auf eine Client-Applikation, welche für den Zugriff auf die Server Items mit dem NETx KNX OPC Server verbunden ist. Ein BMS Client kann ein NETx Voyager Client, ein NETx BMS Client oder ein anderer OPC Client eines Dritt-Herstellers sein. 1.2.7. VNET VNET ist ein proprietäres Protokoll, welche von Management-Clients als Alternative zu OPC benützt werden kann. VNET ist für alle NETx Management Clients verfügbar. NETx KNX OPC Server 3.5.10 Seite 7 von 74

1.2.8. NETx BMS Client Ein NETx BMS Client ist ein Client, der für den Zugriff auf die im NETx KNX OPC Server entweder eine HyperText Transfer Protocol (HTTP) Verbindung (für web-basierte Clients) oder eine VNET Verbindung (z.b. für WinCE Clients) verwendet. NETx KNX OPC Server 3.5.10 Seite 8 von 74

1.3. System Überblick KNX-Telegramme werden von Gateways in LAN-Telegramme konvertiert, die dann über LAN an den NETxKNX Server weitergeleitet werden. (Abbildung 1.1, Abbildung 1.2) Der Server empfängt, analysiert, führt Fehlerüberprüfungen durch, protokolliert und sendet über die OPC-Schnittstelle die Daten an alle angeschlossenen OPC Clients. Alle Ereignisse werden in den LOG-Dateien protokolliert, die für Systemanalyse und Fehlersuche verwendet werden können. Jeder Ausfall eines Gateways wird sofort entdeckt, angezeigt und ebenfalls protokolliert. Ein virtuelles Modell der gesamten KNX-Anlage wird vom Server verwaltet, jede Telegrammdefinition wird dort als Cell, eine Zelle abgebildet. In dieser Zelle wird nicht nur der aktuelle Wert des Datenpunktes, sonder auch eine Reihe von Zusatzinformationen (wie z.b. Zeitpunkt der letzten Zustandsänderung) mitgespeichert. Der aktuelle Wert jeder Zelle kann im Studio, im Cell Monitor überprüft werden. Der Event Prozessor ist eine Erweiterung des NETxKNX Server Kernes, und ermöglicht die Realisierung von komplexeren, ereignisabhängigen Aufgaben. KNX Linie LAN NETXKNXOSERVERO SchalterO KNXOlog.OAdresse:O 1/1OO u KNX IP Gateway 1/1#1 1/2#1 EVENTO PROCESSORO O DeckenleuchteO KNXOlog.OAdresse:O 1/2OO KNXuIPuGatewayu HieruwerdenuKNX- TelegrammeuinuLAN- Telegrammeukonvertiertu unduumgekehrtuu Schnittstellenu Abbildung 1.1.: Datenfluss in NETxKNX MP Open OPC System, Version 3.5 1.3.1. Systemarchitektur Das System besteht aus zwei wesentlichen Teilen: dem Server und dem Studio. Der Server ist ein autonomes Programm, das die gesamten Abläufe durchführt und kontrolliert. Das Studio stellt eine Schnittstelle zwischen dem Server und dem Administrator dar, die nur für die Dauer der Zustandsanalyse gestartet wird. Diese Umgebung verfügt über mehrere nützliche Tools, die dem Administrator das Verwalten, Analysieren und die Fehlersuche im gesamten KNX-Projekt ermöglichen. NETx KNX OPC Server 3.5.10 Seite 9 von 74

Abbildung 1.2.: Physikalischer Aufbau des Systems. NETx KNX OPC Server 3.5.10 Seite 10 von 74

2. Schnelleinstieg 2.1. Installation Legen Sie die CD in das optische Laufwerk. Die Installation der Software startet entweder automatisch mittels Autorun oder sie muss manuell gestartet werden. Das Setup führt den Benutzer durch die Installation. Während der Setup-Routine können diverse Einstellungen (wie z.b. der Installationspfad) geändert oder die Standardwerte benützt werden. Im Verzeichnis (entweder das durch den Benutzer spezifizierte oder das Standardverzeichnis) wird ein Unterverzeichnis Workspaces erzeugt. Letzteres wird bei der Deinstallation nicht gelöscht. Diese hat beim Speichern der Workspaces eine spezielle Rolle und enthält außerdem den Default-Workspace, von diesen alle neuen Workspaces abgeleitet sind.! Beachten Sie dass unter Microsoft Windows Server Systemen die Installation des Microsoft.NET Framework 3.5 eventuell manuell erfolgen muss, indem das entsprechende Server Feature ausgewählt werden muss.!achtung: Sämtliche Antivirus und Antimalware Software muss eventuell deaktiviert werden. Der Benutzer welcher die Software installiert muss die entsprechenden Rechte besitzen. Stellen Sie sicher dass die notwendigen Ausnahmen in Ihrer Security Software entsprechend gesetzt sind, damit die NETx KNX OPC Server normal laufen kann. Mit dem Setup für den NETx KNX OPC Server werden verschiedene Komponenten am Systeme installiert und registriert der NETx KNX OPC Server selbst als Dienst oder Serverkomponenten, um den Clients the notwendigen Informationen bereitzustellen, der NETx BMS Client Editor als ausführbares Programm, NETx KNX OPC Server Studio 3.5 ebenfalls als ausführbares Programm und verschiedene Treiber für die Unterstützung zu KNX und VNet als Kommunikationsschnittstelle. Microsoft SQL Server Express wird zusätzlich für das Speichern von historischen Daten installiert. 2.2. Erste Schritte Starten Sie das NETx KNX OPC Server Studio 3.5. Ein Symbol zum Starten befindet sich am Desktop. Alternativ kann das Programm über das Startmenü geöffnet werden. Wenn die Software das erste Mal gestartet wird und kein gültiger Hard-Lock Dongle (USB stick) mit dem Computer verbunden ist, erscheint eine Warnung. Diese Warnung weißt darauf hin, dass es sich um eine unlizenzierte Kopie der Software handelt und das die Software im Demo Modus ausgeführt wird. Um die Software zu lizenzieren kann entweder ein gültiger Hardware Dongle verwendet werden oder der Lizenzmanager kann gestartet werden. Für diese ersten Schritte ist der Demo Modus ausreichend. Näherer Informationen bez. der Lizenzierung der Software sind im Abschnitt A.2 zu finden. Wird nun die Software das erste Mal gestartet, wird der Workspace Default oder MyFirstWorkspace gestartet. Wird danach das Programm geschlossen, wird der letzte, aktive Workspace beim nächsten Start wieder geöffnet.! Es wird nicht empfohlen im Default Workspace zu arbeiten, da diese als Vorlage für alle zukünftigen Workspaces fungiert. Sämtliche Einstellungen, die im Default Workspace durchgeführt werden, werden an neue Workspaces weiter vererbt. Um einen neuen Workspace zu erzeugen, muss der Menüeintrag New Workspace im Menü Workspace ausgewählt werden. Die Applikation fordert nun den Benutzer auf, einen neuen Workspace-Namen zu vergeben. Da der Workspace-Name auch als Name für das Verzeichnis verwendet wird, sind Sonderzeichen wie Anführungszeichen, Slash, Backslash oder ähnliches nicht erlaubt. Sollte der Server noch laufen, wird dieser nun beendet und der neu erzeugte Workspace wird gestartet. Dieser enthält ein kleines Demo-Projekt, welches im Default Workspace enthalten ist. Als nächstes müssen die Konfigurationsdaten der Geräte und Datenpunkte, welche in der Feldebene des Gebäudeautomationssystems verwendet werden, importiert werden. NETx KNX OPC Server 3.5.10 Seite 11 von 74

3. NETx KNX OPC Server Studio Das NETxKNX OPC Studio ist in mehrere Bereiche aufgeteilt (Abbildung 3.1). Durch den Fenster-Manager ist es dem Benutzer überlassen, wie er die Umgebung seinen Bedürfnissen anpasst. Abbildung 3.1.: OPC Studio Fenster 3.1. Menü 3.1.1. Workspace New Workspace Erstellt einen neuen Arbeitsbereich. Dabei wird der Inhalt des Workspaces\Default Verzeichnisses in das neu erstellte Verzeichnis kopiert. Das neue Verzeichnis wird mit dem Namen des neuen Arbeitsbereiches benannt (Abbildung 3.2). Abbildung 3.2.: Neuen Arbeitsbereich erstellen Open Workspace Öffnet einen bestehenden Arbeitsbereich. In dem Open Workspace Dialog werden alle Unterverzeichnisse des Workspaces-Verzeichnisses aufgelistet (Abbildung 3.3). Wird eine neue Workspace geöffnet, wird der Server gestoppt und mit der neuen Konfiguration wieder gestartet. Save Workspace As Speichert den aktuellen Arbeitsbereich unter neuem Namen. Dabei werden alle relevanten Dateien des Quellverzeichnisses in das neue Verzeichnis kopiert. (Abbildung 3.4) Delete Workspace (Abbildung 3.5) Löscht unwiderruflich den Arbeitsbereich mit dem gesamten Inhalt und sein Verzeichnis. NETx KNX OPC Server 3.5.10 Seite 12 von 74

Abbildung 3.3.: Bestehenden Arbeitsbereich öffnen Abbildung 3.4.: Neuen Namen für den Arbeitsbereich angeben. Abbildung 3.5.: Bestehenden Arbeitsbereich löschen Exit Beendet das Studio, der Server wird dabei nicht heruntergefahren. 3.1.2. Edit Cut Ist während dem Editieren der Konfigurationstabellen aktiv und schneidet markierten Text aus. Copy Ist während dem Editieren der Konfigurationstabellen aktiv und kopiert markierten Text in die Zwischenabla- NETx KNX OPC Server 3.5.10 Seite 13 von 74

ge. Paste Ist während dem Editieren der Konfigurationstabellen aktiv und fügt den Text aus der Zwischenablage in die Editierzeile. Search Dies sucht einen Text in der Definitionstabelle (es wird aktiviert, wenn die Tabelle im aktuellen Fenster aktiviert wird). Search and Replace Dies sucht und ersetzt einen Text in der Definitionstabelle (es wird aktiviert, wenn die Tabelle im aktuellen Fenster aktiviert wird). Select all Ist während dem Editieren der Konfigurationstabellen aktiv und selektiert den gesamten Text. 3.1.3. Server Import ETS(c) Project Startet das Importierungstool, mit dem die exportierten ETS OPC Dateien (*.esf) in Telegramm- und Linkdefinitionsdateien konvertiert werden können. Genauere Informationen finden Sie in chapter 10. Nach jeder Änderung in Telegrammdefinitionsdatei muss der OPC Server neu gestartet werden. Ein entsprechender Hinweis wird angezeigt (Abbildung 3.6). Abbildung 3.6.: Der OPC Server erfordert einen Neustart. SystemConfiguration Hier können spezielle Server Parameter verändert werden (Abbildung 3.7). Die Optionen sind beschrieben und auswählbar. Diese Parameter sind auch in der System Konfigurationsdatei beschrieben. Router Configuration Hier können spezielle Router Parameter verändert werden (Abbildung 3.8). Die Optionen sind beschrieben und auswählbar. Diese Parameter sind auch in der Router Konfigurationsdatei beschrieben. N-Mesh Configuration Hier können spezielle N-Mesh Parameter verändert werden (Abbildung 3.9). Die Optionen sind beschrieben und auswählbar. Diese Parameter sind auch in der N-Mesh Konfigurationsdatei beschrieben. Für die Verwendung von N-Mesh-Routing-Tabellen ist es nicht notwendig ebenfalls die N-Mesh Node IP Adresse zu konfigurieren. Wenn N-Mesh Node IP Adressen konfiguriert sind, werden alle Änderungen zu den N-Mesh Nodes gesendet und zusätzlich zur N-Mesh Routing Tabelle. So kann man das abstellen. Main / Backup Server Configuration Für den Main / Backup Server Betrieb, können Use Redundancy, Enable Synchronization, die Main Server IP address des Haupt Servers, die Backup Server IP address des Backup Servers und zum Schluss die IP Adresse der Netzwerkkarte die die Server verwenden um miteinander zu kommunizieren, konfiguriert werden. Bei der letzten Information, weiß der Server ob er als Haupt oder Backup Server konfiguriert wurde. Die Network Port Number kann geändert werden und die Firewall muss diesen Port öffnen. Zuerst wird der Main Server konfiguriert, danach wird der Workspace zum Backup Server kopiert und die Network card IP address NETx KNX OPC Server 3.5.10 Seite 14 von 74

Abbildung 3.7.: Parameter des OPC Servers. Abbildung 3.8.: Parameter des KNX Routers. geändert. Das war alles. In der Status Zeile des OPC Servers kann man auch den Betriebsmodus einsehen. Entweder zeigt er Main oder Backup Server als active oder im standby Modus. Wenn der Haupt Server stoppt, wird der Backup Server alle KNX IP Gateways übernehmen. Er hat denselben NETx KNX OPC Server 3.5.10 Seite 15 von 74

Abbildung 3.9.: N-Mesh Parameter. Status wie der Haupt Server, weil er bei allen Änderungen in der Vergangenheit mitgelauscht hat. Wenn der Haupt Server wieder startet, überlässt ihm der Backup Server die KNX IP Gateways und der Haupt Server übernimmt sie wieder. Ebenso wenn die Verbindung zwischen Haupt und Backup Server verloren geht, versucht der Backup Server nach dem Connection Timeout die KNX IP Gateways zu übernehmen. In Verbindung mit dem Voyager 4.1 OPC wird der Main Server den Voyager trennen bevor er gestoppt wird, damit der Voyager sich automatisch mit dem Backup Server verbindet und umgekehrt. Für den Main / Backup Betrieb wurde, die Voyager 4.1 OPC Visualisierung optimiert um das perfekte Frontend für höchste Systemanforderungen zu sein. System Settings zeigt das Konfigurationsfenster an (Abbildung 3.10). Hier können die Systemparameter verändert werden, die im laufenden Betrieb das Verhalten des Systems beeinflussen. Alle anderen Parameter können nur direkt in den Konfigurationsdateien (Dateien nxaopcrouter.35.cfg und nxaopcsystem.35.cfg) verändert werden. Send Interval definiert die Zeitabstände in welchen die Telegramme an ein bestimmtes Gateway verschickt werden. Da das KNX ca. 17 Telegramme pro Sekunde übertragen kann, trägt das Datenmanagement Modul des Servers die Sorge, dass die Telegramme in vordefinierten Zeitabständen an ein Gateway versendet werden. Sollten z.b. 2000 Telegramme an das Gateway 192.168.1.1 versendet werden, wird das 2000 200 ms = 6, 6 Minuten dauern bis alle versendet worden sind. Group Address Type Definiert wie die KNX Gruppenadressen im Studio in der logical group address Eigenschaft eines OPC Items (2- oder 3-stufig). Dieser Parameter hat keinen Einfluss auf die OPC ItemID. Start Server Startet den OPC Server (wird aktiviert wenn der Server nicht hochgefahren ist, oder das Studio die Verbindung zum Server verloren hat). Shutdown Server Der Server wird heruntergefahren. Sind zur Zeit OPC Clients mit dem Server verbunden, muss der Anwender die Aktion bestätigen (Abbildung 3.11). NETx KNX OPC Server 3.5.10 Seite 16 von 74

Abbildung 3.10.: System settings. Abbildung 3.11.: Hier wird informiert, dass noch ein OPC Client angeschlossen ist, und abgefragt, ob der Server wirklich gestoppt werden soll.!achtung: Obwohl das System über die OPC Shutdown Schnittstelle verfügt, und die Information über das Herunterfahren vom Server an die Clients verschickt wird, berücksichtigen einige Clients dies nicht und melden einen Verbindungsfehler. benso versuchen manche Clients sich automatisch wieder zum OPC Server zu verbinden und möchten den Server neu starten. So ist das ein guter Weg dieses Verhalten der Client schon im Vorhinein zu stoppen. Restart Server Initialisiert das System neu und ladet die aktuellen Definitionstabellen und Konfigurationsdateien. In diesem Fall wird der Server niedergefahren, und die Verbindung zu den OPC Clients wird unterbrochen. Sind zur Zeit OPC Clients mit dem Server verbunden, muss der Anwender die Aktion bestätigen (Abbildung 3.11). Reload N-Mesh Routing Mit diesem Befehl wird die N-Mesh Routing Datei manuell nachgeladen. Set Filter Diese Funktion vereinfacht die Analyse des Datenverkehrs (Abbildung 3.12). Mit diesem Filter kann festgelegt werden, welche Telegramme in der Telegrammliste gezeigt werden sollen. Der Filter besteht aus drei Teilen. Der erste Teil definiert den Bereich der log. KNX-Adressen, die gezeigt werden sollen. Im zweiten Teil kann noch die IP-Adresse definiert werden, so werden nur die Telegramme aufgelistet, die von oder zu diesem Gateway empfangen/geschickt werden, das diese Adresse besitzt. Der letzte Teil legt den Typ der Telegramme fest, die gezeigt werden sollen. Die Filter-Teile können beliebig kombiniert werden. Set Cell Value Dieses Tool ermöglicht das direkte Setzten eines Zellenwertes (Abbildung 3.13). Dieser Wert wird in dem virtuellen Modell der Anlage im Serverspeicher verändert, und an die OPC Clients weitergegeben. Es wird aber kein Telegramm zum KNX verschickt. Somit können bestimmte Datenpunkte mit Werten initialisiert werden. Die Voraussetzung ist, dass die angegebenen Parameter gültig sind, sonst wird eine Fehlermeldung ausgegeben und die Durchführung unterbrochen. Send Telegram Verwenden Sie diese Funktion um ein Telegramm auf den KNX-Bus zu senden (Abbildung 3.14). Bei WRITE und RESPONSE Telegrammen wird der Wert der Zelle entsprechend verändert. Sind alle Eingaben NETx KNX OPC Server 3.5.10 Seite 17 von 74

Abbildung 3.12.: Filter im Telegramm-Monitor. Abbildung 3.13.: Wert einer Zelle setzen. korrekt, die Netzwerkverbindung jedoch unterbrochen, so wird das Telegramm verworfen. Der Typ des Telegramms definiert die Funktion: Telegramm Typen: WRITE: Wert auf eine Gruppenadresse schreiben READ: Wert einer Gruppenadresse anfordern RESPONSE: Antwort auf ein READ Telegramm, die den aktuellen Wert enthält Advanced Configuration Extended Logging ON/OFF Schaltet die erweiterte Protokollierung ein bzw. aus. Set Logging Level Default: 0; anderen Wert nur auf Anweisung von NETx Support einstellen. 3.1.4. File System Log File (Open, Close) Zugriff auf die System-LOG-Datei des aktuellen Arbeitsbereiches; der gesamte Inhalt wird in einer Tabelle angezeigt. Bei größeren Dateien kann dieser Vorgang länger dauern. Gateway Definitions (Open, Save, Close) Hier müssen alle KNX NETIP Gateways definiert werden. NETx KNX OPC Server 3.5.10 Seite 18 von 74

Abbildung 3.14.: Telegramm an den KNX-Bus senden. Nach dem Speichern von Änderungen ist ein Neustart des NETx Server erforderlich um die Änderungen zu übernehmen. Telegram Definitions (Open, Save, Close) Diese Tabelle wurde automatisch beim Import der.esf Datei erstellt. Sie definiert welche KNX Telegramme aufgelistet werden sollen und wie der Wert in dem Item gehalten wird und wo sich die logischen KNX Gruppenadressen befinden. Es ist ebenfalls möglich kleinere Änderungen der Definitionen in der Tabelle zu editieren. Für größere Änderungen gibt es die Möglichkeit die Telegramm Definitionen nach Excel zu exportieren und nach den Änderungen wieder zu importieren. Nach dem Speichern von Änderungen ist ein Neustart des NETx Server erforderlich um die Änderungen zu übernehmen. Device Definitions (Open, Save, Close) Der eingebaute Device Manager (nur in UnifiedDriver!) überprüft die definierten KNX Geräte zyklisch und wenn sie verbunden werden können zeigt er ihren Status on oder off. Nach dem Speichern von Änderungen ist ein Neustart des NETx Server erforderlich um die Änderungen zu übernehmen. [Live] Task Definitions (Open, Save, Close) Task Definitionen werden verwendet um eine Verbindung (Link) zwischen den Items und der Möglichkeit zum Ausführen von LUA Skripts, wenn das Quellitem gesetzt wurde, empfangen oder gesendet hat. Der Wert des Quellitems wird weitergeleitet zum Zielitem. Dieses Verhalten kann auch verzögert werden. Nach dem Speichern werden Änderungen sofort übernommen. [Live] N-Mesh Routing Definitions (Open, Save, Close) Wenn in der N-Mesh Konfiguration Enable Routing aktiviert ist, werden diese Definitionen ausgeführt. Mit ihnen ist es möglich Telegramme von einem zu einem anderen OPC Server zu routen. Nach dem Speichern werden Änderungen sofort übernommen. [Live] KNX Link Definitions (Open, Save, Close) Diese Tabelle verbindet logische Gruppenadressen untereinander, wie im KNX Feld. Wenn z.b.: mehr als eine Gruppenadresse verwendet wird um denselben Eingang zu steuern (Master Control). Nach dem Speichern werden Änderungen sofort übernommen. [Live] KNX Response Event Definitions (Open, Save, Close) In dieser Tabelle kann man Events definieren, die auf empfangenen KNX Telegrammen basieren und neue KNX Telegramme erstellen. Nach dem Speichern werden Änderungen sofort übernommen. NETx KNX OPC Server 3.5.10 Seite 19 von 74

[Live] KNX Timer Event Definitions (Open, Save, Close) Hier können Timer Events definiert werden um neue KNX Telegramme zu erzeugen. Nach dem Speichern werden Änderungen sofort übernommen. [Live] KNX Cyclic Event Definitions (Open, Save, Close) Hier können zyklische Events definiert werden, um neue KNX Telegramme zu erzeugen. Nach dem Speichern werden Änderungen sofort übernommen. Advanced Configuration System Configuration File (Open, Save, Close) Zugriff auf die Systemkonfigurationsdatei. Nach dem Speichern von Änderungen ist ein manueller Neustart des NETx Server erforderlich um die Änderungen zu übernehmen. Router Configuration File (Open, Save, Close) Zugriff auf die Router-Konfigurationsdatei. Nach dem Speichern von Änderungen ist ein manueller Neustart des NETx Server erforderlich um die Änderungen zu übernehmen. N-Mesh Configuration File (Open, Save, Close) Zugriff auf die N-Mesh Router-Konfigurationsdatei. Nach dem Speichern von Änderungen ist ein manueller Neustart des NETx Server erforderlich um die Änderungen zu übernehmen. Print Druckt die Definitionstabellen (wird aktiviert, wenn die Tabelle als aktuelles Fenster ausgewählt wird). 3.1.5. Tools Telegram History Explorer analysiert werden können. Startet den Telegram History Explorer, mit dem die aufgezeichneten Telegramme 3.1.6. Windows Items Tree Schaltet die OPC Items-Ansicht ein und aus. (Abbildung 3.15) System Messages Schaltet die Systemnachrichten ein und aus. Telegram Monitor Schaltet den Telegrammmonitor ein und aus. Cell Monitor Schaltet den Zellenmonitor ein und aus. Gateway Monitor Schaltet den Gatewaymonitor ein und aus. Search Hilft ein OPC Item nach ItemID oder Beschreibung zu finden. Suchmuster wie 1/* sind möglich. Item Properties Schaltet das Item Eigenschaften Fenster ein und aus. Restore Positions Setzt die Position aller Fenster auf die Ursprungsposition zurück. Cascade Positioniert die Definitionsfenster in den Mittelbereich als Kaskade. NETx KNX OPC Server 3.5.10 Seite 20 von 74

Abbildung 3.15.: OPC Item Tree. Vertical Positioniert die Definitionsfenster vertikal in den Mittelbereich. Horizontal Positioniert die Definitionsfenster horizontal in den Mittelbereich. 3.1.7. Info License Manager Dieses Tool wird zur Lizenzierung der Software mit der Hardware abhängigem Local System ID verwendet. Das ist unser Softlock Code System um die Software zu schützen. Dieses Tool nicht zur Überprüfung der Lizenz verwenden. Dafür bitte in den System messages oder das System Log File nachsehen. About Ein allgemeiner Info-Dialog wird angezeigt. 3.2. Toolbar Abbildung 3.16.: Toolbar der Unified Driver Version. Save All Speichern aller offenen Definitionstabellen. Wird eine Tabelle gespeichert, folgt die Abfrage über die Neuinitialisierung des Servers. Wird diese Abfrage mit JA bestätigt, wird das System mit der neuen Tabelle initialisiert.!achtung: Der OPC Server wird in diesem Fall neu gestartet und die Verbindung zu den OPC Clients unterbrochen. NETx KNX OPC Server 3.5.10 Seite 21 von 74

Abbildung 3.17.: Toolbar der Direct(KNX) Version. To Excel Exportiert eine Definitionstabelle in Microsoft Excel (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). From Excel Importiert eine Definitionstabelle aus einer Microsoft Excel Datei (wird aktiviert wenn die Tabelle als aktuelles Fenster ausgewählt wird). Connection Öffnet den Falcon Connection Manager. (Nur Direct(KNX) Version) Start Startet den OPC Server (wird aktiviert wenn der Server nicht hochgefahren ist oder das Studio die Verbindung zum Server verloren hat). Simulation Startet den OPC Server im Simulationsmodus. Das heißt die Verbindung von KNX NETIP Gateways ist simuliert. Natürlich sind die KNX Geräte nicht simuliert, aber es ist möglich Items im Item Baum zu setzen und so manuell die OPC Clients testen etc. Es gibt ebenfalls die Möglichkeit das System Zufallswerte für die Items generieren zu lassen, damit man z.b.: in der Visualisierung Aktivitäten sieht. Shutdown Der Server wird heruntergefahren. (wird aktiviert wenn das Studio eine Verbindung zum hochgefahrenen Server aufgebaut hat)!achtung: Obwohl das System über die OPC Shutdown-Schnittstelle verfügt, und die Information über das Herunterfahren vom Server an die Clients verschickt wird, berücksichtigen einige Clients dies nicht und melden in diesem Fall einen Verbindungsfehler. Sind zur Zeit OPC Clients mit dem Server verbunden, wird der Dialog wie in Abbildung 3.18 angezeigt. Abbildung 3.18.: Hier wird informiert, dass noch ein OPC Client angeschlossen ist, und abgefragt, ob der Server wirklich gestoppt werden soll. Items Tree Öffnet den Items Baum. Search Es startet ein Such Tool für OPC Items. Edit Script Startet den eingebauten Skript Editor für LUA Skripts. Remote Es startet das eingebaute Quick Support Tool, welches mit der TeamViewer Applikation verwendet werden kann um eine Remote Desktop Verbindung für Wartung und Support aufzubauen. NETx KNX OPC Server 3.5.10 Seite 22 von 74

3.3. Windows 3.3.1. System Messages Hier werden alle relevanten Ereignisse des Systems angezeigt. Jeder Informationstyp wird entsprechend markiert. Alle angezeigten Informationen werden gleichzeitig in der nxaopcsystem.35.log Datei gespeichert, was eine spätere Systemanalyse ermöglicht. Wenn eine Spaltenüberschrift genommen und auf das Gruppierfeld über der Tabelle losgelassen wird, wird die Überschrift herausgezogen und die Tabelle wird nach dieser Überschrift gruppiert. Wenn man während des Verschiebens zusätzlich die Strg-Taste drückt, bleibt die Überschrift in der Tabelle erhalten. Mit dem Mistkübel Icon können alle Systemnachrichten in der Tabellenansicht gelöscht werden. Fehler Nachrichten sind rot gefärbt. Warnungen Nachrichten sind gelb gefärbt. Info Nachrichten sind nicht eingefärbt. (Abbildung 3.19) Abbildung 3.19.: System Messages. 3.3.2. Telegram Monitor Die empfangenen bzw. gesendeten Telegramme werden im Telegramm Monitor angezeigt (Abbildung 3.20). Es werden nur die Telegramme aufgelistet, die im System tatsächlich definiert worden sind, alle anderen werden ignoriert. Die erste Spalte zeigt, ob ein Telegramm gesendet (OUT) oder empfangen (IN) wurde. Die zweite Spalte beinhaltet den Typ des Telegramms. In der dritten wird der Zeitpunkt des Ereignisses angezeigt. Bei den ankommenden Telegrammen wird in der vierten Spalte die IP-Adresse des sendenden Gateways aufgelistet, bei gesendeten wird hier die Ziel- IP-Adresse stehen. BROADCAST steht für ein Telegramm, das an alle Gateways gleichzeitig geschickt wird (zentrales Telegramm). Die nächste Spalte zeigt die logische KNX-Adresse, die das Telegramm übermittelt. Die physikalische KNX-Adresse der Quelle des empfangenen Telegramms steht in der sechsten Spalte. Der Klartext-Beschreibung des Telegramms folgt dann der Wert. In Anlagen, in denen das Telegrammaufkommen sehr hoch ist, soll die Tabelle nur zur Systemüberprüfung verwendet werden, und danach wieder geschlossen werden, um dem Server keine wichtigen Ressourcen zu entziehen. Konfiguration der Tabelle Die Breite einer Spalte kann verändert werden. Wenn eine andere Reihenfolge der Spalten gewünscht ist, einfach per Drag und Drop umgruppieren. Filter Der Filter ermöglicht die gezielte Überwachung von bestimmten KNX-Gruppenadressen/ KNX-Bereichen und/oder bestimmten Gateways. NETx KNX OPC Server 3.5.10 Seite 23 von 74

Abbildung 3.20.: Telegramm Monitor. Set Filter Diese Funktion vereinfacht die Analyse des Datenverkehrs (Abbildung 3.21). Mit diesem Filter kann festgelegt werden, welche Telegramme in der Telegrammliste gezeigt werden sollen. Der Filter besteht aus drei Teilen. Der erste Teil definiert den Bereich der log. KNX-Adressen, die gezeigt werden sollen. Im zweiten Teil kann noch die IP-Adresse definiert werden, so werden nur die Telegramme aufgelistet, die von oder zu diesem Gateway empfangen/geschickt werden, das diese Adresse besitzt. Der letzte Teil legt den Typ der Telegramme fest, die gezeigt werden sollen. Die Filter-Teile können beliebig kombiniert werden. Abbildung 3.21.: Filter im Telegramm-Monitor. 3.3.3. Cell Monitor Das virtuelle Modell der Anlage ist im Server-Speicher abgebildet. Die einzelnen Datenpunkte sind hier als Zellen (Cell) implementiert. Die Wertänderungen einer Zelle können in Echtzeit mit Hilfe des Cell Monitors überwacht werden (Abbildung 3.22). Die Überwachung einer Zelle kann durch Angabe der gesamten Adresse (KNX-Gruppenadresse + IP-Adresse) und Drücken des ADD-Buttons eingefügt werden. Eine Überwachung kann entfernt werden, indem die gewünschte Zeile angeklickt wird, und die Entfernen-Taste auf der Tastatur gedrückt wird. Ist einer Zelle noch kein Wert zugewiesen, wird in der Spalte Value der Text??? angezeigt. Es können nur die im System definierten Zellen (Telegrammdefinitionstabelle) überwacht werden. 3.3.4. Gateway Monitor Der Gateway Monitor listet alle in der Gateway-Definitionsdatei definierten Gateways auf (Abbildung 3.23). NETx KNX OPC Server 3.5.10 Seite 24 von 74

Abbildung 3.22.: Cell-Monitor. Hier ist auch der aktuelle Zustand (OFF - offline, ON - online), die Zeitdauer seit dem letzten Zustandswechsel und die IP-Adresse dargestellt. Ist ein Gateway für das System nicht erreichbar, wird es mit rotem Kreuz und OFF gekennzeichnet. Das BROADCAST Gateway stellt ein imaginäres Gerät dar, es wird verwendet um die zentralen Telegramme, also die, die an alle Gateways gleichzeitig geschickt werden, zu versenden. Hat das BROADCAST Gerät Offline Status, bedeutet das, dass der Server keine Verbindung zum Netzwerk hat. In diesem Fall muss die Netzwerk-Konfiguration des Rechners überprüft werden. Durch das Doppelklicken auf ein aufgelistetes Gateway, wird das Gateway Info-Fenster geöffnet. Abbildung 3.23.: Gateway-Monitor. 3.3.5. Gateway Info Dieser Bereich zeigt die vorhandenen Informationen über das ausgewählte Gateway (Abbildung 3.24). Das Fenster wird aktiviert, indem ein Gateway-Icon aus dem Gateway Monitor mit Doppelklick ausgewählt wird. Current Status - der aktuelle Status des Gerätes (ONLINE/OFFLINE) Name - die Bezeichnung des Gateways IP Address - die IP-Adresse Locality - Standort Description - die Kurzbeschreibung Status changed at - der Zeitpunkt zu welchem die letzte Statusänderung statt gefunden hat. Status changes - die Anzahl der Statusänderungen seit der letzten Initialisierung des Systems. Telegrams received - die Anzahl der Telegramme, die der Server von diesem Gerät empfangen hat. Telegrams Sent - die Anzahl der Telegramme, die an das Gateway versendet worden sind. 3.3.6. Telegram Definition Table Die gesamte Datenstruktur des Systems ist in der Telegram Definitions Tabelle festgelegt (Abbildung 3.25). NETx KNX OPC Server 3.5.10 Seite 25 von 74

Abbildung 3.24.: Gateway-Info. Diese Tabelle wird aus der nxatelegramdefinitions.35.dat Datei gelesen und in dieser Form dem Benutzer zur Verfügung gestellt. Um in dieser Datei zu arbeiten, empfiehlt es sich die Datei nach Microsoft Excel (.xls Datei) zu exportieren, die Datei dort bearbeiten und danach von der.xls Datei wieder zurück zu importieren. Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Kontextmenü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition - fügt eine neue Zeile in die Tabelle ein, die mit Telegrammdefinitions-Daten ausgefüllt werden kann. Insert new Comment - fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition - konvertiert Zeile in eine Telegram Definition. Convert to Comment - konvertiert Zeile in einen Kommentar. Delete - löscht die selektierte Zeile Send Telegram - sendet ein Telegram der ausgewählten Gruppen Adresse. Set Cell Value - setzt nur den Wert der Zelle ohne ein Telegramm zu verschicken. Add to monitor - fügt die Gruppen Adresse dem Cell Monitor hinzu Eine Telegrammdefinitionszeile besteht aus mehreren Spalten. Für detaillierte Informationen siehe section 4.5. Abbildung 3.25.: Telegramm-Definitionstabelle. 3.3.7. Gateway Definition Table Alle Gateways, die vom System verwaltet werden sollen, müssen in dieser Tabelle definiert werden (Abbildung 3.26). Diese Tabelle wird aus der nxagatewaydefinitions.35.dat Datei herausgelesen, und in dieser Form dem NETx KNX OPC Server 3.5.10 Seite 26 von 74

Benutzer zur Verfügung gestellt. Um in dieser Datei zu arbeiten, empfiehlt es sich die Datei nach Microsoft Excel (.xls Datei) zu exportieren, die Datei dort bearbeiten und danach von der.xls Datei wieder zurück zu importieren. Diese Darstellung ermöglicht die Durchführung kleinerer Anpassungen, bzw. das Erweitern der Tabelle, so können auch eventuelle Fehler leichter korrigiert werden. Das Popup-Menü zum Bearbeiten der Tabelle wird über die rechte Maustaste geöffnet. Insert new Definition - fügt eine neue Zeile in die Tabelle ein, die mit Gateway Definitions-Daten ausgefüllt werden kann. Insert new Comment - fügt eine Kommentarzeile ein, die mit einem Text versehen werden kann Convert to Definition - konvertiert Zeile in eine Telegram Definition. Convert to Comment - konvertiert Zeile in einen Kommentar. Delete - löscht die selektierte Zeile Eine Gatewaydefinitionszeile besteht aus mehreren Spalten. Für detaillierte Informationen siehe section 4.6. Abbildung 3.26.: Gateway-Definitionstabelle. 3.3.8. System log file Alle relevanten Informationen werden in einer Datei gespeichert (Abbildung 3.27). Diese Datei kann im Studio zur Überprüfung geladen werden. So können auch die älteren Ereignisse analysiert werden. Wenn eine Spaltenüberschrift genommen und auf das Gruppierfeld über der Tabelle losgelassen wird, wird die Überschrift herausgezogen und die Tabelle wird nach dieser Überschrift gruppiert. Wenn man während des Verschiebens zusätzlich die Strg-Taste drückt, bleibt die Überschrift in der Tabelle erhalten. Mit dem Mistkübel Icon können alle Systemnachrichten in der Tabellenansicht gelöscht werden. Fehler Nachrichten sind rot gefärbt. Warnungen Nachrichten sind gelb gefärbt. Info Nachrichten sind nicht eingefärbt. 3.3.9. Link Manager Der NETx Server kann nun mit verknüpften KNX Gruppenadressen arbeiten und somit verbundene OPC Clients spürbar entlasten. Die Werte der verknüpften Gruppenadressen werden im Server gesetzt, und verbundene OPC Clients werden automatisch über die Wertänderung informiert. Das Konzept der verknüpften Gruppenadressen soll anhand des folgenden Beispiels erklärt werden: Zwei KNX Geräte mit den physikalischen Adressen 1.2.3 und 1.2.4 sind in der ETS definiert. Die Gruppenadressen 1/1 und 10/0 werden dem Gerät 1.2.3 zugewiesen. Die Gruppenadressen 1/2 und 10/0 werden dem Gerät 1.2.4 zugewiesen. Ein Wert von 1 wird an Gruppenadresse 1/1 gesendet. Der Wert wird im Gerät 1.2.3 gesetzt. Ein Wert von 2 wird an Gruppenadresse 1/2 gesendet. Der Wert wird im Gerät 1.2.4 gesetzt. Ein Wert von 3 wird an Gruppenadresse 10/0 gesendet. Der Wert wird in den Geräten 1.2.3 und 1.2.4 gesetzt. Wird der Wert der Gruppenadressen 1/1 und 1/2 durch ein KNX READ Telegramm abgefragt, so ist die Antwort 3. Weil dem NETx Server jedoch die Verknüpfung in der der Gruppenadressen nicht bekannt ist haben die Zellen im folgende Werte: 1/1: 1 NETx KNX OPC Server 3.5.10 Seite 27 von 74

Abbildung 3.27.: System Protokolldatei. 1/2: 2 10/0: 3 Mit einer Link Definition legt man fest, dass sub link Adressen (z.b. 1/1 und 1/2) mit dem Wert einer master Adresse (z.b. 10/0) im Server belegt werden. Für das obige Beispiel lautet die Link Definition: 10/0;BROADCAST;1/1;1/2 Wichtig: Es werden keine Telegramme versendet. Nichtsdestotrotz werden verbundene OPC Clients über die Wertänderung informiert. Der Mechanismus des Link Managers wird über empfangene und gesendete Telegramme ausgelöst. Wird der Wert der master Adresse durch ein anderes Ereignis verändert (z.b. set Cell Value im Studio), so werden die Werte der sub link Adressen nicht verändert, weil sich der wahre Wert des KNX Geräts auch nicht geändert hat.!achtung: Der Link Manager muss in der Systemkonfiguration des Servers aktiviert werden. Folgende Systemparameter müssen auf ON gesetzt sein: KNX.SetLinkOnReceive, KNX.SetLinkOnSend:ON. Es ist möglich, die Verknüpfung auf eine bestimmte IP-Adresse einzuschränken, z.b. 10/0;192.168.1.100;1/1;1/2 Nur die Gruppenadressen aus dem Gateway 192.168.1.100 werden gesetzt. In einer Zeile können bis zu 1000 sub link Adressen angegeben werden. Dennoch kann eine Definition auch auf mehrere Zeilen aufgeteilt werden. 10/0;192.168.1.100;1/1;1/2;1/3;1/4 10/0;192.168.1.100;2/1;2/2;2/3;2/4 Mit dieser Definition werden die Werte der Adressen 1/1, 1/2, 1/3, 1/4, 2/1, 2/2, 2/3 und 2/4 mit dem Wert von 10/0 verknüpft. Eine bidirektionale Verknüpfung kann folgendermaßen erstellt werden: 10/0;192.168.1.100;1/1 1/1;192.168.1.100;10/0 Ändert sich der Wert von 10/0, so wird 1/1 auf den gleichen Wert gesetzt. Nachdem diese Änderungen keine KNX Telgramme erzeugen, führt das nicht zur Endlosschleife. NETx KNX OPC Server 3.5.10 Seite 28 von 74

Link Definition Table Die Tabelle ist in der Datei nxalinkdefinitions.35.dat abgespeichert und kann bearbeitet werden. Zum Bearbeiten empfehlen wir Microsoft Excel (.csv Datei Import). Diese Ansicht ist für kleinere Änderungen und Erweiterungen konzipiert. Auftretende Fehler können rasch behoben werden. Das Kontextmenü wird durch einen Rechtsklick angezeigt. Insert new Definition - fügt eine neue Zeile in der Tabelle ein, in der die Link Definition angegeben werden kann. Insert new Comment - Fügt eine Kommentarzeile ein, die beliebigen Text enthalten kann. Delete - löscht die selektierte Zeile Convert to Definition - konvertiert Zeile in eine Link Definition. Convert to Comment - konvertiert Zeile in einen Kommentar. Column 1 Master Link Die KNX-Gruppenadresse (Master Link) deren Wert von den Sub-Link-Adressen übernommen wird. Sie kann mehrmals eingetragen werden. Column 2 IP Address Die IP-Adresse des Gateways (Bereichs). Ist hier das BROADCAST Gateway angegeben, müssen Master Link und alle Sub Links Adressen in der Telegram Definitionsdatei als BROADCAST definiert sein. Nur dann wird die Wertzuweisung auch durchgeführt. Column 3 bis zu 1000 Sub Links Die Sub Link KNX Gruppenadressen. Die Werte dieser Adressen werden auf den Wert der Master Link Adresse gesetzt. Die Link-Definitionstabelle kann mit Hilfe des NETxKNXConvertETS Tools automatisch aus einer.esf ETS Datei erstellt werden. Siehe: NETxKNXConvertETS Tool in chapter 10. 3.3.10. Event Processor Der NETxKNX Server verfügt jetzt über ein neues Sub-System: den Event Processor (Ereignisprozessor). Wie der Name sagt, beschäftigt sich dieses System mit Ereignissen (Events). Es gibt drei Arten von Ereignissen, die verwaltet werden: Response Event (Antwort-Ereignisse) Die Response Events ermöglichen das Realisieren von Router- Funktionalitäten, so können bestimmte KNX-Telegramme automatisch an andere Gateways oder deren Werte an andere Adressen weitergeleitet werden. Sie werden ausgelöst von den ankommenden KNX-Telegrammen. Timer Event (Schaltuhr-Ereignisse) Die Timer Events sind sehr nützlich um definierte Telegramme zu festgelegten Zeitpunkten zu verschicken. Cyclic Event (zyklische Ereignisse) Die zyklischen Events können verwendet werden, um bestimmte Gruppenadressen in definierten Zeitabständen nach den aktuellen Werten abzufragen (z.b. Stromzähler). Sie werden regelmäßig an KNX versendet, und können als WRITE (Wert setzen) oder als READ (Wert abfragen) Telegramme definiert werden. Alle diese Aufgaben werden unabhängig von den OPC Clients durchgeführt - was diese sehr entlastet. Da der Server hauptsächlich für das Datenmanagement konzipiert ist, stellen normalerweise diese Aufgaben keine große Belastung für ihn dar. Die OPC Clients werden natürlich über jede Änderung und durchgeführte Aktion informiert, so dass sie auf jeden Fall die aktuellen Daten zur Verfügung haben. Response Event Definition Table Die Response Event Definition Tabelle legt die Antwort-Ereignisse fest. Jede Zeile dieser Datei (ausgenommen die Kommentarzeilen) definiert ein Ereignis (Abbildung 3.28). Diese Tabelle wird aus der nxaresponeevents.35.dat Datei (EventFiles Verzeichnis des aktuellen Arbeitsbereiches) herausgelesen und in dieser Form dem Benutzer zur Verfügung gestellt. Zur Bearbeitung dieser Datei NETx KNX OPC Server 3.5.10 Seite 29 von 74