-
Die Erfindung betrifft ein Verfahren zur Steuerung eines Netzwerkknotens, ein System mit mehreren Netzwerkknoten sowie einen einzelnen Netzwerkknoten zur Verwendung in einem solchen System.
-
Unter einem Netzwerkknoten wird dabei ein einzelner Rechner verstanden, der Programme ausführen und über eine Kommunikationsverbindung mit anderen Netzwerkknoten kommunizieren kann. Mindestens einzelne der Netzwerkknoten sind dabei durch Rahmenbedingungen insbesondere hinsichtlich Leistungsaufnahme, Baugröße und Kosten beschränkt (constrained environments), so dass entsprechend begrenzte Rechenleistung und Speichergrößen zur Verfügung stehen. Die Netzwerkknoten oder auch die gesamten hieraus gebildeten Netzwerke bilden bevorzugt eingebettete Systeme (embedded systems). Sie können verwendet werden bspw. im Bereich der Automation zur Ausführung von Überwachungs-, Steuerungs- oder Regelfunktionen.
-
Derartige Netzwerkknoten und hieraus gebildete Netzwerke sind bspw. bekannt in Form von drahtlosen Sensornetzwerken.
-
US 2010/0205596 A1 beschreibt ein drahtloses Sensornetzwerk mit einer Anzahl von Sensorknoten die jeweils dazu in der Lage sind, Informationen zur Erkennung von Objekten oder Informationen über Umgebungsbedingungen zu ermitteln und in Echtzeit über ein Netzwerk zu übermitteln. Um die Firmware der Knoten zu erneuern, überträgt ein Gateway erneuerte Firmware über eine RS232C-Schnittstelle an einen Knoten, die sequentiell an eine Mehrzahl von Knoten weitergeleitet wird. Die jeweiligen Knoten speichern die Firmware im Speicher und führen einen Neustart aus, wobei Boot-Programme die erneuerte Firmware ausführen.
-
US 8,204,971 B2 beschreibt Systeme und Verfahren zur Steuerung von Sensornetzwerken mit einer Mehrzahl von Sensorknoten, die Sensoren zur Überwachung von Betriebsparametern und drahtlose Kommunikationsmodule aufweisen. Ein Benutzer kann auf einfache Weise dynamisch das Verhalten jedes Netzwerkknotens konfigurieren oder rekonfigurieren ohne physikalischen Zugriff auf den Knoten zu haben. Ein Koordinator-Netzwerkknoten kann verschiedene Aspekte des Netzwerks koordinieren oder steuern, bspw. einen Sensorknoten dazu anweisen, ein Relais in Abhängigkeit von einem bestimmten Ereignis zu aktivieren. Der Koordinatorknoten ist mit einem Host verbunden. Der Host konfiguriert den Koordinatorknoten entsprechend der vorgesehenen Nutzung des Netzwerks. Ein Teil der Logik des Koordinatorknotens kann durch ein oder mehrere Skripte implementiert sein, die ohne Kompilierung ausgeführt werden können. Bspw. kann eines der Skripte verwendet werden, um auf ein bestimmtes Ereignis zu reagieren. In einer beispielhaften Ausführungsform werden Skripte vom Koordinatorknoten heruntergeladen. Bspw. kann ein Benutzer ein Skript herunterladen, das bei Ausführung dem Koordinatorknoten ermöglicht, einen Aspekt des Netzwerks zu kontrollieren. Der Benutzer kann auch angeben, wann das Skript ausgeführt werden soll.
-
Jeder der Sensorknoten kann vom Koordinatorknoten konfiguriert werden. Der Koordinatorknoten kann Skripte und/oder Daten übermitteln. Um das System zu rekonfigurieren, kann der Benutzer von einem zentralen Ort ohne physikalischen Zugriff auf die Knoten über den Host neue Skripte an den Koordinatorknoten übermitteln. Wenn gewünscht, können Skripte an die Sensorknoten übermittelt und dort ausgeführt werden.
-
Die
US 8,438,250 beschreibt Systeme und Verfahren zur Erneuerung von Skript-Abbildern (script images) in drahtlosen Sensornetzwerken. Ein drahtloses Netzwerk umfasst eine Mehrzahl von Knoten. Durch das Erstellen und Hochladen von Skripten an verschiedene Knoten kann ein Benutzer das Netzwerk dynamisch rekonfigurieren. Jeder Knoten des Netzwerks umfasst einen Network Stack und eine virtuelle Maschine. In einem Beispiel ist die virtuelle Maschine als Bytecode Interpreter ausgeführt. Ein script image umfasst durch die virtuelle Maschine ausführbaren Bytecode. Die Kernfunktionen eines Netzwerkknotens sind in der Sprache C geschrieben und das script image ist in der Sprache Python geschrieben. Wenn ein Benutzer eine bestimmte Funktion ausführen möchte, kann er ein Quellskript schreiben zur Ausführung durch einen Netzwerkknoten. Ein herkömmlicher Quellparser parst, kompiliert und tokenisiert das Quellskript, um ausführbaren Bytecode zu erzeugen.
-
Es kann als eine Aufgabe der Erfindung angesehen werden, ein System und ein Verfahren sowie einen Netzwerkknoten vorzuschlagen, mit dem ein besonders flexibler Aufbau von Netzwerken insbesondere für Automationsaufgaben möglich ist.
-
Diese Aufgabe wird gemäß einem ersten Aspekt der Erfindung gelöst durch ein Verfahren nach Anspruch 1, ein System nach Anspruch 7 und einen Netzwerkknoten hierfür nach Anspruch 11. Gemäß einem alternativen Aspekt der Erfindung wird die Aufgabe weiter gelöst durch ein Verfahren gemäß Anspruch 12.
-
Die Verwendung von Skripten zur Ausführung auf Netzwerkknoten ist an sich bekannt, ebenso wie zu Konfigurationszwecken die Übermittlung derartiger Skripte von einem Netzwerkknoten an einen anderen Netzwerkknoten. Von solchen bekannten Netzwerken, Knoten und Verfahren unterscheidet sich der erste Aspekt der Erfindung (Ansprüche 1, 7 und 11) dadurch, dass einem Netzwerkknoten nicht ein vollständiges Funktionsskript übermittelt wird, das ein vorheriges Funktionsskript überschreibt und ersetzt, sondern dass ein Skript-Fragment, d. h. ein Teil eines Funktionsskripts übermittelt wird, das ein bestehendes Funktionsskript zu dessen Laufzeit modifiziert. Gemäß dem zweiten Aspekt der vorliegenden Erfindung (Anspruch 12) findet die Übertragung eines Skripts bei Wahrnehmung einer Überwachungs-, Steuer- oder Regelfunktion statt, nämlich in Abhängigkeit von einem Sensorwert. Wie insbesondere im Zusammenhang mit den bevorzugten Ausführungen deutlich wird, unterscheidet sich die somit vorgeschlagene Verwendung von Skripten deutlich von der Übermittlung von Skripten zur Konfiguration eines Systems in einer Konfigurationsphase und kann insbesondere während der Betriebsphase des Systems verwendet werden. Die beiden Aspekte der Erfindung sind dabei vorteilhaft miteinander kombinierbar.
-
Bei dem Verfahren, dem System und dem Knoten gemäß dem ersten Aspekt der Erfindung sind mindestens ein erster und ein zweiter Netzwerkknoten vorgesehen, die über eine Kommunikationsverbindung verbunden sind. Wie oben erläutert stellt jeder Netzwerkknoten einen eigenständigen Rechner dar mit Speicher, Zentraleinheit und Kommunikationsschnittstelle sowie optional mit Ankopplung an einen Sensor und/oder Aktor. Die Netzwerkknoten sind bevorzugt räumlich verteilt, d. h. im Abstand angeordnet. Die Kommunikationsverbindung ist bevorzugt eine drahtlose oder drahtgebundene digitale Datenverbindung nach beliebigem Protokoll.
-
Der erste Netzwerkknoten führt ein Funktionsskript aus. Hierunter wird ein Skript verstanden, das die Funktion des ersten Netzwerkknotens bspw. in Form einer Steuer-, Regelungs- oder Überwachungsfunktion definiert, also insbesondere bevorzugt die Verarbeitung von Eingangswerten (bspw. Sensorwerten) und Ausgabe von Ausgabewerten (bspw. zur Ansteuerung eines Aktors) umfasst. Das Funktionsskript definiert die Funktion des ersten Netzwerkknotens in der Betriebsphase des Systems, d. h. wenn – je nach Einsatzzweck – die betreffende Regel-, Steuer- oder Überwachungsfunktion ausgeführt wird.
-
Das Funktionsskript ist in einer Skript-Sprache verfasst und wird durch den ersten Netzwerkknoten ausgeführt, bspw. mittels eines Interpreters oder Echtzeit-Compilers (Just-In-Time-Compiler). Dabei wird unter einem Interpreter eine durch ein Programm realisierte Funktionalität verstanden, die Skript-Kommandos, sei es Quelltext oder in Token-Form ausführt, indem diese zur Laufzeit eingelesen werden. Wie dem Fachmann bekannt ist, kann dies verschiedene einzelne Programm-Elemente und Einzelschritte umfassen, bspw. einen Tokenizer, mit dem Skript-Quelltext zunächst in Tokens umgewandelt wird, die anschließend ausgeführt werden.
-
Erfindungsgemäß übermittelt der zweite Netzwerkknoten in der Betriebsphase, also während der Ausführung des Funktionsskripts am ersten Netzwerkknoten, an diesen ein Skript-Fragment. Ein Skript-Fragment kann ein einzelner Skript-Befehl oder eine Gruppe von Skript-Befehlen sein, bspw. Skript-Befehle zur Definition einer oder mehrerer aufrufbarer Funktionen (wobei der Begriff „aufrufbare Funktion” in diesem Zusammenhang Bezug nimmt auf die Verwendung in Programmiersprachen, also vordefinierte Befehlsfolgen, die ggf. mit Parametern aufgerufen werden und einen oder mehrere Rückgabewerte liefern können).
-
Das Skript-Fragment dient erfindungsgemäß zur Modifikation des Funktionsskripts des ersten Netzwerkknotens. Bspw. kann es dieses ergänzen, ebenso aber auch in Teilen überschreiben oder Teile davon löschen oder neu definieren. Die Modifikation kann erfolgen, indem der erste Netzwerkknoten das Skript-Fragment ausführt, woraufhin dieses die Modifikation vornimmt. Ebenso kann die Modifikation auch anderweitig, bspw. durch ein übergeordnetes Betriebsprogramm des ersten Netzwerkknotens erfolgen, das automatisch das Skript-Fragment dem Funktionsskript hinzufügt bzw. die Modifikation ausführt.
-
Im Gegensatz zu bekannten Update-Mechanismen wird das Funktionsskript dabei während seiner Laufzeit durch das Skript-Fragment modifiziert. Dabei erfolgt wie erläutert keine vollständige Ersetzung, sondern das Funktionsskript bleibt bevorzugt bis auf die vorgenommene Modifikation unverändert und läuft weiter.
-
Durch die erfindungsgemäße Modifikation zur Laufzeit wird ermöglicht, dass durch das Skript-Fragment Steuerfunktionen ausgeführt werden, also bspw. die Übermittlung von Werten, Steuerkommandos etc.. Die Skript-Fragmente können also so genutzt werden, dass sie nicht den Zweck einer einmaligen oder gelegentlichen (Um-)Konfiguration erfüllen, sondern Teil der eigentlichen Funktion des Gesamtsystems zur Laufzeit während der Betriebsphase sind. So kann bspw. eine Schaltfunktion auf dem ersten Netzwerkknoten dadurch ausgelöst werden, dass der zweite Netzwerkknoten ein Skript-Fragment übermittelt, das das Funktionsskript des ersten Netzwerkknotens so modifiziert, dass die Schaltfunktion ausgeführt wird.
-
Das Verhalten des Systems kann hierdurch sehr flexibel gestaltet werden.
-
Gemäß einer Weiterbildung der Erfindung erfolgt die Modifikation des Funktionsskripts derart, dass das Skript-Fragment eine aufrufbare Funktion definiert, die durch das Funktionsskript aufgerufen wird. Dabei kann das Skript-Fragment bspw. aus der aufrufbaren Funktion selbst bestehen, so dass eine Installationsroutine am ersten Netzwerkknoten nach Erhalt des Skript-Fragments die so definierte Funktion installiert, d. h. aufrufbar bereitstellt. Besonders bevorzugt ist allerdings eine Implementierung, bei der das Skript-Fragment vom ersten Netzwerkknoten direkt ausgeführt wird und dabei zur Bereitstellung der aufrufbaren Funktion führt. So ist eine spezielle Installationsroutine auf Seiten des ersten Netzwerkknotens nicht notwendig, sondern der erste Netzwerkknoten führt einfach den jeweils von anderen Netzwerkknoten übermittelten Code aus, im vorliegenden Kontext das Skript-Fragment.
-
Die Übermittlung eines Skript-Fragments lässt sich besonders gut und flexibel dazu nutzen, Sensor-Werte, hiervon abgeleitete Werte oder hierauf basierende Ereignisse (bspw. Über- /Unterschreitung einer Schwelle) über das Netzwerk zu signalisieren. Gemäß einer entsprechenden Weiterbildung der Erfindung ist der zweite Netzwerkknoten mit mindestens einem Sensor für eine physikalische Größe verbunden. Das Skript-Fragment kann nun in Abhängigkeit von mindestens einem von dem Sensor gelieferten Wert erstellt werden, bspw. automatisch generiert oder aus einer Anzahl von vordefinierten Skript-Fragmenten ausgewählt.
-
Hierdurch sind Steuer- und Regelungsfunktionen besonders einfach implementierbar. Bspw. zur Signalisierung eines aktuellen Sensor-Wertes kann der zweite Netzwerkknoten den Sensorwert auslesen und ein Skript generieren, das den so ausgelesenen Sensorwert enthält. Das generierte Skript kann dabei auch eine weitere Verarbeitung des Wertes vorsehen, bspw. einen von einem oder mehreren Sensorwerten abhängigen Wert berechnen, den Wert auf Über-/Unterschreitung einer Schwelle prüfen und abhängig von Ergebnissen hiervon Aktionen auslösen oder Steuervorgaben machen. Das so generierte Skript kommt allerdings bevorzugt erst nach Übermittlung zum ersten Netzwerkknoten dort zur Ausführung.
-
Wie nachfolgend im Hinblick auf den zweiten Aspekt der Erfindung näher erläutert wird, kann der Grundgedanke der Erstellung bzw. Auswahl eines Skripts abhängig von Sensor-Werten und Übermittlung des Skripts an einen anderen Netzwerkknoten zur Ausführung auch generell, unabhängig von der Verwendung Skript-Fragmenten, erhebliche Vorteile hinsichtlich der Flexibilität und Konfigurierbarkeit eines Systems bieten.
-
Gemäß dem zweiten Aspekt der Erfindung umfasst ein System analog zum ersten Aspekt zwei oder mehr Netzwerkknoten, bzw. werden diese Netzwerkknoten in einem Steuerverfahren verwendet. Dabei ist mindestens einer der Netzwerkknoten erfindungsgemäß mit einem Sensor für eine physikalische Größe verbunden.
-
Abhängig von einem Sensorwert wird am zweiten Netzwerkknoten ein Skript bereitgestellt. Dies kann bspw. erfolgen, indem das Skript automatisch generiert wird. Das Generieren eines Skriptes kann bspw. auf Basis von einer oder mehreren Skript-Vorlagen erfolgen, wobei in dort vorgesehene Platzhalter der Sensorwert oder von dem Sensorwert abhängige Werte bzw. Anweisungen eingesetzt werden. Das Skript kann alternativ auch bereitgestellt werden durch Auswahl unter einer Anzahl von vorhandenen Skripten, wobei die Auswahl abhängig vom Sensorwert erfolgt. Weiter kann die Bereitstellung des Skriptes auch erfolgen durch Abruf eines Skriptes über das Netzwerk, d. h. von einem anderen Netzwerkobjekt, sofern auch dies in Abhängigkeit vom Sensorwert erfolgt.
-
In jedem Fall ist das so bereitgestellte Skript abhängig vom Sensorwert, d. h. es kann bspw. den Sensorwert oder einen daraus abgeleiteten Wert enthalten, oder aber abhängig von dem Sensorwert verschiedene Steuervorgaben machen.
-
Bei dem Skript kann es sich um ein umfassendes Funktionsskript, ebenso aber auch um einen einzelnen Skript-Funktionsaufruf oder um ein Skript-Fragment zur Modifikation eines Funktionsskriptes handeln.
-
Das so bereitgestellte Skript wird an den ersten Netzwerkknoten übermittelt und dort ausgeführt.
-
Wie im Zusammenhang mit bevorzugten Ausführungsformen genauer erläutert wird, können durch die Übertragung und entfernte Ausführung von Skripten, die von mindestens einem Sensorwert abhängen, auf sehr vorteilhaft flexible Weise Steuer- und Regelungsfunktionen ausgeführt werden.
-
Eine Anzahl von Weiterbildungen betreffen beide Aspekte der Erfindung. Gemäß einer Weiterbildung umfasst das System bzw. Verfahren einen Aktor-Sensorknoten, der mit mindestens einem Aktor zur Vorgabe einer physikalischen Größe verbunden ist und zu der Ansteuerung des Aktors vorgesehen ist. Bei dem Aktor-Sensorknoten kann es sich um einen der Sensorknoten der Systeme gemäß beider Aspekte der Erfindung wie oben beschrieben handeln, d. h. sowohl der dort jeweils beschriebene erste als auch zweite Netzwerkknoten kann die Rolle eines solchen Aktor-Sensorknotens einnehmen. Ebenso kann der Aktor-Sensorknoten ein zusätzlicher Sensorknoten des Systems sein.
-
Die Ansteuerung des Aktor-Sensorknotens erfolgt gemäß der Weiterbildung dadurch, dass von einem anderen Sensorknoten (wiederum kann es sich hierbei um einen der oben bereits beschriebenen Knoten handeln oder alternativ um einen zusätzlichen Knoten) ein Skript (dies umfasst vollständige Funktionsskripte, Skript-Fragmente oder auch nur einzelne Skript-Funktionsaufrufe) übermittelt wird. Dieses Skript wird auf dem Aktor-Sensorknoten ausgeführt. Bei der Ausführung des Skriptes erfolgt eine Ansteuerung des Aktors.
-
Die Verwendung von Skripten ermöglicht im Gegensatz zur Übermittlung von einfachen Vorgabewerten oder Einzelkommandos eine sehr flexible Steuerung, bspw., je nach Ausgestaltung des Skripts, auch bedingte Ansteuerungen (wenn-dann-Anweisungen), wiederholte Ansteuerungen (Schleifen), Kommunikation mit weiteren Netzwerkknoten etc.. Vor allem ist zur Ansteuerung auf dem Aktor-Sensorknoten zunächst keine dezidierte Software erforderlich, sondern diese wird in Form des Ansteuer-Skripts von einem anderen Netzwerkknoten übermittelt, was eine dynamische Konfiguration ermöglicht.
-
Eine andere Weiterbildung der Erfindung in beiden Aspekten ist der auch separat verwendbare Gedanke von Skripten, die in umgebenden Skripten eingebettet sind, was als „Nesting” bezeichnet werden kann. In einer Ausführung kann ein Netzwerkknoten ein erstes (äußeres) Skript an einen Mittler-Netzwerkknoten übermitteln (auch hier umfasst der Begriff Skript sämtliche ausführbaren Skripte inklusive Skript-Fragmenten und einzelnen Skript-Funktionsaufrufen). Der Mittler-Netzwerkknoten ist auch hierbei eine Rolle, d. h. jeder der vorbeschriebenen Netzwerkknoten oder ein zusätzlicher Netzwerkknoten kann diese Rolle übernehmen. Der Mittler-Netzwerkknoten führt das erste (äußere) Skript aus. Dieses ist so aufgebaut, dass es bei der Ausführung ein zweites (inneres) Skript an einen weiteren Netzwerkknoten übermittelt.
-
Das Konzept des „Nesting” kann flexibel eingesetzt werden, insbesondere um unter Zwischenschaltung des Mittler-Netzwerkknotens einen oder mehrere weitere Netzwerkknoten zu erreichen. Bspw. kann das erste (äußere) Skript so ausgebildet sein, dass es bei seiner Ausführung mehrere zweite (innere) Skripte an verschiedenen Netzwerkknoten übermittelt. Ebenso können das Ziel oder der Inhalt des zweiten Skripts von Bedingungen abhängig gemacht werden, die bei der Ausführung des ersten (äußeren) Skripts überprüft werden.
-
Besondere Vorteile bietet das Nesting-Konzept bei der Überwindung von Protokollgrenzen. Wird das erste Skript über eine Kommunikationsverbindung nach einem ersten Kommunikationsprotokoll und das zweite Skript über eine Kommunikationsverbindung nach einem zweiten, hiervon verschiedenen Kommunikationsprotokoll übermittelt, kann mit Hilfe derart eingebetteter Skripte sehr einfach eine Multiprotokoll-Fähigkeit erreicht werden.
-
Ein genereller Gedanke der hier vorgestellten Verfahren und Systeme, der für beide Aspekte der Erfindung verwendet werden kann, ebenso aber auch separat verwendbar ist, ist die Unterteilung von Netzwerkknoten in verschiedene Knotenklassen mit unterschiedlicher Leistungsfähigkeit. Als bevorzugte Knotenklassen können Smart Nodes, Clever Nodes und Primitive Nodes definiert sein. Netzwerkknoten dieser drei Knotenklassen sind jeweils in der Lage, Skripte oder mindestens einzelne Skript-Befehle bzw. Skript-Funktionsaufrufe auszuführen. Netzwerkknoten völlig anderen Typs, ohne die Fähigkeit zum Ausführen von Skripten oder Skript-Funktionsaufrufen, können als Alien Nodes zusätzlich vorhanden sein, die bspw. über ein Gateway angesprochen werden können. Bevorzugt umfasst ein System jeweils einen oder mehrere Netzwerkknoten jeder der drei Klassen (Smart Nodes, Clever Nodes, Primitive Nodes).
-
Die verschiedenen Knotenklassen sind durch ihre Funktion voneinander abzugrenzen. Primitive Nodes verfügen über die Möglichkeit, einzelne Skript-Befehle in Form jeweils eines einzelnen Skript-Funktionsaufrufs auszuführen. Sie können keine komplexen Skripte ausführen, also bspw. keine Schleifen, Funktionsdefinitionen, etc.. Primitive Nodes können bspw. nur über einen Einzelzeilen-Interpreter zur Ausführung einzelner Funktionsaufrufe verfügen.
-
Clever Nodes unterscheiden sich hiervon durch die Fähigkeit, komplexe Skripte auszuführen. Hierfür ist auf Clever Nodes ein Interpreter oder Echtzeit-Compiler (JIT, Just-in-time compiler) vorhanden, bevorzugt als virtuelle Maschine. Clever Nodes weisen dabei keine grafische Benutzeroberfläche auf, sondern verfügen allenfalls über nicht-grafische Ausgabemöglichkeiten, bspw. eine Text-Konsole.
-
Smart Nodes hingegen verfügen über eine grafische Benutzeroberfläche (GUI) und die Möglichkeit zur Ausführung von komplexen Skripten.
-
In derzeit bevorzugten Ausführungen unterscheiden sich die Knotenklassen hinsichtlich der Leistungsfähigkeit der gewählten Hardware, also bspw. Rechenleistung und Speichergröße. Smart Nodes verfügen i. d. R. über hohe Rechenleistung und Speichergröße. Clever Nodes verfügen im Vergleich meist über begrenzte Rechenleistung und Speichergröße. Primitive Nodes können bereits mit geringer Rechenleistung und Speichergröße realisiert sein. Die in einem konkreten System jeweils verwendete Hardware wird anhand der benötigten Informationen und gegebenen Rahmenbedingungen (insbesondere Kosten, Baugröße, Leistungsaufnahme) jeweils so ausgewählt, dass sie für den jeweils angestrebten Verwendungszweck innerhalb des Systems ausreichend dimensioniert sind, allerdings möglichst nicht deutlich überdimensioniert.
-
Wie nachfolgend anhand von bevorzugten Ausführungsformen im Detail erläutert wird, können Smart Nodes insbesondere für die Benutzer-Interaktion dienen. Bei der Kommissionierung eines Systems kann ein Smart Node als Konfigurations-System verwendet werden. Primitive Nodes können je nach Anforderung bspw. zur direkten Ansteuerung eines Aktors oder zum Auslesen eines Sensors verwendet werden.
-
Eine besonders wichtige Rolle kommt den Clever Nodes zu, die aufgrund ihrer Fähigkeit zum Ausführen und Übermitteln von Skripten die eigentliche verteilte Intelligenz des Systems in der Betriebsphase darstellen können, dabei aber im Gegensatz zu Smart Nodes bereits realisierbar sind unter Einhaltung enger Rahmenbedingungen. Sie sind somit vielfältig und ggf. auch in größerer Zahl einsetzbar, bspw. für Steuer-, Regelungs- oder Überwachungsaufgaben.
-
Nachfolgend werden Beispiele von Systemen aus Netzwerkknoten und Steuer- sowie Kommunikationsverfahren hiefür anhand von Zeichnungen näher beschrieben. In den Zeichnungen zeigen:
-
1 eine schematische Darstellung eines ersten Beispiels eines Systems von Netzwerkknoten zur Steuerung eines Heizelements;
-
2 in schematischer Darstellung einen Netzwerkknoten der Knotenklasse Clever Node mit Darstellung von Hardwarekomponenten;
-
3 eine schematische Darstellung einer Software-Schichtstruktur des Netzwerkknotens aus 2;
-
4 in schematischer Darstellung ein zweites Beispiel eines Systems von Netzwerkknoten mit einem Konfigurationssystem in einer Konfigurationsphase;
-
5 in schematischer Darstellung eine Bildschirmausgabe des Konfigurationssystems aus 4;
-
6 in schematischer Darstellung das System aus 4 in einer Betriebsphase;
-
7 in schematischer Darstellung ein drittes Beispiel eines Systems von Netzwerkknoten mit Kommunikationsverbindungen mit unterschiedlichen Kommunikationsprotokollen;
-
8 in schematischer Darstellung ein System zur Konfiguration eines Netzwerkknotens des Systems aus 1.
-
Nachfolgend werden beispielhaft Systeme von Netzwerkknoten sowie Verfahren zur Steuerung, Konfiguration und zum Betrieb von derartigen Systemen und einzelnen Knoten beschrieben.
-
Die nachfolgend dargestellten Systeme stellen Beispiele von Netzwerken dar, die durch miteinander verknüpfte Netzwerkknoten gebildet sind. Jeder Netzwerkknoten ist dabei ein eigenständiger Rechner und kann je nach Aufgabe und gegebenen Rahmenbedingungen auf sehr unterschiedlicher Hardware realisiert werden, bspw. auch als FPGA oder Ein-Chip-System (System-on-Chip, SoC).
-
Beispielhaft erläutert an einem in 2 schematisch dargestelltem Netzwerkknoten 10 verfügt jeder Netzwerkknoten über einen Speicher 12, der üblicherweise flüchtigen (RAM)-Speicher sowie nichtflüchtigen Speicher (bspw. ROM und/oder Flash-Speicher) umfasst und zur Speicherung von Daten und/oder Programmen genutzt wird. Eine Zentraleinheit 14 ist zum Ausführen von Programmen vorgesehen und kann einen oder mehrere Mikroprozessoren, Mikrokontroller, Signalprozessoren etc. umfassen. Eine Netzwerkschnittstelle 16 ermöglicht eine digitale Netzwerkkommunikation mit anderen Netzwerkknoten, wobei verschiedenste Schnittstellentypen, Kommunikationsmedien (kabelgebunden, drahtlos) und Übertragungswege sowie Kommunikationsprotokolle verwendet werden können. Weiter verfügt jeder Netzwerkknoten über eine Leistungsversorgung 18 (hier symbolisch dargestellt in Form einer Batterie; je nach Ausführung kann neben oder statt einer Batterie oder einem wiederaufladbaren Akkumulator auch eine Netzverbindung oder jede andere Energiequelle wie Mittel zum Energy Harvesting genutzt werden, bspw. eine Solarzelle, ein Piezo-Element, ein Thermo-Element, etc. mit einer Speichermöglichkeit für die gesammelte Energie), mit der die Komponenten des Netzwerkknotens mit elektrischer Leistung versorgt werden. Optional kann jeder Netzwerkknoten eine oder mehrere weitere Schnittstellen 20 aufweisen, bspw. zur direkten Verbindung mit Sensoren und/oder Aktoren.
-
Die hier behandelten Systeme bilden bevorzugt cyber-physische Systeme, d. h. einen Verbund informationstechnischer Komponenten mit mechanischen und elektronischen Teilen, die über eine Dateninfrastruktur kommunizieren. Derartige cyber-physische Systeme sind gegenwärtig in intensiver Erforschung und Weiterentwicklung. Wie cyber-physische Systeme im Allgemeinen können auch die hier vorgestellten Systeme vorteilhaft verwendet werden in Einsatzbereichen wie medizinische Geräte und Systeme, altersgerechte Assistenzsysteme, Verkehrssteuerung und Verkehrslogistik, automobile Sicherheits- und Assistenzsysteme, industrielle Prozesssteuerungen, Umweltbeeinflussungs- und Beobachtungssysteme, Energieversorgungsmanagementsysteme, militärische Systemvernetzungssysteme und Kommunikationsinfrastruktur.
-
Sensoren, die mit Netzwerkknoten verbunden sind, können zur Erfassung einer physikalischen Größe dienen. Dies kann sich auf Umgebungsbedingungen beziehen, also bspw. auf Druck, Helligkeit, Temperatur etc., ebenso aber auf überwachte Vorrichtungen, Geräte und Anlagen, an denen bspw. Betriebs-Parameter wie Drehzahl, Dreh- oder Verschiebeposition, Geschwindigkeit etc. mit Hilfe eines Sensors überwacht werden können. Aktoren dienen hingegen zur Beeinflussung bzw. Vorgabe physikalischer Größen. Die Ansteuerung erfolgt dabei bevorzugt zunächst elektrisch, wodurch dann mittelbar oder unmittelbar durch den Aktor eine Steuerfunktion beliebiger Art, also bspw. mechanisch oder elektrisch, ausgeführt werden kann. Dementsprechend können Aktoren bspw. elektrische Treiber- und Ansteuerschaltungen für beliebige elektrische Geräte und Vorrichtungen sein, ebenso aber Ansteuerungen für Stellventile, Elektromagnete, Motoren, Heizelemente, Leuchten, Relais etc..
-
Die hier vorgestellten Systeme können in einer Vielzahl von Gebieten der Technik verwendet werden, wobei allerdings die Verwendung in der Automationstechnik besonders bevorzugt ist. Daher umfassen die Systeme bevorzugt mindestens einen, meist mehrere Sensoren und mindestens einen, meist mehrere Aktoren. Jeder der Sensoren oder Aktoren ist dabei bevorzugt an mindestens einem der Netzwerkknoten direkt angekoppelt, z. B. an einer der in 2 dargestellten Schnittstellen 20. Eine solche direkte Ankopplung liegt dabei auch dann vor, wenn der Sensor oder Aktor unmittelbar in die Hardware oder bspw. auch in das Gehäuse eines Netzwerkknotens integriert ist.
-
Der Begriff der Automation bezieht sich dabei einerseits auf Felder wie die Gebäude- und Fabrikautomation, also bspw. Funktionalitäten wie eine Heizungsregelung, Lichtsteuerung, Steuerung und Regelung von Maschinen und Anlagen, Steuerung und Regelung von Verteilnetzen (smart grids) etc.. Andererseits kann Automation aber neben klassischen Steuer-, Regelungs- und Überwachungsaufgaben auch logistische Prozesse betreffen, also bspw. der Warenverkehr in einem Unternehmen, Steuerung einer Gruppe von Fahrzeugen, etc..
-
1 zeigt beispielhaft ein für eine Automatisierung, nämlich in diesem Beispiel eine Steuerung eines Heizelements nutzbares Netzwerk 30 mit vier Netzwerkknoten 32, 34, 36, 38. Entsprechend ihrer unterschiedlichen Hardware-Ausstattung sind die Netzwerkknoten dabei in verschiedene Klassen von Knoten einzuteilen.
-
Die Unterteilung der Klassen erfolgt dabei anhand von bereitgestellten Funktionen in Smart Nodes, Clever Nodes und Primitive Nodes. Eine Smart Node verfügt über die Möglichkeit zur Ausführung von komplexen Skripten, also einen Interpreter oder Just-in-Time Compiler, bevorzugt eine virtuelle Maschine, z. B. eine Lua Virtual Machine für die Skriptsprache Lua. Die Bezeichnung „komplexe Skripte” dient hier zur Abgrenzung von einzelnen Anweisungen oder Skript-Funktionsaufrufen, die keinen vollständigen Interpreter benötigen, sondern mit einem deutlich einfacheren Single Line Interpreter ausgeführt werden können. Komplexe Skripte umfassen dabei mindestens ein komplexes Sprachelement der verwendeten Skript-Sprache wie Schleifen und/oder die Definition ausführbarer Funktionen.
-
Weiter umfasst eine Smart Node eine grafische Benutzeroberfläche (GUI), z. B. Touchscreen und/oder Bildschirm, Maus, Tastatur. Die Hardware – Ausstattung einer Smart Node muss ausreichen, um die Funktionalität (komplexe Skripte, GUI) zu erfüllen. Dabei gibt es in der Regel keine deutlichen Beschränkungen hinsichtlich Leistungsaufnahme, Größe und Kosten. Ein Smart Node 32 kann daher beliebig hohe Rechenleistung und Speichergröße aufweisen. Bspw. kann es sich hierbei um einen Notebook- oder Desktoprechner sowie anderen voll ausgestatteten handelsüblichen Computer handeln, um ein Tablet oder Smart Phone, oder bspw. um einen dedizierten Steuerrechner. Ein Smart Node kann beispielsweise ausgerüstet sein mit mindestens einem Mehrkernprozessor und Arbeitsspeicher von 1 GB oder mehr.
-
Im dargestellten Beispiel wird der Netzwerkknoten 32 der Knotenklasse Smart Node von einem Benutzer dazu verwendet, das Verhalten der übrigen Knoten zu konfigurieren und zu visualisieren.
-
Die Netzwerkknoten 34 und 36 gehören der Klasse der Clever Nodes an. Diese Knotenklasse ist funktional dadurch definiert, dass die zugehörigen Netzwerkknoten Mittel zum Ausführen von komplexen Skripten aufweisen, also bspw. einen Interpreter oder JIT-Compiler (bevorzugt als virtuelle Maschine), dabei aber keine grafische Benutzeroberfläche. Clever Nodes können ohne Benutzerschnittstelle auskommen oder eine nicht-grafische Ausgabe erlauben, also beispielsweise eine Text-Konsole.
-
Clever Nodes können dabei in beliebiger Hardware realisiert werden, die die o. g. Funktionen unterstützt. Aufgrund von regelmäßig vorhandenen Einschränkungen hinsichtlich Leistungsaufnahme, Baugröße und/oder Kosten werden Clever Nodes i. d. R. eine geringere Rechenleistung und Speicherausstattung aufweisen als die Klasse der Smart Nodes. Ein Clever Node kann bspw. mit einem Ein- oder Mehrkernprozessor ausgerüstet und über Arbeitsspeicher von bspw. 512 kB bis üblicherweise weniger als 1 GB verfügen. Von heute verfügbarer Hardware können Clever Nodes bspw. mit Mikroprozessoren der Leistungsklasse eines ARM Cortex-M4 oder M3 ausgestattet sein.
-
Die Klasse der Primitive Nodes, der der Netzwerkknoten 38 angehört, weist ebenfalls keine grafische Benutzeroberfläche auf. Auch Primitive Nodes verfügen über einen Speicher und Mikroprozessor, können aber keine vollständigen Skripte, sondern bspw. mit Hilfe eines Single Line Interpreter nur einzelne Skript-Funktionsaufrufe ausführen, wiederum bevorzugt in Lua. Hardwaremäßig können Primitive Nodes sehr enge Rahmenbedingungen einhalten, d. h. auf gering ausgestatteter Hardware realisiert werden. Von heute verfügbarer Hardware könnte die Zentraleinheit einer Primitive Node bspw. ein Atmel AVR ATmega oder vergleichbarer Prozessor sein.
-
In 3 sind schematisch die Schichten der Software-Architektur eines Clever Node Netzwerkknotens dargestellt. Die unterste Schicht bildet die Hardware 40, auf der zunächst ein Runtime-Sytem 41 läuft. Das Runtime-System 41 umfasst übliche Systemroutinen wie bspw. Speicherverwaltung, Interupt-Handling, etc. sowie einen Interpreter (oder alternativ: Just-In-Time-Compiler) für eine Skriptsprache, hier bevorzugt Lua, bevorzugt unter Verwendung einer Lua Virtual Machine.
-
Auf dem Runtime-System setzt eine Systemschicht 42 auf, die als Bibliothek von aufrufbaren Funktionen realisiert sein kann. Die Systemschicht 42 kann als Maschinencode vorliegt, bspw. als kompiliertes C-Programm, mindestens zum Teil aber auch in Form von Skripten. Auf der Systemschicht 42 setzt eine Hardware-Abstraktionsschicht HAL 44 auf, die im bevorzugten Beispiel in Lua bzw. einer anderen gewählten Skriptsprache programmiert ist und auf dem Interpreter ausgeführt wird. Die Hardware-Abstraktionsschicht HAL 44 dient dazu, die darauf aufsetzende Anwendungsebene 46 (Application Layer) von der jeweils tatsächlich vorhandenen Hardware 40 so zu entkoppeln, dass diese über Standard-Aufrufe angesprochen werden kann, ohne dass die jeweilige Applikation spezifisch auf die jeweils vorhandene Hardware angepasst werden muss.
-
Die hier behandelten Netzwerke können eine im Prinzip beliebige Anzahl von Netzwerkknoten der verschiedenen Knotenklassen umfassen. Je nach Verwendungszweck ist es dabei nicht erforderlich, dass immer Netzwerkknoten jeder Knotenklasse vorhanden sind. Zusätzlich können Netzwerkknoten anderen Typs ohne die Fähigkeit zur Ausführung von Skripten ebenfalls Teil des Netzwerks sein, wobei diese dann in einer Knotenklasse von Alien Nodes zusammengefasst werden.
-
Die einzelnen Netzwerkknoten sind in der Regel räumlich verteilt angeordnet, d. h. sie befinden sich jeweils im Abstand voneinander, wobei es in einzelnen Fällen aber ebenso möglich ist, dass zwei oder mehr Netzwerkknoten nebeneinander, bspw. im selben Schaltschrank angeordnet sind. Untereinander sind die Knoten durch eine digitale Datenverbindung als Kommunikationsverbindung miteinander gekoppelt, wobei allerdings nicht zwingend alle Datenverbindungen der verschiedenen Knoten vom selben Typ sein müssen. Ebenso muss nicht zwischen allen Paaren von Knoten eine direkte Verbindung bestehen, sondern eine solche kann auch durch Mittelung über einen oder mehrere zwischengeschaltete Knoten gebildet sein. Mögliche Formen der Kommunikationsverbindung zwischen Netzwerkknoten können bspw. drahtgebunden sein, z. B. als Ethernet-Netzwerk oder auch in Form einer seriellen Schnittstelle, bspw. RS-232, RS-422 etc.. Ebenso können die Netzwerkknoten drahtlos miteinander in Verbindung stehen, wie es bspw. von drahtlosen Sensornetzwerken (Wireless Sensor Networks) bekannt ist. Mögliche drahtlose Datenverbindungen umfassen Protokolle wie bspw. Bluetooth, Zigbee, Thread etc..
-
Eine Besonderheit der hier bevorzugt vorgestellten Systeme besteht darin, dass die zwischen den Knoten übermittelten Daten nicht wie herkömmlich bekannt als einzelne Werte bzw. Steuerbefehle übermittelt werden, sondern jeweils in Form ausführbarer Skripte oder Skript-Fragmente.
-
Dadurch, dass die einzelnen Netzwerkknoten der drei Knotenklassen wie erläutert jeweils dazu in der Lage sind, ganze Skripte oder wenigstens einzelne Skript-Funktionsaufrufe auszuführen, ist das aus den Knoten gebildete System sehr flexibel. Übermittelt bspw. in herkömmlichen Netzwerken ein Netzwerkknoten, der direkt mit einem Sensor für eine physikalische Größe verbunden ist, einen von diesem gelieferten Wert an einen anderen Netzwerkknoten, so ist auf dem empfangenden Netzwerkknoten zwangsläufig eine dedizierte Programmierung zur Verarbeitung des Wertes notwendig. Bei den hier vorgestellten Netzwerken hingegen kann die Kommunikation zwischen zwei Knoten in der Form erfolgen, dass ein Knoten ein ausführbares Skript, bevorzugt in Lua, oder ein Skript-Fragment, oder auch nur einen einzelnen Skript-Funktionsaufruf an einen anderen Netzwerkknoten überträgt. Der empfangende Netzwerkknoten führt das übertragende Skript aus.
-
Im Fall eines Netzwerkknotens, der direkt mit einem Sensor verbunden ist, kann demnach der jeweils gelieferte Sensorwert (oder ebenso hiervon abgeleitete Werte, bspw. Signale, wenn der Sensorwert eine vorgegebene Schwelle erreicht) in Skript-Form übertragen werden, so dass nach Ausführung des übertragenden Skripts im empfangenden Knoten der Wert zur Verfügung steht sowie optional bereits eine Anweisung ausgeführt wird, die eine Verarbeitung des Wertes vorgibt. Somit kann eine Sensor-Funktionalität mit Signalisierung in Form eines Skriptes erfolgen, wobei das Skript innerhalb des sendenden, mit dem Sensor verbundenen Netzwerkknotens bspw. generiert werden kann, z. B. aus einer Skript-Vorlage, in die noch Werte eingesetzt werden, oder das Skript kann aus einer Anzahl von vorgespeicherten Skripten oder Skript-Vorlagen ausgewählt werden.
-
In gleicher Weise wie die oben dargestellte Verarbeitung von Sensordaten kann auch die Ansteuerung eines Aktors durch Übermittlung eines Skriptes erfolgen. Während herkömmlich bspw. an einen Netzwerkknoten, der direkt mit einem Aktor, bspw. einer Motorsteuerung verbunden ist ein Steuerkommando (bspw. an/aus) oder ein Ansteuerwert (bspw.: Drehzahl) übermittelt wird, ermöglichen die hier vorgestellten Systeme die Ansteuerung mittels eines ausführbaren Skriptes, das über die Kommunikationsverbindung übertragen und in dem betreffenden Netzwerkknoten ausgeführt wird und dabei die Ansteuerung des Aktors bewirkt. Statt also bspw. eine bestimmte Drehzahl für den zu steuernden Motor zu übertragen, wird ein Skript übertragen, das bei Ausführung die Drehzahl entsprechend vorgibt. Die Parameter der Ansteuerung (im Beispiel also an/aus, Drehzahl) können bspw. fest (d. h. bspw. als Konstanten) im Skript enthalten sein, oder von diesem ausgerechnet oder abgerufen werden.
-
Bei dem in 1 dargestellten System ist der Primitive Node Netzwerkknoten 38 mit einem Aktor, in diesem Beispiel einer Ansteuerung eines Heizelements 48 verbunden. Der Clever Node Netzwerkknoten 34 ist mit einem Sensor, in diesem Fall einem Schalter 50 verbunden, der von einem Benutzer bedient werden kann. Der Clever Node Netzwerkknoten 36 ist mit zwei Sensoren verbunden, im gezeigten Beispiel einem Helligkeitssensor 52 und einem Feuchtesensor 54.
-
Das System 30 soll beispielhaft eingesetzt werden zur Heizungssteuerung, nämlich zur Ansteuerung des Heizelements 48 in Abhängigkeit von der Bedienung des Schalters 50 sowie in Abhängigkeit von der durch die Sensoren 52, 54 erkannten Umgebungsbedingungen der Raumhelligkeit und Luftfeuchte.
-
Innerhalb des Systems 30 erfolgt die Kommunikation zwischen den Netzwerkknoten in Form der Übermittlung von Lua-Skripten, sei es als vollständige Funktionsskripte, Skript-Fragmente oder einzelne Skript-Funktionsaufrufe. Die Konfiguration des Systemverhaltens, d. h. hier speziell die Funktion, nach der die von dem Heizelement 48 abgegebene Heizleistung bzw. die resultierende Temperatur abhängig von den durch die Sensoren 50, 52, 54 gelieferten Werten gesteuert werden soll, wird von dem Smart Node Netzwerkknoten 32 in Form eines Skriptes 56 vorgegeben, dass in diesem Fall den Clever Node Netzwerkknoten 36 übermittelt wird. Der Clever Node Netzwerkknoten 36 fragt die Sensoren 52, 54 ab, und übermittelt in Abhängigkeit von den gelieferten Werten nach Vorgabe des Skriptes 56 einen Ansteuerwert. Dieser Ansteuerwert wird allerdings nicht als solcher, sondern in Form eines Skriptes 58 an den Clever Node Netzwerkknoten 34 übermittelt. Das Skript 58, bei dem es sich wie nachfolgend näher erläutert wird in diesem Beispiel um ein Skript-Fragment handelt, wird innerhalb des Clever Node Netzwerkknotens 36 ausgehend von einer Skript-Vorlage generiert.
-
Der Clever Node Netzwerkknoten 34 führt ein Funktionsskript 60 aus, das die Stellung des Schalters 50 abfragt. Das Funktionsskript 60 wird zur Laufzeit durch das Skript-Fragment 58 ergänzt, wie unten näher erläutert wird. Durch das so ergänzte Skript wird bei weiterer Ausführung ein Ansteuerwert für das Heizelement 48 ermittelt.
-
Die Ansteuerung des Heizelements erfolgt durch den Primitive Node Netzwerkknoten 38. Allerdings wird auch hier der Ansteuerwert vom Clever Node Netzwerkknoten 34 an dem Primitive Node Netzwerkknoten 38 nicht als reiner Wert übermittelt, sondern wiederum in Skript-Form, in diesem Fall als einzelnen Skript-Funktionsaufruf 62. Der Skript-Funktionsaufruf 62 wird durch den Single Line Interpreter auf dem Primitive Node Netzwerkknoten 38 ausgeführt und so die Ansteuerung des Heizelements 48 vorgenommen.
-
Zum besseren Verständnis der hierbei verwendeten Techniken werden nachfolgend die Skripte (beispielhaft in Lua-Code) sowie deren Generierung und Zusammenführung näher erläutert:
Das vom Smart Node Netzwerkknoten
32 an den Clever Node Netzwerkknoten
36 übermittelte Skript
56 kann bspw. in Lua-Code wie folgt lauten:
-
Dabei entspricht der oben mit ... angedeutete Platzhalter einer Funktion bzw. Rechenvorschrift, mit der aus Werten für Licht und Feuchtigkeit ein Temperaturwert zurückgegeben wird.
-
Das vom Smart Node Netzwerkknoten 32 übermittelte Skript wird vom Clever Node Netzwerkknoten 36 nach Übermittlung ausgeführt. Bei dieser Ausführung wird allerdings die darin enthaltene aufrufbare Funktion LightAndHumidtyToTemp nicht direkt ausgeführt, sondern zunächst installiert. Im Kontext des auf dem Clever Node Netzwerkknoten 36 ausgeführten Funktionsskriptes ist diese Funktion anschließend aufrufbar.
-
Das vom Clever Node Netzwerkknoten
36 ausgeführte Funktionsskript könnte bspw. folgendermaßen definiert sein:
-
Dieses Skript weist zunächst der Variablen t den Wert zu, der sich durch Aufruf der installierten aufrufbaren Funktion LightAndHumidtyToTemp mit Übergabe der Sensorwerte der Sensoren 52, 54 als Parameter errechnet. Die Sensoren 52, 54 werden dabei durch die Hardware-Abstraktionsschicht HAL angesprochen (hal.getLight()).
-
Anschließend wird ausgehend von einer Skript-Vorlage in Form eines Strings mit einem Platzhalter (%f) das Skript-Fragment 58 zunächst in einer String-Variablen mit der Bezeichnung „code” gespeichert. Das Skript-Fragment 58 definiert dabei die aufrufbare Funktion GetTemp, wobei der Rückgabeparameter dieser aufrufbaren Funktion fest durch den vorher ausgerechneten Wert gebildet und in Textform in das Skript-Fragment 58 eingesetzt ist.
-
Durch den Befehl join.attach(code) wird das so gebildete Skript-Fragment an den Clever Node Netzwerkknoten 34 übermittelt und dort installiert. Anschließend ist im Clever Node Netzwerkknoten 34 die Funktion GetTemp wie oben definiert installiert.
-
Das Funktionsskript
60 des Clever Node Netzwerkknotens
34 kann bspw. wie folgt aussehen:
-
In dem Funktionsskript wird zunächst die Funktion hal.setTemp definiert, in der abhängig von dem übergebenen Parameter t ein einzelner Lua-Funktionsaufruf als String mit der Bezeichnung „code” erzeugt und mittels join.send an den Primitive Node Netzwerkknoten 38 zur Ausführung übergeben werden kann.
-
Weiter wird die durch das Umschalten des Schalters 50 (Switch Event) getriggerte Funktion OnSwitchEvent() definiert, die bei ausgeschaltetem Schalter die Funktion hal.setTemp mit dem Parameter (o) aufruft, um das Heizelement auszuschalten oder im Fall des eingeschalteten Schalters die durch das Skript-Fragment 58 installierte Funktion GetTemp aufruft und die daraus erhaltenen Werte über hal.setTemp an den Primitive Node Netzwerkknoten 38 übermittelt.
-
Im Primitive Node Netzwerkknoten 38 wird der jeweils übermittelte Skript-Funktionsaufruf Temp.set() mit dem darin vorgegebenen Parameter ausgeführt und somit die Ansteuerung des Heizelements 48 entsprechend vorgenommen.
-
Insgesamt führt das System 30 somit eine Steuerfunktion aus, bei der das Heizelement 48 in Abhängigkeit von den Sensoren 52, 54 und dem Schalter 50 (der ebenfalls ein Sensor ist) mit verschiedenen Ansteuerwerten (t) betrieben bzw. an- und ausgeschaltet wird. Wie beschrieben wird diese Funktionalität erreicht, indem zwischen den Netzwerkknoten stets Skripte übermittelt werden. Durch Änderung der Skripte ist das Steuerverhalten dynamisch anpassbar, auch während des Betriebes.
-
Das System erweist sich dabei als besonders robust, da keine zentrale Steuerung erfolgt, sondern die jeweiligen Funktionen dezentral auf die Knoten verteilt sind. Der Smart Node Netzwerkknoten 32 wird, nachdem er einmalig das Skript 56 mit Vorgabe der Funktion LightAndHumidtyToTemp konfiguriert hat, zunächst nicht mehr benötigt. Während der Laufzeit der Regelung muss der Smart Node Netzwerkknoten 32 nicht aktiv sein, er kann allerdings zur Umkonfiguration des System genutzt werden, bspw. indem eine geänderte Funktion LightAndHumidtyToTemp an dem Clever Node Netzwerkknoten 36 übermittelt wird, um das Systemverhalten zu ändern.
-
Das System 30 kann durch die dargestellte Verwendung von Skripten leicht dynamisch umkonfiguriert werden. Bspw. durch den Smart Node Netzwerkknoten 32 kann jedem der Netzwerkknoten ein geändertes Funktionsskript übermittelt werden. So ist das System sehr leicht an geänderte Anforderungen anpassbar.
-
4 zeigt ein zweites Beispiel eines Systems 70 mit einer Anzahl von Netzwerkknoten.
-
Im Beispiel von 4 sind ein Smart Node 72 als Konfigurationssystem und zwei Clever Nodes 74, 76 vorgesehen, von denen der erste Clever Node Netzwerkknoten 74 an einen Aktor (Treiberschaltung für das Heizelement 75) und der zweite Clever Node Netzwerkknoten 76 an einen Sensor (Schalter 78) angeschlossen ist.
-
Im Beispiel von 4 wird der Smart Node Netzwerkknoten 72 nur in einer Konfigurationsphase benötigt. Der Smart Node Netzwerkknoten 72, der über eine grafische Benuteroberfiäche GUI verfügt, kann von einem Benutzer dazu verwendet werden, das System 70 zu konfigurieren bzw. zu kommissionieren, d. h. das Verhalten der Netzwerkknoten 74, 76 entsprechend der gewünschten Automationsaufgabe vorzugeben.
-
Die Funktion der Netzwerkknoten 74, 76 in der späteren Betriebsphase wird wie zuvor beschrieben durch auf den Knoten ausgeführte Funktionsskripte vorgegeben. Es ist nun möglich, dass der Benutzer die jeweiligen Funktionsskripte einzeln erstellt bzw. auf dem Konfigurationssystem vorgegebene Skripte auswählt, ggf. anpasst und über die Netzwerk-Verbindung an die Netzwerkknoten zur dortigen Ausführung übermittelt. Hierfür würde der Benutzer aber vorab Informationen über die im System 70 zur Verfügung stehenden Netzwerkknoten 74, 76 benötigen und müsste zur anschließenden Programmierung von Skripten diese jeweils im Einzelfall manuell vornehmen bzw. anpassen.
-
Vereinfacht wird die Kommissionierung des Systems 70 durch die Verwendung von speziellen Skripten, hier bezeichnet als Avatare. Ein Avatar-Skript repräsentiert ein Netzwerkobjekt, also bspw. einen einzelnen Netzwerkknoten oder eine Gruppe von Netzwerkknoten, und dokumentiert Fähigkeiten und/oder Eigenschaften des Netzwerkobjekts, insbesondere bevorzugt mögliche Verbindungen, d. h. mögliche Ausgaben oder Empfangsmöglichkeiten für Werte oder Signale. Die Avatar-Skripte werden von dem jeweiligen Netzwerkobjekt an das Konfigurationssystem 72 übermittelt und dort ausgeführt und ermöglichen dann die Kommissionierung, so dass anschließend vom Konfigurationssystem 72 Funktionsskripte an die jeweiligen Netzwerkobjekte zur Ausführung in der anschließenden Betriebsphase übermittelt werden.
-
Im Beispiel des Systems 70 übermittelt der Clever Node Netzwerkknoten 74 ein Avatar-Skript 80 und der Clever Node Netzwerkknoten 76 übermittelt ein Avatar-Skript 82 an das Konfigurationssystem 72. Bei den Skripten handelt es sich in dem bevorzugten Beispiel wiederum um Lua-Skripte, die auf dem Konfigurationssystem 72 ausgeführt werden. Jedes Avatar-Skript repräsentiert und beschreibt den jeweiligen Netzwerkknoten und seine Eigenschaften und Fähigkeiten, so dass bspw. das Avatar-Skript 80 die Fähigkeit des Clever Node Netzwerkknotens 74 zur Ansteuerung des Heizelements 75 dokumentiert und das Avatar-Skript 82 des Clever Node Netzwerkknotens 76 die Fähigkeit zur Abfrage des Sensors 78.
-
Die jeweiligen Netzwerkknoten des Systems 70 melden sich somit jeweils als einzelne Netzwerkobjekte beim Konfigurationssystem 72 unter Übermittlung ihrer Avatar-Skripte an, so dass im Konfigurationssystem 72 eine Datenbank aus den verfügbaren Netzwerkobjekten und ihren jeweiligen Eigenschaften, Anschlüssen etc. erstellt werden kann.
-
Die Kommissionierung im Konfigurationssystem 72 kann bspw. automatisch anhand der so erstellten Datenbank erfolgen, wenn der Regelungs- bzw. Automatisierungszweck dies ermöglicht. Ebenso kann die Datenbank aber auch zur Unterstützung eines Benutzers dienen, der anhand der jeweils gewünschten Automatisierungsaufgabe und des gewünschten Regelverhaltens die Kommissionierung auf dem Konfigurationssystem vornimmt.
-
Im dargestellten, bevorzugten Beispiel enthalten die Avatar-Skripte 80, 82 Befehle zur grafischen Darstellung der jeweiligen Netzwerkobjekte, d. h. hier der Knoten 74, 76 auf dem GUI des Konfigurationssystems 72. Eine mögliche Bildschirmausgabe ist beispielhaft in 5 dargestellt. Das Avatar-Skript 80 des Aktor-Netzwerkknotens 74 stellt diesen grafisch in Form einer Heizelement-Repräsentation dar mit einem Steuereingang 84. Das Avatar-Skript 82 des Schalter-Netzwerkknotens 76 stellt diesen mit einem Schaltersymbol und einem Ausgang 86 dar.
-
Mit Hilfe des GUI des Konfigurationssystems 72 kann das (im dargestellten Beispiel sehr einfache) System 70 nun durch den Benutzer kommissioniert werden. Beispielsweise kann ein Benutzer den Ausgang 86 mit dem Eingang 84 verbinden, wie in 5 beispielhaft dargestellt, um so eine Funktion vorzugeben, bei der das Heizelement 75 abhängig von der Stellung des Schalters 78 in der späteren Betriebsphase geschaltet werden soll.
-
Sobald der Benutzer die gewünschte Funktion des Systems 70 definiert hat, generiert ein Skript-Generator des Konfigurationssystems 72 automatisch Funktionsskripte für die jeweiligen Netzwerkknoten. Bevorzugt ist dabei eine unmittelbare Verarbeitung durch den Skript-Generator, so dass Benutzer-Eingaben direkt in eine Konfiguration des laufenden Systems umgesetzt werden (live coding).
-
Der Skript-Generator erzeugt automatisch für die jeweils vom Benutzer vorgegebene Funktionalität entsprechende Funktionsskripte für die beteiligten Netzwerkknoten. Hierfür interpretiert der Skript-Generator Benutzer-Eingaben, hier bspw. Eingaben auf der grafischen Oberfläche wie das Verbinden von Ein- und Ausgängen, oder sonstige Anforderungen, und wandelt diese in ein oder mehrere Funktions- oder Konfigurationsskripte um, hier bspw. in das Funktionsskript 88.
-
Dem Sensor-Netzwerkknoten 76 wird ein solchermaßen erstelltes Funktionsskript 88 übermittelt, was eine Ansteuerung des Heizelements 75 über den Aktor-Netzwerkknoten 74 abhängig von der Stellung des Schalters 78 vorsieht. In gleicher Weise kann auch dem Aktor-Netzwerkknoten 74 ein Funktionsskript übermittelt werden, was aber bei der hier beispielhaft gezeigten sehr einfachen Funktionsweise nicht notwendig ist.
-
Im Fall der Erstellung eines Konfigurationsskripts wird dieses dem jeweiligen Netzwerkknoten übermittelt und dort ausgeführt, so dass dadurch das entsprechende Funktionsskript installiert wird.
-
Zusätzlich werden die Vorgaben des Benutzers an die beteiligten Netzwerkknoten als sogenannte Retain-Werte zur dortigen Speicherung übermittelt. Diese Retain-Werte dienen bei einer künftigen Neu-Konfiguration bzw. Kommissionierung als Startwert. Denn während bei einer Ersteinrichtung des Systems 70 die Netzwerkknoten 74, 76 zunächst unkonfiguriert sind, ist dies nach der ersten Konfiguration nicht mehr der Fall. Kommt es zu einer Anmeldung bereits konfigurierter Netzwerkknoten an einem Konfigurationssystem 72, so wäre es nachteilig, wenn bereits konfigurierte Netzwerkknoten dann stets in einen unkonfigurierten Zustand zurückgesetzt würden. Andererseits wird es regelmäßig nicht bzw. nur mit sehr hohem Aufwand möglich sein, die jeweilige Konfiguration der Netzwerkknoten 74, 76 (d. h. im vorliegenden Beispiel die Verbindung des Ausgangs 86 mit dem Eingang 84) aus den jeweils dort laufenden Funktionsskripten zu extrahieren.
-
Um die jeweils zuletzt eingerichtete Konfiguration eines einzelnen Netzwerkknotens 74, 76, aber auch eines Systems 70 mit mehreren Netzwerkobjekten so zu speichern, dass bei einer erneuten Konfiguration stets von den vorherigen Konfigurationsstand ausgegangen werden kann, werden die Benutzer-Vorgaben (hier: Verbindung des Ausgangs 86 mit dem Eingang 84) den beteiligten Netzwerkobjekten (hier: Netzwerkknoten 74, 76) zur dortigen Speicherung übermittelt. Dies kann bspw. in Skript-Form erfolgen, d. h. den beiden Netzwerkknoten 74, 76 wird jeweils ein Skript übermittelt, mit dem die Retain-Werte dort lokal abgespeichert werden.
-
Bei einer erneuten Anmeldung an einem Konfigurationssystem 72 übersendet dann jedes Netzwerkobjekt, das bereits über eine vorherige Konfiguration verfügt, die als Retain-Werte dort lokal gespeichert ist, sein jeweiliges Avatar-Skript 80, 82. Die Retain-Werte können innerhalb des Avatar-Skripts 80, 82 enthalten oder zusätzlich zu diesem übermittelt werden. Bei Ausführung der Avatar-Skripte 80, 82 werden diese anhand der Retain-Werte in einen Zustand entsprechend der vorherigen Konfiguration versetzt (d. h. im folgenden Beispiel die Verknüpfung des Ausgangs 86 mit dem Eingang 84 hergestellt).
-
In einer anschließenden Betriebsphase, die in 6 dargestellt ist, werden die jeweiligen Funktionsskripte auf den Netzwerkknoten ausgeführt, d. h. im gezeigten Beispiel das Funktionsskript 88 auf dem Sensor-Netzwerkknoten 76. Das Konfigurationssystem 72 wird in der Betriebsphase nicht benötigt, d. h. dort stattfindende Kommunikation kann ausschließlich zwischen den übrigen, in diesem Fall unmittelbar an der gewünschten Steuerfunktion beteiligten Netzwerkknoten 74, 76 erfolgen.
-
Im Fall der einfachen Aufgabe des Beispiels ist das Funktionsskript 88 so ausgebildet, dass der Sensor-Netzwerkknoten 76 im Fall einer Schalterbetätigung (Event) ein Skript 90 an den Aktor-Netzwerkknoten 74 übermittelt, mit dem je nach Schalterstellung das Heizelement 75 ein- bzw. ausgeschaltet wird. Hierzu wird das übermittelte Skript 90 auf dem Aktor-Netzwerkknoten 74 ausgeführt, so dass die darin vorgegebene Steuerfunktion ebenfalls zur Ausführung kommt.
-
In der 7 ist ein weiteres Beispiel eines Systems 100 mit drei Netzwerkknoten 102, 104, 106 der Knotenklasse Clever Node dargestellt. Die Netzwerkknoten 102, 104, 106 sind allerdings in diesem Falle nicht alle untereinander mit derselben Kommunikationsverbindung verbunden, sondern es besteht eine erste Kommunikationsverbindung 108 mit einem ersten Kommunikationsprotokoll zwischen dem ersten Netzwerkknoten 102 und einem Mittler-Netzwerkknoten 104. Diese erste Kommunikationsverbindung 108 kann bspw. eine drahtgebundene digitale Datenübertragung über eine Ethernet-Verbindung sein.
-
Weiter besteht eine zweite Kommunikationsverbindung 110 nach anderem Protokoll zwischen dem Mittler-Netzwerkknoten 104 und einem weiteren (Ziel-)Netzwerkknoten 106. Hierbei kann es sich bspw. um eine drahtgebundene serielle Datenübertragung handeln, bspw. nach dem RS-485-Protokoll. Der erste Netzwerkknoten 102 ist direkt an einen Sensor 112 angekoppelt; der weitere Netzwerkknoten 106 ist an einen Aktor 114 angeschlossen.
-
Um eine Steuerung des Aktors 114 in Abhängigkeit von einem Sensorwert S des Sensors 112 zu erreichen, muss das System 100 multiprotokoll-fähig sein, da keine direkte Kommunikationsverbindung mit nur einem Kommunikationsprotokoll zwischen den beteiligten Netzwerkknoten 102, 106 besteht. Dies wird durch das Konzept eines eingebetteten Skripts gelöst, auch bezeichnet als Nesting.
-
Der erste Netzwerkknoten 102 wird durch sein Funktionsskript so gesteuert, dass er den Sensorwert S abfragt und in Abhängigkeit von dem Sensorwert S ein spezielles Skript 116 zur Ansteuerung des Heizelements generiert. Dieses auch als „äußeres” bezeichnete Skript wird dem Mittler-Netzwerkknoten 104 zur Ausführung übermittelt und dort ausgeführt. In das äußere Skript 116 ist ein inneres Skript 118 eingebettet. Die Einbettung des inneren Skriptes 118 ist dabei derart gelöst, dass das äußere Skript 116 bei seiner Ausführung auf dem Mittler-Netzwerkknoten 104 das innere Skript 118 erzeugt und an den weiteren, Ziel-Netzwerkknoten 106 zur dortigen Ausführung übersendet.
-
Bei der Ausführung des inneren Skriptes 118 im Ziel-Netzwerkknoten 106 wird die vorgegebene Steuerfunktion ausgeführt.
-
Beispielsweise könnte das äußere Skript 116 im JSON-Format lauten
[”rs485.non(\”temp.set(1.0)\”)”]
-
Bei Ausführung des äußeren Skripts 116 wird ein inneres Skript 118 wie folgt dem Ziel-Netzwerkknoten 106 zur Ausführung übermittelt:
[”temp.set(1.0)”]
-
Mit diesem einzelnen Lua-Funktionsaufruf wird die Ansteuerung des Heizelements mit den enthaltenen Werten vorgegeben.
-
Zu den dargestellten Systemen, Netzwerkknoten und Verfahren sind eine Anzahl von Abweichungen, Alternativen und Änderungen möglich. Insbesondere sind beliebige Kombinationen verschiedener Merkmale und Aspekte möglich. Bspw. der Aspekt der grundsätzlichen Kommunikationsweise mittels Skripten, die nach Übermittlung auf einem Ziel-Netzwerkknoten ausgeführt werden, der Aspekt der Zusammenfügung von Skripten und Skript-Fragmenten, der Aspekt des Nesting, und der Aspekt der Kommissionierung mittels Avatar-Skripten können in beliebiger Weise kombiniert werden, d. h. ein System oder Verfahren kann einen, mehrere oder alle dieser Aspekte in sich vereinen.
-
Bspw. kann das oben beschriebene Steuerverhalten des Systems 30 aus 1 am GUI eines Konfigurationssystems anhand eines Avatar-Skripts vorgegeben und ein Funktionsskript des Smart Node Netzwerkknotens 32, ebenso wie optional die jeweiligen Funktionsskripte der Netzwerkknoten 34, 36, 38 als automatisch generierte Funktionsskripte erzeugt und zur späteren Ausführung an diese übermittelt werden.
-
8 zeigt hierzu beispielhaft einen zusätzlichen Smart Node Netzwerkknoten 33 als Konfigurationssystem zur Konfiguration des Smart Node Netzwerkknotens 32. Als GUI verfügt das Konfigurationssystem 33 über ein Touchscreen 35.
-
Der Netzwerkknoten 33 meldet sich am Konfigurationssystem unter Übermittlung eines Avatar-Skripts 83 an. Dieses stellt bei Ausführung auf dem Touchscreen des Konfigurationssystems 33 den Graphen der jeweils aktuell vorgegebenen Funktion LightAndHumidityToTemp dar und erlaubt dem Benutzer, die gezeigte Kurve durch Ziehen auf dem Touchscreen 35 zu ändern.
-
Sobald der Benutzer eine Änderung der Kurve vorgenommen hat, wird diese ausgewertet und ein entsprechendes Konfigurationsskript 57 an den Smart Node Netzwerkknoten 32 übermittelt (live coding). Das Konfigurationsskript 57 installiert ein neues Funktionsskript 56 mit einer geänderten Funktion LightAndHumidityToTemp. Das Konfigurationsskript 57 kann dabei beispielsweise generiert werden aus den grafischen Benutzer-Vorgaben durch Approximation der vom Benutzer eingestellten Kurve mittels Splines.
-
Ein solches im Avatar-Skript
83 des Smart Node Netzwerkknotens
32 enthaltenes Skript, das seinerseits als Skript-Generator arbeitet, könnte in Grundzügen bspw. wie folgt aussehen:
-
Die angegebenen Hardware-Leistungsmerkmale der Klassen von Smart Node, Clever Node und Primitive Node sind beispielhaft unter Berücksichtigung heute zur Verfügung stehender Hardware zu verstehen. Mit der zukünftig zu erwartenden Verfügbarkeit von Hardware mit höherer Rechenleistung, größerer Speicherausstattung etc. bei gleichem oder geringeren Anforderungen an Baugröße, Leistungsaufnahme und Kosten können die jeweiligen Funktionen der Knotenklassen künftig durch andere Hardware realisiert werden. Maßgeblich sind daher die funktionalen Merkmale der Knotenklassen.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 2010/0205596 A1 [0004]
- US 8204971 B2 [0005]
- US 8438250 [0007]
