-
Die Erfindung betrifft ein Internet-of-Things(IoT)-Hardware-Modul, eine entsprechende Funktionseinheit mit einem derartigen IoT-Hardware-Modul und einer Erweiterungskomponente zur Realisierung einer anwendungsspezifischen Funktionalität sowie ein System für IoT-Anwendungen, aufweisend mehrere solcher Funktionseinheiten.
-
Ferner betrifft die Erfindung eine Verwendung eines entsprechenden IoT-Hardware-Moduls, einer entsprechenden Funktionseinheit oder eines entsprechenden Systems.
-
So genannte Internet-of-Things-Anwendungen (IoT-Anwendungen) halten immer stärkeren Einzug in der Vernetzung elektronischer Endgeräte beziehungsweise in der Vernetzung von so genannten „Smart Devices“, die einem Endnutzer eine bestimmte Funktionalität bereitstellen. Dabei verschwindet der traditionelle PC zunehmend als Gerät und wird durch intelligente Gegenstände (intelligente Alltagsgegenstände, insbesondere Haushaltsgegenstände) ersetzt, die dem Menschen bei seinen alltäglichen Tätigkeiten unterstützen und miteinander zur Kommunikation beziehungsweise zum Austausch von Daten vernetzt sind. Anwendungsfelder sind beispielsweise am Körper getragene Gesundheits- beziehungsweise Fitnessgeräte, so genannte Wearables, die zum Beispiel mit Smartphones oder Tablets kommunizieren. Eine weitere Anwendung ist beispielsweise durch die Vernetzung von Haushaltsgeräten gegeben, um dem Endnutzer ein möglichst intelligentes globales Bedien- und Organisationskonzept einer Vielzahl von Endgeräten zur Verfügung zu stellen.
-
Eine andere Anwendung beschreibt die Vernetzung einer Vielzahl von Sensor- und/oder Aktor-Systemen, wie sie zum Beispiel in einer gebäudetechnischen Infrastruktur eingesetzt werden. Hierbei können intelligente Gegenstände gemäß dem IoT-Ansatz derart vernetzt sein, dass beispielsweise bestimmte situationsabhängige Statusänderungen einer Komponente anderen Komponenten mitgeteilt werden kann, wodurch die gebäudetechnische Infrastruktur selbständig auf bestimmte Gegebenheiten reagieren kann. Konkret ist beispielsweise denkbar, IoT-Komponenten im Rahmen eines in einem Gebäude verteilten Zugangskontroll-Systems einzurichten.
-
Ein wesentliches Merkmal des IoT-Konzeptes besteht darin, dass herkömmliche Gegenstände oder Geräte mit einer Intelligenz gemäß dem IoT-Ansatz erweitert werden. Das bedeutet, dass die intelligente Vernetzung in den herkömmlichen Alltagsgegenständen selbst integriert ist. Dies reicht von der internetfähigen Spülmaschine über intelligente Uhren (so genannte Smartwatches) bis hin zu Kopfhörern, die biometrische Daten des Trägers aufzeichnen. Das Anwendungsfeld dieser IoT-Systeme ist weitreichend und zukunftsträchtig.
-
Die rasche Entwicklung der denkbaren IoT-Anwendungsfelder bringt das Problem mit sich, dass es eine enorme Vielzahl solch intelligenter Gegenstände in komplexen und ständig verändernden Umgebungen gibt, wobei die immer stärkere Vernetzung möglichst vieler intelligenter Gegenstände gemäß dem IoT-Ansatz im Vordergrund steht.
-
Aufgrund der Vielzahl unterschiedlicher Systeme und Anwendungen existiert jedoch auch eine Vielzahl von unterschiedlichen Kommunikationsschnittstellen mit teilweise völlig unterschiedlichen Plug-Ins für Endgeräte, individuellen Konfigurationen und speziellen anwendungsspezifischen Programmierschnittstellen (so genannte Application Programming Interfaces, API‘s) für eine Vielzahl unterschiedlicher Geräte. Dies erschwert eine Vernetzung unterschiedlicher intelligenter Gegenstände, Komponenten oder Systeme, da für die Vernetzung verschiedener solcher Gegenstände, Komponenten oder Systeme unterschiedlicher Hersteller aufwendige Konfigurationen notwendig sind. Auch eine Steuerung einer Vielzahl vernetzter Hardware-Module über ein Backend-Gerät (z.B. einen Server und/oder ein daran angebundenes Steuergerät, Endgerät, usw.) gestaltet sich oftmals als schwierig, da eine Integration des gesamten IoT-Systems im Backend-Gerät aufgrund teilweise völlig unterschiedlicher Komponenten bzw. Plattformen und deren Konfiguration nur mit großem Aufwand zu erreichen ist.
-
Auch die Skalierbarkeit und dynamische Anpassbarkeit von IoT-Systemen ist aufgrund der Diversität bestehender Plattformen schwierig zu realisieren. Es gibt bereits Lösungsansätze, dynamisch skalierbare IoT-Netze vorzusehen, in denen unterschiedliche Konfigurationen, Software-Plug-Ins oder Programmierschnittstellen beziehungsweise Schnittstellenstandards berücksichtigt werden und in einer dynamisch anpassbaren Form zusammengeführt werden. Derartige Lösungen haben jedoch weiterhin den Nachteil, dass völlig unterschiedliche Systeme zusammengeführt werden müssen und eine einheitliche Steuerung eines IoT-Netzes erschweren.
-
Es ist daher eine Aufgabe der Erfindung, ein IoT-Hardware-Modul beziehungsweise eine Funktionseinheit mit einem solchen IoT-Hardware-Modul und einer Erweiterungskomponente zur Realisierung einer anwendungsspezifischen Funktionalität sowie ein gesamtes System derartiger Funktionseinheiten zu beschreiben, die eine erleichterte Integration in ein Gesamtsystem sowie eine verbesserte Handhabung eines solchen Gesamtsystems ermöglichen.
-
Diese Aufgabe wird in einem ersten Aspekt durch ein IoT-Hardware-Modul der eingangs genannten Art gelöst, wenigstens aufweisend
- – einen Prozessor,
- – einen Betriebssystem-Kern,
- – eine Hardware-Anbindungs-Schnittstelle für die Anbindung einer Erweiterungskomponente zur Realisierung einer anwendungsspezifischen Funktionalität, sowie
- – eine Netzwerk-Schnittstelle zur Kommunikation des IoT-Hardware-Moduls mit weiteren IoT-Hardware-Modulen oder sonstigen Geräten innerhalb eines Netzwerks.
Die Netzwerk-Schnittstelle ist auf anwendungsorientierter Ebene gemäß wenigstens einem standardisierten Kommunikations-Protokoll implementiert. Das IoT-Hardware-Modul ist ferner eingerichtet, eine Steuerung einer anwendungsspezifischen Funktionalität einer an das IoT-Hardware-Modul angebundenen Erweiterungskomponente vermittels standardisierter Protokollanweisungen des standardisierten Kommunikations-Protokolls durchzuführen, welche vom IoT-Hardware-Modul über die Netzwerk-Schnittstelle empfangen werden.
-
Ein derartiges IoT-Hardware-Modul zeichnet sich demnach dadurch aus, dass eine Steuerung einer anwendungsspezifischen Funktionalität einer an das IoT-Hardware-Modul angebundenen Erweiterungskomponente über standardisierte Protokollanweisungen eines standardisierten Kommunikations-Protokolls möglich ist. Auf diese Weise kann ein Steuergerät beziehungsweise ein Backend-Gerät (z. B. Server) derart einfach eingerichtet werden, dass in diesem auf anwendungsorientierter Ebene der Netzwerk-Schnittstelle als Verbindung zu dem IoT-Hardware-Modul lediglich ein standardisiertes Kommunikations-Protokoll implementiert ist. Auf diese Weise entfällt das Einrichten spezieller Programmbibliotheken, Programmierschnittstellen, Kommunikations-Protokollen oder allgemeinen Software-Plug-Ins in einem Endgerät einzeln und unterschiedlich für jedes anzusprechende IoT-Hardware-Modul in einem Netzwerk. Vielmehr erfolgt eine Steuerung beziehungsweise ein Ansprechen einer anwendungsspezifischen Funktionalität einer Erweiterungskomponente, die als intelligenter Gegenstand eingerichtet und an das IoT-Hardware-Modul angebunden ist vermittels standardisierter Protokollanweisungen, die das IoT-Hardware-Modul über seine Netzwerk-Schnittstelle empfängt.
-
Das IoT-Hardware-Modul ist gewissermaßen ein Vermittler zwischen einer einfach realisierten und standardisierten Kommunikationsstruktur auf Seiten eines Backend-Geräts und einer anwendungsspezifischen, speziellen Funktionalität einer Erweiterungskomponente, die an das IoT-Hardware-Modul angebunden ist. Das standardisierte Kommunikations-Protokoll gemäß der oben erläuterten Anwendung kann beispielsweise in Form von „http“ oder „https“ implementiert sein und erlaubt einfache, standardisierte Protokollanweisungen zur Steuerung der entsprechenden Funktionalität beziehungsweise zum Austausch von Daten zwischen einem Backend-Gerät und dem IoT-Hardware-Modul zur Steuerung der entsprechenden Funktionalität.
-
Der Begriff „anwendungsorientierte Ebene“ bezeichnet in diesem Kontext sämtliche anwendungsorientierten Schichten des so genannten „Open Systems Interconnection“-Modells (OSI-Modell) als Referenzmodell der Schichtenarchitektur der Netzwerk-Schnittstelle. Insbesondere sollen hier die Schichten fünf bis sieben des bekannten OSI-Modells bezeichnet sein.
-
Der Begriff „Anbindung einer Erweiterungskomponente“ bedeutet in diesem Kontext das Betreiben, gegebenenfalls die Selbstkonfiguration und das Steuern der Erweiterungskomponente über das IoT-Hardware-Modul. Das bedeutet, dass eine Erweiterungskomponente an das IoT-Hardware-Modul mittels der Hardware-Anbindungs-Schnittstelle angesteckt wird, so dass das IoT-Hardware-Modul die Steuerung der durch die Erweiterungskomponente zur Verfügung gestellten anwendungsspezifischen Funktionalität vermittels der über die Netzwerk-Schnittstelle empfangenen standardisierten Protokollanweisungen eines externen Gerätes (beispielsweise eines Backend-Geräts, Servers, und so weiter) übernimmt.
-
Eine Anbindung der Erweiterungskomponente kann auch durch eine spezielle Adapter-Karte erfolgen, welche an die Hardware-Anwendungs-Schnittstelle des IoT-Hardware-Moduls angesteckt wird und ihrerseits einen speziellen Anschlussstecker für den Anschluss einer entsprechenden Erweiterungskomponente aufweist.
-
Das IoT-Hardware-Modul bezeichnet in diesem Kontext ein Modul als Plattform zum Betrieb einer entsprechenden Erweiterungskomponente. Insbesondere unterscheidet sich das IoT-Hardware-Modul von herkömmlichen Computern, PCs, Kleincomputern, und so weiter und ist speziell in seinem Formfaktor auf die IoT-Anwendung abgestimmt. Dies kann vorteilhaft insbesondere bedeuten, dass bis auf die in diesem Kontext erforderlichen bestimmungsgemäßen Komponenten des IoT-Hardware-Moduls (Prozessor, Betriebssystem-Kern, Arbeitsspeicher, Langzeitspeicher, Spannungsversorgung, Spannungsregler, Netzwerk-Schnittstellen sowie Hardware-Anbindungs-Schnittstelle) keine sonstigen Zusatzkomponenten, wie sie in einem herkömmlichen Computersystem Anwendung finden, erforderlich oder eingerichtet sind.
-
Auf diese Weise beschreibt das IoT-Hardware-Modul ein speziell für IoT-Anwendungen eingerichtetes, kostengünstiges Minimalsystem als Hardware-Plattform zur Vernetzung und Anbindung einer speziell eingerichteten Erweiterungskomponente in einem IoT-Netzwerk. Dies kann vor allem bedeuten, dass das IoT-Hardware-Modul physisch mit der Erweiterungskomponente an deren Einsatz- beziehungsweise Installationsort eingerichtet ist. Auf diese Weise kann sich ergeben, dass das IoT-Hardware-Modul kleine Bauteilabmessungen von wenigen Zentimetern oder sogar geringer aufweist. Wichtig in diesem Kontext ist, dass das IoT-Hardware-Modul derart verstanden sein soll, dass es sich von herkömmlichen Computersystemen unterscheidet und als spezielle Plattform zur Kommunikation und Steuerung einer Funktionalität einer speziellen Erweiterungskomponente innerhalb eines IoT-Netzwerkes eingerichtet ist.
-
In einer Ausführungsform weist die Netzwerk-Schnittstelle des IoT-Hardware-Moduls eine Hardware-Schnittstelle gemäß dem USB-Standard auf (USB = Universal Serial BUS). Vorteilhaft ist die Netzwerk-Schnittstelle auf transportorientierter Ebene gemäß dem Ethernet-Protokoll implementiert. Die transportorientierte Ebene ist hier, wie die anwendungsorientierte Ebene gemäß den obigen Erläuterungen, gemäß dem OSI-Modell zu verstehen. Insbesondere sollen hierunter die Schichten eins bis vier, insbesondere die Netzzugriffsschichten eins und zwei verstanden sein. Eine derartige Ausführung der Netzwerk-Schnittstelle ermöglicht die Realisierung von Ethernet über USB, also die Implementierung des Ethernet-Protokolls auf einer USB-Hardware. Dies erlaubt den Einsatz einer sehr einfachen sowie kostengünstigen Hardware in Verbindung mit den Vorzügen des Ethernet-Protokolls, auf dem das Internet-Protokoll (IP) und darauf aufbauend zum Beispiel das Transport-Protokoll TCP realisiert werden kann. Somit ist über einfache Hardware-USB-Schnittstellen ein Datentransport über TCP/IP möglich. Dies erlaubt eine leichte Adressierung mehrerer IoT-Hardware-Module in einem entsprechenden Netzwerk, in dem die IoT-Hardware-Module organisiert sind.
-
Ein jedes IoT-Hardware-Modul kann eine IP-Adresse erhalten und ist auf diese Weise einfach adressierbar. Somit ist die Integration einer Vielzahl von IoT-Hardware-Modulen mit gegebenenfalls angebundenen Erweiterungskomponenten zur Realisierung ggf. verschiedenster anwendungsspezifischer Funktionalitäten in einem Netzwerk möglich, wobei auf standardisierte Protokollstrukturen wie Ethernet, IP beziehungsweise TCP/IP gegebenenfalls in Verbindung mit http beziehungsweise https als anwendungsorientiertes Kommunikations-Protokoll zurückgegriffen werden kann. Das Netzwerk ist beispielsweise über ein Backend-Gerät steuerbar. Im Backend-Gerät müssen auf diese Weise lediglich die anwendungsspezifischen Funktionalitäten selbst unterschieden werden. Eine Unterscheidung verschiedener Erweiterungskomponenten und deren Programmierschnittstellen, speziellen Bibliotheken oder Software-Plug-Ins ist nicht erforderlich, nachdem eine Ansteuerung derartiger Erweiterungskomponenten über standardisierte Protokollanweisungen vermittels der IoT-Hardware-Module erfolgen kann. Der Integrations- beziehungsweise Konfigurationsaufwand verschiedenster Funktionalitäten in einem entsprechenden Netzwerk kann somit sehr gering gehalten werden.
-
In einer Ausführungsform ist das IoT-Hardware-Modul vorteilhaft dazu eingerichtet, eine Umsetzung von standardisierten Protokollanweisungen des standardisierten Kommunikations-Protokolls der Netzwerk-Schnittstelle in spezifische Anweisungen zur Steuerung einer anwendungsspezifischen Funktionalität einer an das IoT-Hardware-Modul angebundenen Erweiterungskomponente durchzuführen. Dies kann beispielsweise dadurch realisiert sein, dass im IoT-Hardware-Modul eine entsprechende Treiber-Software zum Ansprechen einer an das IoT-Hardware-Modul angebundenen Erweiterungskomponente gespeichert ist. Wie bereits oben allgemein erläutert, ist das IoT-Hardware-Modul somit ein Vermittler zwischen einem einfach und standardisiert implementierten Backend-Gerät und einer anwendungsspezifischen Funktionalität der entsprechenden Erweiterungskomponente, die über spezielle Treiber angesprochen werden kann. Diese Treiber sind jedoch lediglich im IoT-Hardware-Modul abgelegt und müssen nicht für eine Vielzahl verschiedenster Erweiterungskomponenten in einem Backend-Gerät eingerichtet und administriert werden. Vielmehr kann über ein Backend-Gerät eine Vielzahl unterschiedlicher Funktionalitäten angesprochen werden, wobei entsprechende Protokollanweisungen an die IoT-Hardware-Module weitergegeben werden und dort in spezielle Anweisungen zum Ansprechen der angebundenen Erweiterungskomponente umgesetzt werden.
-
Aus diesen Erkenntnissen resultiert auch eine einfache Skalierbarkeit beziehungsweise Anpassbarkeit eines Netzwerkes mit einer Vielzahl von IoT-Komponenten, weil entsprechende Komponenten dynamisch integriert oder weggenommen werden können, ohne jedes Mal in einem Backend-Gerät entsprechende umfangreiche Anpassungen von Programmierschnittstellen, Treiber-Bibliotheken oder sonstiger Software-Plug-Ins vorgenommen werden muss. Lediglich die zur Verfügung stehenden Funktionalitäten müssen entsprechend im Backend-Gerät abgebildet und bei Veränderung angepasst werden. Dies kann jedoch aufgrund des Rückgriffs auf standardisierte Protokollanweisungen eines standardisierten Kommunikations-Protokolls der oben erläuterten Art einfach realisiert werden.
-
Vorteilhaft ist das IoT-Hardware-Modul der erläuterten Art derart eingerichtet, dass eine Erweiterungskomponente aus einer Vielzahl unterschiedlicher Erweiterungskomponenten vermittels der Hardware-Anbindungs-Schnittstelle an das IoT-Hardware-Modul angebunden werden kann. Somit kann zur Realisierung unterschiedlicher anwendungsspezifischer Funktionalitäten ein und dasselbe IoT-Hardware-Modul einer bestimmten Konfiguration verwendet werden. Auch diese Tatsache vereinfacht die Verschaltung unterschiedlicher spezifischer Erweiterungskomponenten in einem IoT-Netzwerk, da nicht für jede Erweiterungskomponente ein anderes IoT-Hardware-Modul eingesetzt werden muss. Vielmehr können mehrere gleiche IoT-Hardware-Module um spezielle Erweiterungskomponenten ergänzt werden, wobei sämtliche IoT-Hardware-Module über ein einheitliches Kommunikationsprotokoll ansprechbar sind.
-
Die Hardware-Anbindungs-Schnittstelle des IoT-Hardware-Moduls der erläuterten Art kann eine proprietäre Schnittstelle sein. Vorteilhart weist die Schnittstelle ein so genanntes Superset an BUS-Leitungen auf, um für die Anbindung einer Vielzahl unterschiedlicher Erweiterungskomponenten eingerichtet zu sein. Dabei kann jede Erweiterungskomponente einen identischen Steckverbinder aufweisen, wobei eine Konfiguration der Erweiterungskomponente durch unterschiedliche Belegung von BUS-Leitungen am Steckverbinder codiert ist. Durch Stecken der Erweiterungskomponente auf dem IoT-Hardware-Modul ist somit die Erweiterungskomponente auf einfache Weise an das IoT-Hardware-Modul anbindbar.
-
Eine vorteilhafte Anwendung findet ein IoT-Hardware-Modul der insgesamt erläuterten Art in einer Funktionseinheit für IoT-Anwendungen, wobei die Funktionseinheit ein entsprechendes IoT-Hardware-Modul sowie eine Erweiterungskomponente aufweist, die vermittels der Hardware-Anbindungs-Schnittstelle zur Realisierung einer anwendungsspezifischen Funktionalität an das IoT-Hardware-Modul angebunden ist. Die Erweiterungskomponente kann beispielsweise ein Smartcard-Leser-Modul, ein Display-Modul, ein Handvenen-Scanner-Modul oder eine Kombination derartiger Komponenten sein.
-
Auf diese Weise sind unterschiedliche Funktionseinheiten realisierbar, welche jeweils unterschiedliche Erweiterungskomponenten aufweisen, die an vorteilhaft identische IoT-Hardware-Module angebunden sind. Derartige Funktionseinheiten können in einem IoT-Netzwerk verbunden werden, wodurch ein komplexes System intelligenter Gegenstände realisierbar ist.
-
Ein derartiges System für IoT-Anwendungen weist vorteilhaft mehrere der erläuterten Funktionseinheiten auf. Ein derartiges System kann als verteiltes System eingerichtet sein, bei dem unterschiedliche Funktionseinheiten über deren Netzwerk-Schnittstellen kommunizieren. Beispielsweise ist denkbar, ein derartiges System innerhalb einer gebäudetechnischen Infrastruktur, zum Beispiel als Zugangskontroll-Systeme, einzurichten. Es ist aber auch denkbar, ein derartiges System als elektronisches Gerät auszuführen, in dem die mehreren Funktionseinheiten integriert sind. Auf diese Weise können unterschiedliche skalierbare und dynamisch anpassbare elektronische Geräte realisiert werden, in denen unterschiedliche Funktionseinheiten je nach Anwendungsfall und/oder Kundenwunsch eingebettet sind.
-
Bevorzugt sind bei dem hier erläuterten System die an die jeweiligen IoT-Hardware-Module der Funktionseinheiten angebundenen Erweiterungskomponente unterschiedlich ausgeführt, so dass die Funktionseinheiten jeweils eine unterschiedliche Funktionalität bereitstellen. Auf diese Weise kann das System verschiedenste Funktionalitäten vermittels der Funktionseinheiten bereitstellen. Dies wird insbesondere dadurch auf einfache Weise ermöglicht, dass eine Kommunikation der verschiedenen Funktionseinheiten des Systems untereinander beziehungsweise mit einem Backend-Gerät zur Steuerung und Verwaltung der jeweils durch die Funktionseinheiten zur Verfügung gestellten anwendungsspezifischen Funktionalitäten vermittels standardisierter Protokollanweisungen des standardisierten Kommunikations-Protokolls durchgeführt wird, welche vom jeweiligen IoT-Hardware-Modul einer Funktionseinheit über dessen Netzwerk-Schnittstelle, wie oben erläutert, empfangen werden können. Das bedeutet, dass trotz einer Diversität des Systems eine einfache Steuerung möglich ist. In einem Backend-Gerät muss daher nicht für jede anwendungsspezifische Funktionalität des Systems, insbesondere nicht für unterschiedliche Funktionseinheiten, unterschiedliche Plug-Ins zu deren Steuerung eingerichtet werden. Vielmehr kann das Backend-Gerät vermittels des standardisierten Kommunikations-Protokolls über die jeweiligen Netzwerk-Schnittstellen der IoT-Hardware-Module eine anwendungsspezifische Funktionalität einer an das IoT-Hardware-Modul der Funktionseinheit angebundenen Erweiterungskomponente ansprechen.
-
Beispielsweise ist denkbar, ein Zugangskontroll-Gerät einzurichten, bei dem ein Smartcard-Leser, ein Display oder ein Handvenen-Scanner oder eine Kombination derartiger Komponenten integriert sind. Der Charme eines derartigen Systems beziehungsweise Gerätes besteht darin, dass trotz einer dynamischen Anpassbarkeit unterschiedlicher Funktionseinheiten lediglich eine einfache Anpassung auf Seiten eines Backend-Geräts, an das das System beziehungsweise das Gerät angebunden ist, erforderlich ist. Vorteilhaft sieht ein Backend-Gerät lediglich die durch das System oder Gerät zur Verfügung gestellten Funktionalitäten, ohne dass spezielle Treiber-Software, Programmierschnittstellen oder sonstige Software-Plug-Ins im Backend-Gerät eingerichtet werden müssen.
-
Es sei angemerkt, dass bei einem System für IoT-Anwendungen der oben erläuterten Art die jeweiligen IoT-Hardware-Module der Funktionseinheiten in ihrer Konfiguration identisch aufgebaut sein können. Die IoT-Hardware-Module können sich aber auch unterscheiden.
-
In einer bevorzugten Ausführungsform weist das System ein Dispatcher-Modul auf, das eingerichtet ist zur Verwaltung der mehreren Funktionseinheiten, insbesondere zur Verwaltung der anwendungsspezifischen Funktionalitäten der mehreren Funktionseinheiten. Vorteilhaft weist das Dispatcher-Modul eine interne Netzwerk-Schnittstelle zur Kommunikation mit den IoT-Hardware-Modulen auf. Vorteilhaft weist das Dispatcher-Modul eine externe Netzwerk-Schnittstelle zur Kommunikation mit einem externen Gerät auf. Bevorzugt ist das Dispatcher-Modul über seine interne Netzwerk-Schnittstelle mit den Netzwerk-Schnittstellen der IoT-Hardware-Module verbunden.
-
Das Dispatcher-Modul der oben erläuterten Art fungiert als eine Art „transparenter Proxy“ für die Funktionseinheiten des Systems. Das Dispatcher-Modul sammelt alle Informationen über die durch die entsprechenden Funktionseinheiten zur Verfügung gestellten Funktionalitäten und verwaltet diese. Vorteilhaft stellt das Dispatcher-Modul die gesammelten Informationen für eine Ansprechbarkeit durch ein externes Gerät zur Verfügung. Bevorzugt erfolgt dies über die externe Netzwerk-Schnittstelle des Dispatcher-Moduls. Die externe Netzwerk-Schnittstelle ist zum Beispiel eine Ethernet-LAN-Schnittstelle (LAN = Local Area Network). Ein externes Gerät kann beispielsweise ein Backend-Gerät zur Steuerung des gesamten Systems sein.
-
Das System kann ein separates Dispatcher-Modul aufweisen, welches gegebenenfalls auf die erläuterte Funktionalität beschränkt ist. Alternativ weist das Dispatcher-Modul zusätzlich die Merkmale eines erläuterten IoT-Hardware-Moduls auf beziehungsweise ist eines der IoT-Hardware-Module als Dispatcher-Modul eingerichtet. In diesem Fall entspricht die interne Netzwerk-Schnittstelle vorteilhaft der Implementierung, wie oben zu den IoT-Hardware-Modulen beschrieben.
-
Das Dispatcher-Modul kann ein IoT-Hardware-Modul sein, das sich in seiner Konfiguration (insbesondere in der externen Netzwerk-Schnittstelle) von anderen IoT-Hardware-Modulen unterscheidet. Es ist alternativ denkbar, dass alle IoT-Hardware-Module identisch konfiguriert sind und jedes IoT-Hardware-Modul theoretisch (und auch praktisch) die Funktion des Dispatcher-Moduls im obigen Sinne übernehmen kann.
-
In einer vorteilhaften Ausführungsform des Systems sind die IoT-Hardware-Module eingerichtet, vorbestimmte Parameter einer anwendungsspezifischen Funktionalität einer angebundenen Erweiterungskomponente abzufragen und diese Parameter an das Dispatcher-Modul zu übergeben. Die vorbestimmten Parameter einer anwendungsspezifischen Funktionalität einer an das jeweilige IoT-Hardware-Modul angebundenen Erweiterungskomponente können von der Erweiterungskomponente auch automatisch an das jeweilige IoT-Hardware-Modul übergeben werden. Dies kann zum Beispiel bei Anbindung der Erweiterungskomponente an das IoT-Hardware-Modul erfolgen.
-
In dem Fall, dass das Dispatcher-Modul selbst eine Funktionalität eines IoT-Hardware-Moduls aufweist beziehungsweise eines der IoT-Hardware-Module, wie oben erläutert, als Dispatcher-Modul eingerichtet ist, und falls an die IoT-Hardware-Funktionalität des Dispatcher-Moduls eine Erweiterungskomponente entsprechend angebunden ist, werden vorbestimmte Parameter einer anwendungsspezifischen Funktionalität dieser angebundenen Erweiterungskomponente durch das Dispatcher-Modul selbst abgefragt und entsprechend hinterlegt.
-
In einer bevorzugten Ausführungsform ist das System, insbesondere das Dispatcher-Modul, für eine Kommunikation gemäß einem so genannten „Representational-State-Transfer“-Dienst eingerichtet. Representational-State-Transfer (REST) erlaubt eine sehr einfache Implementierung zur Abfrage bestimmter Statusinformationen der Architektur eines über REST abgebildeten Systems. Die Einrichtung eines REST-Dienstes kann im Rahmen der hierin erläuterten IoT-Funktionalität dazu verwendet werden, anwendungsspezifische Funktionalitäten von Erweiterungskomponenten, die über IoT-Hardware-Module in das System integriert sind, zu steuern, abzufragen beziehungsweise zu konfigurieren. Ein sehr großer Vorteil eines REST-Dienstes besteht darin, dass auf standardisierte Kommunikations-Protokolle zurückgegriffen werden kann. Auf anwendungsorientierter Ebene (siehe obige Erläuterungen) kann REST beispielsweise über „http“ oder „https“ realisiert werden. Auf diese Weise können über ein extern an das System angebundenes Gerät, zum Beispiel ein Backend-Gerät (Server) Funktionalitäten des Systems für IoT-Anwendungen angesprochen werden, ohne dass spezielle Software-Plug-Ins, spezielle Programmbibliotheken oder Programmier-Schnittstellen im externen Gerät erforderlich wären. Für das externe Gerät sind lediglich die durch das System zur Verfügung gestellten Funktionalitäten „sichtbar“, ohne dass spezielle Kenntnis über vorhandene Erweiterungskomponenten und deren Konfiguration im externen Gerät erforderlich sind. Eine Umsetzung standardisierter Protokollanweisungen in spezielle Steuerungsprozesse, die von den im System eingebundenen Erweiterungskomponenten abhängig sind, erfolgt (wie oben erläutert) in den jeweiligen IoT-Hardware-Modulen, an die die Erweiterungskomponenten jeweils angebunden sind.
-
Über den REST-Dienst, der beispielsweise als Webdienst eingerichtet sein kann, erfolgt lediglich eine Verwaltung der Funktionen des Systems über standardisierte Protokollanweisungen des standardisierten Kommunikations-Protokolls, über das REST implementiert ist. Auf diese Weise kann beispielsweise ein Client-System (Computer, Smartphone, Tablet, Smartwatch, und so weiter) auf den REST-Dienst zugreifen (im Falle eines Webdienstes beispielsweise über ein Web-Interface) und die Steuerung des Systems durchführen.
-
Es ist in diesem Fall denkbar, dass das Client-System seinerseits auf ein Backend-Gerät, zum Beispiel einen Server, zugreift, um den REST-Webdienst zu nutzen. Es ist alternativ oder ergänzend jedoch auch denkbar, auf dem Client-System eine Programmierschnittstelle beziehungsweise Programmumgebung zur Realisierung des REST-Dienstes (so genannte REST-API) einzurichten. Somit kann das Client-System (d. h. ohne Umweg über ein Backend-Gerät) auf das System für IoT-Anwendungen zugreifen, um dieses zu steuern. Hier sind vielerlei Anwendungen und auch Kombinationen von Anwendungsfällen denkbar.
-
Eine vorteilhafte Anwendung eines IoT-Hardware-Moduls, einer Funktionseinheit beziehungsweise eines Systems der insgesamt oben erläuterten Art ergibt sich aus einer Verwendung in einer gebäudetechnischen Infrastruktur, insbesondere in einer Wand-, Tür-, Fenster-, Decken-, Heizungs- oder Lüftungsinstallation oder einer Kombination daraus. Beispielsweise können ein oder mehrere IoT-Hardware-Module oder Funktionseinheiten (das heißt IoT-Hardware-Module mit daran angebundenen Erweiterungskomponenten) als Unterputz-Installation in einem Gebäude eingesetzt werden. Auf diese Weise kann ein in einem Gebäude verteiltes IoT-System geschaffen werden, welches beispielsweise als Zugangskontroll-System mit verteilten intelligenten Gegenständen (z. B. Display, Handvenen-Scanner, Smartcard-Leser, und so weiter) eingerichtet ist. Es ist jedoch auch denkbar, dass ein Gesamtsystem, umfassend eine Mehrzahl von erläuterten Funktionseinheiten, als integriertes elektronisches Gerät in einer gebäudetechnischen Infrastruktur der oben erläuterten Art eingesetzt wird. Hierbei kann das System beispielsweise ein kombiniertes Display-Scanner-Gerät, gegebenenfalls kombiniert mit einem Smartcard-Leser, sein. Je nach Anforderung sind verschiedene Funktionseinheiten skalierbar und modular zu einem System zusammenfassbar, wobei eine Kommunikation mit dem Gesamtsystem über ein externes Gerät auf einfache Weise über standardisierte Kommunikations-Protokolle der oben erläuterten Art erfolgen kann. Auf diese Weise ist das System trotz seiner Modularität und Diversität einfach zu steuern.
-
Die oben erläuterten Aspekte, Merkmale und Ausführungsmöglichkeiten entsprechender IoT-Hardware-Module, Funktionseinheiten beziehungsweise Systeme für IoT-Anwendungen werden im Folgenden anhand konkreter Ausführungsformen unter Zuhilfenahme mehrerer Zeichnungen näher erläutert.
-
Es zeigen:
-
1 eine schematisierte Darstellung einer Funktionseinheit, umfassend ein IoT-Hardware-Modul und eine Erweiterungskomponente sowie
-
2 eine Anordnung eines Systems für IoT-Anwendungen und eines daran angebundenen externen Gerätes.
-
1 zeigt eine schematisierte Darstellung einer Funktionseinheit 14, umfassend ein Internet-of-Things(IoT)-Hardware-Modul 1 und eine Erweiterungskomponente 2 zur Realisierung einer anwendungsspezifischen Funktionalität. Auf diese Weise stellt die Funktionseinheit 14 eine bestimmte Funktionalität der Erweiterungskomponente 2 zur Verfügung, wobei die Funktionseinheit 14 in ein System für IoT-Anwendungen integriert werden kann. Das System kann dabei ein verteiltes System mit örtlich verteilten mehreren Funktionseinheiten 14 darstellen. Alternativ kann ein derartiges System aber auch mehrere Funktionseinheiten 14 aufweisen, die beispielsweise in einem elektronischen Gerät integriert sind.
-
Das IoT-Hardware-Modul 1 weist einen Prozessor 7, einen Arbeitsspeicher 12 sowie einen Langzeitspeicher 13 auf. Der Arbeitsspeicher 12 kann beispielsweise als RAM-Speicher (Random Access Memory) ausgeführt sein. Der Langzeitspeicher 13 ist beispielsweise ein Flash-Speicher.
-
Daneben weist das IoT-Hardware-Modul 1 eine Hardware-Anbindungs-Schnittstelle 8 für die Anbindung der Erweiterungskomponente 2 auf. Die Hardware-Anbindungs-Schnittstelle 8 ist beispielsweise eine proprietäre Schnittstelle und weist vorteilhaft ein Superset an Gussleitungen auf, um elektrische Verbindungen zwischen dem IoT-Hardware-Modul 1 und einer Vielzahl unterschiedlich konfigurierter Erweiterungskomponenten bereitstellen zu können. Je nach anwendungsspezifischer Funktionalität einer an das IoT-Hardware-Modul 1 angebundenen Erweiterungskomponente 2 werden bestimmte Signalleitungen des Supersets herangezogen.
-
Im Ausführungsbeispiel gemäß 1 ist zwischen die Hardware-Anbindungs-Schnittstelle 8 und die Erweiterungskomponente 2 eine Adapter-Karte 9 zwischengeschaltet. Die Adapter-Karte 9 ist eine spezielle Adapter-Karte, welche an die Hardware-Anbindungs-Schnittstelle 8 angesteckt wird und ihrerseits einen speziellen Adapter-Stecker 10 für den Anschluss der entsprechenden Erweiterungskomponente 2 aufweist. Die Erweiterungskomponente 2 ist über einen Gegenstecker 11 mit dem Adapter-Stecker 10 der Adapter-Karte 9 verbunden. Die Adapter-Karte 9 hat den Vorteil, dass sie speziell an die Konfiguration der Erweiterungskomponente 2 angepasst sein kann und die elektrische Verbindung zwischen der Erweiterungskomponente 2 und dem IoT-Hardware-Modul 1 überbrückt. Auf diese Weise kann der Gegenstecker 11 ein von der Konfiguration der Erweiterungskomponente 2 abhängiger spezieller Anschluss-Stecker sein, dessen Gegenanschluss als Adapter-Stecker 10 auf der Adapter-Karte 9 ausgebildet ist, ohne dass der Gegenstecker 11 und die Hardware-Anbindungs-Schnittstelle 8 einer gemeinsamen Konfiguration entsprechen müssen. Beispielsweise kann die Erweiterungskomponente 2 ein Display-Modul sein mit einem speziellen Display-Anschlussstecker 11, dessen Gegenstecker als Adapter-Stecker 10 eingerichtet ist. Die Adapter-Karte 9 vermittelt dann die Konfiguration des Display-Moduls 2 an die Hardware-Anbindungs-Schnittstelle 8 weiter.
-
In einer zu 1 alternativen Ausführungsform kann die Adapter-Karte 9 zwischen dem IoT-Hardware-Modul 1 und der Erweiterungskomponente 2 auch entfallen. In dieser Konstellation wäre dann der Gegenstecker 11 in seinem Formfaktor derart eingerichtet, dass er als Gegenstecker zur Hardware-Anbindungs-Schnittstelle 8 unmittelbar fungiert.
-
Das IoT-Hardware-Modul 1 weist neben den bisher erläuterten Komponenten auch Netzwerk-Schnittstellen 4 zur Kommunikation des IoT-Hardware-Moduls 1 mit weiteren IoT-Hardware-Modulen 1 (wie nachfolgend näher erläutert) oder sonstigen Geräten innerhalb eines Netzwerks auf.
-
Vorteilhaft sind die Netzwerk-Schnittstellen 4 gemäß einer Netzwerk-Architektur aufgebaut, wie sie durch das OSI-Schichtenmodell repräsentiert ist. Auf anwendungsorientierter Ebene sind die Netzwerk-Schnittstellen 4 gemäß wenigstens einem standardisierten Kommunikations-Protokoll implementiert. Dies ist vorteilhaft http beziehungsweise https. Die Netzwerk-Schnittstellen weisen ferner Hardware-Schnittstellen gemäß dem USB-Standard auf und sind auf transportorientierter Ebene gemäß dem Ethernet-Protokoll implementiert. Auf diese Weise wird Ethernet über USB an den Netzwerk-Schnittstellen 4 realisiert. Das bedeutet, dass das Ethernet-Protokoll über USB-Hardware übertragen werden kann. Dies erlaubt ferner die Einrichtung des Ethernet-Protokolls beziehungsweise auf transportorientierter Ebene des so genannten TCP-Protokolls, wodurch die Funktionseinheit 14 über eine lokale IP-Adresse in einem Netzwerk adressierbar ist und angesprochen werden kann. Die Realisierung von Ethernet über USB hat ferner den Vorteil, dass kostengünstige Hardware eingesetzt werden kann und dennoch die Vorzüge des Ethernet-Protokolls ausgenutzt werden können.
-
Auf diese Weise kann das IoT-Hardware-Modul 1 über die Netzwerk-Schnittstellen 4 standardisierte Protokollanweisungen des implementierten, standardisierten Kommunikations-Protokolls empfangen beziehungsweise versenden. Vermittels empfangener standardisierter Protokollanweisungen kann eine anwendungsspezifische Funktionalität der Erweiterungskomponente 2 gesteuert werden. Das bedeutet konkret, dass beispielsweise standardisierte Protokollanweisungen per http beziehungsweise https über die Netzwerk-Schnittstellen 4 an das IoT-Hardware-Modul 1 gesendet werden und im IoT-Hardware-Modul 1 in Steuerbefehle zur Ansteuerung der Erweiterungskomponente 2 umgesetzt werden. Hierzu ist im Speicher 13 des IoT-Hardware-Moduls 1 vorbestimmte Treiber-Software zum Ansprechen der Erweiterungskomponente 2, das heißt einer Funktionalität der Erweiterungskomponente 2, gespeichert. Vermittels des Prozessors 7 in Verbindung mit einem Betriebssystem-Kern, der ebenfalls im Speicher 13 gespeichert ist und zu dessen Ausführung gegebenenfalls teilweise oder vollständig in den Arbeitsspeicher 12 geladen wird, kann die Treiber-Software geladen und ausgeführt werden, so dass bestimmte Funktionalitäten der Erweiterungskomponente 2 über das IoT-Hardware-Modul 1 angesprochen werden können. Im Falle, dass die Erweiterungskomponente 2 ein Display-Modul ist, ist im IoT-Hardware-Modul 1, konkret im Speicher 13, eine Display-Treiber-Software hinterlegt, vermittels derer das Display-Modul 2 angesprochen werden kann.
-
So kann beispielsweise über eine Netzwerk-Schnittstelle
4 ein Befehl <Put „Display Content“> an das IoT-Hardware-Modul
1 gesendet werden, der im IoT-Hardware-Modul
1 in einen Display-Treiber-Befehl umgewandelt wird, um den Inhalt „Display Content“ an das Display-Modul
2 weiterzuleiten, so dass das Display-Modul
2 den Inhalt „Display Content“ anzeigen kann.
-
Auf diese Weise ist das IoT-Hardware-Modul 1 ein Vermittler zwischen einer netzwerkseitigen standardisierten Protokollsprache, die über die Netzwerk-Schnittstellen 4 ausgetauscht wird, und einer anwendungsspezifischen Steuersprache zur Steuerung einer anwendungsspezifischen Funktionalität der an das IoT-Hardware-Modul 1 angebundenen Erweiterungskomponente 2 zur Realisierung der entsprechenden Funktionalität. Somit kann die Funktionseinheit 14 insgesamt in ein IoT-Netzwerk beziehungsweise ein IoT-System eingebunden werden, welches auf einfache Weise über standardisierte Protokollanweisungen steuerbar ist. Dies hat den Vorteil, dass in einem externen Gerät zur Steuerung der Funktionseinheiten 14 keine speziellen Software-Bibliotheken, Programmier-Schnittstellen, Software-Plug-Ins oder sonstiges installiert werden müssen, die zur Ansteuerung der Erweiterungskomponente 2 erforderlich sind. Derartige Software-Bausteine sind vielmehr direkt im IoT-Hardware-Modul 1 hinterlegt. Ein System, umfassend eine Vielzahl von Funktionseinheiten 14 gemäß der Ausführungsform in 1 ist somit dynamisch skalierbar beziehungsweise modular, wobei Funktionseinheiten 14 beliebig ausgetauscht werden können, ohne dass in einem externen Gerät, zum Beispiel in einem Backend-Gerät (Server), eine Anpassung der Konfiguration durch Hinzufügen oder Wegnehmen spezieller Programmierschnittstellen oder sonstiger Software-Bausteine erforderlich wäre. Somit kann auf einfache Weise eine Vielzahl von Funktionseinheiten 14 unterschiedlichster anwendungsspezifischer Funktionalitäten in einem IoT-System durch standardisierte Protokollanweisungen in einem externen Gerät, zum Beispiel in einem Backend-Gerät, abgebildet werden.
-
2 zeigt eine Anordnung mit einem System 3 für IoT-Anwendungen und einem externen Gerät 15. Das System 3 kann entweder als verteiltes System eingerichtet sein, bei dem mehrere Funktionseinheiten 14a bis 14c zum Beispiel räumlich verteilt in einer gebäudetechnischen Infrastruktur eingerichtet sind. Es ist jedoch auch denkbar, das System 3 als elektronisches Gerät auszuführen, in dem die Funktionseinheiten 14a bis 14c integriert sind.
-
Konkret umfasst die Ausführungsform gemäß 2 drei Funktionseinheiten 14a, 14b und 14c. Es können auch weitere Funktionseinheiten vorgesehen sein, die hier jedoch nicht dargestellt sind. Sämtliche Funktionseinheiten 14a bis 14c sind über Netzwerk-Schnittstellen 4a, 4b und 4c miteinander verbunden und können darüber kommunizieren. Die Netzwerk-Schnittstellen 4a bis 4c entsprechen der Konfiguration der Netzwerk-Schnittstelle 4 gemäß 1 und bedürfen an dieser Stelle keiner weiteren Erläuterung.
-
Sämtliche Funktionseinheiten 14a bis 14c weisen ein IoT-Hardware-Modul 1a bis 1c auf. Konkret weist die Funktionseinheit 14a ein IoT-Hardware-Modul 1a, die Funktionseinheit 14b ein IoT-Hardware-Modul 1b und die Funktionseinheit 14c ein IoT-Hardware-Modul 1c auf. Sämtliche IoT-Hardware-Module 1a bis 1c umfassen die Funktionalität des IoT-Hardware-Moduls 1 gemäß 1. An sämtliche IoT-Hardware-Module 1a bis 1c sind Erweiterungskomponenten 2a bis 2c angebunden. Das bedeutet in der Ausführungsform gemäß 2, dass an das IoT-Hardware-Modul 1a eine Erweiterungskomponente 2a, an das IoT-Hardware-Modul 1b eine Erweiterungskomponente 2b und an das IoT-Hardware-Modul 1c eine Erweiterungskomponente 2c angebunden sind. Beispielsweise kann die Erweiterungskomponente 2a ein Smartcard-Leser-Modul sein, während die Erweiterungskomponente 2b ein Display-Modul und die Erweiterungskomponente 2c ein Handvenen-Scanner-Modul sein können. Natürlich ist dies rein beispielhaft gewählt, wobei auch andere anwendungsspezifische Funktionalitäten, zum Beispiel ein Kamera-Modul, und so weiter realisiert sein können.
-
Das IoT-Hardware-Modul 1c der Funktionseinheit 14c ist im Unterschied zu den anderen IoT-Hardware-Modulen 1a und 1b der Funktionseinheiten 14a und 14b als so genanntes Dispatcher-Modul 6 eingerichtet. Das Dispatcher-Modul 6 dient zur Verwaltung der Funktionseinheiten 14a bis 14c, insbesondere zur Verwaltung der anwendungsspezifischen Funktionalitäten der Erweiterungskomponenten 2a bis 2c. Das Dispatcher-Modul 6 weist neben der internen Netzwerk-Schnittstelle 4c eine externe Netzwerk-Schnittstelle 5 zur Kommunikation mit einem externen Gerät 15 auf. Die externe Netzwerk-Schnittstelle 5 ist zum Beispiel eine Ethernet-LAN-Schnittstelle. Das externe Gerät 15 kann beispielsweise ein Backend-Gerät, wie zum Beispiel ein Server, sein. Es ist jedoch auch denkbar, dass das externe Gerät 15 ein Client-System, wie zum Beispiel ein Computer, Tablet, Smartphone, etc. ist.
-
Das Dispatcher-Modul 6 arbeitet als transparenter Proxy für sämtliche Funktionseinheiten 14a bis 14c. Das Dispatcher-Modul 6 sammelt alle Informationen über die durch die entsprechenden Funktionseinheiten 14a bis 14c zur Verfügung gestellten Funktionalitäten der Erweiterungskomponenten 2a bis 2c und verwaltet diese. Ferner stellt das Dispatcher-Modul 6 derartige Informationen für eine Ansprechbarkeit durch das externe Gerät 15 zur Verfügung.
-
Konkret ist das Dispatcher-Modul 6 für eine Kommunikation mit dem externen Gerät 15 gemäß einem REST-Dienst eingerichtet. Auf diese Weise kann das externe Gerät 15 durch standardisierte Protokollanweisungen bestimmte Funktionalitäten und Ressourcen aufrufen und steuern, die durch das System 3 vermittels sämtlicher Funktionseinheiten 14a bis 14c zur Verfügung gestellt werden. Für das externe Gerät 15 sind lediglich die entsprechenden Funktionalitäten sichtbar, ohne dass spezielle Kenntnis über vorhandene Erweiterungskomponenten 2a bis 2c und deren Konfiguration im externen Gerät 15 erforderlich sind. Eine Steuerung der Funktionalitäten erfolgt beispielsweise über http beziehungsweise https. Es ist auch denkbar, einen entsprechenden REST-Webdienst einzurichten, so dass das externe Gerät 15 über ein Web-Interface eine entsprechende Steuerung vornehmen kann. Ferner ist denkbar, dass das externe Gerät 15 ein Server ist, der einen entsprechenden Webdienst zur Verfügung stellt, so dass wiederum Client-Systeme auf das externe Gerät 15 zugreifen können, um eine Steuerung des Systems 3 durchzuführen.
-
Sämtliche IoT-Hardware-Module 1a bis 1c sind eingerichtet, vorbestimmte Parameter einer anwendungsspezifischen Funktionalität der entsprechend angebundenen Erweiterungskomponenten 2a bis 2c abzufragen und diese Parameter an das Dispatcher-Modul 6 zu übergeben. Im Falle des IoT-Hardware-Moduls 1c, welches selbst das Dispatcher-Modul 6 bildet, erfolgt eine solche Abfrage ebenso, wobei die Parameter lokal im Dispatcher-Modul 6 hinterlegt werden. Auf diese Weise verwaltet das Dispatcher-Modul 6 ständig eine aktuelle Konfiguration des Systems 3 und kann diese Konfiguration über die externe Netzwerk-Schnittstelle 5 an das externe Gerät 15 abbilden. Werden Funktionseinheiten 14a bis 14c dynamisch und modular hinzugefügt oder entfernt, so kann eine Abfrage vorbestimmter Parameter automatisiert durchgeführt werden, wobei entsprechende Informationen automatisch an das Dispatcher-Modul 6 gesendet werden (Broadcast über die internen Netzwerk-Schnittstellen 4a bis 4c). Falls das Dispatcher-Modul 6 selbst aus dem System 3 entfernt wird, ist es denkbar, dass eine andere Funktionseinheit (in diesem Fall 14a oder 14b) die Funktionen des Dispatcher-Moduls 6 übernimmt. In diesem Falle wären alle IoT-Hardware-Module 1a bis 1c eingerichtet, die Funktion des Dispatcher-Moduls 6 zu übernehmen. Es ist jedoch auch denkbar, die Ausführungsform gemäß 2 derart abzuwandeln, dass ein separates Dispatcher-Modul 6 vorgesehen wird.
-
Die Konfiguration gemäß 2 erlaubt eine einfache Steuerung des Systems 3 durch standardisierte Protokollanweisungen von einem externen Gerät 15 aus, ohne dass im externen Gerät 15 spezielle Programmier-Schnittstellen, Software-Plug-Ins, Software-Bibliotheken oder sonstiges zur Realisierung der anwendungsspezifischen Funktionalitäten der Erweiterungskomponenten 2a bis 2c hinterlegt sein müssen. Vielmehr greift das externe Gerät 15 auf den REST-Dienst zu, um bestimmte Ressourcen des Systems 3 aufzurufen und/oder zu steuern. Spezifische Steuerbefehle, die zur Steuerung der anwendungsspezifischen Funktionalitäten der Erweiterungskomponenten 2a bis 2c notwendig sind, werden in Form von Steuer- beziehungsweise Treiber-Software in den entsprechenden IoT-Hardware-Modulen 1a bis 1c hinterlegt, so dass eine Umsetzung der standardisierten Protokollanweisungen des externen Gerätes 15 in spezifische Steuerbefehle zur Steuerung der Erweiterungskomponenten 2a bis 2c durchgeführt werden kann.
-
Die dargestellten Ausführungsformen sind lediglich beispielhaft gewählt.
-
Bezugszeichenliste
-
- 1, 1a, 1b, 1c
- IoT-Hardware-Modul
- 2, 2a, 2b, 2c
- Erweiterungskomponente
- 3
- System
- 4, 4a, 4b, 4c
- interne Netzwerk-Schnittstelle
- 5
- externe Netzwerk-Schnittstelle
- 6
- Dispatcher-Modul
- 7
- Prozessor
- 8
- Hardware-Anbindungs-Schnittstelle
- 9
- Adapter-Karte
- 10
- Adapter-Stecker
- 11
- Gegenstecker
- 12
- Arbeitsspeicher
- 13
- Langzeitspeicher
- 14, 14a, 14b, 14c
- Funktionseinheit
- 15
- externes Gerät
