-
Die vorliegende Erfindung behandelt ein Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage, die mit einer oder mehreren Notlichtleuchten aufgebaut ist.
-
Des Weiteren behandelt die vorliegende Erfindung ein System zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage.
-
Mit anderen Worten, die vorliegende Erfindung behandelt ein Verfahren für Notlichtbeleuchtungsanlagen nach dem Oberbegriff von Anspruch 1 sowie ein System nach dem Oberbegriff von Anspruch 26.
-
Technisches Gebiet
-
Notlichtbeleuchtungsanlagen gibt es in verschiedenen Ausgestaltungen. Nach einem Unterscheidungs- und Ordnungskriterium werden die Notlichtbeleuchtungsanlagen in die Kategorien Zentralbatterieanlagen und Einzelbatterieanlagen sowie in weitere Kategorien (z. B. Gruppenbatterieanlagen und Brandabschnittsanlagen) unterteilt.
-
Egal, ob es sich bei einer konkreten Anlage um eine Einzelbatterieanlage oder um eine Zentralbatterieanlage oder eine sonst wie schaltungsarchitektonisch zu bezeichnende Anlage handelt, gibt es zahlreiche Anforderungen, die für alle Anlagentypen einheitlich in Bezug auf ihre topographische Gestaltung gelten.
-
Grundsätzlich sind aufgrund von einschlägigen Normen in vielen Staaten, z. B. auch in der Bundesrepublik Deutschland und in der Republik Österreich, Prüfbücher über die Prüfung der Leuchten einer Notlichtbeleuchtungsanlage zu führen. Normen für Notlichtbeleuchtungsanlagen bestimmen u. a., dass diese Anlagen ein sogenanntes „Prüfbuch“ vorhalten müssen (z. B. durch Punkt 6.3 in der EN 50172:2005 und z. B. Kapitel 7 der DIN EN 62034: 2012; auch sind gewisse Forderungen z. B. aus der DIN IEC 60598-2-22:2014 (siehe z. B. Punkt 5, Punkt 6.3.4 und Punkt 22.21) ableitbar). Die Interpretation der Normen erfolgt von Hersteller zu Hersteller von Notlichtbeleuchtungsanlagen aber ein wenig unterschiedlich. Denn einige, für die Umsetzung der Forderung nach Prüfbüchern zentrale Punkte werden in den Normen offen gelassen. Z. B. schweigen sich die Normen dazu aus, wo konkret das Prüfbuch anzuordnen ist, z. B. welche Stelle in Bezug auf eine Zentralbatterieanlage und z. B. welche Stelle in Bezug auf Einzelbatterieleuchten die jeweils geeignetste Stelle sein soll. Auch ergibt sich aus den Normen nicht unmittelbar, in welcher Form und in welchem Format ein solches Prüfbuch zu führen ist.
-
Stand der Technik
-
Neben den einschlägigen Normen als Fundus für Anregungen, wie Forderungen nach Prüfbüchern technisch beantwortet werden können, steht die Patentliteratur zur Verfügung.
-
Datenarchivierungs- und/oder Sammeleinrichtungen sind u. a. auch in der Patentliteratur beschrieben, wie z. B. in der
DE 10 2007 024 423 B4 (Patentinhaberin: Cooper Crouse-Hinds GmbH; Patenterteilungstag: 12.09.2019).
-
In der
DE 10 2007 024 423 B4 wird anhand eines nicht sonderlich konkret gestalteten Kästchenbildchens eine besondere Aufzeichnungsvorrichtung beschrieben, mit der Einrichtungsparameter von explosionsgeschützten Betriebsmitteln gesammelt werden, anschließend abgespeichert werden und dann an eine externe Gegenstation übermittelt werden. Das Patent wirkt wie ein Wunschkatalog, für die die technischen Lösungen noch anzugeben sind.
-
In der
WO 2017/215 951 A1 (Anmelderin: Zumtobel Lighting GmbH; Veröffentlichungstag: 21.12.2017) wird aufbauend auf speziellen Lesegeräten vorgeschlagen, von einer Gebäudetechnikkomponente Betriebszustände durch diese speziellen Lesegeräte auszulesen und damit Prüfbücher zu erstellen. Als Alternative zu dem Anlegen von Prüfbüchern wird vorgeschlagen, in einer „cloud“ oder auf einem Server die Betriebszustände von jedem der Lesegeräte zu speichern.
-
Die beiden Patentbeschreibungen basieren also auf der Idee, spezielle Geräte zu entwickeln, die in Anlagen einzubauen oder für diese vorzuhalten sind, damit eine elektronische Prüfbuchführung ermöglicht wird.
-
Ferner sind die Lesegeräte der
WO 2017/215 951 A1 mit einem Transponder, einer Batterie und einer Sende- und Empfangs-Einheit ausgestattet. Die Batterie kann den Transponder mit Energie versorgen. Die Sende- und Empfangs-Einheit kann Daten von dem Transponder empfangen und zu dem Transponder schicken. Hierfür stellt die Sende- und Empfangs-Einheit eine drahtlose, direkte Verbindung zu dem Transponder her. Weiter umfasst das Lesegerät eine Steuereinheit in Form eines Prozessors mit einer Software, die einen Lese- und Schreibprozess und die Erstellung des Prüfbuchs steuert. Für die Erstellung eines zentralen Prüfbuchs tauschen mehrere Lesegeräte untereinander die ausgelesenen und protokollierten Betriebszustände aus. Alternativ können die Betriebszustände von jedem Lesegerät auch in einem Rechnernetz oder einem Server gespeichert werden. Dabei ist es ausreichend, wenn eines der untereinander vernetzten Lesegeräte auf das Rechnernetz zugreifen kann.
-
Weiter wird bei der
WO 2017/215 951 A1 vorgeschlagen, vor einer Datenübertragung der Lesegeräte eine Authentifizierung durchzuführen oder die zu übertragenden Daten zu verschlüsseln. Damit könne verhindert werden, dass unbefugte Personen Daten senden oder empfangen. Hierdurch würde die Sicherheit erhöht werden.
-
Aus der
DE 20 2018 003 253 U1 (Gebrauchsmusterinhaber: Richard Kurig; Eintragungstag: 06.09.2018) ist eine Überwachungsvorrichtung für eine Vielzahl von Leuchten bekannt, die mehrere Überwachungseinheiten mit Sensoren und Sendeeinrichtungen aufweist. Die Sensoren generieren bei einem Nicht-leuchten einer Leuchte ein Datensignal, das mittels der Sendeeinrichtung an eine Empfangseinrichtung einer Anzeige versendet wird. So können z. B. Positionsdaten von nicht-leuchtenden Leuchten von der Anzeige angezeigt oder aus dieser ausgelesen werden. Weiter wird eine Kontrollvorrichtung zum Überwachen der Leuchtdauer von Leuchten beschrieben. Eine solche Kontrollvorrichtung soll einen Energiespeicher, einen Datenspeicher, eine Sende/Empfang-Einheit und Sensoren umfassen. Mittels der Sende/Empfang-Einheit kann die Kontrollvorrichtung über das Internet Signale von einer Fernbedienung, einem Mobiltelefon oder dergleichen empfangen. Somit kann eine Fehlermeldung z. B. an einen Zentralrechner gesendet werden. Die Sende/Empfang-Einheit kann auch eine Schnittstelle bilden und beispielsweise einen bekannten Standard wie Bluetooth verwenden. So kann die Kontrollvorrichtung regelmäßig Datensignale über ein lokales Netzwerk an den Zentralrechner versenden.
-
Erwähnen hierbei Dokumente den Fachbegriff „Prüfbücher“, ohne zusätzliche Angaben zu den Prüfhäufigkeiten zu machen, so ergeben sich durch die einschlägigen, in der Bundesrepublik Deutschland geltenden Normenwerke Prüfhäufigkeiten von einmal monatlich bezüglich der Prüfung des Lichts der Lampen, bei der Inbetriebnahme und von einmal jährlich für die gesamte Bemessungsdauer. Speichersysteme, die sich mit der Speicherung von Prüfbüchern auseinandersetzen, können nur äußerst punktuelle Daten in sehr großen Abständen archivieren.
-
Weitere Anregungen, wie Leuchte, Leuchtmittel und Lampen überwacht werden können, dazu gehört auch der Umgang mit Fehlercodes, sind der
EP 928 126 A2 (Anmelderin: Ahlström Sähkötarvikkeet Oy i-Valo; Prioritätstag: 05.01.1998), der
EP 2 849 541 A2 (Anmelderin: INOTEC Sicherheitstechnik GmbH; Anmeldetag 19.08.2014) und der
US 2002/047 546 A 1 (Anmelder: R. Kayser; Anmeldetag 13.11.2001) zu entnehmen.
-
In der
EP 928 126 A2 wird ein Verfahren und eine Anordnung zur Überwachung des Betriebszustands von elektrischen Geräten, insbesondere von Leuchten für Industriegebäude und von Straßenlampen, die schwer zugänglich sind, beschrieben. Eine Übermittlung mittels „transducer“ von wenigstens zwei unterschiedlichen Betriebsstati bzw. Fehlerzuständen wird in der
EP 928 126 A2 behandelt. Eine Abfrage der ermittelten Daten soll bedarfsabhängig erfolgen. Eine Datenauswertung z. B. anhand von Statistiken soll jedoch nicht in der Leuchte, sondern in einem Empfängercomputer durchgeführt werden, also wiederum in einer besonders gestalteten Hardware.
-
Ein anderes Verfahren zum Bereitstellen von Leuchtenparametern an einer Schnittstelle einer Not- oder Sicherheitsleuchte ist in der
EP 2 849 541 A2 beschrieben. Es sollen z. B. Informationen über das Alter eines jeweiligen Leuchtmittels ausgegeben werden. Auch sollen Mittel zur Funktionsprüfung vorhanden sein, anhand derer Leuchtenparameter bzw. Fehlercodes ausgebbar sind. Als weitere mögliche Parameter werden in der
EP 2 849 541 A2 beispielhaft eine Betriebsstundenanzahl der Batterie, eine Anzahl von Ladezyklen sowie verschiedene Temperaturen aufgelistet, deren Übertragung für das menschliche Auge unsichtbar kodiert erfolgen soll. Als Übertragungsmittel werden blinkende Lichtquellen vorgeschlagen. Die zu übertragenden Informationen können einem Mikrokontroller zugeführt bzw. in dem Mikrokontroller abgelegt werden, wobei der Mikrokontroller ein Übertragungssignal modulieren soll. Der Schwerpunkt der
EP 2 849 541 A2 dürfte jedoch bei der Beschreibung der Art der Kodierung von Informationen im durch ein menschliches Auge nicht-sichtbaren Wellenbereich liegen.
-
Eine Lichtquelle, in der eine Vorrichtung zur Abspeicherung von Betriebsparametern integriert sein soll, ist in der
US 2002/047 546 A1 beschrieben. In einer „Lichterzeugungseinheit“ soll es einen Sensor geben, der mit einer Datenspeichereinrichtung verbunden ist, wobei das Ganze in einem Gehäuse montiert sein soll. Zu der Schaltungsanordnung kann auch eine Steuereinheit gehören. Die Speichereinheit wird beispielhaft durch ein „non-volatile RAM“ mit wenigstens 1 Kilobyte Speicherkapazität spezifiziert. Eine solche elektronische Schaltung soll Betriebszeiten, Gesamtbetriebszeiten, Temperaturen bzw. Temperaturentwicklungen und Fehlereignisse, wie Starterfehler oder unzeitiges Selbstabschalten, registrieren. Das Überwachungsgerät kann ein LC-Display umfassen. Zur Realisierung der Kontrollschaltung wird eine „geeignet programmierte CPU“ angegeben, die sowohl „RAM“ als auch „ROM“ aufweist.
-
Die zuvor genannten Druckschriften gelten mit ihrer Benennung als vollumfänglich in vorliegende Erfindungsbeschreibung inkorporiert. Hierdurch soll vermieden werden, nicht mehr erneut und wiederholt allgemein bekannte Zusammenhänge zwischen Notlichtbeleuchtungsanlagen und Prüfbüchern, insbesondere die in ihnen zu speichernden bzw. vorzuhaltenden Parameter, Messwerte und Ereignisprotokollierungen, sowie die zu beachtenden Vorschriften erörtern zu müssen, sondern durch Verweis auf die Druckschriften sollen diese Zusammenhänge als ebenfalls definiert für vorliegende Erfindung angesehen werden dürfen.
-
Außerdem wird in der
DE 102 41 875 A1 (Anmelderin: GIRA Giersiepen GmbH & Co. KG; Offenlegungstag: 18.03.2004) ein Datenverarbeitungssystem für ein elektrisches Gebäude-Installationsbussystem beschrieben. Elektrische Geräte, die mithilfe eines Mikroprozessors eine künstliche Intelligenz besitzen sollen, u. a. werden Klimaanlagen Solaranlagen und Sanitäranlagen als Anwendungsbeispiele für solche Geräte genannt, sollen über einen Installationsbus zur Steuerung und/oder zur Kommunikation verbunden sein. Es soll ein solches Kontrollgerät im Installationsbus eingebunden sein, auf das Anwendern nach einer Legitimationsprüfung Zugriff zum Abrufen von im Kontrollgerät gesammelten Daten gewährt werden soll. Das Kontrollgerät kann mit Mitteln zur unterbrechungsfreien Energieversorgung ausgestattet sein. Aus einer Datenbank sollen außerdem mittels Web-Server beliebige Dienste bzw. Informationen wie Wettervorhersagen bereitgestellt werden können.
-
Die
EP 2 081 415 B1 (Inhaberin: RP-Technik GmbH; Veröffentlichungstag: 28.04.2010) beschreibt eine Mikrokontroller-gesteuerte Notlichtbeleuchtungsanlage und ein geeignetes Kommunikationsverfahren hierfür. Ein Energieverteiler der Anlage soll wenigstens eine Dauerlichtleuchte und wenigstens eine Bereitschaftslichtleuchte versorgen können und mit wenigstens einer Schnittstelle für ein Hypertext Transfer Protocol ausgestattet sein. In dessen Mikrokontroller soll ein Webserver installiert sein, mit dem Anlagendaten der zugehörigen Beleuchtungsanlage verwaltet werden können. Unter Nutzung eines bestimmten Verwaltungs- und Steuerungsverfahren können zwei Berechnungseinheiten kommunikativ miteinander verbunden werden, wodurch ein Austausch von Anlagendaten ermöglicht wird.
-
Die nachveröffentlichte
DE 10 2021 105 552 A1 (Anmelderin: RP-Technik GmbH; Offenlegungstag: 09.09.2021) beschreibt eine Notlichtbeleuchtungsanlage, die sich modular zusammensetzt, indem einzelne, jeweils autark arbeitende Module zur Notlichtbeleuchtungsanlage zusammengesetzt werden. Die Module sind jeweils in eine Bus-Struktur eingebunden. Jedes Modul nimmt eine eigene Kernfunktion wahr. Über den Bus können Datenpakete, z. B. mit einem Steuerbefehl an eine Notlichtleuchte, ausgetauscht werden. Mindestens eines der Module ist aufgrund seiner Programmierung zu einer selbständigen Entscheidung in Reaktion auf ein bestimmtes Ereignis befähigt. Außerdem kann das Modul Informationen über das Ereignis zu einem weiteren Funktionsmodul übertragen sowie einen Zustand mindestens einer Leuchte zur dynamischen Fluchtwegführung ändern. Auch gibt es Module zur Anbindung der Notlichtbeleuchtungsanlage an eine externe Cloud, um beispielsweise in der Cloud Kopien von Konfigurationsdaten und Log-Daten sowie von Ereignissen zu speichern. Anhand einer Elektronikseriennummer können Informationen zu einer bestimmten Leuchte abgefragt werden. Ein Backup der Konfigurationsdaten aller Komponenten soll sowohl periodisch als auch über eine Aktion eines Benutzers in die Cloud übertragen werden.
-
In dem Fachartikel „Smarte Sensoren für das Internet der Dinge“ des Autors Klaus-Dieter Walter, veröffentlicht in dem Sensor Magazin 2/2016, Seite 32 (URL: www.sensormagazin.de/dateien/smonline/redaktion/fachartikel/fachartikel2 sm2_16.pdf), wird eine Nutzung der Cloud im Zusammenhang mit Überwachungs- und Datensammelaufgaben, z. B. im Maschinen- und Anlagenbau, plakativ vorgestellt. Ein sog. „Smart Connected Sensor“ soll in einem einzigen Gehäuse ein Messgrößenerfassung und eine komplette Signalaufbereitung und eine komplette Signalverarbeitung besitzen. Auch soll es eine digitale Schnittstelle zur Kommunikation mit übergeordneten Systemen geben. Zu dem Sensor soll eine spezielle Cloud-Serviceplattform gehören, an die der Sensor Daten für ein virtuelles Datenabbild des Sensors weitergeben kann. Zugang zu dem Datenabbild sei durch Autorisierungen der Zugriffe zu begrenzen. Der Artikel bietet nur ein einziges konkreteres Beispiel, nämlich einen Füllstandssensor.
-
Aufgabenstellung
-
Idealerweise bietet eine Notlichtbeleuchtungsanlage ein Wartungssystem, das bei allen möglichen Anlagenstrukturen zum Einsatz kommen kann, beispielsweise sowohl bei Einzelbatterieanlagen als auch für Gruppen- oder Zentralbatterieanlagen. Gibt es eine zentrale Eingabevorrichtung, z. B. eine Software, die in der Lage ist, sowohl bei Einzelbatterieanlagen als auch bei Gruppen- oder Zentralbatterieanlagen eine gleiche Eingabevorrichtung gegenüber einem Wartungsdienst zu bieten, so reduziert sich der Aufwand für ein Wartungsunternehmen, ihre Mitarbeiter auf verschiedene Anlagensysteme zu schulen. Sobald ein Mitarbeiter die Eingabevorrichtung, z. B. in Gestalt einer App, bedienen kann, könnte dieser Mitarbeiter zu Wartungsaufgaben unabhängig von der Art der Anlage (Einzelbatterieanlage, Gruppenbatterieanlage, Zentralbatterieanlage, Mischformen, Brandabschnittsanlagen usw.) aufbrechen. Dank einer Vereinheitlichung bei den Wartungswerkzeugen würden sich die Einarbeitungs- und Schulungszeiten, denen Elektrofachkräfte zu unterziehen sind, reduzieren.
-
Es stellt sich also die Frage, wie ein solcher Wunsch anlagen- und/oder steuerungstechnisch umgesetzt werden kann.
-
Erfindungsbeschreibung
-
Die erfindungsgemäße Aufgabe wird durch ein Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage nach Anspruch 1 gelöst, ein entsprechendes System einer Notlichtbeleuchtungsanlage, d. h. ein Notlichtbeleuchtungssystem, lässt sich Anspruch 26 entnehmen. Vorteilhafte Weiterbildungen lassen sich den abhängigen Ansprüchen entnehmen.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage stellt jene Daten zusammen, mit denen eine möglichst wirklichkeitsgenaue Abbildung der Notlichtbeleuchtungsanlage möglich ist. Anhand der Daten kann der Zustand und die Konfiguration der Notlichtbeleuchtungsanlage beschrieben werden.
-
Hierzu sind insbesondere Daten zu den Komponenten der Notlichtbeleuchtungsanlage archiviert. Solche Daten können Daten zu einer Zentralsteuerung der Notlichtbeleuchtungsanlage sein.
-
Diese Daten werden von der jeweiligen Komponente oder von einer zentral die Notlichtbeleuchtungsanlage verwaltenden Zentralsteuereinheit sensorisch aufgenommen. Ideal ist es, wenn an mehreren Stellen Daten erhoben werden, z. B. in redundanter Weise. Daneben können noch weitere Daten hinzugesetzt werden, die nicht sensorisch aufzunehmen sind, wie z. B. ein Versionsnummer einer Software oder einer Hardware, aber auch eine Seriennummer einer Komponente.
-
Aus den Daten werden Zustandsdatenpakete gebildet. Eine autarke Datenermittlung bzw. Datenzusammenstellung ist besonders wenig fehleranfällig, weil nicht die gesamte Messdatenerfassung von der Zentralsteuereinheit abhängt.
-
Das Zustandsdatenpaket kann über einen Datenübertragungskanal weitergeleitet werden, damit es archiviert wird. Ein entsprechender (Daten-)Speicher liegt an einem von der Notlichtbeleuchtungsanlage entfernten Ort in der „cloud“ (auch als Cloud bezeichnet). Ein entfernt betriebenes Datennetzwerk sichert die Daten unabhängig von schädigenden Ereignissen und Situationen am Ort der Notlichtbeleuchtungsanlage. Die Daten werden vorteilhafterweise entfernt von der Notlichtbeleuchtungsanlage abgelegt.
-
Das Zustandsdatenpaket gelangt, insbesondere über einen sich speziell ausbildenden Kommunikationskanal, in einen Netzwerkdatenspeicher, der an einem nicht näher bestimmten Ort in der „cloud“ angesiedelt ist. Dort ist eine Datenbank angesiedelt, in die die Zustandsdatenpakete eingeschrieben werden.
-
Eine vorteilhafte Datenbank speichert zu jeder Notlichtbeleuchtungsanlage, die durch eine Seriennummer identifiziert sein kann, einmalig einige Daten und mehrmalig andere Daten.
-
Als Daten gespeichert werden einmalige Daten, die Meta-Informationen sind, wie ein Aufstellungsort oder Kundenadressdaten. Einmalige Daten können eine Seriennummer oder ein Produkt-Typ sein.
-
Durch das zuletzt übermittelte Zustandsdatenpaket und ggf. früher schon übermittelte Zustandsdatenpakete in dem Netzwerkdatenspeicher kann eine Abbildung der Notlichtbeleuchtungsanlage erstellt werden, d. h., durch die so abgelegten Datensätze wird die Notlichtbeleuchtungsanlage beschrieben. Ein solcher Datensatz stellt die Notlichtbeleuchtungsanlage, insbesondere graphisch, dar. Der Datensatz ist die Grundlage für eine graphische Darstellung der Notlichtbeleuchtungsanlage.
-
Das zuvor beschriebene Verfahren kann auf einem System laufen, das einer Notlichtbeleuchtungsanlage zugerechnet wird. Zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage wird das zuvor vorgestellte Verfahren ausgeführt.
-
Mindestens eine Komponente der Notlichtbeleuchtungsanlage weist dabei einen Transponder auf. Mit einem solchen Transponder können Systemdaten in ein Datenübertragungsnetzwerk eingespeist werden.
-
In dem Datenübertragungsnetzwerk ist wenigstens ein auslesbarer, wiederbeschreibbarer, elektronischer oder magnetischer oder optischer Systemdatenspeicher. Dieser Systemdatenspeicher ist als Teil der Notlichtbeleuchtungsanlage eingebunden. In diesem Speicher sind die Systemdaten ablegbar.
-
Wenn eine Komponente eine Zustandsänderung erfährt, so ist dies das auslösende Ereignis (im Sinne eines „Triggers“), um erneut bzw. neuere Daten abzulegen. Einzelne Komponenten können das Ablegen der Systemdaten in dem Systemdatenspeicher veranlassen. Dies kann durch einen oder durch mehrere Steuerbefehle bewirkt werden.
-
Der Systemdatenspeicher ist ein Netzwerkdatenspeicher.
-
Als Daten in der Datenbank werden einmalige Daten gespeichert, die Meta-Informationen sind, wie ein Aufstellungsort oder Kundenadressdaten.
-
Nachfolgend werden vorteilhafte Ausgestaltungen und Weiterbildungen dargelegt, die für sich gesehen, sowohl einzeln als auch in Kombination, ebenfalls erfinderische Aspekte offenbaren können.
-
Weitere geeignete Daten sind Daten zu einer Batterieanlage der Notlichtbeleuchtungsanlage.
-
Daten zu den einzelnen Leuchten sind hilfreich, insbesondere Daten zu Leuchten wie zu einzelnen Rettungszeichenleuchten, zu einzelnen Dauerlichtleuchten und/oder einzelnen Sicherheitsleuchten.
-
Hierzu gehören auch Daten, die für einzelne Prüfbücher der Notlichtbeleuchtungsanlage bestimmt sind.
-
Für den Umgang mit solchen zusätzlichen Informationen helfen sogenannte Experteninformationen, die zusätzlich zu den im Prüfbuch vorgehaltenen Informationen aufbereitet abgelegt werden können. Liest eine Elektrofachkraft das Prüfbuch aus und erhält die Elektrofachkraft noch eine Interpretationsunterstützung durch weiterführende Informationen, wie z. B. eine Spannungsangabe in einem Spannungsfenster oder wie z. B. einen Spannungsverlauf in Bezug auf Grenzwerte von noch zu akzeptierenden Spannungen, so kann die Elektrofachkraft qualifiziertere Entscheidungen zu den Wartungsnotwendigkeiten und Wartungsumfängen treffen.
-
Die Daten können durch regelmäßig, periodisch wiederholte Prüfungen und Tests ermittelt werden.
-
Zustandsdaten der Notlichtbeleuchtungsanlage sind von einer ersten Rettungszeichenleuchte über einen Datenübertragungskanal auf einen Router übertragbar, der unter anderem Daten zur Arbeitsstation sowie Daten über einen Datenserver zum Netzwerkdatenspeicher weiterleitet.
-
Aus den Daten können unabhängig von der Zentralsteuereinheit Zustandsdatenpakete gebildet werden.
-
Das Datennetzwerk sichert als fremdbetriebenes Datennetzwerk die Daten unabhängig von schädigenden Ereignissen und Situationen am Ort der Notlichtbeleuchtungsanlage.
-
Die „cloud“-Anbindung schafft außerdem auch noch eine weitere Lösung für einen bisher existierenden Nachteil. Die erst im Laufe der weiteren Betreuung der Notlichtbeleuchtungsanlage zuständig werdende Person greift üblicherweise auch gerne auf die früheren Daten zur Notlichtbeleuchtungsanlage zurück. Der neue Verantwortliche für die Notlichtbeleuchtungsanlage müsste die Daten von dem früheren Zuständigen anfordern. Aus diesem Grund bietet die zentral angeordnete Datenbank zugleich eine Oberflächenschnittstelle, über die die einzelnen Leuchten dargestellt werden können. Die Darstellung erfolgt aber mithilfe der entsprechenden App. In der „cloud“ liegt ein Systemabbild, Daten zur Systemkonfiguration und das oder die Prüfbücher. Die menschengerechte Darstellung dieser Daten erfolgt idealerweise über die App.
-
Die Cloud kann somit auch als „backup“-Speicher für Dokumentationen zur Funktionstüchtigkeit und Betriebssicherheit der Notlichtbeleuchtungsanlage genutzt werden.
-
Eine Übertragung der kompletten Konfiguration, einzelner Daten oder einer neuen Firmware in die Notlichtbeleuchtungsanlage wird vereinfacht. Ein entsprechender Datentransfer kann aus der „cloud“ heraus angefordert werden oder auch von der Notlichtbeleuchtungsanlage (z. B. durch Benutzerinteraktion) initiiert werden. Beispiele:
- • Wiederherstellung einer in der Cloud gespeicherten Konfiguration in der Notlichtbeleuchtungsanlage;
- • ein Firmware-Update in der Notlichtbeleuchtungsanlage
-
Die einzelnen Konfigurationen und/oder eine Gesamtkonfiguration für alle Komponenten der Notlichtbeleuchtungsanlage können/kann aus dem Datennetzwerk den Komponenten und damit der Notlichtbeleuchtungsanlage zur Verfügung gestellt werden.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann die zuvor gespeicherten Zustandsdatenpakete der Notlichtbeleuchtungsanlagen mit einem Kommunikationsgerät wieder zugänglich machen. Hat das Kommunikationsgerät z. B. eine LTE-Verbindung (oder eine GSM-Verbindung oder etwas Ähnliches), d. h. kann das Kommunikationsgerät als LTE-fähiges Gerät bezeichnet werden, so kann das Gerät als mobiles Kommunikationsgerät an einem beliebigen, mit einer LTE-Netzabdeckung ausgestatteten Ort Daten zur Notlichtbeleuchtungsanlage zur Verfügung stellen. Auf diese Weise können Daten aus dem Netzwerkdatenspeicher ausgelesen werden.
-
Ist das mobile Kommunikationsgerät mit einem graphischen Abbildungsrahmen ausgestattet, können die Daten leicht verständlich vorgestellt werden. Ein Nutzer des mobilen Kommunikationsgeräts erfasst die Daten leichter bzw. sie sind für ihn eingängiger.
-
So ist es möglich, dass aus den abgerufenen Zustandsdatenpaketen eine ein Gebäude oder ein Bauwerk wiedergebende Darstellung wird. Eine solche Darstellung kann z. B. eine dreidimensionale, Räume abbildende Darstellung sein. Die Daten werden so umformatiert, dass daraus eine Gebäudeabbildung erzeugt wird.
-
Es ist vorteilhaft, wenn die Zustandsdatenpakete auf einer visuellen Ausgabeeinheit des Kommunikationsgeräts der Notlichtbeleuchtungsanlage sichtbar gemacht werden können.
-
Mithilfe der Darstellung können z. B. zu einem veränderbaren Zeitpunkt (z. B. mithilfe eines Zeitschiebers) in der Vergangenheit ein Zustand und/oder eine Konfiguration der Notlichtbeleuchtungsanlage anhand von einer (reduzierten) Anzahl Symbole abgebildet werden, sodass der Benutzer eines entsprechenden Programms leicht und schnell den Zustand der Notlichtbeleuchtungsanlage zu einem beliebigen Zeitpunkt in der Vergangenheit erfassen kann. Die Daten sind mit einer Zeitmarke versehen, die den Zeitpunkt deren Erstellung angibt.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage basiert in einer Ausgestaltung auf Zustandsdatenpaketen der Notlichtbeleuchtungsanlage. Durch eine Zeitentwicklungsdarstellung, insbesondere in Verbindung mit einer räumlich drei-dimensionale Darstellung, können Zustände visualisierbar sein. Die Darstellung kann z. B. auf einem Display des mobilen Kommunikationsgeräts stattfinden.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann auch mit mehreren Passwörtern und einer Passwortvererbung Zugänge zu den Zustandsdaten und zu einer graphischen Wiedergabe des Gebäudes freigeben und diese auch sperren.
-
Idealerweise ist eine Vererbung so geregelt, dass ein Benutzer, der einen neuen Benutzer anlegt, diesem nicht mehr Rechte einräumen kann, als er selbst hat.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage mag in einer günstigen Ausgestaltung Daten von einer oder mehreren Rettungszeichenleuchten und/oder von einer oder mehreren Dauerlichtleuchten und/oder von einer oder mehreren Sicherheitsleuchten bearbeiten. Eine solche Bearbeitung kann z. B. zentralsteuergerätelos erfolgen. Insbesondere ist es vorteilhaft, wenn eine Verbindung in die „cloud“ auch ohne zentrales Steuergerät möglich ist. Mit dem Netzwerkdatenspeicher kann dann „dezentral“ eine Verbindung aufgebaut werden.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann so ausgestaltet sein, dass es einen Zugriff und/oder ein Herunterladen von einem Notlichtbeleuchtungsanlagendatensatz oder eines Teils des Notlichtbeleuchtungsanlagendatensatzes erst nach Eingabe eines Sicherungscodes, wie eines Passworts, aus dem Netzwerkdatenspeicher zulässt.
-
Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann vorteilhafterweise so weitergebildet sein, dass ein erster Teil des Notlichtbeleuchtungsanlagendatensatzes auf dem Netzwerkdatenspeicher durch ein erstes Passwort und ein zweiter Teil des Notlichtbeleuchtungsdatensatzes durch ein zweites Passwort, das von dem ersten Passwort verschieden ist, geschützt ist.
-
Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann auch so ausgebildet sein, dass vor einer Passworteingabe eine persönliche Identifikationseingabe erfolgen muss, um einen Ablauf einer Passworteingabe überhaupt erst zu starten. Die Identifikationseingabe ist die Voraussetzung für die Passworteingabe.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann mit verschiedensten Daten operieren. Zu den Daten können Zustandsdatenpakete und/oder Betriebszustandsdaten und/oder Sensordaten gehören. Beispiele hierfür sind Lichtstärkemessdaten von Leuchtmitteln, Ladezustandsmessdaten und Ladespannungen von Akkumulatoren. Es kann vorteilhaft sein, wenn Temperaturmessdaten aus einem Inneren einer Rettungszeichenleuchte, einer Dauerlichtleuchte und/oder einer Sicherheitsleuchte erfasst werden.
-
Messungen können in regelmäßig sich widerholenden Messvorgängen von einer Komponente der Notlichtbeleuchtungsanlage durchgeführt werden. Natürlich können auch Messvorgänge durchgeführt werden, bei denen durch die Messung Werte von mehreren Komponenten erfasst werden.
-
Das Verfahren zur Verwaltung von Systemdaten einer Notlichtbeleuchtungsanlage kann derart weitergebildet sein, dass die Komponente einen Zeitzähler aufweist. Der Zeitzähler ist vorteilhafterweise mit einem Netzwerkdatenspeicherzeitzähler synchronisierbar. Eine Aktualisierung des Zustandsdatenpakets erfolgt nach einem (bestimmten) Zeitintervall. Das Zeitintervall kann z. B. auf eine zeitliche Länge eingestellt sein. Das Zeitintervall kann z. B. auf eine Dauer eingestellt werden.
-
Über die Schnittstelle in die „cloud“ ist ein einheitliches Interface für die softwaremäßige Verwaltung in das Internet und zu dem Hersteller der Notlichtbeleuchtungsanlage bereitgestellt.
-
Als zentrale Softwarekomponenten, Software-Apps, Softwareteile, Softwaredienste, Softwareinstanzen und -module können die folgenden Module und Komponenten angesehen werden:
- • eine clientseitige Klassenbibliothek:
- Eine Bibliothek, mit der die komplette Notlichtbeleuchtungsanlage (im Falle einer modularen Notlichtbeleuchtungsanlage alle Module samt ihrer Vernetzungsstruktur) im Gateway als Datenobjekt abgebildet werden kann. Die Klassenbibliothek kümmert sich dann um die Kommunikation mit dem Internet/der „cloud“; sie tauscht Daten in einheitlicher Form aus und empfängt Befehle, etwa zum Einstellen eines Parameters, zur Umordnung von Baum- oder Netzstrukturen oder um Firmware zu aktualisieren.
- • eine zentrale Datenbank in der „cloud“:
- In einer zentralen Datenbank laufen Daten von einzelnen Notlichtbeleuchtungsanlagen auf und werden archiviert bzw. online verfügbar gemacht. Die Ablage erfolgt in einem einheitlichen Format, sodass weitere Neuentwicklung unter Nutzung des bisherigen Codes für einen Server möglich ist.
- • eine Stelle mit zentralen Diensten:
- Auf den Servern der „cloud“ laufende Dienstprogramme, die folgende Aufgaben übernehmen:
- o Abgleich/Sichern/Backup zwischen der Datenbank und einer Notlichtbeleuchtungsanlage;
- o Online-Analyse von Datenbankinhalten;
- o Online-Verfügbarmachung einer generischen Benutzungsoberfläche, um z. B. Konfigurationen direkt einzusehen und zu verändern (z. B. Editieren einer XML-Datei) oder um die Ausführung bestimmter Funktionen in einem Programm zu triggern;
- o Online-Verbindung zum Web-Interface.
-
Die Onlinefunktionen sind mit Zugangsberechtigungen geschützt, die eine Rechteverwaltung durchführen. Durch die Rechteverwaltung ist der Zugang für einzelne Lizenznehmer auf eine Untermenge der Produkt-Instanzen begrenzbar. Beispielsweise können nur bestimmte Software-Module freigegeben werden.
-
Eine Sicherheit für die gesamte Notlichtbeleuchtungsanlage kann gesteigert werden, wenn sämtliche Funktionen nur authentifizierten Benutzern zur Verfügung stehen. Der Datenaustausch zwischen dem Programm und der „cloud“ und/oder zwischen dem Programm und der Datenbank sollte verschlüsselt ablaufen. Der Datenaustausch zwischen dem Benutzer eines online-Dienstes und der Notlichtbeleuchtungsanlage sollte abhörsicher sein.
-
Moderne „cloud“-Speicher-Möglichkeiten ermöglichen eine Datensicherung, -speicherung und -bearbeitung an externen Standorten und unabhängig von Einrichtungen, welche die Daten erhoben und abgespeichert haben. Im Bereich der Notlichtbeleuchtungsanlagen ist hierzu eine „cloud“-Applikation vorteilhaft, mit der mehrere Anlagen überwacht werden können. Jede Anlage, die online mit einer „cloud“ verknüpft ist, lädt Daten über ihre Konfiguration, ihren Status, Details über ihre einzelnen Module, Logbücher und auch Prüfbücher in die „cloud“ hoch. Dabei erfolgt die Synchronisation der Daten entweder manuell oder automatisch. Die Applikation erlaubt eine Anzeige vieler Anlagen und zugleich ein gezieltes Auffinden einer einzelnen fehlerhaften Leuchte. Der Nutzer sucht dabei nach als fehlerhaft markierten Anlagen und kann dann gezielt in einzelne Komponenten der Anlage (genauer: in die Datensätze und ihre Darstellungen) hineinnavigieren, bis er z. B. bei einer einzelnen fehlerhaften Leuchte landet. Sowohl der Zugang zu Daten im „cloud“-Speicher als auch der Zugang zu Anlagen und deren Daten mittels eines mobilen Endgeräts sind an Zugangsberechtigungen, wie Benutzername und Passwort, gekoppelt, welche von der Applikation verwaltet werden.
-
Die zuvor dargestellten Kombinationen und Ausführungsbeispiele lassen sich auch in zahlreichen weiteren Verbindungen und Kombinationen betrachten.
-
Für die Schnittstelle zum Gateway gibt es wenigstens zwei Alternativen, die sowohl einzeln als auch in Kombination realisierbar sind:
- Variante 1: Das Gateway ist eine separate „Box“ mit Internet-Konnektivität (drahtlos oder leitungsgebunden). Der Datenaustausch mit dem Programm geschieht über eine einheitliche Schnittstelle (wie z. B. USB, XML, Ethernet).
- Variante 2: Das Gateway ist integraler Bestandteil des Programms. Beispielsweise wäre die Kontrolleinheit der Notlichtbeleuchtungsanlage sowohl Web-Interface-Server als auch Cloud-Gateway. Das entsprechende Modul eines dieses Modul umfassenden Programms kann intern direkt eine geeignete CoreLink-Bibliothek einbinden und seine Daten direkt in Form der dort definierten Objekte verwalten.
-
Die Variante 2 führt zu einem kompakteren Design.
-
Idealerweise sind möglichst viele Funktionen separat (einzeln oder in sinnvoll definierten Paketen) pro Benutzer aktivierbar und deaktivierbar. Beispiele sind:
- • Pro Benutzer kann vorgebbar sein, auf welche Programme oder Module eines Programms (ID) er zugreifen darf.
- • Pro Benutzer kann vorgebbar sein, welche Funktionen er verwenden darf.
- • Die pro Benutzer verfügbaren Funktionen können zumindest mit dem Gerätetyp oder mit jedem einzelnen Programm verknüpfbar sein.
-
Eine Übertragung einer kompletten Konfiguration, eines Prüfbuches, eines Datenlogs oder einzelner bestimmter Daten bzw. Datensätze von einem entsprechenden Programm in eine „cloud“-Datenbank kann individuell einstellbar sein. Ein Transfer könnte aus der Cloud heraus anforderbar sein. In einer alternativen Ausgestaltung kann auch von einem Programm aus (z. B. durch eine Benutzerinteraktion) ein Datenaustausch initiiert werden. Anlässe hierfür sind zum Beispiel:
- • Sicherung einer Konfiguration in der „cloud“;
- • Abfrage einer Konfiguration von der „cloud“ aus, wenn ein Benutzer eines online-Dienstes an seinem PC diese einsehen will;
- • automatische Aktualisierung von Daten in der „cloud“;
- • Rückgabewert einer durch Aufruf aus der „cloud“ ausgeführten Funktion.
-
Eine vorteilhafte Datenbank speichert zu jeder Notlichtbeleuchtungsanlage, die durch eine Seriennummer z. B. eindeutig identifiziert sein kann, einmalig einige Daten und mehrmalig andere Daten:
- • Einmalige Daten können eine Seriennummer, ein Produkt-Typ oder Meta-Informationen wie ein Aufstellungsort oder Kundenadressdaten sein.
- • Mehrfach zu speichernde Daten können solche Daten wie ein Systemstatus, eine Hardware- und Softwareversion oder auch Konfigurationseinstellungen sein.
-
Ferner können für jede Gruppe ein Satz von Default-Konfigurationen, eine für jede Notlichtbeleuchtungsanlage, vorgehalten werden.
-
Eine Datenanalyse kann für authentifizierte Benutzer als nutzbarer online-Dienst zur Verfügung gestellt werden. Eine Datenanalyse-Funktion kann zur Verfügung stehen, die in einem online-Portal aufrufbar ist. Jeder Benutzer kann - entsprechende Rechte vorausgesetzt - diese Analysen für die Notlichtbeleuchtungsanlagen, die er verwaltet, durchführen. Bei Bedarf kann ein Benutzer auf solche Dienste zurückgreifen, die Analysen durchführen. Die Ergebnisse können online im WebBrowser in einem Dashboard angezeigt werden. Beispiele hierfür sind:
- • Notlichtbeleuchtungsanlagen eines bestimmten Typs mit bestimmter Software-Version auflisten,
- • Notlichtbeleuchtungsanlagen eines bestimmten Typs mit einer bestimmten Konfiguration auflisten,
- • Statistik, welche Werte eine bestimmte Einstellung, Version o. a. wie häufig hat,
- • Liste mit dem Systemzustand aller Notlichtbeleuchtungsanlagen,
- • Liste mit der Anzahl von Leuchten, genommen über alle WirelessControl-Installationen,
- • Liste von Notlichtbeleuchtungsanlagen anzeigen, die eine Wartung erfordern.
-
Auch ist es vorteilhaft, wenn es eine Möglichkeit gibt, einen serverseitigen online-Dienst einzurichten, der in regelmäßigen Abständen Kontakt zu bestimmten Notlichtbeleuchtungsanlagen, insbesondere der gerade untersuchten Notlichtbeleuchtungsanlage, aufnimmt und deren Status abfragt.
-
Zu einem geeigneten Programm gehört es auch, dass das Programm für eingeloggte und authentifizierte User eine Verbindung in die „cloud“ herstellen kann. Über diese Verbindung kann, z. B. per Web-Browser, Zugang zur „cloud“, z. B. per Web-Interface des Programms, hergestellt werden.
-
Idealerweise können Benutzer und Gruppen verwaltet werden.
-
Ein Benutzer kann Mitglied einer oder mehrerer Gruppen sein.
-
Eine Gruppe kann keine Rechte, eingeschränkte Rechte oder sogar mehrere Rechte besitzen.
-
Jeder Benutzer, der Mitglied einer oder mehrerer Gruppen ist, erhält für die Dauer dieser Zugehörigkeit die Rechte aus allen diesen Gruppen.
-
Ein eingeloggter Benutzer hat Zugriff entweder auf alle Daten, auf eine Default-Konfiguration und auf weitere Daten oder auf ausgewählte Datensätze. Es kann mit Gruppen agiert werden. Die Gruppen erlauben es, dass unterschiedliche Daten zur Verfügung stehen. Diese verschiedenen Gruppen sind idealerweise optisch von Gruppe zu Gruppe voneinander abgesetzt. Auch sollten Daten den Gruppen entsprechend, d. h. gruppenweise ausblendbar sein, um eine bessere Übersichtlichkeit zu gewährleisten.
-
Als Vorprogrammierung der Zugriffsgruppen können ausgewählte Gruppen angelegt sein. Ein Programm erhält als Voreinstellung eine zugriffsberechtigte Gruppe (bzw. mehrere solcher Gruppen), z. B. einen Notlichtbeleuchtungsanlagenbetreiber sowie ausgewählte Gruppen des Herstellers. Hierbei ist es vorteilhaft, wenn einige Gruppen nicht gelöscht werden können.
-
In einem entsprechenden Programm, das z. B. auf einem mobilen Gerät wie einem Tablet-PC oder einem Handy ablaufen kann, sollte vorteilhafterweise außerdem eine Defaulteinstellungs-Gruppe programmiert sein. Dank dem Aufspielen des Programms auf ein mobiles Gerät wird aus einem beliebigen mobilen Gerät ein mobiles Kommunikationsgerät. Bei der Erstinbetriebnahme vor Ort und/oder bei einem Kontakt mit der Cloud lädt das Programm die in dieser Gruppe definierte Default-Konfiguration (einschließlich Service-Adresse etc.) herunter.
-
Das (elektronische) Prüfbuch kann zum einen in jeder einzelnen Leuchte vorgehalten sein. Vorzugsweise hat jede Leuchte das zu ihr gehörende individuelle Prüfbuch. Bei Anlagen, die keine Zentralbatterieanlagen sind, z. B. Rettungszeichenleuchtenanlagen mit Einzelbatterieversorgung, d. h. einer Energieversorgung in jeder Leuchte, die über ein Funknetzwerk untereinander verbunden sind und über das Funknetzwerk miteinander kommunizieren, sollte - aufgrund des Fehlens einer zentralen Instanz - das jeweilige Prüfbuch sogar tatsächlich in der jeweiligen Leuchte - mangels alternativer Platzierungsorte - vorhanden sein, sofern keine Zentralinstanz für das Prüfbuch geschaffen wird.
-
Zum anderen kann das Prüfbuch an einer zentralen Stelle, z. B. in der „cloud“, angeordnet und dort vorgehalten werden.
-
Die Anordnung des Prüfbuches in der Leuchte macht insbesondere für solche Parameter Sinn, die leuchtenabhängig sind. Aus einschlägigen Normen kann z. B. die Forderung abgeleitet werden, dass batteriegestützte Leuchten bekannt geben sollten, ob die Akkumulatoren der jeweiligen Leuchte in Ordnung sind. Ob eine ermittelte oder gemessene Akkumulatorspannung eines Akkumulators als akzeptabel anzusehen ist, dürfte jedoch nicht von den einschlägigen Normen gefordert werden. Es stellt aber eine zusätzlich interessante Information, insbesondere für Wartungspersonal, dar, ob die Akkumulatorspannung sich permanent in einem akzeptablen Spannungsbereich bewegt. Es ist z. B. möglich und zulässig, nach außen (in Bezug auf die Leuchte) nur die (informationell beschränkten) Einzelheiten bzw. Informationsumfänge abzugeben, ob die Akkumulatoren in Ordnung sind. Das genaue „Know-how“ (i. S. v. Fachwissen), bei welchen Spannungen welche Einstufungen der Akkumulatoren in Bezug auf ihre Güte getroffen werden, könnte eigentlich in der Leuchte behalten werden. Nach einer Interpretation der einschlägigen Normen muss nicht das Messergebnis anhand der Leuchtenspannung einer Leuchte kommuniziert werden, sondern normungsgemäß reichte es auch, nur das summarische Testergebnis „in Ordnung“ oder „nicht in Ordnung“ zu kommunizieren. Erschwerend kommt hinzu, dass das Kriterium, bei welcher Akkumulatorspannung von einer guten, akzeptablen bzw. betriebsbereiten Akkumulatorspannung auszugehen ist, von Leuchte zu Leuchte abweichen kann, weil auch der Typ des Leuchtmittels mit berücksichtigt werden kann.
-
Die Platzierung des Prüfbuchs in solchen Leuchten, die mit „Bluetooth“-Intelligenz ausgestattet sind, ist äußerst vorteilhaft zu realisieren, denn einschlägige „Bluetooth“-Module, die vorzugsweise nach dem „Bluetooth-smart-Standard“ (auch als „Bluetooth-low-energy“ bzw. als „Bluetooth LE“ bekannt) kommunizieren, können sowieso schon von Haus aus mit Mikrokontrollern und Speichern ausgestattet sein. Das Prüfbuch kann also als Teil der Programmlogik mit in den Funkchip des „Bluetooth“-Modules integriert sein. Folglich braucht in einer Leuchte mit „Bluetooth“-Konfiguration das Prüfbuch nicht in der eigentlichen Leuchte angeordnet zu werden (z. B. nicht in der eigentlichen Leuchtensteuerung), sondern das Prüfbuch kann als Nachrüstsatz einer nachrüstbaren „Bluetooth“-Kommunikationsschnittstelle vorhanden sein.
-
Zu den Tests, die gem. einschlägiger Normen durchzuführen sind, gehören Testroutinen, wie lange die Betriebszeit-Kapazität der einzelnen Leuchten ist, welche Leuchtmittel vorhanden sind und ob die Akkumulatorspannungen in Ordnung sind. Idealerweise ist eine Aussage zu treffen, ob jedes einzelne Leuchtmittel einer Leuchte in Ordnung ist. Dies alles, kann aber, wie gesagt, als eine Sammelantwort angeboten werden; anstelle eine dezidierte Aufschlüsselung jedes einzelnen Prüfteilergebnisses anzubieten.
-
Wird der Datensatz bzw. das Zustandsdatenpaket in Abhängigkeit eines Sicherungscodes unterschiedlich detailliert zur Verfügung gestellt, ist es möglich, einem Gebäudebetreiber die normungsgemäß erforderlichen Daten kompakt und übersichtlich zur Verfügung zu stellen, z. B. die Angabe, dass alle Leuchten noch im akzeptablen Bereich sind. Einer Wartungsfachkraft kann in Abhängigkeit eines anderen Sicherungscodes eine detailliertere Information, insbesondere ein mit mehr Daten ausgestattetes Zustandsdatenpaket, unterbreitet oder zur Verfügung gestellt werden. So kann z. B. die Wartungsfachkraft aufgrund von zusätzlichen Daten voraussehen, dass eine baldige größere Wartung mit Austausch von Akkumulatoren ansteht, während der Gebäudebetreiber beruhigt weiß, dass die Notlichtbeleuchtungsanlage noch betriebsbereit ist und das Gebäude weiterhin benutzt werden darf.
-
Das Prüfbuch, das insbesondere in der einzelnen Komponente, wie einer Leuchte, einer Notlichtbeleuchtungsanlage existiert, ist vorteilhafterweise zusammen mit einem Zeitzähler in der Komponente, wie z. B. in der Leuchte oder in einem Prüfbuchmodul, realisiert, wodurch die Daten des Prüfbuchs synchronisiert abgelegt bzw. eingestellt werden können. Vorteilhafterweise gibt es eine Gangreserve. Ist eine Gangreserve vorhanden, die idealerweise wenigstens 7 Tage lang ist, können mehrere Tests, die in das Prüfbuch eingeschrieben werden, durchgeführt werden. Nach z. B. 7 Tagen wird jeweils ein Test gespeichert. Es handelt sich also um einen Dauerspeicher, der z. B. mit Messergebnissen, die in 7-Tagesabständen gemessen worden sind, aufgefüllt wird.
-
Mit den entsprechenden Kenntnissen der Kodierung ist das Prüfbuch (für einen eingeweihten Fachmann) auch wieder zurücksetzbar. Eine Manipulation des Prüfbuchs wird aber durch die Kodierung erschwert. Idealerweise ist der Speicher so ausgelegt, dass wenigstens 52 Tests pro Jahr gespeichert werden können, wobei es besonders vorteilhaft ist, wenn auf einen Zeitraum von wenigstens 10 Jahren alle Tests eines Jahres gespeichert werden können, das heißt also wenigstens 520 Tests speicherbar sind.
-
Das Prüfbuch kann als „log-file“ oder „Logbuch“ geführt sein.
-
Das Prüfbuch kann der Art nach als ein Zustandsarchiv geführt sein, das in einem Dauerspeicher vorgehalten wird. Leuchten, die mit einem individuellen Prüfbuch ausgestattet sind, können als Prüfbuch-Leuchten oder auch als „self-control-Leuchten“ (Leuchte mit autarker Eigenüberwachung) bezeichnet werden.
-
Eine entsprechende Leuchte kann über „Bluetooth“ mit einem „Bluetooth“-Gerät wie einem Tablet-Rechner kommunizieren. Das Prüfbuch kann in dem „Bluetooth-smart-Modul“ angeordnet werden. Dem Tablet-Rechner kann das Prüfbuch in grafisch ansprechender Weise übersandt werden. Darüber hinaus gibt es zusätzliche Funktionen, die mit dem Tablet-PC ein- und ausgeschaltet werden können, wie z. B. das Einschalten einzelner Leuchtmittel einer ausgewählten Leuchte.
-
Obwohl mit dem Thema „Prüfbuch“ unterschiedlich umzugehen ist, je nach Größe der installierten Notlichtbeleuchtungsanlage, zeigt die vorliegende Erfindung auf, wie einheitlich damit umgegangen werden kann. Obwohl kleinere Installationen mit einem geringeren Prüfaufwand und mit einer geringeren Prüfdokumentation überwacht werden können als große Anlagen, zeigt die vorliegende Erfindung, wie ein System aussehen kann, das auf alle Anlagentypen gleichermaßen angewendet werden kann. Die Trennlinie, bei welcher Anzahl Leuchten eine Notlichtbeleuchtungsinstallation als große Installation und bei welcher Anzahl Leuchten eine Notlichtbeleuchtungsanlage als kleine Installation zu bezeichnen ist, hat sich im Laufe der Jahre immer wieder gewandelt.
-
Aus diesem Grund schafft die vorliegende Erfindung auch eine Ergänzungsmöglichkeit zu reinen autark betriebenen Rettungszeichenleuchtenanlagen. So kann auch dieser Anlagentyp mit der aus den Normen und somit von dem Gesetzgeber aufgegriffenen Forderung nach entsprechenden Prüfbüchern umgehen. Das erfindungsgemäße Konzept ist so gestaltet, dass die entsprechenden Module auch als nachrüstbarer Gerätesatz zu montierten Leuchten in diesen nachträglich eingebaut werden kann.
-
Das Prüfen der Funktionstüchtigkeit aller Leuchten einer Notlichtbeleuchtungsanlage könnte generell auch per Hand durchgeführt werden. Diese Arbeitsweise ist aber entsprechend arbeitsaufwändig. Aus diesem Grund ist eine autark arbeitende Leuchtenüberwachung sinnvoll.
-
Die Leuchtenüberwachung selbst muss aber nicht an einem zentralen Ort ablaufen bzw. abgearbeitet werden. Die Leuchtenüberwachung kann dem Prinzip der verteilten Prüfbücher, von denen jeweils ein Prüfbuch in einer einzelnen Leuchte abgelegt ist, folgen. Ein Teil der vorliegenden Erfindung basiert auf der Idee, eine erforderliche Dokumentation der vorgenommenen Prüfungen statt in einem einzigen Prüfbuch vorzuhalten, durch lokal angesiedelte Prüfbücher sicherzustellen.
-
Eine andere Schwierigkeit, die immer wieder vor Ort bei vielen Notlichtbeleuchtungsanlagen kleinerer Größen vorzufinden ist, ist die wechselnde Betreuung. Bei kleineren und mittleren Notlichtbeleuchtungsanlagen bzw. Notlichtbeleuchtungsinstallationen gibt es häufig nicht nur einen einzigen Verantwortlichen, sondern die Zuständigkeit für die Notlichtbeleuchtungsanlage wird teilweise in recht kurzer Folge weitergereicht. So kommt es auch vor, dass der die Notlichtbeleuchtungsanlage installierende Elektro-Betrieb gelegentlich nur für die ersten Prüfungen hinzugezogen wird. Irgendwann wechseln viele Gebäudebetreiber dazu über, eine solche Aufgabe einem Verantwortlichen des Gebäudes, wie z. B. dem Hausmeister des Gebäudes, zu übertragen.
-
Das Know-How des Mitarbeiters des Elektrobetriebs, der die Notlichtbeleuchtungsanlage errichtet hat, geht dank der zentral verwalteten Daten - nahezu automatisch - auf den „neuen“ Verantwortlichen über.
-
Bei wechselnden Verantwortlichkeiten, wechselndem Personal und bei sich ändernden Personen, die die Prüfungen und Überwachungen der Notlichtbeleuchtungsanlage durchzuführen haben, ist ein Bedarf nach einer zentral angesiedelten Datenverwaltung erkannt worden.
-
Viele Notlichtbeleuchtungsinstallationen kleinerer Größe benötigen keinen permanenten Kontakt zu einer zentral angeordneten Datenbank, z. B. in der „cloud“. Diese Situation der Notlichtbeleuchtungsanlage kann als „normally not-connected“ zur zentral angeordneten Datenbank bezeichnet werden. Mit einem entsprechenden mobilen Gerät, wie einem Laptop oder wie einem Handy, ist dann die Verbindung zwischen Leuchten und ihrem Wireless-Kommunikationssystem auf der einen Seite und der Datenbank in der „cloud“ auf der anderen Seite leichter herzustellen.
-
Die Kommunikation in Richtung „cloud“ ist vorteilhafterweise so ausgelegt, dass es standardmäßig zwei Pfade in die „cloud“ gibt. Der eine Pfad in die „cloud“ ist herzustellen, wenn der die Notlichtbeleuchtungsanlage Wartende über sein mobiles Gerät eine Anbindung herstellt. Der zweite Pfad kann durch ein (dezidiertes) Schnittstellengerät hergestellt werden, das als Teil der Notlichtbeleuchtungsanlage installiert zu bestimmten Zeitpunkten einen Kontakt in die „cloud“ herstellt. So können auch bereits installierte Notlichtbeleuchtungsanlagen als sich selbständig mit der „cloud“ verbindende Notlichtbeleuchtungsanlagen umgebaut werden oder als Notlichtbeleuchtungsanlagen ausgestaltet werden, die eine Anbindung in die „cloud“ finden, wenn ein mobiles Kommunikationsgerät in den Nahbereich der Notlichtbeleuchtungsanlage gebracht wird.
-
Die Daten aus den Prüfbüchern der einzelnen Notlichtleuchten werden in einer „App“ eines mobilen Geräts oder in dem Schnittstellengerät zusammengefügt und dann in die „cloud“ transferiert. Die Daten sollen aber idealerweise in den einzelnen Leuchten erhalten bleiben. Ein Auslesen von Daten soll nicht zu deren Vernichtung in der Leuchte führen.
-
Die Prüfbücher sind überschreibbar, wenn ihre Speicherkapazität erreicht ist. Werden Leuchten entsprechend lange betrieben, so sind irgendwann dann einmal die ältesten Daten in dem Leuchten-Prüfbuch-Speicher zu überschreiben. Wenn der Speicher vollgeschrieben ist, sind die ältesten Daten (quasi zyklisch) zu löschen. Ein Auslesen von Daten sorgt aber idealerweise nicht für ein Zurücksetzen des Speichers.
-
Eine günstige Ausgestaltung einer möglichst kompakten App umfasst nur die Steueralgorithmen zur Erstellung der Darstellung der Notlichtbeleuchtungsanlage und ihrer Prüfbücher sowie die Datenbank mit den Daten aus den Prüfbücher und den Leuchten.
-
Die auf dem mobilen Gerät installierte App kann also als nahezu „nackte“ App ausgelegt sein. Die Daten zur Notlichtbeleuchtungsanlage befinden sich entweder in der „cloud“ oder auf den Notlichtleuchten. Wird eine Person mit einer entsprechenden App auf ihrem mobilen Gerät zu einer Notlichtbeleuchtungsanlage geschickt, so können die notwendigen Daten zur Beschreibung der Notlichtbeleuchtungsanlage entweder aus der „cloud“ oder vor Ort aus den einzelnen Prüfbüchern in die App hineingeladen werden.
-
Die App oder das Schnittstellengerät (mit einer entsprechenden App) dient als Sammelstelle für die Daten aus den einzelnen Prüfbüchern. Mit Hilfe der App ist das Anzeigegerät in der Lage, die gesamte Anlage darzustellen. Fehlende Daten können aus der „cloud“ bezogen werden, insbesondere in dem Fall, in dem Daten aus irgendwelchen Prüfbüchern nicht zur Verfügung stehen sollten. Das mobile Gerät mit der App übernimmt sozusagen die Funktion eines Relais bzw. einer Relais-Station.
-
Ein so aufgestelltes Prüfbuch- und Überwachungs- bzw. Wartungssystem einer Notlichtbeleuchtungsanlage kann auch als administratorloses System bezeichnet werden. Die Zugriffsrechte können von einem auf den nächsten zuständigen „vererbt“ werden. Übergibt ein Elektroinstallationsbetrieb den Datenzugriff auf eine Notlichtbeleuchtungsanlage an einen Hausmeister, so können diesem die höchsten Zugriffsrechte übergeben werden. Hat der Hausmeister weitere Hilfskräfte, z. B. ein Elektromonteur zur Wartung eines Teilbereichs oder nur für eine bestimmte Wartungsaufgabe, so kann diesem wiederum ein eingeschränkteres Zugriffsrecht eingeräumt werden. Die in der höchsten Stufe angesiedelte Person bzw. die Personen können Personen mit weniger Zugriffsrechten den weiteren Zugang entziehen. Aus diesem Grund ist ein personalisiertes Log-In auf die „cloud“-Daten ideal. Zur Weitergabe und zur Einräumung von Rechten gibt es ein Share- und Vererbungssystem. Ein Teil-Set aus Rechten kann geteilt werden („shared“). Die Übergabe von einer ersten Person auf eine zweite Person (z. B. Elektroinstallationsbetrieb auf Hausmeister) kann durch Vererbung erfolgen. Der Erblasser ist weg („gestorben“), der Erbe hat die gleichen, ggf. vollständigen Rechte wie der Erblasser.
-
Das mobile Kommunikatonsgerät kann sich ändern. Wird eine andere Person beauftragt, so bringt diese erfahrungsgemäß ihre eigenen mobilen Geräte mit. Daher ist es vorteilhaft, wenn die Daten zur jeweiligen Notlichtbeleuchtungsanlage nachgeladen werden können (z. B. aus der „cloud“). Daher sind die Zugriffsdaten und -rechte nicht auf einzelne Hardware(n) ausgerichtet, sondern das personalisierte Login erfolgt über Daten in einer Datenbank mit ID-Daten.
-
Im Gegensatz zu klassischen, sich aus Normen ergebenden Prüfbüchern, die nur die Daten von durchgeführten Tests archivieren, z. B. auf Papier ausdrucken sollen, schafft die vorliegende Verwaltung von Systemdaten die Möglichkeit, eine komplette Abbildung (im Sinne von zeitabhängigen Abbildern) einer Notlichtbeleuchtungsanlage zur Verfügung zu stellen. Diese Abbilder können im Nachhinein (z. B. über Zeitschieber) zu veränderbaren Zeitpunkten dargestellt und/oder nachvollzogen werden (zeitlich veränderbare Abbildung). Hierbei werden nicht nur die typischen Daten eines Prüfbuchs verwaltet, sondern auch Daten, die eine oder mehrere Konfigurationen von Leuchten sowie von kompletten Notlichtbeleuchtungsanlagen darstellen.
-
Hierbei können einzelne Abbildungen in Zustandsdatenpaketen gespeichert werden. Ein solches Zustandsdatenpaket kann mit einer kompletten Abbildung der Notlichtbeleuchtungsanlage zu einem Zeitpunkt gleichgesetzt werden. Idealerweise umfasst ein Zustandsdatenpaket alle Daten einer Notlichtbeleuchtungsanlage zu einem (ausgewiesenen) Zeitpunkt. Ein weiteres Zustandsdatenpaket gibt die Daten einer Notlichtbeleuchtungsanlage zu einem anderen Zeitpunkt wieder. Hierbei ist verständlich, dass Daten, die längere Zeit gleich bleiben, z. B. Daten von Konfigurationen, auch so im Datennetzwerk abgelegt werden können, dass sie mehreren Zustandsdatenpaketen zugeordnet werden können (komprimierte Datenspeicherung bzw. Datenkompression).
-
Das erfindungsgemäße Verfahren sowie das erfindungsgemäße System arbeiten mit untereinander vernetzten (Gebäudetechnik-)Komponenten, z. B. Leuchten, sodass nur zu einem Teil der Komponenten überhaupt eine Direktverbindung zwischen Kommunikationsgerät und Komponenten bestehen braucht. Durch die Komponenten, die eine Direktverbindung zu dem Kommunikationsgerät haben, besteht dann zugleich eine Verbindung des Kommunikationsgeräts zu der netzwerkartigen Notlichtbeleuchtungsanlage. Die Leuchten untereinander bilden (im Endeffekt) auch ein Netzwerk. Eine Datenübertragung aus den Leuchten geschieht durch dieses (zweite) Netzwerk. D. h., eine Kommunikation braucht nicht direkt zu erfolgen.
-
Vorteilhafterweise geschieht die Diagnose in jeder einzelnen Leuchte selbst, weil diese intern sowohl über die dafür benötigte Sensorik als auch über eine Auswerteintelligenz verfügt (z. B. einen zur Leuchten-Selbstdiagnose programmierten Microcontroller des Typs RX65N (Hersteller: „Renesas“). Eine solche Leuchte ist in der Lage, eventuelle Fehler „fix und fertig“ an das Kommunikationsgerät und somit in das Datennetzwerk zu melden.
-
Mit dem Datennetzwerk verbundene, d. h. zu einer Notlichtbeleuchtungsanlage gehörende Komponenten werden durch Netzwerkverschlüsselung gegen Zugriffe Dritter geschützt. Eine Steuerung und Konfiguration der Komponenten ist nur möglich, wenn der Schlüssel bekannt ist. Dieser kann durch Vererbung weitergegeben werden. In gleicher Weise können Daten nicht von einem beliebigen Lesegerät ausgelesen werden. Nur ein autorisierendes bzw. autorisiertes Kommunikationsgerät gibt ein Auslesen der Daten aus der Notlichtbeleuchtungsanlage frei.
-
Zu den Daten, die zu einem Zustandsdatenpaket zusammengefügt werden können, gehören solche Daten wie aktuelle Statusinformationen, aktuelle Fehlerinformationen, eine Statushistorie, eine Fehlerhistorie, eine Ereignishistorie und die (eigentlichen) Prüfbücher. Jede dieser Informationen kann auf eine einzelne Komponente, z. B. auf eine einzelne Leuchte bezogen sein und so verwaltet werden. Prüfbücher können sich zusätzlich auf Gruppen von Leuchten oder auch eine vollständige Notlichtbeleuchtungsanlage mit vielen Leuchten beziehen, indem sie dann die Informationen sämtlicher jeweils enthaltenen Komponenten (z. B. Leuchten) beinhalten.
-
Idealerweise ist jede Komponente, z. B. jede Leuchte durch eine unveränderliche Geräteadresse und optional durch eine von einem (dazu autorisierten) Benutzer frei eingebbare Kennung/Namensvergabe/Benennung eindeutig identifizierbar.
-
Mit einer solchen Verwaltung ist es möglich, die verwalteten Komponenten (z. B. Batterien, Steuerungselektronik, Leuchten, Messelektroniken, Spannungsüberwachungen etc.) hierarchisch in Gruppen zu ordnen und zu verwalten, wobei eine Gruppe außer Leuchten auch weitere Gruppen enthalten kann (Baum- oder Ordnerstruktur, vergleichbar einem Dateisystem mit Dateien auf einem Computer).
-
Darüber hinaus ist es vorteilhaft, wenn eine Gruppenbildung von Komponenten zur gruppenweisen Klassifikation, Markierung, Kennzeichnung oder Einstufung genutzt wird. Einer Gruppe wird ein Status zugeordnet (stets der „schlechteste“ oder „ungünstigste“ Status unter den Status aller enthaltenen einzelnen Elemente). Das bedeutet, der Status einer Gruppe ist grün („OK“, fehlerfrei), wenn alle Komponenten (Gruppen, Komponenten, Leuchten usw.) darin auch fehlerfrei sind; sobald eine Komponente wie Leuchte oder eine Gruppe den Status rot („Fehler“) hat, wird auch die beinhaltende Gruppe den Status „Fehler“ haben. Die Abbildung einer Notlichtbeleuchtungsanlage erhält in gleicher Weise den Status, der dem ungünstigsten Status aller enthaltenen Komponenten, Gruppen, Leuchten usw. entspricht. Die Abbildung ist mit „grün“ markiert, wenn kein Element einen Fehler aufweist. Auf diese Weise erlaubt das Verfahren die Anzeige vieler Abbildungen unterschiedlichster Notlichtbeleuchtungsanlagen zugleich. Außerdem ermöglicht diese Form der Abbildung das gezielte Auffinden eines einzelnen fehlerhaften Gerätes selbst in dem Fall, in dem nicht alle Gruppen zugleich bis auf Komponentenebene „ausgeklappt“ sind. Ein mit der Überwachung einer größeren Gruppe Notlichtbeleuchtungsanlagen beauftragter Nutzer (z. B. die Haustechnik von Messehallen wie in Frankfurt) muss nur die als fehlerhaft markierten Abbildungen suchen. Ein Nutzer muss in einer als fehlerhaft markierten Abbidlung nur noch gezielt in „rote“ Elemente hineinnavigieren, bis er bei einer einzelnen fehlerhaften Leuchte angekommen ist.
-
Vorteilhafterweise stellt das mobile Kommunikationsgerät (z. B. ein Smartphone, z. B. ein Tablet) ein automatisches Datenbackup her. Gehen das mobile Kommunikationsgerät und/oder darauf vorhandene Daten über eine Abbildung verloren, können diese aus der „cloud“-basierten Datenbank wahlweise sowohl auf dieses als auch auf ein anderes Kommunikationsgerät zurückgespielt werden. In ähnlicher Weise ist eine Weitergabe von Zugriffsberechtigungen an neue Kommunikationsgeräte, die entweder als Ersatz beschafft wurden oder die bei Übergabe bzw. Freigabe an eine weitere Personen für eine Verwaltung der Systemdaten der Notlichtbeleuchtungsanlage dienen sollen, möglich.
-
Idealerweise ist der Zugang zu Daten in das Datennetzwerk als auch der Zugang zu Abbildungen und deren Daten via mobilem Kommunikationsgerät an Zugangsberechtigungen (wie Benutzername und/oder wie Passwort) gekoppelt. Diese Daten (Zugangsberechtigungen wie Benutzername und/oder wie Passwort) werden vorteilhafterweise ebenfalls im Datennetzwerk verwaltet.
-
Zu den Daten, die über typische Daten für ein Prüfbuch hinausgehen, gehören solche Daten wie
- • Temperaturwerte einer oder mehrerer Leuchten,
- • Zustand eines Akkumulators (z. B. in einer Leuchte),
- • Betriebszeiten einer Leuchte durch oder während eines „Akkumulator-backup“,
- • Betriebsstundenzähler,
- • Dimmwerte,
- • Helligkeitswerte,
- • Dimmungsdauern,
- • zeitabhängige Dimmungsprofile,
- • Versionsnummer einer Software,
- • Versionsnummer einer Hardware,
- • Netzüberwachungen innerhalb und an einer Leuchte,
- • Betriebsart einer Leuchte (z. B. ob sie als Dauerlichtleuchte betrieben wurde) und
- • Schaltbefehle an einzelne Leuchten (z. B. zur Umstellung von einem ersten Piktogramm auf ein zweites Piktogramm).
-
Dank der erfindungsgemäßen Verwaltung von Systemdaten ist es auch möglich, jederzeit ein Backup auf jede der Leuchten sowie jede der Komponenten zurückzuspielen.
-
Die Daten, aus denen Zustandsdatenpakete gebildet werden können, können sich aus sensorischen und nicht-sensorischen Daten zusammensetzen.
-
Figurenliste
-
Die vorliegende Erfindung kann noch besser verstanden werden, wenn Bezug auf die beiliegende Figur genommen wird, die beispielhaft eine besonders vorteilhafte Ausgestaltungsmöglichkeit darlegt, ohne die vorliegende Erfindung auf diese einzuschränken, wobei
- 1 ein erstes Ausführungsbeispiel einer Notlichtbeleuchtungsanlage mit Anbindung an die „cloud“ zeigt.
-
Figurenbeschreibung
-
1 zeigt eine Notlichtbeleuchtungsanlage mit Anbindung an die „cloud“.
-
Detailreicher ausgeführt zeigt 1 ein System 1 zur Verwaltung von Daten einer Notlichtbeleuchtungsanlage 6. Die Notlichtbeleuchtungsanlage 6 gehört zu einem Gebäude 2, das mehrere Räume wie den (symbolisch dargestellten) Gebäuderaum 4 aufweist. In dem Gebäude 2 befindet sich ein Gebäudeleitsystem, dass unter anderem eine Zentralsteuerung 8 für die Notlichtbeleuchtungsanlage 6 bildet. Die Notlichtbeleuchtungsanlage 6 umfasst eine erste Rettungszeichenleuchte 10, eine zweite Rettungszeichenleuchte 12, eine dritte Rettungszeichenleuchte 14, eine vierte Rettungszeichenleuchte 16, eine Dauerlichtleuchte 18 sowie eine Sicherheitsleuchte 20. Die erste Rettungszeichenleuchte 10 zeigt ein erstes Piktogramm 24 infolge eines Fluchtwegsindikators. Die zweite Rettungszeichenleuchte 12 zeigt ein zweites Piktogramm 26 in Reaktion auf einen Fluchtwegsindikator, wobei das zweite Piktogramm 26 in eine andere Richtung weist als das erste Piktogramm 24. Die dritte Rettungszeichenleuchte 14 zeigt ein drittes Piktogramm 28, das eine Wegsperrung kenntlich macht. Die vierte Rettungszeichenleuchte 16 zeigt ebenfalls eine Wegsperrung an. Bei der vierten Rettungszeichenleuchte 16 handelt es sich um eine Leuchte, die nachträglich in die Notlichtbeleuchtungsanlage 6 integriert wurde. Außerdem hat die Notlichtbeleuchtungsanlage 6 eine Dauerlichtleuchte 16 und eine Sicherheitsleuchte 20.
-
Die Leuchten 10, 12, 14, 16, 18, 20 sind jeweils mit einem Transponder 29 ausgestattet, der sich im Inneren der Leuchten 10, 12, 14, 16, 18, 20 (also von außen nicht zu sehen) befindet. Mit Hilfe des Transponders 29 können die Leuchten 10, 12, 14, 16, 18, 20 Funksignale empfangen sowie Funksignale aussenden.
-
Die Notlichtbeleuchtungsanlage 6 hat einen Repeater 48, mit dem Zustandsdatenpakete von der zweiten Rettungszeichenleuchte 12 sowie von der Sicherheitsleuchte 20 zur ersten Rettungszeichenleuchte 10 weiterleitbar sind. Der Repeater 48 dient unter anderem dazu, Signale in das Datennetzwerk 50 weiterzuleiten, um auf diese Weise Entfernungen zu überbrücken und ggf. Abschirmungen oder Störungsquellen zu umgehen. Der Repeater 48 hat eine höhere Sendeleistung als zumindest einige der Rettungszeichenleuchten der Notlichtbeleuchtungsanlage 6, wie die erste Rettungszeichenleuchte 10. In der Notlichtbeleuchtungsanlage 6 sind mehrere Datenübertragungskanäle 30, 32, 34, 36, 38, 40, 41, 42, 43, 44, 45, 46, 47 vorhanden.
-
Ein mobiles Kommunikationsgerät 54 hat ein Display 56, das eine erste visuelle Ausgabeeinheit 58 für über Datenübertragungskanäle, wie z. B. den Datenübertragungskanal 30, empfangene Daten darstellt. Das mobile Kommunikationsgerät 54 kann Daten auf dem Datenübertragungskanal 30 mit der ersten Rettungszeichenleuchte 10 austauschen. Das mobile Kommunikationsgerät 54 kann auf einem Kommunikationskanal 32 Daten mit einer vierten Rettungszeichenleuchte 16 austauschen. Das mobile Kommunikationsgerät 54 kann (darüber hinaus) auch Daten zu der Zentralsteuerung 8 senden.
-
Genauso kann das Kommunikationsgerät 54 von der Zentralsteuerung 8 Daten empfangen. Außerdem ist das mobile Kommunikationsgerät 54 ein Interface für eine Kommunikation über einen Datenübertragungskanal 36 mit dem externen Datennetzwerk 50.
-
Eine Kommunikation mit dem externen Datennetzwerk 50 erfolgt über einen Router 70. Außerdem sind in das externe Datennetzwerk 50 ein Datenserver 68, eine Arbeitsstation 62 sowie ein Netzwerkdatenspeicher 52 eingebunden. Eine Steuersoftware 72 dient unter anderem dazu, Zustandsdatenpakete in einen Datensatz auf dem Netzwerkdatenspeicher zu integrieren bzw. Zustandsdaten z. B. einer Arbeitsstation 62 oder einem mobilen Kommunikationsgerät 54 bereitzustellen. Die Arbeitsstation 62 dient als zweite visuelle Ausgabeeinheit 64. Außerdem ist die Arbeitsstation 62 eine zweite Eingabeeinheit 66, mit der Steuerbefehle an die Notlichtbeleuchtungsanlage 6 geschickt sowie Zustandsdaten von der Notlichtbeleuchtungsanlage 6 empfangen werden können.
-
Der Datenserver 68 ist über eine Datenleitungsverbindung 84 an eine Datenleitungsverbindung 82 der Zentralsteuerung 8 angeschlossen. Zustandsdaten der Notlichtbeleuchtungsanlage 6 sind von der vierten Rettungszeichenleuchte 16 über den Datenübertragungskanal 40 auf die erste Rettungszeichenleuchte 10 und von der ersten Rettungszeichenleuchte 10 über den Datenübertragungskanal 38 auf den Router 70 übertragbar, der unter anderem Daten zur Arbeitsstation 62 sowie Daten über den Datenserver 68 zum Netzwerkdatenspeicher 52 weiterleitet. Zustandsdaten der Notlichtbeleuchtungsanlage 6 können von der zweiten Rettungszeichenleuchte 12 über den Datenübertragungskanal 44 zu dem Repeater 48 und von dem Repeater 48 über den Datenübertragungskanal 46 zu dem Router 70 geleitet werden. Die dritte Rettungszeichenleuchte 14 kommuniziert über den Datenübertragungskanal 42 mit der ersten Rettungszeichenleuchte 10. Zustandsdaten der dritten Rettungszeichenleuchte und Zustandsdaten der vierten Rettungszeichenleuchte sind zusammen mit Zustandsdaten der ersten- 10 und der zweiten Rettungszeichenleuchte 12 und Zustandsdaten der Sicherheitsleuchte 20 sowie Zustandsdaten aus dem mobilen Kommunikationsgerät 54 von der ersten Rettungszeichenleuchte 10 zum Router 70 übertragbar. Hierbei handelt es sich um ein Zustandsdatenpaket. Damit wird eine besondere Übertragungssicherheit erzielt. Auch die Dauerlichtleuchte 18 und die Sicherheitsleuchte 20 sind über Datenübertragungskanäle 45 bzw. 43, 46, 41 in das Datenübertragungsnetzwerk der Notlichtbeleuchtungsanlage 6 eingebunden. Außerdem ist die Zentralsteuerung 8 über die Datenübertragungsverbindung 47 per Funk mit der Cloud 50 bzw. Datencloud 50 verbunden.
-
Die in der einzigen Figur gezeigte Ausgestaltungsmöglichkeit lässt sich auch mit weiteren Ausführungen aus der allgemeinen Erfindungsbeschreibung in beliebiger Form verbinden.
-
Z. B. ist es möglich, mit weiteren mobilen Kommunikationsgeräten, sobald sie sich im Einflussbereich der Notlichtbeleuchtungsanlage 6 befinden, eine zweite, dritte oder vierte Verbindung in das Datennetzwerk 50 herzustellen.
-
Bezugszeichenliste
-
- 1
- System zur Verwaltung von Daten einer Notlichtbeleuchtungsanlage
- 2
- Gebäude
- 4
- Gebäuderaum
- 6
- Notlichtbeleuchtungsanlage
- 8
- Zentralsteuerung, insbesondere Gebäudeleitsystem
- 10
- erste Rettungszeichenleuchte
- 12
- zweite Rettungszeichenleuchte
- 14
- dritte Rettungszeichenleuchte
- 16
- vierte Rettungszeichenleuchte
- 18
- Dauerlichtleuchte
- 20
- Sicherheitsleuchte
- 24
- erstes Piktogramm
- 26
- zweites Piktogramm
- 28
- drittes Piktogramm
- 29
- Transponder
- 30
- Datenübertragungskanal, insbesondere Leuchtenabfragekanal
- 32
- Datenübertragungskanal, insbesondere Erweiterungskanal
- 34
- Datenübertragungskanal, insbesondere Zentralsteuerungskanal
- 36
- Datenübertragungskanal, insbesondere mobiler Cloudverbindungskanal
- 38
- Datenübertragungskanal, insbesondere Notlichtleuchtendatenkanal zur Cloud
- 40
- Datenübertragungskanal, insbesondere Erweiterungskanal
- 41
- Datenübertragungskanal, insbesondere Repeaterverbindungskanal zur ersten Notlichtleuchte
- 42
- Datenübertragungskanal, insbesondere Leuchtenabfragekanal
- 43
- Datenübertragungskanal, insbesondere Leuchtenabfragekanal über Repeater
- 44
- Datenübertragungskanal, insbesondere Leuchtenabfragekanal über Repeater
- 45
- Datenübertragungskanal, insbesondere Leuchtenzustandsdatenübertragungskanal zur Cloud
- 46
- Datenübertragungskanal, insbesondere Repeaterverbindungskanal zur Cloud
- 47
- Datenübertragungskanal, insbesondere Datenübertragungsverbindung zwischen Cloud und Zentralsteuerung, vorzugsweise Funkverbindung
- 48
- Repeater
- 50
- Datennetzwerk, insbesondere Datencloud
- 52
- Netzwerkdatenspeicher, insbesondere Systemdatenspeicher
- 54
- mobiles Kommunikationsgerät, insbesondere Tablet
- 56
- Display
- 58
- erste visuelle Ausgabeeinheit
- 60
- erste Eingabeeinheit
- 62
- Arbeitsstation
- 64
- zweite visuelle Ausgabeeinheit
- 66
- zweite Eingabeeinheit
- 68
- Datenserver
- 70
- Router
- 72
- Steuersoftware
- 80
- Funksignal
- 82
- Datenleitungsverbindung
- 84
- Datenleitungsverbindung
