Verfahren zum Update von Firmware von Geräten

Die Erfindung bezieht sich auf ein Verfahren zum Update von Firmware von Geräten wie Automatisierungsgeräten und/oder Energie-Management-Geräten, umfassend die Verfahrensschritte:

- Bereitstellen zumindest einer Firmware-Datei;

- Laden der zumindest einen Firmware-Datei in ein Lade-Tool;

- Verbinden des Lade-Tools mit dem Gerät und

- Übertragen der Firmware-Datei in das Gerät unter Berücksichtigung von Lade- Informationen.

Ein Verfahren der eingangs genannten Art ist in der DE 10 2006 044 182 AI beschrieben. Zur bedarfsgerechten Funktionalisierung von Steuer-/Regeleinrichümgen, 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 bedaifsgemäß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 Dl ... Dn nach dem Stand der Technik ist rein schematisch in Fig. 1 dargestellt. Die Geräte Dl ... 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ätes ggfs. aktualisiert werden muss.

Da die Geräte Dl ... 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 Dl ... 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äß Fig. 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 Geräts D zu laden und ggfs. die Installation der Firmware-Datei zu überwachen.

Nachteilig bei dem bekannten Verfahren ist, dass für unterschiedliche Geräte Dl ... Dn jeweils ein eigenes Lade-Tool LT1 ... LTn 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 die Lade-Informationen ausgegliedert aus dem Lade-Tool auf zumindest einer externen Datenquelle gespeichert und durch das Lade-Tool aus der zumindest einen externen Datenquelle geladen werden.

Gemäß einer bevorzugten Verfahrensweise ist vorgesehen, dass die Lade- Informationen als firmwarespezifische 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. In einem Paket können mehrere Lade-Optionen stehen. Das beinhaltet sowohl unterschiedliche Protokolle als auch verschiedene Lade-Modi. Somit ist es auch möglich, mehrere Geräte an eine Produktgruppe/Familie mit einem Paket zu adressieren, wenn alle auf derselben Firmware-Datei basieren, aber unterschiedliche Protokolle bzw. Lade-Modi unterstützen.

Die gerätespezifischen Lade-Informationen enthalten vorzugsweise Informationen wie Geräte-ID, aktuelle Firmware- Version, Statusinformationen, Speichennformationen, 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-Files 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.

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-Automatisierungsgerä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 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-Tools und Gerät 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 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 Automatisierungsgerä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 Automatisierungsgeräten zu aktualisieren, da keine gerätespezifischen Software- Teile in das Lade-Tool implementiert werden müssen. Ü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 Transportmechanismus 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 zur Verfügung gestellt und anschließend von dem Lade-Tool bzw. der Lade-Software 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: Fig. 1 eine schematische Darstellung eines Verfahrens zum Updaten von

Firmware von Geräten nach dem Stand der Technik,

Fig. 2 eine schematische Darstellung eines Systems zum Updaten von

Firmware eines Gerätes nach dem Stand der Technik,

Fig. 3 eine schematische Darstellung einer ersten Ausführungsform eines

Firmware-Management-Systems zum Updaten von Firmware eines Gerätes gemäß der Erfindung,

Fig. 4 eine schematische Darstellung einer zweiten Ausführungsform eines

Firmware-Management-Systems,

Fig. 5 eine schematische Darstellung einer Anwendungs- und Service-Layer-

Architektur des Lade-Tools, eine schematische Darstellung von Service-Domains einer Device- Service-Infrastruktur des Lade-Tools,

Fig.7a), b) schematische Darstellungen von Kommunikations-Diagrammen zwischen Lade-Tool und Automatisierungsgerät,

Fig. 8 eine schematische Darstellung einer Service-Architektur-Schicht,

Fig. 9 eine schematische Darstellung eines Verfahrens zum Laden von

Anwendungs-, Konfigurations- und/oder Firmware-Dateien über unterschiedliche Lade-Tools nach dem Stand der Technik,

Fig. 10 eine schematische Darstellung eines Verfahrens zum Laden von

Datenpaketen über unterschiedliche Lade-Tools gemäß der Erfindung und Fig. 11 eine schematische Darstellung einer Datenstruktur von Datenpaketen umfassend Paket-Meta-Daten sowie Firmware-, Konfigurationsund/oder Anwendungs-Dateien.

Fig. 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 Dl ... Dn mit unterschiedlichen Geräteeigenschaften und/oder Geräteanforderungen. Die Geräte Dl ... 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 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 Fig. 3 dargestellten Ausführungsbeispiel können die Geräte- Eigenschafts-Informationen DI in dem Gerät Dl ... Dn bereitgestellt und über einen definierten Kommunikationsbefehl, welcher von jedem einzelnen individuellen Gerät Dl ... 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 Dl ... 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 Dl ... Dn zu senden bzw. zu empfangen.

Fig. 4 zeigt rein schematisch eine eigenerfinderische zweite Ausführungsform eines Firaiware-Management-Systems FMS2 zur Aktualisierung von Firmware FW von Geräten Dl, 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 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 Dil, über welches Datenpakete DP in eine Datenbank DPDB des Datenspeichers DPI 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 sowohl eine manuelle als auch automatische (zyklische) Überprüfung oder Abfrage nach neuen oder noch nicht - gemäß der Geräteliste - vorhandenen Updates beinhalten.

Des Weiteren umfasst das Firmware-Management-Gerät FMU ein anpassbares Netzwerk- Interface NI, in das verschiedene Kommunikations-Protokoll Nil, NI2, NI3 wie beispielsweise Modbus, EtherNet-IP oder FTP als sogenannte „Plug-ins" implementierbar sind. Das Netzwerk-Interface NI ist über einen Netzwerk N mit den Geräten Dl, D2, D3 verbunden.

Ferner umfasst das Firmware-Management-Tool FMT ein Lade-Tool-Interface LTI zur Implementierung verschiedener Lade-Tools LTI, LT2, LT3, die verschiedene Kommunikations- und Transportmechanismen zum Download der Datenpakete in die Geräte Dl, D2, D3 zur Verfügung stellen.

Gemäß eines erfinderischen Gedankens ist vorgesehen, dass über das Daten-Interface Dil oder über das Daten-Interface DI2 importierter Datenpakete DP in der Datenbank DPDB des Datenspeichers DR1 gespeichert werden.

Ein weiteres erfinderisches Merkmal sieht vor, dass zumindest eines der Netzwerk- Interfaces Nil, NI2, NI3 ausgebildet ist, entsprechend der Ausprägung des Netzwerkes N, Geräte Dl, D2, D3 des Netzwerks N zu erkennen und deren gerätespezifischen Lade- Information Dil, DI2, DI3 zu erfassen. Die erkannten Geräte Dl, D2, D3 sowie deren gerätespezifischen Lade-Informationen Dil, DI2, DI3 werden als eine Geräteliste DL bzw. Netzwerktopologie NT in einer Datenbank DLDB des zweiten Datenspeichers DR2 gespeichert.

Durch das Fkmware-Management-Tool FMT erfolgt eine Analyse der in den Datenbanken DLDB, DPDB enthaltenen Informationen wobei auf der Grundlage der Geräteinformationen Dil, DI2, DI3, welche Geräte-ID-Informationen, aktuelle Firmware- Versions-Informationen, Geräte-Typ-Informationen, Speicherinformationen und/oder Lade-Informationen enthalten, sowie der firaiwarespezifischen Informationen FWI, welche die Information enthält, welches Lade-Tool verwendet werden soll, eine Auswahl getroffen wird, bei welchem Gerät Dl, D2, D3 und mit welchen Ladeparametern und welches Lade"Plug-in" die Firmware FWI, FW2, FW3 aktualisiert werden soll.

Nach Auswahl eines gewünschten Datenpakets DP werden durch das Firmware- Management-Tool 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 Dl, 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, dann 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 Daten Verwaltung 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 Nil, NI2, NI3 als sogenannte „Plug-ins" ist das Firmware-Management-Tool FMT in der Lage, verschiedene Arten von Kommunikationswegen, Kommunikationsansätzen, Kommunikationsprotokollen oder Kommunikationsmechanismen zu integrieren bzw. zu nutzen, um mit verschiedenartigen Geräten Dl, 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 oder 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 wiedergespiegelt werden. Ferner ergibt sich die Möglichkeit, eine Momentaufnahme der aktuellen Netzwerkkonfiguration zu erzeugen und abzuspeichern. Dies ermöglicht die Wiederherstellung früherer Konfigurationen von verschiedenen Netzwerken oder das Arbeiten, ohne überhaupt mit dem 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 Nutzbarkeit zur Akquirierung, Verwaltung und zum Download aller wichtigen Informationen durch ein einziges Firmware-Management-Tool FMT. Somit wird die Komplexität für verschiedene Bereiche des Informations- und Datenflusses reduziert.

Fig. 5 zeigt rein schematisch eine Architektur des Lade-Tools LT, umfassend eine Anwendungs schicht 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 Anwendungs-Software AS Informationen betreffend die Anwendung von Device-Services DS, um die Firmware-Dateien in das entsprechende Gerät Dl ... 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.

Fig. 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" keine 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 beispielsweise 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 Dl ...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 Dl ... Dn zu laden. Auch besteht die Möglichkeit, Daten oder Dateien aus dem Gerät Dl ... Dn herunterzuladen, z. B., um ein Backup von dem Gerät Dl ... Dn zu erstellen. Über den Befehl„Send Command" werden Befehle an das Gerät Dl ... 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 Dl ... Dn gesendet werden. Der Notifikations- Ansatz verwendet ein 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.

Fig. 7a) zeigt rein schematisch eine Kommunikation zwischen der Anwendungs- Software AS des Lade-Tools LT mit dem Gerät Dl ... 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 Dl ... 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 Dl ... 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 mit dem Befehl„Get Device Information", um zu überprüfen, ob der Update- Vorgang der Firmware erfolgreich verlaufen ist.

Fig. 7b) zeigt rein schematisch eine alternative Kommunikation zwischen der Anwendungs-Software AS des Lade-Tools LT und dem Gerät Dl ... Dn, bei welcher der Lade-Vorgang mit den verfügbaren Anpassungsmöglichkeiten an die individuellen Gegebenheiten des Gerätes angepasst wurde. Bei dieser Ausführungsform ist in dem Datenpaket DP ergänzend zu den Firmware-Dateien und den firmwarespezifischen Lade-Informationen eine Skriptdatei enthalten, über die der Ladevorgang der Firmware- Datei entsprechend den Besonderheiten des Gerätes gesteuert werden kann.

Die weiteren Verfahrensschritte entsprechen den gemäß Fig. 7a) beschriebenen Verfahrensschritten.

Fig. 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-spezifische Daten umgewandelt werden. Der Zugriff durch ein Tool bzw. eine Software auf das umgesetzte Protokoll findet aber immer noch über die einheitliche und generische Service-Schnittstelle statt und nicht über die Protokoll-Umsetzung selbst. Die Service- Architektur SAL umfasst die aus Fig. 5 bekannte Service-Layer SL sowie - dieser untergeordnet - eine Mapping-Layer ML, eine Protokoll-Layer PL sowie eine 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 der 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 umgesetzt werden. Die einzelnen Kommunikationsprotokolle wie MODBUS, FTP (S) sowie EtherNet/IP stellen jeweils Transportmechanismen wie SL, USB und/oder TCP/IP der 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-Stich oder SC-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.

Fig. 9 zeigt die gegenwärtige Situation, bei der Anwendungs-Dateien AF, Konfigurations-Dateien CF sowie Firmware-Datei FWF nur über entsprechende 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 mitgeteilt 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-Rahmen wird 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 erfindungs gemäß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 wird. Das Tool muss nur die benötigten generischen Services als auch deren allgemeine (Basis-) Ablauf- bzw. Aufruf-Sequenzen bereitstellen.

Fig. 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.