-
Die Erfindung betrifft ein Verfahren und ein System zur Konfiguration eines Netzwerk-Objekts sowie einen 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 in den hier betrachteten Systemen 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.
-
Ein Netzwerk-Objekt besteht aus mindestens einem Netzwerkknoten und kann mehrere Netzwerkknoten umfassen. Netzwerkknoten und Netzwerk-Objekte 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 re-konfigurieren 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 eine besonders einfache Konfiguration möglich ist, insbesondere für Automationsaufgaben.
-
Diese Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1, ein System nach Anspruch 12 und einen Netzwerkknoten hierfür nach Anspruch 15. Abhängige Ansprüche beziehen sich auf vorteilhafte Ausführungsformen der Erfindung.
-
Bei dem Verfahren und dem System gemäß der Erfindung sind zunächst ein Netzwerk-Objekt (bestehend aus mindestens einem Netzwerkknoten) und ein Konfigurationssystem beteiligt, die über eine Kommunikationsverbindung verbunden sind. Bevorzugt können weitere Netzwerk-Objekte vorgesehen sein, die ebenfalls über eine Kommunikationsverbindung mit dem Konfigurationssystem und/oder mit dem genannten Netzwerk-Objekt in Verbindung stehen. Dabei stellt ein 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.
-
Das Konfigurations-System ist ebenfalls ein Rechner und kann seinerseits ein Netzwerkknoten sein. Das Konfigurations-System ist dazu ausgerüstet, Skripte auszuführen, d.h. es verfügt über einen Interpreter oder Just-in-time Compiler für eine Skriptsprache. Auch mindestens ein Netzwerkknoten des Netzwerk-Objekts ist entsprechend zur Ausführung von Skripten ausgerüstet. Dabei wird unter einem Interpreter eine durch ein Programm realisierte Funktionalität verstanden, die Skript-Kommandos, sei es als 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äß wird ein Avatar-Skript an das Konfigurations-System übertragen. Das Avatar-Skript ist mit dem Netzwerk-Objekt verknüpft, d.h. es repräsentiert das Netzwerk-Objekt, indem es Eigenschaften des Netzwerk-Objekts beschreibt. Beispiele für Eigenschaften des Netzwerk-Objekts, die in dem Avatar-Skript repräsentiert sind, können bspw. Parameter der Kommunikationsverbindung (bspw. Netzwerk-Adresse), Parameter der Hardware-Ausstattung des oder der Netzwerkknoten (z.B. Speichergröße, Prozessortyp, Netzwerk-Interfaces, angeschlossene Aktoren oder Sensoren, etc.) und/oder Software-Ausstattung (verfügbare Protokolle, Betriebssystem, etc.) sein.
-
Ist mindestens ein Netzwerkknoten des Netzwerk-Objekts mit mindestens einem Sensor oder Aktor verbunden, so enthält das Avatar-Skript bevorzugt Informationen hierüber, d.h. bspw. über die von dem Sensor gelieferten Werte Informationen wie Art der erfassten physikalischen Größe, Wertebereich etc.. Im Fall eines Aktors kann das Avatar-Skript ebenso Informationen über den Aktor und mögliche Ansteuerungen enthalten, also bspw. Art des Aktors, Typ der Ansteuerung (bspw. mittels eines einzelnen Werts oder einer Mehrzahl von Vorgabewerten), Wertebereich etc..
-
Beispielsweise mit Bezug auf eine Heizungssteuerung kann ein Avatar-Skript die Information enthalten, dass ein in dem Netzwerk-Objekt enthaltener Netzwerkknoten mit einem Temperatursensor verbunden ist, um die Umgebungstemperatur zu erfassen, und/oder ein Netzwerkknoten des Netzwerk-Objekts mit einer Heizelementansteuerung verbunden ist, um eine Beheizung zu steuern.
-
Diese Informationen werden dabei nicht als reine Daten, bspw. in Listenform, sondern in Form eines ausführbaren Avatar-Skripts geliefert. Hierfür können verschiedene Skript-Sprachen zum Einsatz kommen; besonders bevorzugt ist die Skriptsprache Lua. Durch die Verwendung von Skripten sind das Verfahren und System besonders flexibel und anpassbar. Dabei erfolgt zwar die Ausführung des Avatar-Skripts auf dem Konfigurations-System, aber da das Avatar-Skript von einer anderen Quelle übermittelt wird, kann dort leicht sichergestellt werden, dass stets ein passendes und aktuelles Avatar-Skript für jedes Netzwerk-Objekt verwendet wird.
-
Das Avatar-Skript kann bspw. auf einem Netzwerkknoten des Netzwerk-Objekts gespeichert sein und von dort an das Konfigurations-System übermittelt werden. Ebenso kann das Avatar-Skript auch anderswo gespeichert sein und über die Kommunikationsverbindung an das Konfigurations-System übertragen werden. Hierzu kann das Netzwerk-Objekt eine Referenz auf das an einem anderen Ort gespeicherte Avatar-Skript an das Konfigurations-System übermitteln, um so das passende Avatar-Skript zu identifizieren. Bspw. können eine Mehrzahl von Avatar-Skripten für verschiedene Typen von Netzwerk-Objekten, bspw. verschieden ausgestattete Netzwerkknoten, auf einem Server gespeichert sein. Jedes der Netzwerk-Objekte kann dann so konfiguriert sein, dass es eine Referenz, also bspw. eine Typ-Identifikation oder einen Link auf den Speicherort des betreffenden Avatar-Skripts an das Konfigurations-System überträgt, woraufhin dieses das referenzierte Avatar-Skript abruft und herunterlädt.
-
Das Avatar-Skript wird auf dem Konfigurations-System mit dem Zweck ausgeführt, eine Konfiguration des Netzwerk-Objektes zu erreichen. Diese Konfiguration erfolgt durch Bereitstellung eines Skripts, nämlich als Funktionsskript oder als Konfigurations-Skript, das an das Netzwerk-Objekt übermittelt und auf mindestens einem Netzwerk-Knoten davon ausgeführt wird. Das in einer Skript-Sprache verfasste Funktions- oder Konfigurationsskript kann bspw. mittels eines Interpreters oder Echtzeit-Compilers (Just-In-Time-Compiler) auf dem Netzwerkknoten ausgeführt werden. Dabei kann das Funktions- oder Konfigurationsskript je nach den Fähigkeiten des jeweiligen Netzwerkknotens ein komplexes Skript sein, d.h. bspw. aus einer Vielzahl von Anweisungen bestehen und/oder Elemente wie Schleifen und Funktionsdefinitionen enthalten. Ebenso ist es aber auch möglich, dass das Funktionsoder Konfigurationsskript nur als ein einzelner Skript-Funktionsaufruf realisiert ist, bspw. um bei einem Netzwerkknoten mit Einzelzeilen-Interpreter einen einzelnen Steuerbefehl auszuführen oder Sensorwert abzufragen etc..
-
Unter einem Funktionsskript wird dabei ein Skript verstanden, das bei Ausführung auf dem Netzwerkknoten zu einer gewünschten Funktionalität in einer Betriebsphase führt. Für Automatisierungszwecke bspw. kann eine solche Funktionalität die Ausführung einer Steuer-, Regelungs- oder Überwachungsfunktion sein, bei der das Funktionsskript, bspw. die Verarbeitung von Eingangswerten (bspw. Sensorwerten) und Ausgabe von Ausgabewerten (bspw. zur Ansteuerung eines Aktors) umfasst.
-
Ein Konfigurationsskript dient hingegen nicht zur direkten Ausführung einer Funktionalität im Betrieb des Netzwerkknotens, sondern dazu, bei seiner Ausführung auf dem Netzwerkknoten eine Konfiguration vorzunehmen. Das Konfigurationsskript kann dazu beispielsweise ein Funktionsskript auf dem Netzwerkknoten sowie ggfs. auf anderen Netzwerkknoten des Netzwerk-Objekts installieren.
-
Die Verwendung von Avatar-Skripten bietet erhebliche Vorteile im Hinblick auf die Konfiguration von einzelnen Netzwerkobjekten, insbesondere aber die Kommissionierung von Systemen mit einer Mehrzahl von Netzwerkobjekten.
-
Durch die Programmierbarkeit mittels Skripten sind die Schnittstellen nicht anwendungsspezifisch, sondern universell verwendbar und für die jeweilige Anwendung flexibel anpassbar. Die Funktionalität ist nicht durch die Architektur festgelegt; weder die Fähigkeiten der einzelnen Netzwerkobjekte noch die Funktionalität des Gesamtsystems ist fest vorgegeben, sondern kann jeweils geeignet definiert werden.
-
Das Konfigurationssystem kann im Allgemeinen universell genutzt werden, eine spezielle Anpassung ist nicht erforderlich, da die Spezifika der jeweiligen Netzwerkobjekte durch deren Avataren beschrieben, dargestellt und konfiguriert werden.
-
Durch die Zuordnung der jeweils passenden Avatar-Skripte ist eine korrekte Beschreibung und Konfiguration jedes Netzwerkobjektes sichergestellt. Bei jeder Änderung ist durch Update des Avatar-Skripts leicht sicherzustellen, dass bei einer darauffolgenden Anmeldung des Netzwerkobjekts bei einem Konfigurations-System eine aktualisierte, passende Fassung verwendet wird.
-
Besondere Vorteile bietet die durch die Verwendung von Skripten universell anpassbare Schnittstelle zwischen den Netzwerkobjekten. Bei einem System, bei dem bspw. Komponenten verschiedenen Typs in unterschiedlichen Varianten verwendbar sind, ermöglicht die Verwendung von Avatar-Skripten eine einfache Konfiguration bzw. Kommissionierung jeder aus den verschiedenen Komponenten zusammengestellten Variante.
-
Das Funktions- oder Konfigurations-Skript kann bspw. auf dem Konfigurations-System von einem Benutzer manuell entwickelt werden, wobei die Informationen des Avatar-Skripts über die Eigenschaften des Netzwerk-Objekts genutzt werden können. Wie nachstehend näher erläutert wird, kann das Avatar-Skript die Entwicklung durch eine geeignete grafische Darstellung unterstützen. Ebenso kann das Funktions- oder Konfigurations-Skript aber auch halb- oder vollautomatisch generiert werden. Die Generierung kann durch das Avatar-Skript erfolgen oder durch einen Skript-Generator des Konfigurations-Systems. In einer bevorzugten Ausführung interpretiert dabei ein Skript-Generator Benutzer-Eingaben und/oder sonstige Anforderungen und wandelt diese in ein Skript um.
-
Eine Möglichkeit ist dabei die Erstellung des Funktions- oder Konfigurations-Skripts durch Auswahl aus einer Anzahl von vordefinierten, gespeicherten Funktions- oder Konfigurations-Skripten. Weiter ist die Verwendung von Vorlagen (Templates) möglich, die durch Anpassung auf die gewünschte Funktionalität, und ggfs. unter Verwendung von im Avatar-Skript enthaltenen Informationen über das Netzwerk-Objekt (bspw.: Adresse) zur Erstellung des Funktions- oder Konfigurations-Skripts verwendet werden.
-
Die Übertragung des Funktions- oder Konfigurations-Skripts an das Netzwerk-Objekt kann dann bevorzugt durch das Avatar-Skript erfolgen, d.h. dieses enthält bevorzugt Befehle, um ein fertiggestelltes Funktions- oder Konfigurations-Skript zur Ausführung durch mindestens einen Netzwerkknoten davon an dieses zu übertragen.
-
Generell ist es nicht nur für die Phase der Konfiguration bzw. Kommissionierung eines Systems mit bevorzugt mehreren Netzwerkknoten vorteilhaft, Skripte über eine Kommunikationsverbindung zu übermitteln und am Empfangsort auszuführen, sondern auch in einer Betriebsphase. Wie im Zusammenhang mit bevorzugten Ausführungsformen näher gezeigt wird, sind durch die Übertragung von Skripten zwischen Netzwerkknoten in der Betriebsphase bspw. Steuer- und Regelungsfunktionen besonders einfach und flexibel implementierbar. Bspw. kann ein Funktionsskript vorsehen, dass zur Signalisierung eines aktuellen Sensor-Wertes ein an einen Sensor angeschlossener Netzwerkknoten den Sensorwert ausliest und ein Skript generiert, 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 oder abhängig von Ergebnissen hiervon Aktionen auslösen oder Steuervorgaben machen. Das so generierte Skript kann an einen Netzwerkknoten übermittelt werden und dort zur Ausführung kommen. Der Grundgedanke der Erstellung bzw. Auswahl eines Skripts abhängig von Sensor-Werten und Übermittlung des Skripts an einen anderen Netzwerkknoten zur Ausführung kann erhebliche Vorteile hinsichtlich der Flexibilität und Konfigurierbarkeit eines Systems bieten.
-
Gemäß einer Weiterbildung der Erfindung ist vorgesehen, dass sich ein Netzwerk-Objekt bzw. ein Netzwerkknoten hiervon am Konfigurations-System anmeldet. Dies hat besondere Vorteile bei der Kommissionierung eines Systems mit mehreren Netzwerk-Objekten, insbesondere mit einer großen Anzahl hiervon. Eine solche Anmeldung kann bspw. bei einem Neustart eines Netzwerk-Objekts (d.h. beim Einschalten oder Zurücksetzen) oder nach einer entsprechenden Konfigurations-Aufforderung erfolgen, die über die Kommunikationsverbindung erfolgt. Die Anmeldung erfolgt dann bevorzugt dadurch, dass mindestens ein Netzwerkknoten des Netzwerk-Objekts dafür sorgt, dass das Avatar-Skript an das Konfigurations-System übertragen wird. Dies kann erfolgen, indem der Netzwerkknoten das lokal gespeicherte oder durch den Netzwerkknoten abrufbare Avatar-Skript selbst an das Konfigurations-System überträgt. Ebenso ist aber auch die Übertragung einer Referenz auf das Avatar-Skript möglich, bspw. eines Links auf einen entfernten Speicherort.
-
Auf dem Konfigurations-System kann nach Anmeldung von mehreren Netzwerk-Objekten eine Speicherung der Netzwerk-Objekte und deren Eigenschaften erfolgen, bspw. in Form einer Datenbank.
-
In einer Weiterbildung der Erfindung werden Konfigurationsdaten eines Netzwerkknotens, eines Netzwerkobjekts oder eines Systems von mehreren Netzwerkobjekten dort lokal gespeichert, um als Startwert bei einer Neukonfiguration bzw. bei einer erneuten Anmeldung an einem Konfigurations-System zu dienen. Damit soll dem Problem begegnet werden, dass eine bestimmte Konfiguration, die zuvor auf dem Konfigurations-System (oder auf einem anderen Konfigurations-System) vorgegeben wurde, rein anhand des auf einem Netzwerkobjekt gespeicherten Ergebnisses, nämlich i.d.R. eines Funktionsskripts, oft nicht ohne weiteres rekonstruierbar sein wird.
-
Bevorzugt ist daher, in mindestens einem Netzwerkknoten Retain-Daten zu speichern. Diese Retain-Daten enthalten Informationen über eine Konfiguration eines oder mehrerer Netzwerkobjekte, bevorzugt über eine vorherige Konfiguration des Netzwerkknotens selbst sowie weiter bevorzugt aller durch die Konfiguration funktional mit ihm verbundener Netzwerkknoten.
-
Die Retain-Daten können an das Konfigurations-System übermittelt werden, um so Informationen für eine Anfangskonfiguration zu erhalten. Sie können bspw. im Avatar-Skript enthalten oder separat hierzu übermittelt werden. Das Konfigurations-System verwendet bevorzugt die Retain-Daten, um eine Anfangs-Konfiguration, bspw. eine funktionale Verknüpfung von Netzwerkobjekten einzurichten, d.h. bevorzugt als solche anzuzeigen. Somit erscheinen Netzwerkobjekte, zu denen Retain-Daten mit einer vorherigen Konfiguration übermittelt werden, nicht unkonfiguriert, sondern können entsprechend der vorherigen Konfiguration behandelt, dargestellt und/oder angesteuert werden.
-
Bei einer Änderung der Konfiguration eines Netzwerkobjektes werden bevorzugt geänderte Retain-Daten von dem Konfigurations-System an mindestens einen Netzwerkknoten des Netzwerkobjekts übermittelt, um so die Retain-Daten auf aktuellem Stand zu halten. Die Übermittlung der geänderten Retain-Daten kann durch entsprechende Befehle im Avatar-Skript erfolgen.
-
Systeme, die mindestens ein Netzwerk-Objekt, bevorzugt eine Vielzahl von Netzwerk-Objekten umfassen, eignen sich besonders zur Steuerung, Regelung und Überwachung. Dabei kann sich die Vorgehensweise in einer Kommissionierungsphase, d.h. der Konfiguration eines Netzwerk-Objekts, unterscheiden von einer anschließenden Betriebsphase des Netzwerk-Objekts. In der Kommissionierungsphase erfolgt die Übertragung des Avatar-Skripts und anschließende Ausführung sowie die Übertragung des Konfigurations- oder Funktions-Skripts. Im Fall eines Konfigurations-Skripts kann dieses ebenfalls in der Kommissionierungsphase ausgeführt werden. In der Betriebsphase werden die Netzwerk-Objekte zur Erfüllung der Funktionalität hinsichtlich Steuerung, Regelung und/oder Überwachung bevorzugt durch dort ausgeführte Funktions-Skripte gesteuert.
-
Dabei müssen Kommissionierung und Betriebsphase nicht zwingend zeitlich aufeinander folgen, jedenfalls nicht systemweit. Im Gegenteil ist eine unmittelbare Erzeugung eines Konfigurations- oder Funktions-Skripts, bspw. während der Eingabe durch einen Benutzer bevorzugt (live coding). D.h., dass ein Netzwerk-Objekt bereits seine Funktion ausführen kann, während der Benutzer noch die gewünschte Funktionalität im Übrigen weiter vorgibt.
-
Gemäß einer Weiterbildung der Erfindung kann das Avatar-Skript Befehle zur grafischen Darstellung einer Repräsentation des Netzwerk-Objekts auf dem Konfigurations-System enthalten. Eine solche grafische Repräsentation kann einem Benutzer die Konfiguration erleichtern, einerseits durch die Visualisierung der zur Verfügung stehenden Netzwerk-Objekte sowie ggf. von deren Eigenschaften und andererseits optional durch die Möglichkeit, eine Konfiguration unmittelbar anhand der grafischen Darstellung vorzunehmen, also bspw. Verbindungen durch Bezug auf die grafische Darstellung zu definieren, bspw. durch Zeichnen. Alternativ sind auch andere Darstellungen bzw. Repräsentationen möglich, bspw. akustisch, haptisch, etc..
-
Während der Benutzer das Funktions- oder Konfigurations-Skript für das Netzwerk-Objekt im Prinzip vollständig oder teilweise manuell entwickeln kann, ist es möglich, durch eine bedienbare grafische Oberfläche die Vorgabe von zu erfüllenden Funktionen und von Verbindungen zwischen verschiedenen Netzwerk-Objekten auf einfache Weise einzugeben und darzustellen. So kann bspw. eine grafische Repräsentation eines Netzwerk-Objekts, das über einen angeschlossenen Sensor verfügt, eine Ausgabemöglichkeit des Sensor-Werts anzeigen. Ebenso kann eine Repräsentation eines Netzwerk-Objekts, das über einen angeschlossenen Aktor verfügt, die Ansteuerungsmöglichkeit dieses Aktors grafisch darstellen. Durch Verbindung von Ausgabe- und Ansteuerungsmöglichkeiten kann ein Benutzer innerhalb der grafischen Repräsentation eine gewünschte Funktionalität vorgeben. Aus diesen Vorgaben kann durch einen Skript-Generator die entsprechende Befehlsfolge für ein Funktions- oder Konfigurations-Skript erstellt werden, die nach Übertragung auf die jeweiligen Netwerk-Objekte die vom Benutzer vorgegebene Funktionalität erfüllen.
-
Wie bereits erwähnt ist es möglich, dass das Avatar-Skript Befehle zum automatischen Generieren des Konfigurations- oder Funktions-Skripts enthält. Es ist auch möglich, dass eine Mehrzahl von Konfigurations- oder Funktions-Skripten gespeichert und durch das Konfigurations-System abrufbar sind. Die Speicherung kann dabei auf dem Konfigurations-System, in einem Netzwerk-Objekt oder auf einem entfernten Server erfolgen. Die Konfigurationsoder Funktions-Skripte können bspw. für verschiedene Typen von Netzwerk-Objekten vorgesehen sein und verschiedene Funktionalitäten, insbesondere zur Automatisierung, erfüllen. Die vorgespeicherten Konfigurations- oder Funktions-Skripte können bereits vollständig sein, oder können noch anpassbar sein, bspw. durch Platzhalter, die zur Verwendung mit bestimmten Netzwerk-Objekten passend zu ergänzen sind. Derartige Bibliotheken von Konfigurations- oder Funktions-Skripten, oder von Vorlagen (templates) hierfür, können bspw. in Form eines Shops für einen Benutzer abrufbar sein.
-
Um insbesondere bei der Verwendung derartiger vorgefertigter Skripte oder Vorlagen Kompatibilitätsprobleme mit den jeweils tatsächlich vorhandenen Netzwerk-Objekten zu vermeiden, auf denen die Skripte ausgeführt werden sollen, kann gemäß einer Weiterbildung der Erfindung vorgesehen sein, dass das Avatar-Skript Befehle zur Überprüfung der Kompatibilität eines Konfigurations- oder Funktions-Skripts mit dem durch das Avatar-Skript repräsentierten Netzwerk-Objekt enthält. Das Avatar-Skript ist für diese Überprüfung besonders gut geeignet, da dort die Informationen über das repräsentierte Netzwerk-Objekt vorliegen. So kann einerseits eine hohe Flexibilität durch Verwendung von vorgespeicherten Skripten aus verschiedenen Quellen erreicht werden, andererseits können aber Probleme mit Inkompatibilitäten vermieden werden.
-
Ein genereller Gedanke der hier vorgestellten Verfahren und Systeme 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-Funktionsanfragen, können als Alien Nodes zusätzlich vorhanden sein und bspw. über gateways angesprochen werden. Bevorzugt umfasst ein System jeweils einen oder mehrere Netzwerkknoten jeder Klasse (Smart Nodes, Clever Nodes, Primitive Nodes).
-
Die verschiedenen Knotenklassen sind durch ihre Funktion voneinander abzugrenzen. Primitive Nodes verfügen nur ü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., sondern umfassen bspw. nur einen Einzelzeilen-Interpreter zur Ausführung von einzelnen Funktionsaufrufen.
-
Clever Nodes unterscheiden sich hiervon durch die Fähigkeit, komplexe Skripte ausführen zu können. Hierfür ist auf Clever Nodes ein Interpreter oder Laufzeit-Compiler (just-in-time Compiler) vorhanden, bevorzugt als virtuelle Maschine. Clever Nodes weisen dabei keine grafische Benutzeroberfläche auf, sondern verfügen allenfalls über rudimentäre nicht-grafische Darstellungsmöglichkeiten, bspw. eine reine Textkonsolen-Ausgabe.
-
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 verschiedenen 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 Funktionen 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, dabei aber im Gegensatz zu Smart Nodes enge Rahmenbedingungen einhalten und somit vielfältig einsetzbar sind, 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 1GB 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 Skripsprache 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 Heizelementes 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 (0) 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 Benuteroberflä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 des 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
-
Bei Ausführung des äußeren Skripts
116 wird ein inneres Skript
118 wie folgt dem Ziel-Netzwerkknoten
106 zur Ausführung übermittelt:
-
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 [0005]
- US 8204971 B2 [0006]
- US 8438250 [0008]
