Verfahren zur Softwareaktualisierung bei Cloud-Gateways , Computerprogramm mit einer Implementation des Verfahrens und Verarbeitungseinheit zur Ausführung des Verfahrens

Die Erfindung betrifft zuvorderst ein Verfahren zur Software ^¬ aktualisierung bei Cloud-Gateways. Die Erfindung betrifft im Weiteren ein Computerprogramm mit einer Implementation des Verfahrens sowie eine Verarbeitungseinheit, zum Beispiel in Form eines Rechnerknotens in der Cloud, zur Ausführung des Verfahrens .

Die Verwendung von Cloud-Diensten wird mehr und mehr üblich und zwar auch für sogenannte I IoT-Anwendungen (IIoT = Indus- trial Internet of Things) . In diesem technischen Kontext sind zum Beispiel Sensoren und Aktoren, Automatisierungsgeräte, zum Beispiel speicherprogrammierbare Steuerungen, dezentrale Feldgeräte und dergleichen, oder gesamte Automatisierungssys- teme, zum Beispiel in Form eines Netzwerks der vorgenannten Automatisierungsgeräte sowie angeschlossener Sensorik und Aktorik, mit der Cloud über im Folgenden kurz als Gateways bezeichnete sogenannte Cloud-Gateways verbunden. Bei einem solchen Gateway handelt es sich um ein insbesondere am Ort der jeweiligen Automatisierungslösung installiertes Modul oder Gerät, welches die Schnittstelle zwischen den zur Auto ^¬ matisierungslösung gehörigen Funktionseinheiten (Sensoren, Aktoren, Automatisierungsgeräte, Maschinen, Aggregate und An ^¬ lagen oder Anlagenteile der Automatisierungslösung usw.) oder einer Gruppe derartiger Funktionseinheiten und der Cloud bildet. Das Gateway sammelt die Daten von Funktionseinheiten der vorgenannten Art und leitet diese an eine jeweilige Cloud- Plattform mit Automatisierungsfunktio ^¬ nen/Automatisierungsdiensten weiter. Im Zusammenhang mit ei- ner solchen Weiterleitung kann eine optionale Vorverarbeitung der Daten und/oder eine Verschlüsselung der Daten erfolgen. Mittels des Gateways kann auch ein geschlossener Regelkreis gebildet sein, wenn die Regelungsfunktion als Dienst in der Cloud implementiert ist und im Rahmen der Regelung aus der Automatisierungslösung stammende Daten verarbeitet und innerhalb der Cloud als Regelgröße oder Regelgrößen für eine Funk ^¬ tionseinheit der Automatisierungslösung bestimmte Daten er- zeugt werden.

Jedes Gateway fungiert als eigenständige Schnittstelle zwi ^¬ schen einer jeweiligen Automatisierungslösung zur Steuerung und/oder Überwachung eines technischen Prozesses oder einer Gruppe einzelner Funktionseinheiten einer Automatisierungslösung und der Cloud. Zur Nutzung von I IoT-Diensten ist eine Automatisierungslösung über zumindest ein Gateway oder eine Gruppe von Gateways mit der Cloud verbunden. Bei einer Viel ^¬ zahl von mit der Cloud verbundenen Automatisierungslösungen resultiert entsprechend auch eine Vielzahl von Gateways. Im Sinne einer sprachlichen Vereinfachung, aber ohne Verzicht auf eine weitergehende Allgemeingültigkeit, wird die nachfol ^¬ gende Beschreibung auf Basis jeweils genau eines Gateways für eine Automatisierungslösung, welches gewissermaßen „seine" jeweilige Automatisierungslösung mit der Cloud verbindet, fortgesetzt .

Ein als Gateway im oben genannten Sinne fungierendes Gerät ist in geeigneter Weise mit dem Internet verbunden und über das Internet erfolgt in grundsätzlich an sich bekannter Art und Weise die Verbindung mit der jeweiligen Cloud-Plattform und dort vorgehaltenen I IoT-Diensten . Die Verbindung mit dem Internet bedeutet allerdings ein nicht unerhebliches Sicher ^¬ heitsrisiko. Dieses ist nicht nur auf das Gateway selbst be- schränkt, sondern erstreckt sich auch auf die jeweilige Auto ^¬ matisierungslösung, denn bei einem Ausfall oder einer Fehlfunktion des Gateways ist unmittelbar auch die Automatisie ^¬ rungslösung betroffen. Die Angreifbarkeit eines Gateways über das Internet kann daher auch für einen Angriff auf die mit dem Gateway jeweils verbundene Automatisierungslösung genutzt werden. Aus diesem Grunde sind Funktions- oder Sicherheitsaktualisierungen und dergleichen - im Folgenden zusammenfassend als Softwareaktualisierung oder kurz als Update bezeichnet - der Systemsoftware des Gateways von immenser Bedeutung.

Updates der oben genannten Art stellen allerdings auch selbst ein grundsätzliches Risiko für die ordnungsgemäße Funktion eines Gateways dar. Bei einem fehlerhaften Update oder einem fehlgeschlagenen Update ist die ordnungsgemäße Funktion des Gateways oftmals nicht mehr gegeben. Dies beeinträchtigt in der Folge auch die Funktion der angeschlossenen Automatisie- rungslösung oder stellt deren Funktion sogar vollständig in- frage . Fehlfunktionen des Gateways aufgrund eines fehlerhaf ^¬ ten oder fehlgeschlagenen Updates können zur Folge haben, dass mittels des Gateways übermittelte Daten nicht mehr oder nicht mehr in ordnungsgemäßer Form zur Verfügung stehen. Dies oder andere aufgrund eines fehlerhaften oder fehlgeschlagenen Updates resultierende Fehler können zu Fehlfunktionen in der Automatisierungslösung oder einem nicht definierten Verhalten der Automatisierungslösung mit potenziell desaströsen Ergebnis führen.

Derzeit wird bei einem Software-Update für ein Cloud-Gateway oder eine Mehrzahl von Cloud-Gateways die Art der angeschlos ^¬ senen und über das jeweilige Cloud-Gateway mit der Cloud ver ^¬ bundenen Geräte nicht berücksichtigt. Damit kann bei einem Software-Update nicht in Betracht gezogen werden, welches Ri ^¬ siko sich eventuell ergibt, wenn ein Software-Update schei ^¬ tert .

Eine Aufgabe der vorliegenden Erfindung besteht damit darin, eine Lösung für dieses Problem anzugeben.

Diese Aufgabe wird erfindungsgemäß mittels eines Verfahrens zur Softwareaktualisierung einer Mehrzahl von Cloud-Gateways (Gateways) mit den Merkmalen des Anspruchs 1 gelöst. Dazu sind bei einem Verfahren zur Softwareaktualisierung (Update) einer Mehrzahl von Gateways, wobei über die Gateways Automa ^¬ tisierungslösungen an die Cloud angeschlossen sind, folgende Schritte vorgesehen: In einem ersten Schritt wird eine Rangfolge der Gateways ent ^¬ sprechend einem Gefahrenpotenzial der oder jeder an die Gate ^¬ ways angeschlossenen Automatisierungslösung ermittelt.

In einem zweiten Schritt erfolgt das Update des Gateways oder einer Gruppe von Gateways mit dem geringsten Gefahrenpotenzial . In einem dritten Schritt wird der Erfolg des im vorangehenden zweiten Schritt erfolgten Updates überprüft.

In einem vierten Schritt wird das Updaten mit einem Gateway oder einer Gruppe von Gateways mit dem nächsthöheren Gefah- renpotenzial fortgesetzt, wenn in dem dritten Schritt zum Überprüfen des Erfolgs des vorangehenden Updates ermittelt wurde, dass das Update fehlerfrei erfolgt ist, oder das Upda ^¬ ten abgebrochen, wenn in dem dritten Schritt zum Überprüfen des Erfolgs des vorangehenden Updates ermittelt wurde, dass das Update nicht fehlerfrei erfolgt ist.

Wenn in dem dritten Schritt zum Überprüfen des Erfolgs des vorangehenden Updates ermittelt wurde, dass das Update feh ^¬ lerfrei erfolgt ist und anschließend entsprechend der vierte Schritt ausgeführt wurde, werden danach der dritte und der vierte Schritt wiederholt und das Updaten so lange fortge ^¬ setzt, bis das Update auch für das Gateway oder eine Gruppe von Gateways mit dem höchsten Gefahrenpotenzial erfolgt ist oder das Updaten zwischenzeitlich aufgrund eines nicht feh- lerfreien Updates abgebrochen wurde.

Der Vorteil des hier vorgeschlagenen Verfahrens besteht da ^¬ rin, dass das Update entsprechend der ermittelten Rangfolge der Gateways mit dem Gateway oder einer Gruppe von Gateways mit dem geringsten Gefahrenpotenzial beginnt. Sollten dabei Fehler auftreten, betrifft dies Gateways mit einem höheren Gefahrenpotenzial und vor allem auch deren Automatisierungs ^¬ lösungen nicht. Bei einem Abbruch des Verfahrens aufgrund ei- nes fehlgeschlagenen Updates kann die Fehlerursache ermittelt und bereinigt werden und das Verfahren zu einem späteren Zeitpunkt erneut ausgeführt werden, bis schließlich das Up ^¬ date für alle Gateways und darunter auch das Gateway oder ei ^¬ ne Gruppe von Gateways mit dem höchsten Gefahrenpotenzial er ^¬ folgreich ausgeführt wurde.

Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche. Dabei verwendete Rückbeziehungen weisen auf die weitere Ausbildung des Gegenstandes des Hauptanspru ^¬ ches durch die Merkmale des jeweiligen Unteranspruches hin. Sie sind nicht als ein Verzicht auf die Erzielung eines selb ^¬ ständigen, gegenständlichen Schutzes für die Merkmalskombinationen der rückbezogenen Unteransprüche zu verstehen. Des Weiteren ist im Hinblick auf eine Auslegung der Ansprüche sowie der Beschreibung bei einer näheren Konkretisierung eines Merkmals in einem nachgeordneten Anspruch davon auszugehen, dass eine derartige Beschränkung in den jeweils vorangehenden Ansprüchen sowie einer allgemeineren Ausführungsform des gegenständlichen Verfahrens zum sicheren Verbinden von Geräten mit der sogenannten Cloud nicht vorhanden ist. Jede Bezugnahme in der Beschreibung auf Aspekte nachgeordneter Ansprüche ist demnach auch ohne speziellen Hinweis ausdrücklich als Beschreibung optionaler Merkmale zu lesen.

Allgemein ergibt sich die Rangfolge der Gateways anhand des zu ermittelnden Gefahrenpotenzials der jeweils angeschlosse ^¬ nen Automatisierungslösung. Bei einer Ausführungsform des Verfahrens wird zum Ermitteln des Gefahrenpotenzials der ein ^¬ zelnen Automatisierungslösungen das Gefahrenpotenzial von zu den einzelnen Automatisierungslösungen gehörenden Funktionseinheiten (Assets) betrachtet. Demgemäß wird bei einer Aus ^¬ führungsform des Verfahrens beim Ermitteln einer Rangfolge der Gateways entsprechend einem Gefahrenpotenzial der oder jeder an die Gateways angeschlossenen Automatisierungslösung ein Gefahrenpotenzial der zu einer Automatisierungslösung gehörenden Funktionseinheiten (Assets) berücksichtigt. Dieses wiederum wird anhand von vorgegebenen oder vorgebbaren Daten einer in der Cloud vorgehaltenen Datenbank (Asset-Meta-Daten- bank) ermittelt. Eine solche Datenbank ermöglicht eine dyna ^¬ mische Anpassung der bei der Ermittlung des Gefahrenpotenzials berücksichtigten Daten. Die Anpassung kann zum Beispiel durch einen Betreiber einer jeweiligen Automatisierungslösung und/oder den Betreiber der Cloud-Plattform erfolgen.

Bei einer besonderen Ausführungsform des für die Ermittlung des Gefahrenpotenzials auf einer solchen Datenbank basieren- den Verfahrens gehört zu den Daten in der Datenbank ein

Schätzwert bezüglich des Gefahrenpotenzials der jeweiligen Funktionseinheit (Asset) . Auf diese Weise kann zum Beispiel bei der Inbetriebnahme einer Automatisierungslösung ein von der jeweiligen Automatisierungslösung abhängiger Wert für das Gefahrenpotenzial angegeben werden, denn zum Beispiel ein

Temperaturregler kann sowohl relativ unkritische Funktionen wie auch sicherheitsrelevante Funktionen erfüllen. Die Mög ^¬ lichkeit einer Eingabe eines Schätzwerts durch einen Program ^¬ mierer, einen Inbetriebnehmer oder einen Betreiber der jewei- ligen Automatisierungslösung ermöglicht demnach eine besonders einfache Berücksichtigung der tatsächlichen Verhältnisse der jeweiligen Automatisierungslösung.

Bei einer weiteren Ausführungsform des Verfahrens wird beim Ermitteln einer Rangfolge der Gateways entsprechend einem Ge ^¬ fahrenpotenzial der oder jeder an die Gateways angeschlosse ^¬ nen Automatisierungslösung alternativ oder zusätzlich ein Betriebszustand der zu einer Automatisierungslösung gehörenden Funktionseinheiten (Assets) berücksichtigt. Auf diese Weise kann zum Beispiel das Gefahrenpotenzial eines Gateways mit einer oder zumindest einer potenziell äußerst kritischen Automatisierungslösung sinken, wenn diese zum Beispiel nicht in Betrieb ist. Die Berücksichtigung des Betriebszustands er ^¬ laubt eine Anpassung des Verfahrens nicht nur an die durch eine Kategorisierung der Automatisierungslösungen und der davon umfassten Funktionseinheiten ausgedrückten statischen Verhältnisse, sondern auch an die momentanen Gegebenheiten, also zum Beispiel einen Zustand Automatisierungslösung (Auto- matisierungslösung oder eine davon umfasste Funktionseinheit läuft oder läuft nicht oder ist aus anderen Gründen - Wartung oder dergleichen - nicht in Betrieb) . Daten zum Betriebszustand der Funktionseinheiten werden vorteilhaft in einer in der Cloud vorgehaltenen weiteren Datenbank (Asset-State-Datenbank) verfügbar gemacht und sind dann innerhalb der Cloud für die Ermittlung der Rangfolge der Ga ^¬ teways genau wie die Daten in der Asset-Meta-Datenbank ver- fügbar.

Bei einer weiteren Ausführungsform des Verfahrens erfolgt dessen Ausführung einerseits mittels eines Bewertungsdienstes (Criticality Ranking Service) sowie mittels eines Update- Service (Software Update Roll-out Service) jeweils in der Cloud. Mittels des Bewertungsdienstes (Criticality Ranking Service) erfolgt das Ermitteln der Rangfolge der Gateways. Mittels des Update-Service (Software Update Roll-out Service) erfolgt das Updaten eines Gateways oder einer Gruppe von Ga- teways, das Überprüfen des Erfolgs eines Updates sowie das Abbrechen des Updatens oder das Fortsetzen des Updatens ab ^¬ hängig vom Erfolg des bisherigen Updates. Dadurch sind die wesentlichen Funktionen des hier vorgeschlagenen Verfahrens voneinander getrennt. Dies erleichtert die Implementation des Verfahrens in Software und die Wartung eines resultierenden Computerprogramms .

Die eingangs genannte Aufgabe wird auch mittels einer als Knotenrechner in der Cloud fungierenden Verarbeitungseinheit oder dergleichen gelöst, indem diese Mittel zur Ausführung des hier und im Folgenden beschriebenen Verfahrens umfasst. Die Erfindung ist bevorzugt in Software implementiert. Die Erfindung ist damit einerseits auch ein Computerprogramm mit durch einen Computer in Form der Verarbeitungseinheit aus- führbaren Programmcodeanweisungen und andererseits ein Speichermedium mit einem derartigen Computerprogramm, also ein Computerprogrammprodukt mit Programmcodemitteln, sowie schließlich auch eine Verarbeitungseinheit, in deren Speicher als Mittel zur Ausführung des Verfahrens und seiner Ausge ^¬ staltungen ein solches Computerprogramm geladen oder ladbar ist .

Für die weitere Beschreibung gilt zur Vermeidung unnötiger Wiederholungen, dass Merkmale und Details, die im Zusammen ^¬ hang mit dem genannten Verfahren zur Softwareaktualisierung einer Mehrzahl von Cloud-Gateways sowie eventueller Ausgestaltungen beschrieben sind, selbstverständlich auch im Zusammenhang mit und im Hinblick auf die zur Ausführung des Verfahrens bestimmte und eingerichtete Verarbeitungseinheit und umgekehrt gelten, so dass die Verarbeitungseinheit auch entsprechend einzelner oder mehrerer Verfahrensmerkmale fort gebildet sein kann, indem die Verarbeitungseinheit Mittel zu deren Ausführung umfasst.

Das im Folgenden beschriebene Verfahren zur Softwareaktuali ^¬ sierung einer Mehrzahl von Cloud-Gateways ist zur automati ^¬ schen Ausführung in Form eines Computerprogramms, ggf. auch in Form eines verteilten Computerprogramms, implementiert. Das Computerprogramm ist zur Ausführung zum Beispiel durch eine als Knotenrechner in der Cloud fungierende Verarbei ^¬ tungseinheit bestimmt. Wenn im Folgenden Verfahrensschritte oder Verfahrensschrittfolgen beschrieben werden, bezieht sie dies auf Aktionen, die automatisch und ohne Eingriff eines Benutzers aufgrund des Computerprogramms oder unter Kontroll des Computerprogramms erfolgen. Zumindest bedeutet jede Ver ^¬ wendung des Begriffs „automatisch", dass die betreffende Ak ^¬ tion aufgrund des Computerprogramms oder unter Kontrolle des Computerprogramms erfolgt.

Für den Fachmann ist selbstverständlich, dass anstelle einer Implementation des hier vorgeschlagenen Verfahrens in Software genauso auch eine Implementation in Firmware oder in Firm- und Software oder in Firm- und Hardware möglich ist. Daher soll für die hier vorgelegte Beschreibung gelten, dass von dem Begriff Software oder dem Begriff Computerprogramm auch andere Implementationsmöglichkeiten, nämlich insbesonde re eine Implementation in Firmware oder in Firm- und Software oder in Firm- und Hardware, umfasst sind.

Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand der Zeichnung näher erläutert. Einander entsprechende Gegenstände oder Elemente sind in allen Figuren mit den gleichen Bezugszeichen versehen.

Das Ausführungsbeispiel ist nicht als Einschränkung der Er ^¬ findung zu verstehen. Vielmehr sind im Rahmen der vorliegenden Offenbarung durchaus auch Ergänzungen und Modifikationen möglich, insbesondere solche, die zum Beispiel durch Kombina ^¬ tion oder Abwandlung von einzelnen in Verbindung mit den im allgemeinen oder speziellen Beschreibungsteil beschriebenen sowie in den Ansprüchen und/oder der Zeichnung enthaltenen Merkmalen oder Verfahrensschritten für den Fachmann im Hinblick auf die Lösung der Aufgabe entnehmbar sind und durch kombinierbare Merkmale zu einem neuen Gegenstand oder zu neu ^¬ en Verfahrensschritten bzw. Verfahrensschrittfolgen führen.

Es zeigen

FIG 1 die sogenannte Cloud mit daran angeschlossenen Cloud- Gateways und wiederum daran angeschlossenen und über die Cloud-Gateways mit der Cloud und zum Beispiel ei ^¬ ner dort vorgehaltenen Cloud-Plattform mit IIoT- Diensten verbundenen Automatisierungslösungen,

FIG 2 eine schematisch vereinfachte Darstellung als Basis für eine Erläuterung des hier vorgeschlagenen Verfahrens zur Softwareaktualisierung einer Gruppe von Cloud-Gateways und

FIG 3 eine schematisch vereinfachte Darstellung des hier vorgeschlagenen Verfahrens in Form eines Flussdiag ^¬ ramms als Basis für ein Computerprogramm mit einer Implementation des Verfahrens.

Die Darstellung in FIG 1 zeigt zur Veranschaulichung der Problematik in schematisch vereinfachter Form die Cloud 10 mit darin vorgehaltenen I IoT-Diensten (IIoT Services) sowie angeschlossenen Automatisierungslösungen 12, 14, 16 zur Steuerung und/oder Überwachung eines technischen Prozesses. Bei den Automatisierungslösungen 12-16 kann es sich um unter- schiedlich kritische Automatisierungslösungen 12-16 handeln. Dafür sind in der Darstellung in FIG 1 schematisch vereinfacht Beispiele gezeigt. Demnach handelt es sich bei einer ersten Automatisierungslösung 12 um eine Automatisierungslösung für eine Energieerzeugungsanlage (Power Plant) mit einer kritischen Turbine, bei einer zweiten Automatisierungslösung 14 um eine Automatisierungslösung für einen sogenannten

Fracking-Prozess zur Öl- oder Gasgewinnung (Fracking Process) und bei einer dritten Automatisierungslösung 16 um eine Automatisierungslösung für einen Fertigungsprozess mit zum Bei- spiel einer CNC-Maschine (Machine Tools) . Jede Automatisie ^¬ rungslösung 12-16 ist über zumindest ein eigenes Cloud- Gateway 20, 22, 24 mit der Cloud 10 verbunden.

Bisher ist die Aktualisierung der Systemsoftware von als Cloud-Gateway 20-24 fungierenden Geräten - im Folgenden kurz nur als Gateway 20-24 bezeichnet - ohne Betrachtung der je ^¬ weils angeschlossenen Automatisierungslösungen 12-16 erfolgt. Es ist leicht vorstellbar, dass bei einem Fehler bei einer solchen Aktualisierung - im Folgenden kurz als Update be- zeichnet - die Auswirkungen in einem Fertigungsprozess (drit ^¬ te Automatisierungslösung 16) grundsätzlich weniger kritisch sind als die Auswirkungen in einer Energieerzeugungsanlage mit einer kritischen Turbine (erste Automatisierungslösung 12) . Wenn, wie bisher, bei einer Verfügbarkeit eines Updates für Gateways 20-24 das Update gleichzeitig bei allen an die

Cloud 10 angeschlossenen Gateways 20-24 oder einer Gruppe von an die Cloud 10 angeschlossenen Gateways 20-24 eingespielt wird, droht im Fehlerfalle eine Fehlfunktion nicht nur in der weniger kritischen dritten Automatisierungslösung 16, sondern auch in der besonders kritischen ersten Automatisierungslö ^¬ sung 12. Dies wird mit dem hier vorgestellten Ansatz vermieden, indem beim Update einzelner Gateways 20-24 in einer Gruppe von Gateways 20-24 eine Rangfolge der an diese jeweils angeschlos ^¬ senen Automatisierungslösungen 12-14 ermittelt und berück- sichtigt wird. Die ermittelte Rangfolge drückt die potenziel ^¬ le Gefahr aus (Criticality) , die mit einem Ausfall oder einer Fehlfunktion der jeweiligen Automatisierungslösung 12-16 einhergeht. Das für die Rangfolge ausschlaggebende Bewertungs ^¬ kriterium wird im Folgenden als Gefahrenpotenzial

(Criticality) bezeichnet.

Für die Ermittlung des Gefahrenpotenzials wird ausgenutzt, dass die im Rahmen einer Automatisierungslösung 12-16 an ein Gateway 20-24 angeschlossenen und im Folgenden mitunter auch als Assets bezeichneten Funktionseinheiten, insbesondere

Funktionseinheiten der eingangs genannten Art, jeweils eine eindeutige Kennzeichnung (Asset-ID; zum Beispiel AI, A2, A3 usw.) besitzen. Genauso haben die Gateways 20-22 eine eindeu ^¬ tige Kennzeichnungen (Gateway-ID; zum Beispiel Gl, G2, G3 usw.). In einer als Asset-Meta-Datenbank fungierenden Datenbank 30 (FIG 2) sind innerhalb der Cloud 10 Daten zu jeder mittels eines Gateways 20-24 an die Cloud 10 angeschlossenen Funktionseinheit (Asset) gespeichert. Diese Daten umfassen eine Kodierung eines mit der jeweiligen Funktionseinheit (As- set) einhergehenden Gefahrenpotenzials (Criticality) , wobei dies zum Beispiel als Schätzwert durch den Betreiber der je ^¬ weiligen Funktionseinheit oder den Entwickler der Automatisierungslösung 12-16, zu der die Funktionseinheit gehört, an ^¬ gegeben wird. Die Daten umfassen des Weiteren optional eine Kodierung der Funktion der jeweiligen Funktionseinheit und machen damit zum Beispiel automatisch erfassbar, ob eine Funktionseinheit als Sensor, Aktor, Regler usw. fungiert. Schließlich umfassen die Daten optional Angaben zum Hersteller, zum Modell und/oder zu einer aktuellen Softwareversion der Funktionseinheit und dergleichen. Diese Daten (Meta-

Daten) werden zum Beispiel bei der Konfiguration der einzelnen Funktionseinheiten, bei deren Anschluss an das jeweilige Gateway 20-24 oder bei der Inbetriebnahme der Automatisie- rungslösung 12-16 vergeben und in der Datenbank 30 innerhalb der Cloud 10 in einer unter der jeweiligen Asset-ID abrufbaren Art und Weise abgelegt. Eine grundsätzlich optionale und als Asset-Zustands-Datenbank (Asset State DB) fungierende weitere Datenbank 32 (FIG 2) um- fasst unter der jeweiligen Asset-ID eine Kodierung eines Betriebszustands der jeweiligen Funktionseinheit. Als insoweit erfasste Zustände kommen zum Beispiel Betriebszustände wie „laufend" (running) , „wartend" (waiting) , „Wartung" (under Maintenance) etc. in Betracht.

Auf Basis der Daten in der Datenbank 30 oder optional auf Basis der Daten in der Datenbank 30 und der weiteren Datenbank 32 erfolgt die Bewertung des Gefahrenpotenzials der einzelnen Automatisierungslösungen 12-16 und die Ermittlung einer Rangfolge der Gateways 20-24. Dafür zeigt die Darstellung in FIG 2 die erwähnten Datenbanken 30, 32, die Gateways 20-24, mittels derer die Automatisierungslösungen 12-16 (FIG 1) an die Cloud 10 angeschlossen sind, sowie einen Bewertungsdienst 34 (Criticality Ranking Service) und einen Update-Service (Software Update Roll-out Service) 36.

Mittels des in der Cloud 10 vorgehaltenen Bewertungsdienstes 34 erfolgt die Ermittlung der Rangfolge der Gateways 20-24. Dafür greift der Bewertungsdienst 34 auf die Datenbank 30 (Asset Meta-data DB) oder optional auf die Datenbank 30 (As ^¬ set Meta-data DB) und auf die weitere Datenbank 32 (Asset State DB) zu und ermittelt für alle angeschlossenen Gateways 20-24 für die wiederum daran angeschlossenen Funktionseinheiten (Assets) das Gefahrenpotenzial der jeweiligen Automati ^¬ sierungslösung 12-16. Dabei wird zum Beispiel zunächst für jedes Gateway 20-24 das Gefahrenpotenzial (Criticality Score) jeder einzelnen daran angeschlossenen Funktionseinheit (As- set) als Funktion zumindest eines Datums oder mehrerer für die jeweilige Funktionseinheit in der Datenbank 30 (Asset Me ^¬ ta-data DB) hinterlegter Daten ermittelt: Criticality Score (AI) = f (dl .. dn) , wobei dl bis dn für in der Datenbank 30 (Asset Meta-data DB) verfügbare Daten steht, zum Beispiel für den Schätzwert für das mit einer Funktionseinheit (Asset) einhergehende Gefah ^¬ renpotenzial (Vendor criticality estimate) . In einem weiteren Schritt wird aus dem so ermittelten Gefahrenpotenzial der einzelnen an ein Gateway 20-24 angeschlossenen Funktionseinheiten (Assets) das Gefahrenpotenzial der an das jeweilige Gateway 20-24 angeschlossenen Automatisierungslösung 12-16 ermittelt. Für die Ermittlung des Gefahrenpotenzials jeweils eines Gateways (CGI, CG2, CG3, ...) 20-24 kommt dabei zum Bei ^¬ spiel die Bildung einer Summe der für die daran angeschlosse ^¬ nen Funktionseinheiten (Assets) ermittelten Gefahrenpotenzia- le in Betracht:

Criticality Score (CGx) =

Criticality Score (AI (CGx) )

+ Criticality Score (A2 (CGx) ) + ...

Damit steht eine automatisch verarbeitbare, insbesondere nu ^¬ merische Kodierung des Gefahrenpotenzials jedes einzelnen Ga ^¬ teways 20-24 zur Verfügung. Auf dieser Basis erfolgt eine Ermittlung einer Rangfolge der Gateways 20-24. Auf Basis dieser Rangfolge erfolgt schließlich das Updaten der Gateways 20-24 mittels des Update-Service 36 und zwar entsprechend der er ^¬ mittelten Rangfolge derart, dass das Update zuerst bei dem Gateway 20-24 mit dem niedrigsten ermittelten Gefahrenpotenzial und zuletzt bei dem Gateway 20-24 mit dem höchsten er- mittelten Gefahrenpotenzial erfolgt. Für Gateways 20-24 mit einem zwischen dem niedrigsten ermittelten Gefahrenpotenzial und dem höchsten ermittelten Gefahrenpotenzial liegenden Gefahrenpotenzial erfolgt das Update in der Reihenfolge der er ^¬ mittelten Gefahrenpotenziale.

Optional kann bei der Ermittlung der Rangfolge der Gateways 20-24 eine Gruppierung erfolgen, zum Beispiel derart, dass Gateways 20-24 mit einem besonders niedrigen Gefahrenpotenzi- al einer ersten Gruppe, Gateways 20-24 mit einem mittleren Gefahrenpotenzial einer zweiten Gruppe und Gateways 20-24 mit einem besonders hohen Gefahrenpotenzial einer dritten Gruppe zugeordnet werden, wobei das Update mittels des Update- Service 36 zuerst und gleichzeitig oder quasi-gleichzeitig für die Gateways 20-24 der ersten Gruppe, danach und gleichzeitig oder quasi-gleichzeitig für die Gateways 20-24 der zweiten Gruppe und wiederum danach und gleichzeitig oder qua ^¬ si-gleichzeitig für die Gateways 20-24 der dritten Gruppe er- folgt.

Die Funktion des Update-Service 36 beschränkt sich dabei nicht auf das Herunterladen und Einspielen eines Updates auf ein Gateway 20-24 oder die Gateways 20-24, sondern umfasst vor allem auch eine Kontrolle des Update-Verlaufs. Das Update wird nämlich nach einem Update für ein Gateway 20-24 oder eine Gruppe von Gateways 20-24 nur dann entsprechend der ermit ^¬ telten Rangfolge fortgesetzt, wenn das Update erfolgreich war. Dies gewährleistet, dass bei einem fehlgeschlagenen oder fehlerhaften Update nur ein Gateway 20-24 oder Gateways 20-24 mit einem niedrigen Gefahrenpotenzial und einer entsprechenden Position in der Rangfolge betroffen ist bzw. sind. Gateways 20-24 mit einem höheren Gefahrenpotenzial sind nicht be ^¬ troffen und die darüber mit der Cloud 10 verbundenen Automa- tisierungslösungen 12-16 werden weiterhin ausgeführt.

Im Einzelnen umfasst das hier vorgeschlagene Verfahren zur Softwareaktualisierung (Update) von Cloud-Gateways (Gateways) 20-24, wobei über die Gateways 20-24 Automatisierungslösungen 12-16 an die sogenannte Cloud 10 angeschlossen sind, insbe ^¬ sondere an eine in der Cloud 10 vorgehaltene Cloud-Plattform, die folgenden in der Darstellung in FIG 3 als Beispiel für eine Implementation des Verfahrens in Software (Computerpro ^¬ gramm 40) in Form eines Flussdiagramms gezeigten Schritte:

Zunächst wird in einem ersten Schritt 42 die Rangfolge der Gateways 20-24 entsprechend einem Gefahrenpotenzial der oder jeder an jedes Gateway 20-24 angeschlossenen Automatisie- rungslösung 12-16 ermittelt. Dies erfolgt mittels des in der Cloud 10 vorgehaltenen, insbesondere zur der jeweiligen

Cloud-Plattform gehörenden, Bewertungsdienstes 34. Die Funktion des Bewertungsdienstes 34 umfasst dabei zum Beispiel die oben beschriebenen Funktionen.

Mit der aus dem ersten Schritt 42 feststehenden Rangfolge der Gateways 20-24 wird in einem zweiten Schritt 44 ein Updaten eines Gateways 20-24 oder einer Gruppe von Gateways 20-24 mit dem geringsten Gefahrenpotenzial versucht.

In einem dritten Schritt 46 - genauer bei der ersten Ausführung des dritten Schritts 46 - wird der Erfolg des im voran ^¬ gehenden zweiten Schritt 44 erfolgten Updates überprüft. Dies erfolgt zum Beispiel anhand einer automatischen Prüfung von Protokolldateien und/oder einer Lebenszeichenüberwachung des oder jedes von dem Update betroffenen Gateways 20-24. Abhängig vom Ergebnis der Überprüfung im dritten Schritt 46 wird das Updaten abgebrochen oder zu einem vierten Schritt 48 ver- zweigt. Das Updaten wird abgebrochen (Verzweigung zum Programmende 50), wenn sich bei der Überprüfung im dritten

Schritt 46 ergeben hat, dass das vorangehende Update (zweiter Schritt 44) nicht fehlerfrei erfolgt ist. Das Updaten wird mit dem vierten Schritt 48 fortgesetzt, wenn sich bei der Überprüfung im dritten Schritt 46 ergeben hat, dass das vorangehende Update (zweiter Schritt 44) fehlerfrei erfolgt ist .

Im vierten Schritt 48 wird das Updaten mit einem Gateway 20- 24 oder einer Gruppe von Gateways 20-24 mit dem im Vergleich zum vorangehenden Update nächsthöheren Gefahrenpotenzial fortgesetzt .

Danach wird so lange zum dritten Schritt 46 zurückverzweigt und dabei jeweils geprüft, ob das vorangehende Update

(Schritt 48) erfolgreich oder nicht erfolgreich war, bis das Update auch für das Gateway 20-24 oder eine Gruppe von Gate ^¬ ways 20-24 mit dem höchsten Gefahrenpotenzial erfolgt ist. Wenn das Update für das Gateway 20-24 oder eine Gruppe von Gateways 20-24 mit dem höchsten Gefahrenpotenzial erfolgt ist, endet (Programmende 50) das Verfahren und die Software- aktualisierung für die Gateways 20-24 ist abgeschlossen. Wenn während des Verfahrens festgestellt wird (dritter Schritt 46) , dass ein Update bei einem Gateway 20-24 oder einer Grup ^¬ pe von Gateways 20-24 nicht erfolgreich war, wird das Verfahren sofort abgebrochen. Die Funktionsfähigkeit des oder jedes Gateway 20-24, das von dem oder den bis dahin erfolgten Updates nicht betroffen ist, ist weiterhin gegeben. Weil die Updates entsprechend der zuvor ermittelten Rangfolge und da ^¬ mit entsprechend dem jedem Gateway 20-24 zugeordneten Gefahrenpotenzial erfolgen, ist gewährleistet, dass Gateways 20-24 mit hohem Gefahrenpotenzial nur dann upgedated werden, wenn das Update bereits für zumindest ein Gateway 20-24 mit nied ^¬ rigerem Gefahrenpotenzial erfolgreich ausgeführt wurde und demgemäß davon ausgegangen werden kann, dass auch alle weiteren Updates erfolgreich durchführbar sein werden.

Wie dies in FIG 3 schematisch vereinfacht gezeigt ist, ist das Computerprogramm 40 mit einer Implementation des hier vorgestellten Verfahrens und gegebenenfalls einzelner oder mehrerer Ausführungsformen in einen Speicher 52 einer Verar- beitungseinheit 54, zum Beispiel einer als Rechnerknoten in der Cloud 10 fungierenden Verarbeitungseinheit 54, geladen und wird beim Betrieb der Verarbeitungseinheit 54 zur Soft ^¬ wareaktualisierung (Update) einer Mehrzahl von Cloud-Gateways 20-24 ausgeführt.

Bisher wurde vorausgesetzt, dass jede Automatisierungslösung 12-16 über genau ein eigenes oder zumindest ein eigenes

Cloud-Gateway 20-24 mit der Cloud 10 verbunden ist. Mit dem hier vorgeschlagenen Ansatz ist selbstverständlich auch eine Situation handhabbar, bei der über ein Cloud-Gateway 20-24 mehrere Automatisierungslösungen 12-16 mit der Cloud 10 verbunden sind. Dann kommt zum Beispiel in Betracht, für das be ^¬ treffende Gateway 20-24 die Gefahrenpotenziale der einzelnen darüber mit der Cloud 10 verbundenen Automatisierungslösungen 12-16 zu ermitteln und bei der Bestimmung der Rangfolge des jeweiligen Gateways 20-24 nur das höchste ermittelte Gefah ^¬ renpotenzial zu berücksichtigen.

Obwohl die Erfindung im Detail durch das Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch das oder die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.

Einzelne im Vordergrund stehende Aspekte der hier eingereich ^¬ ten Beschreibung lassen sich damit kurz wie folgt zusammenfassen: Angegeben wird ein Verfahren zur Softwareaktualisie- rung (Update) einer Mehrzahl von Cloud-Gateways 20-24, wobei über die Cloud-Gateways 20-24 Automatisierungslösungen 12-16 an die Cloud 10 angeschlossen sind. Das Verfahren basiert auf einer zunächst erfolgenden Ermittlung einer Rangfolge der Cloud-Gateways 20-24 entsprechend einem Gefahrenpotenzial der angeschlossenen Automatisierungslösungen 12-16. Aus der Rangfolge ergibt sich die Reihenfolge des Updatens . Danach be ^¬ ginnt das Updaten mit dem Cloud-Gateway 20-24 oder einer Gruppe von Cloud-Gateways 20-24 mit dem geringsten Gefahrenpotenzial. Anschließend wird der Erfolg des im vorangehenden Schritt erfolgten Updates überprüft, bevor das Updaten fort ^¬ gesetzt wird. Wenn in dem Schritt zum Überprüfen des Erfolgs des vorangehenden Updates ermittelt wurde, dass das Update fehlerfrei erfolgt ist, wird das Updaten mit einem Cloud- Gateway 20-24 oder einer Gruppe von Cloud-Gateways 20-24 mit dem nächsthöheren Gefahrenpotenzial fortgesetzt. Wenn dagegen in dem Schritt zum Überprüfen des Erfolgs des vorangehenden Updates ermittelt wurde, dass das Update nicht fehlerfrei er ^¬ folgt ist, wird das Updaten insgesamt abgebrochen. Ansonsten werden die Schritte des Überprüfens des Erfolgs des vorange- henden Updates und des Fortsetzen des Updatens so lange wie ^¬ derholt, bis das Update auch für das Cloud-Gateway 20-24 oder eine Gruppe von Cloud-Gateways 20-24 mit dem höchsten Gefah ^¬ renpotenzial erfolgt ist.