-
Die Erfindung bezieht sich auf ein Firmware-Management-System zur Aktualisierung von Firmware der in einem Netzwerk eingebundenen Geräten nach dem Oberbegriff des Anspruchs 1 sowie auf ein Firmware-Management-Verfahren nach dem Oberbegriff des Anspruchs 6.
-
Ein System sowie ein Verfahren der eingangs genannten Art ist in der
DE 10 2006 044 182 A1 beschrieben. Zur bedarfsgerechten Funktionalisierung von Steuer-/Regeleinrichtungen, insbesondere von Motorsteuergeräten, ist wenigstens ein Zugriffsmittel zum Zugriff auf einen ersten Datenspeicher sowie eine Steuer-/Regeleinrichtung mit einem zweiten Datenspeicher vorgesehen, wobei der erste Datenspeicher wenigstens ein Funktionsmodul aufweist, durch welches eine Funktion und/oder Funktionalität der Steuer-/Regeleinrichtung ausführbar ist. Im Zusammenwirken von Zugriffsmittel und erstem Datenspeicher ist selektiv wenigstens ein Funktionsmodul in den zweiten Datenspeicher übertragbar und/oder zur Ausführung speicherbar, wobei die Gesamtfunktionalität der Steuer-/Regeleinrichtung durch bedarfsgemäße Selektion eines oder mehrerer Funktionsmodule flexibel anpassbar ist. Zur bedarfsgerechten Funktionalisierung des Motorsteuergeräts werden anhand einer verfahrensvorbereitend durchgeführten bedarfsgemäßen Funktionsauswahl ein oder mehrere in einer Datenbank des ersten Datenspeichers abgelegte Funktionsmodule selektiv in das Motorsteuergerät geladen. Dazu ist notwendig, dass in einem ersten Schritt eine vorbereitende bedarfsgemäße Funktionsauswahl aus mehreren angebotenen Funktionen durch einen Anwender durchgeführt wird.
-
Sind in einem Netzwerk mehrere Geräte mit verschiedenen Geräteeigenschaften eingebunden, ist es für einen Anwender sehr schwierig, fast unmöglich zu wissen, welche der angeschlossenen Automatisierungsgeräte welches Firmware-Update benötigt.
-
Ergänzend ist zu berücksichtigen, dass Geräte verschiedener Hersteller unterschiedliche Lade-Tools und Lademethoden verwenden, so dass das bekannte System zum Firmware-Update verschiedener Geräte nicht geeignet ist.
-
Ein Verfahren zum Update von Firmware FW1 ... FWn von Geräten D1 ... Dn nach dem Stand der Technik ist rein schematisch in 1 dargestellt. Die Geräte D1 ... Dn sind beispielsweise als Steuergeräte, Sensoren, Lastschalter, Antriebe und/oder programmierbare Steuerungen ausgebildet, die jeweils eine Firmware FW1 ... FWn enthalten, die während der Betriebsdauer des Geräts ggfs. aktualisiert werden muss.
-
Da die Geräte D1 ... Dn unterschiedlicher Art sind und unterschiedliche Eigenschaften aufweisen, ist jedem der Geräte D ein spezifisches Lade-Tool LT1 ... LTn zugeordnet, das von einem Anwender C jeweils an das Gerät D1 ... Dn angekoppelt werden muss, dessen Firmware aktualisiert werden soll. Ein Beispiel für ein Lade-Tool ist der „Multi-Loader VW3 A8 121“ oder „Unity Loader“ der Schneider Electric Automation GmbH.
-
Bei dem bekannten Verfahren wird gemäß 2 eine Firmware-Datei FWF bereitgestellt und in das Lade-Tool LT geladen. In dem Lade-Tool LT sind Lade-Informationen LI abgelegt, die beispielsweise Informationen über Abhängigkeiten von Firmware-Dateien, eine Installationsumgebung, Verfahrensschritte zur Durchführung des Updates, Kommunikations-Informationen sowie Geräteeigenschafts-Informationen wie Geräteart, Firmware-Art sowie Kommunikationsfähigkeiten des Gerätes enthalten.
-
Das Lade-Tool LT wird mit dem Gerät D verbunden, wobei über eine spezifische Lade-Schnittstelle und Lade-Service LS eine Kommunikation mit dem Gerät D hergestellt wird, um die Firmware-Datei FWF in das Ggerät D zu laden und ggfs. die Installation der Firmware-Datei zu überwachen.
-
Nachteilig bei dem bekannten Verfahren ist, dass für unterschiedliche Geräte D1 ... Dn jeweils ein eigenes Lade-Tool LT1 ... LTn bzw. eine Lade-Software verwendet werden muss, was für den Anwender C mit hohem Zeit- und Kostenaufwand verbunden ist.
-
Davon ausgehend liegt der vorliegenden Erfindung die Aufgabe zu Grunde, ein Verfahren der eingangs genannten Art derart weiterzubilden, dass das Firmware-Update unterschiedlicher Geräte ermöglicht und wesentlich vereinfacht wird.
-
Die Aufgabe wird erfindungsgemäß dadurch gelöst, dass das Firmware-Management-Gerät ein Firmware-Management-Tool aufweist, welches ausgebildet ist, um in dem Netzwerk eingebundene Geräte zu erkennen und in den Geräten gespeicherte gerätespezifische Lade-Informationen zu erfassen und diese in einer Datenbank eines zweiten Datenspeicher in Form einer Geräteliste und/oder Netzwerk-Topologie zu speichern und dass das Firmware-Management-Tool Mittel zum Abgleich der gerätespezifischen Lade-Informationen mit in dem zumindest einen Datenpaket enthaltenen firmwarespezifischen Lade-Informationen aufweist, wobei unter Berücksichtigung korrespondierender Lade-Informationen ein automatischer Update der Firmware der Geräte über das zumindest eine Lade-Tool durchführbar ist.
-
Gegenüber dem Stand der Technik wird der Vorteil erreicht, dass mit nur einem einzigen Firmware-Management-Tool ein standardisiertes Firmware-Update von Geräten mit unterschiedlichen Geräteeigenschaften ermöglicht wird.
-
Zur Unterstützung von neueren und älteren Geräten ist vorgesehen, dass das Firmware-Management-Tool über ein modulares Netzwerk-Interface mit dem Netzwerk verbunden ist, wobei in das modular aufgebaute Netzwerk-Interface verschiedene Kommunikationsprotokolle wie Modbus, EtherNet/IP, FTP und/oder Kommunikationsmechanismen wie USB als direkte Verbindung zum Gerät als Plug-Ins implementierbar sind.
-
Zur automatischen Aktualisierung von Firmware ist vorgesehen, dass das Firmware-Management-Tool über eine Datenschnittstelle mit einem Software-Update-Client verbunden ist, über den ein automatischer Download von gewünschten Datenpaketen von einem Software-Update-Server ausführbar ist.
-
Zur Verarbeitung von Ladevorgängen mit verschiedenen Lade-Parametern weist das Firmware-Management-Tool ein modular aufgebautes Lade-Interface auf, umfassend ein oder mehrere Lade-Tools, die als Plug-Ins in das Lade-Interface LI implementierbar sind. Dies ermöglicht die Integration von bestehenden Lade-Tools und Lade-Mechanismen.
-
Des Weiteren ist vorgesehen, dass zumindest eines der Lade-Tools eine Device-Service-Infrastruktur zur Service-orientierten Kommunikation mit den Geräten aufweist.
-
Zudem bezieht sich die Erfindung auf ein Firmware-Management-Verfahren zur Aktualisierung von Firmware von zumindest einem in einem Netzwerk eingebundenen Gerät wie Automatisierungsgerät und/oder Energie-Management-Gerät, umfassend die Verfahrensschritte:
- – Download zumindest eines eine Firmware-Datei aufweisenden Datenpakets in eine Datenbank eines Datenspeichers eines Firmware-Management-Systems,
- – Selektieren eines Datenpakets und
- – Laden des Datenpakets über ein Lade-Tool in zumindest eines der Geräte.
-
Das erfindungsgemäße Verfahren zeichnet sich durch die weiteren Verfahrensschritte aus:
- – Erkennen der in dem Netzwerk vorhandenen Geräte mittels eines in dem Firmware-Management-Gerät implementierten Firmware-Management-Tools,
- – Erfassen von gerätespezifischen Lade-Informationen der erkannten Geräte,
- – Speichern der erkannten Geräte und deren gerätespezifischen Lade-Informationen in einer Datenbank,
- – Selektieren zumindest eines eine Firmware-Datei enthaltenden Datenpakets aus der ersten Datenbank auf der Grundlage der gerätespezifischen Lade-Informationen,
- – Laden des selektierten Datenpakets über das Lade-Tool in das zumindest eine entsprechende Zielgerät und vorzugsweise
- – Handhabung von Geräte-Information sowie Datenpaket in Form von z. B. Firmware-Update-Datei durch Kompatibilitäts-Überprüfung,
- – Verwaltung von Geräte-Information sowie Datenpaket in Form von z. B. Firmware-Update-Datei und/oder
- – Bereitstellung und Abfrage von Datenpaketen.
-
Gemäß einer bevorzugten Verfahrensweise ist vorgesehen, dass die Lade-Informationen als firmenwarespezifische Lade-Informationen und/oder gerätespezifische Lade-Informationen bereitgestellt werden, dass die gerätespezifischen Lade-Informationen von dem zu aktualisierenden Gerät als erste externe Datenquelle über einen Kommunikations-Befehl in das Lade-Tool geladen werden und dass die firmwarespezifischen Lade-Informationen zusammen mit den Firmware-Dateien in einem Datenpaket als zweite externer Datenquelle gespeichert und in das Lade-Tool geladen werden.
-
Gemäß einer alternativen Verfahrensweise können die gerätespezifischen Lade-Informationen zusammen mit den firmwarespezifischen Lade-Informationen in dem Datenpaket bereitgestellt und in das Lade-Tool geladen werden.
-
Die firmwarespezifischen Lade-Informationen enthalten vorzugsweise Informationen wie Art und Identifikationsnummer der Zielgeräte, Firmware-Version, Art der Kommunikationsprotokolle, Art der Lademodi und/oder Installations-Informationen sowie das zu verwendende Lade-Tool („Plu-in“) bzw. die zu verwendende Lade-Mechanismus-Implementierung. In einem Paket können mehrere Lade-Optionen vorhanden sein. Das beinhaltet sowohl unterschiedliche Protokolle als auch verschiedene Lade-Modi.
-
Die gerätespezifischen Lade-Informationen enthalten vorzugsweise Informationen wie Geräte-ID, aktuelle Firmware-Version, Statusinformationen, Speicherinformationen, verwendete Kommunikationsprotokolle, gerätespezifische Lade-Modi, Installations-Informationen und/oder Abhängigkeiten und Kompatibilitäts-Informationen bzw. -Hinweise.
-
Bei einer weiteren bevorzugten Verfahrensweise kann das Datenpaket auch Skript-Dateien enthalten, die Informationen über eine Anpassung des Ladevorgangs an z. B. spezielle Eigenschaften oder Verhaltensweisen von Zielgeräten enthalten.
-
Vorzugsweise werden die firmwarespezifischen Lade-Informationen und die gerätespezifischen Lade-Informationen vor dem Start des Ladevorgangs durch das Lade-Tool interpretiert, wobei durch Abgleich der Lade-Informationen ein Ladevorgang mit von dem Gerät und dem Datenpaket unterstützten, kompatiblen Lade-Informationen ausgewählt wird und eine einheitliche Service-Kommunikationsschnittstelle des Lade-Tools entsprechend der übereinstimmenden Lade-Informationen eingestellt wird. Zudem ist durch die bereitgestellten Informationen ein Komptabilitäts- und Abhängigkeitsüberprüfung möglich.
-
Der Erfindung liegt die Idee zu Grunde, die Lade-Tools zu veranlassen, Kenntnis über Lade-Informationen und Geräte-Eigenschafts-Informationen im Zusammenhang mit dem Firmware-Update zu erlangen, um auf der Grundlage dieser Informationen das Firmware-Download-Verfahren und das Format der Daten flexibel an die jeweiligen Bedingungen anzupassen, ohne eine Adaption der Software des Lade-Tools vornehmen zu müssen bzw. dezidierte Lade-Tools für die jeweiligen Ziel-Geräte verwenden zu müssen.
-
Durch das erfindungsgemäße Verfahren wird gegenüber dem Stand der Technik der Vorteil erreicht, dass der Firmware-Update beliebiger Geräte mit einem einzigen Lade-Tool ermöglicht wird, ohne dass Adaptionen der Software des Lade-Tools vorgenommen werden müssen. Nach dem Stand der Technik musste die Software der Lade-Tools für jeden neuen Geräte-Typ oder jede neue Version eines Produktes oder Produktfamilie angepasst werden, oder es musste ein neues Lade-Tool entwickelt und genutzt werden.
-
Folglich erlaubt das erfindungsgemäße Verfahren eine Aktualisierung von Firmware von unterschiedlichen Geräten mit sehr unterschiedlichen Geräteeigenschaften ohne Anpassung der Software der Lade-Tools.
-
Gemäß einer weiteren bevorzugten Verfahrensweise ist vorgesehen, dass zur einheitlichen Kommunikation zwischen Lade-Tool und Gerät eine einheitliche Service-Kommunikationsschnittstelle mit generischen Services verwendet wird, die einen gemeinsamen Satz von Device-Services definieren, über die Daten und/oder Informationen in Form von Service-Operationen von und zu dem Automatisierungsgerät gesendet bzw. empfangen werden.
-
Diese Device-Services sind protokollunabhängig. Durch das Konzept der protokollunabhängigen Device-Services wird ein einheitlicher Ansatz für die Kommunikation zwischen Lade-Tool und Geräten realisiert.
-
Zur Steuerung verschiedener Aktivitäten können die Device-Services in Gruppen wie Verbindungs-Service, Informations-Service, Datenaustausch-Service, Notifikations-Service und/oder Diagnose-Service unterteilt werden. Ein Service ist so definiert, dass dieser eine oder mehrere Operationen enthält, wobei der Service ein abstraktes Ziel wie beispielsweise „Bereich Geräte-Informationen“ und eine Operation einen konkreten Anwendungsfall wie „Lesegeräte-Informationen“ beschreibt.
-
Zur Unterstützung unterschiedlicher Kommunikations-Protokolle ist vorgesehen, dass die Device-Services auf verschiedene Kommunikations-Protokolle abgebildet bzw. umgesetzt werden, um eine Vielzahl von Geräte-Typen und Bussystemen abdecken zu können.
-
Die Flexibilität der Unterstützung für verschiedene Kommunikationsprotokolle wie MODBUS, FTP oder EtherNet/IP und Kommunikations- und/oder Transportmedien wie Feldbus, WLAN, USB oder Datenträger, ermöglicht die Adressierung der individuellen Geräteeigenschaften, wie beispielsweise Automatisierungsgeräte mit begrenzten Ressourcen und Rechenleistungen, wie Sensoren, bis hin zu intelligenten Automatisierungsgeräten wie Programmable Logic Controller (PLC).
-
Des Weiteren ist vorgesehen, dass die Device-Services für verschiedene Bereiche wie Firmware-Management, Anwendungs-Management oder Konfigurations-Management verwendet werden.
-
Das erfindungsgemäße Verfahren zeichnet sich gegenüber dem Stand der Technik weiterhin dadurch aus, dass Wissen und Information, welche von dem Lade-Tool zur Implementierung von Services zur Kommunikation mit den Geräten benötigt werden, ausgelagert werden.
-
Die Information wird von dem mit dem Lade-Tool verbundenen Gerät in Form von gerätespezifischer Lade-Informationen bereitgestellt und wird als firmwarespezifische Lade-Informationen zusammen mit dem Datenpaket geliefert, welches mit dem Gerät ausgetauscht werden soll. Das Datenpaket liefert die firmwarespezifische Lade-Information, d. h. Informationen, was man mit den Daten machen kann. In dem Gerät werden die gerätespezifischen Lade-Informationen bereitgestellt, durch die dann eine Gruppe von Möglichkeiten gebildet wird, die für den tatsächlichen Ladevorgang zur Verfügung stehen.
-
Der Ansatz vermeidet die Notwendigkeit, die Software des Lade-Tools für neue Typen von Geräten aktualisieren zu müssen, da keine gerätespezifischen Software-Teile in das Lade-Tool implementiert sind. Über die Device-Services werden verschiedene nicht-operative Datenaustausch-Anwendungen in Bezug auf Installation von z. B. Firmware-Dateien, Anwendungs-Dateien, Parameter-Dateien, Konfigurations-Dateien sowie Diagnose und andere Anwendungen mit nur einem Kommunikations-Schnittstelle angesprochen
-
Durch das erfindungsgemäße Verfahren wird ein einheitliches Verhalten der Geräte trotz unterschiedlicher Geräteeigenschaften und Kommunikations-Schnittstellen erreicht. Alle Geräte, in denen die Device-Services implementiert sind, verhalten sich gleichartig, unabhängig davon, welches Kommunikationsprotokoll oder welcher Transport-mechanismus verwendet wird. Erforderliche geräteabhängige Spezialisierungen werden durch Geräte-Informationen auf Geräteebene oder Datenpaket-Metadaten auf Paketebene erreicht, die dem Lade-Tool als auch dem Management-Tool zur Verfügung gestellt und anschließend interpretiert werden. Durch diesen Ansatz wird ein weiter Bereich von Geräte-Typen und Geräte-Klassen in einheitlicher Weise abgedeckt. Die geräteabhängigen Spezialisierungen beinhalten auch standardisierte Daten, die allgemein verstanden oder einheitlich korrekt interpretiert werden können.
-
Weitere Einzelheiten, Vorteile und Merkmale der Erfindung ergeben sich nicht nur aus den Ansprüchen, den diesen zu entnehmenden Merkmalen – für sich und/oder in Kombination –, sondern auch aus der nachfolgenden Beschreibung von den Figuren zu entnehmenden bevorzugten Ausführungsbeispielen.
-
Es zeigen:
-
1 eine schematische Darstellung eines Verfahrens zum Updaten von Firmware von Geräten nach dem Stand der Technik,
-
2 eine schematische Darstellung eines Systems zum Updaten von Firmware eines Gerätes nach dem Stand der Technik,
-
3 eine schematische Darstellung einer ersten Ausführungsform eines Firmware-Management-Systems zum Updaten von Firmware eines Gerätes gemäß der Erfindung,
-
4 eine schematische Darstellung einer zweiten Ausführungsform eines Firmware-Management-Systems,
-
5 eine schematische Darstellung einer Anwendungs- und Service-Layer-Architektur des Lade-Tools,
-
6 eine schematische Darstellung von Service-Domains einer Device-Service-Infrastruktur des Lade-Tools,
-
7a), b) schematische Darstellungen von Kommunikations-Diagrammen zwischen Lade-Tool und Automatisierungsgerät,
-
8 eine schematische Darstellung einer Service-Architektur-Schicht,
-
9 eine schematische Darstellung eines Verfahrens zum Laden von Anwendungs-, Konfigurations- und/oder Firmware-Dateien über unterschiedliche Lade-Tools nach dem Stand der Technik,
-
10 eine schematische Darstellung eines Verfahrens zum Laden von Datenpaketen über unterschiedliche Lade-Tools gemäß der Erfindung und
-
11 eine schematische Darstellung einer Datenstruktur von Datenpaketen umfassend Paket-Meta-Daten sowie Firmware-, Konfigurations- und/oder Anwendungs-Dateien.
-
3 zeigt in schematischer Darstellung eine erste Ausführung eines Firmware-Management-Systems FMS1 zum Laden von Firmware-Dateien FWF über ein Lade-Tool LT in Geräte D1 ... Dn mit unterschiedlichen Geräteeigenschaften und/oder Geräteanforderungen. Die Geräte D1 ... Dn können als einfache Sensoren oder Aktoren, Programmable Logic Controller (PLC), Antriebe (Drives), Messgeräte wie Power Meter zum Messen von Strom und Spannung oder Schaltgeräte ausgebildet sein. Die verwendeten Firmware-Dateien FWF sind von der verwendeten Geräte-Plattform abhängig und sind nicht einheitlich.
-
Gemäß der Erfindung ist vorgesehen, dass das Lade-Tool LT derart ausgebildet ist, um die firmwarespezifische Lade-Information FWI und/oder die in den Geräteeigenschaften bzw. Geräteanforderungen enthaltenen gerätespezifischen Lade-Informationen DI, die im Zusammenhang mit dem Laden der Firmware-Datei benötigt werden, aus externen Datenquellen zu laden. Basierend auf diesen Informationen bzw. dem durch die Informationen erhaltenen Wissen kann das Download-Verfahren und das verwendete Datenformat ohne Anpassung einer Software des Lade-Tools LT spezialisiert, d.h., an die jeweiligen Bedingungen des Ziel-Gerätes angepasst werden.
-
Gemäß dem in 3 dargestellten Ausführungsbeispiel können die Geräte-Eigenschafts-Informationen DI in dem Gerät D1 ... Dn bereitgestellt und über einen definierten Kommunikationsbefehl, welcher von jedem einzelnen individuellen Gerät D1 ... Dn unterstützt wird, durch das Lade-Tool LT aufgerufen und geladen werden.
-
Alternativ besteht die Möglichkeit, dass Firmware-Designer und/oder Geräteexperten sämtliche für den Ladevorgang notwendigen Lade-Informationen LI zusammen mit den Firmware-Dateien FWF in ein Datenpaket DP zum Zeitpunkt der Erstellung der Firmware FW aufnehmen, welches sodann in das Lade-Tool LT geladen wird. Vor dem eigentlichen Ladevorgang der Firmware wird sodann die Lade-Information LI von dem Lade-Tool LT interpretiert.
-
Zur Bereitstellung einer protokollunabhängigen Kommunikation über eine Datenverbindung N zwischen dem Lade-Tool LT und den jeweiligen Geräten D1 ... Dn ist in dem Lade-Tool LT eine Device-Service-Infrastruktur DSI mit generischen Device-Services DS implementiert, die ein gemeinsames Set von Service-Domains definieren, wie beispielsweise Lade-Service LS, Informations-Service IS, Verbindungs-Service CS, Notifikations-Service NS und/oder Discovery-Service DCS, die verwendet werden, um Daten und Informationen von und zu einem der Geräte D1 ... Dn zu senden bzw. zu empfangen.
-
4 zeigt rein schematisch eine eigenerfinderische zweite Ausführungsform eines Firmware-Management-Systems FMS2 zur Aktualisierung von Firmware FW von Geräten D1, D2, D3 wie Automatisierungsgeräten, insbesondere Aktoren, Sensoren und/oder Steuerungsgeräte sowie Energie-Management-Geräte, insbesondere Schaltgeräte. Das Firmware-Management-System FMS2 umfasst ein Firmware-Management-Gerät FMU wie Personal Computer mit Engineering-System oder mobiles Handgerät, umfassend eine Datenverarbeitungseinheit wie Mikrocontroller MC, in der ein Firmware-Management-Tool FMT implementiert ist. Das Firmware-Management-Tool FMT hat Zugriff auf Datenspeicher DR1, DR2, die in dem Firmware-Management-Gerät FMU integriert oder als externe Datenspeicher ausgebildet sein können.
-
Des Weiteren umfasst das Firmware-Management-Gerät FMU ein Daten-Interface DI1, über welches Datenpakete DP in eine Datenbank DPDB des Datenspeichers DP1 importiert werden können. Die Datenpakete DP umfassen jeweils Firmware-Dateien FWF, firmwarespezifische Lade-Informationen FWI sowie Datenpaket-Informationen DPI.
-
Alternativ besteht die Möglichkeit, die Datenpakete DP auf einem Software-Update-Server SUS abzulegen und diese über einen Software-Update-Client SUC über ein zweites Daten-Interface DI2 des Firmware-Management-Tools FMT in die Datenbank DPDB zu laden. Dieser Vorgang kann eine manuelle als auch automatisiert (zyklische) Überprüfung oder Abfrage nach neuen oder noch nicht vorhandenen (gemäß der Geräteliste) Updates beinhalten.
-
Des Weiteren umfasst das Firmware-Management-Gerät FMU ein anpassbares Netzwerk-Interface NI, in das verschiedene Kommunikationsprotokolle NI1, NI2, NI3 wie beispielsweise Modbus, EtherNet/IP oder FTP als sogenannte „Plug-Ins“ implementierbar sind. Das Netzwerk-Interface NI ist über ein Netzwerk N mit den Geräten D1, D2, D3 verbunden.
-
Ferner umfasst das Firmware-Management-Tool FMT ein Lade-Tool-Interface LTI zur Implementierung verschiedener Lade-Tools LT1, LT2, LT3, die verschiedene Kommunikations- und Transportmechanismen zum Download der Datenpakete in die Geräte D1, D2, D3 zur Verfügung stellen.
-
Gemäß eines erfinderischen Gedankens ist vorgesehen, dass über das Daten-Interface DI1 oder über das Daten-Interface DI2 importierten Datenpakete DP in der Datenbank DPDB des Datenspeichers DR1 gespeichert werden.
-
Ein weiteres erfinderisches Merkmal sieht vor, dass zumindest eines der Netzwerk-Interfaces NI1, NI2, NI3 ausgebildet ist, entsprechend der Ausprägung des Netzwerkes N, Geräte D1, D2, D3 des Netzwerks N zu erkennen und deren gerätespezifischen Lade-Information DI1, DI2, DI3 zu erfassen. Die erkannten Geräte D1, D2, D3 sowie deren gerätespezifischen Lade-Informationen DI1, DI2, DI3 werden als eine Geräteliste DL bzw. Netzwerktopologie NT in einer Datenbank DLDB des zweiten Datenspeichers DR2 gespeichert.
-
Durch das Firmware-Management-Tool FMT erfolgt eine Analyse der in den Datenbanken DLDB, DPDB enthaltenen Informationen wobei auf der Grundlage der Geräteinformationen DI1, DI2, DI3, welche Geräte-ID-Informationen, aktuelle Firmware-Versions-Informationen, Geräte-Typ-Informationen, Speicherinformationen und/oder Lade-Informationen enthalten, sowie der firmwarespezifischen Informationen FWI, welche die Informationen enthält, welches Lade-Tool verwendet werden soll, eine Auswahl getroffen wird, bei welchem Gerät D1, D2, D3, mit welchen Ladeparametern und welches Lade „Plug-in“ die Firmware FW1, FW2, FW3 aktualisiert werden soll.
-
Nach Auswahl eines gewünschten Datenpakets DP werden durch das Firmware-Management-Tool FMT die entsprechenden Informationen DI aus der Datenbank DLDB selektiert, welche für den Ladevorgang der Firmware auf das Gerät geeignet sind. Die Auswahl erfolgt auf der Grundlage von Datenpaket-Informationen DPI sowie firmwarespezifischen Lade-Informationen FI, die zusammen mit den Firmware-Dateien FWF in dem Datenpaket DP gespeichert sind. Dabei enthalten die firmwarespezifischen Ladeinformationen beispielsweise Zielgerät-Informationen, Firmware-Informationen, Kommunikations-Informationen sowie Lade-Informationen und das Wissen welches Lade „Plug-in“ verwendet werden soll bzw. muss.
-
Das oder die ausgewählten Datenpakete DP werden dann durch das Firmware-Management-Tool FMT über das Lade-Interface LI und ein entsprechendes Lade-Tool LT1, LT2 oder LT3 in das Zielgerät D1, D2, D3 geladen.
-
Durch die Analyse der Geräteliste DL mit zugehörigen gerätespezifischen Lade-Informationen DI sowie der Analyse der Datenpakete DP bietet das Firmware-Management-Tool FMT die Möglichkeit, Firmware-Updates für ein Gerät, automatisch abzufragen und zu laden. Dabei kann der automatische Empfang über eine Anfrage „Subscribe“ an den Software-Update-Client SUC erfolgen, der auf einem Software-Update-Server SUS nach einem Datenpaket DP mit den entsprechenden Firmware-Updates sucht. „Subscribe“ bedeutet hier, dass man sich für ein Gerät registriert und automatisch neue Updates bei der nächsten automatisierten (regelmäßigen, zyklischen) Abfrage erhält. Geeignete Datenpakete DP können sodann über den Software-Update-Client SUC in die Datenbank DPDB des Firmware-Management-Tools FMT geladen bzw. importiert wird.
-
Die einheitliche bzw. gemeinsame Datenbank DPDB ermöglicht, dass alle Daten innerhalb einer Datenbank basierend auf den intelligenten Datenpaketen DP verwaltet werden. Die Datenbank kann auch extern verfügbar sein und muss sich nicht auf demselben Engineering System befinden, z. B. Cloud für mobile Geräte oder auf einem Server im Intranet. Intelligentes Datenpaket DP bedeutet hierbei, dass die Pakete Datenpaket-Informationen DPI sowie firmwarespezifische Lade-Informationen FI enthalten, die ausgewertet werden können, so dass die Datenpakete DP für die entsprechenden Zielgeräte ausgewählt werden können.
-
Die Datenverwaltung umfasst die Speicherung der Datenpakete DP, DL, NT in einer gemeinsamen Umgebung, d. h. den Datenbanken DPDB, DLDB und die Bereitstellung eines gemeinsamen bzw. einheitlichen Satzes von Informationen in Form der Datenpaket-Informationen DPI und/oder firmwarespezifischen Lade-Informationen FWI für die verschiedenen Arten von Dateninhalten.
-
Eine Auswahl einer gemeinsamen bzw. einheitlichen Datenbank kann nachgebildet und offline benutzt werden. Folglich kann eine Datenwiederherstellung durch Einführung von Auswahlkriterien basierend auf Datenpaket-Informationen DPI, die in dem Datenpaket als Paket-Metadaten enthalten sind, vereinfacht werden.
-
Durch den modularen Aufbau des Firmware-Management-Tools FMT, insbesondere die Möglichkeit der Implementierung von Netzwerk-Interfaces NI1, NI2, NI3 als sogenannte „Plug-Ins“ ist das Firmware-Management-Tool FMT in der Lage, verschiedene Arten von Kommunikationswegen, Kommunikationsansätzen, Kommmunikationsprotokolle oder Kommunikationsmechanismen zu integrieren bzw. zu nutzen, um mit verschiedenartigen Geräten D1, D2, D3 bzw. verschiedenen Netzwerken N zu interagieren. Dadurch wird die Komplexität der Datenverarbeitung betreffend die Gerätekommunikation reduziert. Auch wird eine Kompatibilität zu älteren Geräten unterstützt, nämlich durch Verwendung des „Plug In“-Konzeptes, welches die Einbettung älterer Lade-Mechanismen bzw. Lade-Tools erlaubt.
-
Unabhängig davon kann mit dem Firmware-Management-Tool FMT eine Topologie von verschiedenen Netzwerken N erzeugt werden, wodurch z. B. die verfügbaren Geräte in einer Anlage widergespiegelt werden. Ferner besteht die Möglichkeit, eine Momentaufnahme der aktuellen Netzwerkkonfiguration zu erzeugen und zu archivieren. Dies ermöglicht die Wiederherstellung früherer Konfigurationen von verschiedenen Netzwerken oder das Arbeiten, ohne überhaupt mit einem Netzwerk verbunden zu sein, um z. B. eine Aktualisierung der Firmware verschiedener Geräte in einer Wartungsphase vorzubereiten.
-
Des Weiteren bietet das Firmware-Management-Tool FMT die Optionen eines Daten-Providers, z. B. in einem Intranet zu agieren, um die verarbeiteten und gespeicherten Daten weiteren Kunden oder Auftraggebern anzubieten.
-
Aus obigem ergibt sich, dass das Firmware-Management-Tool FMT eine eindeutige Erfahrung, Unterstützung und Betreuung eines vollständigen Lebenszyklus von Daten betreffend die Geräte-Domäne bereitstellt. Das Firmware-Management-Tool verbessert die Akquirierung und Verwaltung aller für den Download/Bereitstellung wichtiger Informationen. Somit wird die Komplexität für verschiedene Bereiche des Informations- und Datenflusses reduziert.
-
5 zeigt rein schematisch eine Architektur des Lade-Tools LT, umfassend eine Anwendungsschicht AL mit Anwendungs-Software AS sowie eine Service-Schicht SL mit Device-Services DS. Die Anwendungs-Software AS definiert Sequenzen und Verhalten betreffend eines definierten Ablaufschemas wie:
- – Cached loading (Firmware-Dateien bzw. Pakete werden zuerst auf Geräte abgelegt und anschließend von dort installiert),
- – Direct Streamed loading (Die Firmware-Dateien werden in einzelnen Dateien nach und nach übertragen und installiert) und/oder
- – Laden via SD-Card oder USB-Strick des Firmware-Updates (Firmware-Dateien/Paket werden auf ein tragbares Medium kopiert und anschließend in das Zielgerät eingesteckt und von dort aus per Kommunikationsbefehl oder Geräteneustart installiert).
-
Des Weiteren enthält die Applications-Software AS Informationen betreffend die Anwendung von Device-Services DS, um die Firmware-Dateien in das entsprechende Automatisierungsgerät D1 ... Dn zu laden.
-
Der Service-Layer SL repräsentiert die Device-Service-Infrastruktur DSI mit den generischen Device-Services DS wie Lade-Service LS, Informations-Service IS, Verbindungs-Service CS, Notifikations-Service NS oder Discovery-Service DS, über die generische Operationen definiert werden.
-
6 zeigt rein schematisch verschiedene Service-Domains der Device-Service-Infrastruktur DSI. Dabei dient jede Service-Domain einem bestimmten Zweck. Dabei bestehen Abhängigkeiten zwischen den Service-Operationen und den Service-Bereichen. Beispielsweise kann ohne den Service „Connect“ kein Service „Get Device Information“ ausgeführt werden. Für ein Firmware-Loading müssen folglich mehrere Service-Operationen miteinander kombiniert werden. Die einzelnen Service-Operationen werden nachfolgend erläutert.
-
Über den Verbindungs-Service CS wird beispielswiese eine Verbindung zwischen dem Lade-Tool LT und dem Gerät geöffnet oder geschlossen und die Berechtigung abgefragt.
-
Über den Informations-Service IS wird eine protokollunabhängige Kommunikation mit dem Gerät D1 ... Dn ermöglicht; über Kommunikationsbefehle wie „Get Device Information“ oder „Get Device Status“ werden verschiedene Arten von statischen oder dynamischen Geräteinformationen in dem Gerät abgefragt.
-
Über den Lade-Service LS werden Operationen wie „Download“, „Upload“, „Send Command“ sowie „Get Progress Info“ ausgeführt, um z.B. ein Datenpaket DP bzw. Datenfiles aus dem Lade-Tool LT in das Gerät D1 ... Dn zu laden. Auch besteht die Möglichkeit, Daten oder Dateien aus dem Gerät D1 ... Dn herunterzuladen, z. B., um ein Backup von dem Gerät D1 ... Dn zu erstellen. Über den Befehl „Send Command“ werden Befehle an das Gerät D1 ... Dn gesendet und über den Befehl „Get Progress Info“ können Fortschritts-Informationen während der Lade-Sequenz abgefragt werden.
-
Mittels des Notifikations-Services NS können über die Operation „Send Notification“ Nachrichten an das Gerät D1 ... Dn gesendet werden. Der Notifikations-Ansatz verwendet im Vergleich zu den üblichen Ladeverfahren ein abweichendes Ladeverfahren, welches die Lade-Services, Informations-Services sowie Verbindungs-Services benutzt. Je nach eintreffender Nachricht kann das Gerät selbst entscheiden was die Folgeaktivität ist, z. B. das Herunterladen der Firmware-Datei von einem Server oder nach einer vom Benutzer gemachten Bestätigungseingabe.
-
Über den Discovery-Service DCS, der vollkommen unabhängig von den anderen Services ist, können Geräte einheitlich in einem Netzwerk aufgefunden werden.
-
7a) zeigt rein schematisch eine Kommunikation zwischen der Anwendungs-Software AS des Lade-Tools LT mit dem Gerät D1 ... Dn über die in dem Lade-Tool LT implementierte Device-Service-Infrastruktur DSI auf Basis des „Cached Loading“. Nach dem obligatorischen Verbindungsaufbau über den Befehl „Connect“ (nicht in Figur dargestellt) fragt die Anwendungs-Software AS über den Befehl „Get Device Information“ des Informations-Services IS Geräte-Eigenschafts-Informationen des Geräts D1 ... Dn ab. Nach Empfang der Geräte-Eigenschafts-Informationen erfolgt ein Abgleich der Informationen, insbesondere das Auffinden gemeinsamer Lademöglichkeiten. Unabhängig davon wird eine Kompatibilitätsprüfung durchgeführt, um festzustellen, ob das Firmware-Update überhaupt für das Gerät bestimmt und installiert ist.
-
In einem weiteren Schritt wird das Datenpaket DP von dem Lade-Tool LT durch die Operation „Download“ des Lade-Services LS in das Gerät geladen. Anschließend werden über die Operation „Send Command“ Befehle an das Gerät gesendet um dieses in einen Status bzw. Modus zu versetzen, der den Datentransfer und die Firmware-Installation ermöglicht.
-
In der daran anschließenden Initiierungsphase wird der Installationsbefehl über die Anwendungs-Software AS des Lade-Tools LT der Operation „Send Command“ an das Gerät D1 ... Dn gesendet, mit dem die Installation der Firmware in dem Gerät gestartet wird. Während der Installation kann ein Befehl „Get Progress Info“ gesendet werden, um den Status des Firmware-Updates abzufragen.
-
Nach Abschluss der Installation sendet die Anwendungs-Software AS über den Informations-Service den Befehl „Get Device Information“, um zu überprüfen, ob der Update-Vorgang der Firmware erfolgreich verlaufen ist.
-
7b) zeigt rein schematisch eine alternative Kommunikation zwischen der Anwendungs-Software AS des Lade-Tools LT und dem Gerät D1 ... Dn, bei welcher der Lade-Vorgang mit den verfügbaren Anpassungsmöglichkeiten an die individuellen Gegebenheiten des Ziel-Geräts angepasst werden. Bei dieser Ausführungsform ist in dem Datenpaket DP ergänzend zu den Firmware-Dateien und den firmwarespezifischen Lade-Informationen eine Skript-Datei enthalten, über die der Ladevorgang der Firmware-Datei entsprechend den Merkmalen und Besonderheiten des Gerätes gesteuert werden kann.
-
Die weiteren Verfahrensschritte entsprechen den gemäß 7a) beschriebenen Verfahrensschritten.
-
8 zeigt rein schematisch eine Service-Architektur SAL zur Durchführung einer Protokoll-Umsetzung (Mapping). Mapping bedeutet, dass die generischen Device-Service-Operationen auf konkrete Protokolle abgebildet werden, um die Kommunikation über Operationen auf einem speziellen Protokoll zu ermöglichen. Dabei werden protokoll-spezifische Befehle als auch Datenformate verwendet, auf die sowohl die Service-Operationen als auch die operations-spezifischen Daten umgewandelt werden. Der Zugriff durch ein Tool / eine Software auf das gemappte Protokoll findet aber immer noch über die generische Service-Schnittstelle statt und nicht über die Protokoll-Umsetzung.
-
Die Service-Architektur SAL umfasst den aus 5 bekannten Service-Layer SL sowie – diesem untergeordnet – einen Mapping-Layer ML, einen Protokoll-Layer PL sowie einen Transport-Layer TL. Übergreifend sind die einzelnen Layer der Service-Architektur SAL über ein Service-Datenmodell SDM sowie ein Sicherheits-Modell SM gekoppelt.
-
Die Device-Services DS des Service-Layer SL sind ihrerseits protokollunabhängig, um einen einheitlichen Kommunikations-Mechanismus zu ermöglichen.
-
Allerdings können die Device-Services DS auf verschiedene Protokolle wie MODBUS, FTP (S), EtherNet/IP sowie LWM2M unter Verwendung von Service-Data-Mapping-Informationen DMI der Mapping-Layer ML gemappt bzw. umgesetzt werden. Die einzelnen Kommunikationsprotokolle wie MODBUS, FTP (S) sowie EtherNet/IP stellen jeweils Transportmechanismen wie SL, USB und/oder TCP/IP des Transport-Layer TL zur Verfügung. Für das Protokoll LWM2M wird als Transportmechanismus UDP verwendet.
-
Alternativ besteht auch die Möglichkeit, als Transportmechanismus ein portables Medium wie USB-Stick oder SD-Card zu verwenden. Das erfindungsgemäße Verfahren ermöglicht auf einfache Weise die Erweiterung auf weitere Protokolle und Transportmechanismen.
-
Gemäß einem eigenständigen Erfindungsgedanken bezieht sich die Erfindung auf eine standardisierte Beschreibung von Daten wie Anwendungs-Dateien, Konfigurations-Dateien und/oder Firmware-Dateien in Form eines standardisierten Datenpakets ADP, CDP, FWDP.
-
9 zeigt die gegenwärtige Situation, bei der Anwendungs-Dateien AF, Konfigurations-Dateien CF sowie Firmware-Datei FWF nur über entsprechende dezidierte Software-Tools SPT, CST, FLT verarbeitet werden können.
-
Gemäß der Erfindung werden Datenpakete ADP, CDP, FWDP definiert, welche die Daten in Form von Anwendungs-Dateien AF, Konfigurations-Dateien CF sowie Firmware-Dateien FWF enthalten, und denen zusätzlich Paket-Metadaten MD beigefügt sind, die den Inhalt sowie die Strukturierung des Inhalts der Daten-Pakete ADP, CDP, FWDP in allgemeiner Form beschreiben. Dadurch können unterschiedliche Arten von Inhalt in einer einheitlichen Form sowie die Datenpakete in unterschiedlichen Tools SPT, CST, FLT und/oder Systemen einheitlich verwendet werden. Mit anderen Worten: die Metadaten der Datenpakete ADP, CDP, FWDP enthalten Wissen über deren Inhalt.
-
Des Weiteren enthalten die Datenpakete ADP, CDP, FWDP Informationen über den Verwendungszweck und besondere Merkmal (Abhängigkeiten, Kompatibilitätsaspekte) ihres Inhalts. Diese Informationen sind mittels einer erweiterten bzw. spezialisierten Metadaten-Beschreibung in dem Datenpaket enthalten. Die Informationen sind abhängig vom Typ des Inhalts. Das bedeutet, dass für jeden Typ ein eigenes standardisiertes Metadaten-Beschreibungsschema bzw. -Syntax definiert ist. Dies schließt z. B. die Empfänger-Adresse sowie deren Zweck mit ein. Ergänzend können spezielle Rooting-Pfade z. B. für Sub-Module oder Sub-Netzwerke in der Datenpaket-Beschreibung mitgeliefert werden.
-
Die Datenpakete enthalten auch Informationen darüber, wie die Daten benutzt oder angewendet werden sollen, z. B. wie die Daten oder das Datenpaket mit Geräten ausgetauscht werden können oder wie eine Software-Library auf dem Zielgerät installiert werden kann. Ferner können in den Datenpaketen Befehlslisten enthalten sein, die das verarbeitende Tool SPT, CST, FLT oder das jeweilige Gerät befähigen, eine Sequenz von notwendigen Schritten auszuführen. Die Datenpakete ADP, CDP, FWDP beschreiben weiterhin, welche notwendigen Anforderungen zur Benutzung oder Anwendung des Inhalts der Datenpakete mit dem Zielgerät zu beachten sind. Des Weiteren enthält das Datenpaket Informationen über die Kompatibilität und Abhängigkeiten, die zu berücksichtigen sind, wenn der Inhalt benutzt wird.
-
Über einen gemeinsamen Paket-Frame werden die interne Datei-Organisation und die äußere Erscheinung definiert. Jedermann kann das Datenpaket identifizieren und weiß genau, wo bestimmte Dateien in dem Datenpaket platziert sind.
-
Die Datenpakete sind als Basis- und detaillierte Teile definiert. Dies ermöglicht die Erweiterbarkeit für neue Domains oder Anforderungen in einfacher Weise. Ein Datenpaket kann verschiedene Typen von Dateninhalten in üblicher Art und Weise beschreiben, wie z. B. Firmware-Updates, Software-Libraries, Konfigurations-Daten oder Geräte-Anwendungen.
-
Des Weiteren können mehrere Datenpakete in ein Container-Paket zusammengefasst werden um z. B. Dateninhalte für verschiedene Zielgeräte wie beispielsweise für sämtliche Automatisierungsgeräte eines Produktionssystems oder Bereichs bereitzustellen.
-
Durch die erfindungsgemäßen Datenpakete ist es möglich, unterschiedliche Dateninhalts-Typen in einer allgemeinen Art und Wise zu beschreiben, so dass alle am Kommunikationsablauf beteiligten Komponenten oder Instanzen genau wissen, wie die Daten zu interpretieren sind, um die erforderlichen oder benötigten Informationen zu erhalten.
-
Die Datenpakete sind in ihrer Art als intelligent zu bezeichnen, da sie sowohl ihren Inhalt beschreiben als auch Informationen enthalten, wie der Inhalt zu interpretieren und zu handhaben ist. Die Datenpakete liefern unterschiedliche Arten von Informationen, um imstande zu sein, den Dateninhalt auch ausführen zu können. In diesem Zusammenhang ist anzumerken, dass das Wissen über die Daten und deren Nutzung mit dem Datenpaket selbst und nicht durch das Verarbeitungs-Tool SPT, CST bzw. FLT bereitgestellt werden. Das Tool muss nur die benötigten generischen Services als auch deren allgemeine (Basis-)Ablauf- bzw. Aufruf-Sequenzen bereitstellen.
-
11 zeigt in schematischer Darstellung die Struktur der Datenpakete ADP, CDP, FWDP sowie deren Einbindung in ein Container-Paket CP. Das Container-Paket enthält Paket-Metadaten PMD, die User-spezifische Informationen darüber enthalten, was ein Anwender mit den einzelnen Datenpaketen ADP, CDP, FWDP machen kann. Über einen Assignment-Layer AL erfolgt via Adresse ADR eine Zuweisung zu den gewünschten Datenpaketen ADP, CDP, FWDP.
-
Die zuvor wiedergegebene Inhaltsbeschreibung des jeweiligen Datenpaketes ist in sogenannten Paket-Metadaten PMD enthalten, die innerhalb des Datenpakets auf spezifische bzw. detaillierte Metadaten wie Firmware-Metadaten FWMD oder Anwendungs-Metadaten AMD referenzieren, die eine detaillierte Inhaltsbeschreibung enthalten, wie die in den jeweiligen Datenpaketen ADP, CDP, FWDP enthaltenden Dateien, wie Firmware-Dateien FWF oder Anwendungs-Dateien AF, zu behandeln sind, insbesondere welche Lade-Mechanismen zu beachten sind bzw. bei Applikations-Daten, welche Abhängigkeiten zu berücksichtigen sind.
-
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
-
- DE 102006044182 A1 [0002]
