DE102017219188A1 - Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks - Google Patents

Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks Download PDF

Info

Publication number
DE102017219188A1
DE102017219188A1 DE102017219188.0A DE102017219188A DE102017219188A1 DE 102017219188 A1 DE102017219188 A1 DE 102017219188A1 DE 102017219188 A DE102017219188 A DE 102017219188A DE 102017219188 A1 DE102017219188 A1 DE 102017219188A1
Authority
DE
Germany
Prior art keywords
component
software component
manufacturer
block
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102017219188.0A
Other languages
English (en)
Inventor
Thomas Schroeder
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102017219188.0A priority Critical patent/DE102017219188A1/de
Priority to US16/156,011 priority patent/US11106449B2/en
Priority to CN201811251461.0A priority patent/CN109710282A/zh
Publication of DE102017219188A1 publication Critical patent/DE102017219188A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Abstract

Die Erfindung betrifft ein Verfahren zum Aktualisieren von Softwarekomponenten (210, 220, 230, 240, 250) eines Netzwerkteilnehmers eines Netzwerks, wobei ein Programmcode des Netzwerkteilnehmers wenigstens zwei herstellerspezifische Blöcke (201, 202, 203, 204) aufweist, wobei jeder dieser herstellerspezifischen Blöcke (201, 202, 203, 204) mindestens eine Softwarekomponente (210, 220, 230, 240, 250) aufweist, wobei jedem herstellerspezifischen Block (201, 202, 203, 204) jeweils ein Blockfeld (201a, 202a, 203a, 204a) zugeordnet ist, wobei der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) jedes herstellerspezifischen Blocks (201, 202, 203, 204) jeweils ein Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) zugeordnet ist, wobei in wenigstens einem der Blockfelder (201a, 202a, 203a, 204a) und/oder in wenigstens einem der Komponentenfelder (211, 212, 221, 231, 241, 242, 251, 261, 262) jeweils eine Adresse einer für eine Aktualisierung zuständigen Quelle hinterlegt ist, wobei für die mindestens eine Softwarekomponente (210, 220, 230, 240, 250) jedes herstellerspezifischen Blocks (201, 202, 203, 204) in Abhängigkeit von dem dieser mindestens einen Softwarekomponente (210, 220, 230, 240, 250) zugeordneten Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) und von dem diesem jeweiligen herstellerspezifischen Block (201, 202, 203, 204) zugeordneten Blockfeld (201a, 202a, 203a, 204a) eine Adresse der für die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) zuständige Quelle ausgewählt wird und die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) mit Hilfe der ausgewählten Quelle durchgeführt wird.

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks.
  • Stand der Technik
  • Bei der Vernetzung von Maschinen, beispielsweise auf dem Gebiet der Automatisierungstechnik, ist mittlerweile der Begriff „Industrie 4.0“ geläufig. Darunter ist die Vernetzung von Maschinen bzw. Anlagen und insbesondere auch deren Anbindung an das Internet bzw. das Internet der Dinge (sog. IoT, „Internet of Things“) zu verstehen. Vernetzte Geräte können dabei Sensoren und Sicherheitskameras bis hin zu Fahrzeugen und Produktionsmaschinen sein. Da derartige miteinander vernetzte IoT-Geräte typischerweise mit dem Internet verbunden sind, sollte gewährleisten werden, dass auf den IoT-Geräten ausgeführter Programmcode regelmäßig Sicherheitsupdates unterzogen wird und auf dem aktuellsten Stand ist, um nicht anfällig für Angriffe zu sein.
  • Programmcode, welcher auf derartigen IoT-Geräten ausgeführt wird, kann sich oftmals aus einer Vielzahl von einzelnen Softwarekomponenten zusammensetzen, welche von einem ursprünglichen Hersteller und gegebenenfalls von einer Vielzahl von Erstausrüstern bzw. OEMs (Original Equipment Manufacturer) erstellt wurden.
  • Von einem ursprünglichen Hersteller können dabei zunächst eine Basissoftware und eine entsprechende Plattform erstellt werden. Ein weiterer Hersteller, insbesondere ein erster OEM, kann diese Basissoftware und diese Plattform von dem ursprünglichen Hersteller beziehen, um seine eigenen Softwarekomponenten erweitern und somit eine erste erweiterte Version des Programmcodes erzeugen. Ein weitere Hersteller, insbesondere ein zweiter OEM, wiederum kann diese erste erweiterte Version des Programmcodes von dem ersten OEM beziehen, diese wiederum mit seinen eigenen Softwarekomponenten erweitern und dabei eine zweite erweiterte Version des Programmcodes erzeugen. Diese Kaskade kann so lange fortgesetzt werden, bis ein letzter n-ter Hersteller bzw. OEM eine n-te erweiterte finale Version des Programmcodes erstellt, welche letztendlich auf das IoT-Gerät gebracht und von diesem ausgeführt wird.
  • Updates bzw. Aktualisierungen derartiger Programmcodes können sich jedoch als sehr aufwendig erweisen. Wenn beispielsweise der ursprüngliche Hersteller einen sicherheitskritischen Fehler in seiner Basissoftware entdeckt, erstellt er beispielsweise ein Update bzw. eine Aktualisierung für seine Basissoftware, in welcher dieser Fehler behoben wird. Der erste OEM wird zumeist über diese Aktualisierung informiert, beispielsweise mittels eines Triggers. Daraufhin baut der erste OEM diese Aktualisierung in seine Version des Programmcodes ein und erzeugt eine aktualisierte Version dieses ersten erweiterten Programmcodes. Der zweite OEM wird wiederum über diese Aktualisierung informiert, baut diese in seine Version des Programmcodes ein und erzeugt somit eine aktualisierte Version seines zweiten erweiterten Programmcodes. Auch diese Kaskade setzt sich bis zu dem letzten OEM fort, welcher schließlich eine aktualisierte Version des finalen Programmcodes veröffentlicht.
  • Bis also letztendlich dieser aktualisierte finale Programmcode auf dem IoT-Gerät ausgeführt wird, vergeht gegebenenfalls eine lange Zeitperiode, da jeder einzelne beteiligte Hersteller seinen speziell erweiterten Programmcode aktualisieren muss. In dieser Zeitperiode kann das jeweilige IoT-Gerät anfällig für Angriffe sein.
  • Offenbarung der Erfindung
  • Erfindungsgemäß werden ein Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks sowie eine Recheneinheit zu dessen Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
  • Die Erfindung stellt insbesondere die Möglichkeit bereit, um automatisch mehrere und vorzugsweise sämtliche Softwarekomponenten des Netzwerkteilnehmers gegebenenfalls auch von unterschiedlichen Quellen automatisch zu aktualisieren. Den einzelnen Softwarekomponenten sind dabei sog. Blockfelder und Komponentenfelder zugeordnet, in welchen Adressen von Quellen hinterlegt sind, mit deren Hilfe die Aktualisierung der einzelnen Softwarekomponenten automatisch durchführbar ist.
  • Ein Programmcode des Netzwerkteilnehmers weist wenigstens zwei herstellerspezifische Blöcke für Softwarekomponenten auf. Jeder dieser herstellerspezifischen Blöcke weist mindestens eine Softwarekomponente auf. Ein derartiger herstellerspezifischer Block stellt insbesondere einen individuellen Bereich bzw. individuellen Slots dar, in welchem die Softwarekomponenten eines jeweiligen speziellen Herstellers zusammengefasst sind. Insbesondere kann ein spezieller Hersteller oder OEM keinen der übrigen, nicht für ihn vorgesehenen herstellerspezifischen Blöcke verändern. Mit anderen Worten haben also an dem Programmcode beteiligte unterschiedliche Hersteller je einen eigenen Block bzw. Bereich zum Kennzeichnen bzw. Beschreiben ihrer eigenen Softwarekomponenten. Wie die Komponenten physisch abgelegt sind und zusammenwirken, ist an dieser Stelle nicht relevant. Insbesondere müssen die Softwarekomponenten eines Herstellers nicht physisch in einem gemeinsamen Speicherbereich liegen.
  • Jedem herstellerspezifischen Block ist jeweils ein Blockfeld zugeordnet. Der mindestens einen Softwarekomponente jedes herstellerspezifischen Blocks ist jeweils ein Komponentenfeld zugeordnet. In ein derartiges Blockfeld bzw. in ein derartiges Komponentenfeld können von den Herstellern insbesondere Informationen hinterlegt werden, welche den jeweiligen zugeordneten herstellerspezifischen Block bzw. die jeweilige zugeordnete Softwarekomponente beschreiben. Ein derartiges Blockfeld, insbesondere in einem derartigen Blockfeld hinterlegte Informationen, gelten zweckmäßigerweise für sämtliche Softwarekomponenten dieses Blocks. Ein derartiges Komponentenfeld, insbesondere in einem derartigen Komponentenfeld hinterlegte Informationen, gelten insbesondere nur für die jeweilige zugeordnete Softwarekomponente. Es sei darauf hingewiesen, dass Blockfelder und/oder Komponentenfelder auch leer sein können und keine Informationen enthalten können. Die Blockfelder bzw. Komponentenfeld können insbesondere jeweils als digitale Label oder digitale Typenschilder angesehen werden, welche Auskunft über den zugeordneten Block bzw. die zugeordnete Softwarekomponente geben.
  • In wenigstens einem der Blockfelder und/oder in wenigstens einem der Komponentenfelder ist jeweils eine Adresse einer für eine Aktualisierung zuständigen Quelle hinterlegt. Eine derartige Quelle ist dabei insbesondere für die Aktualisierung von einer oder mehreren Softwarekomponenten zuständig. Eine derartige Quelle kann insbesondere ein weiterer Netzwerkteilnehmer des Netzwerks sein, beispielsweise ein Server oder ein verteiltes System von Recheneinheiten (sog. Cloud). Es versteht sich, dass in den einzelnen Blockfeldern sowie den einzelnen Komponentenfeldern zweckmäßigerweise jeweils dieselbe Adresse derselben Quelle oder zweckmäßigerweise jeweils auch unterschiedliche Adressen unterschiedlicher Quellen hinterlegt sein können.
  • Wenn ein Hersteller eine oder mehrere Softwarekomponenten in den ihm zugeordneten Block einbringt, hinterlegt er dabei zweckmäßigerweise in dem jeweiligen Blockfeld und/oder in den Komponentenfeldern jeweils entsprechende Adressen und gibt somit insbesondere die Quelle(n) an, welche für die Aktualisierung der von ihm eingebrachten Softwarekomponenten zuständig ist bzw. sind.
  • Zum Durchführen der Aktualisierung der Softwarekomponenten wird im Rahmen des Verfahrens für die mindestens eine Softwarekomponente jedes herstellerspezifischen Blocks jeweils in Abhängigkeit von dem dieser mindestens einen Softwarekomponente zugeordneten Komponentenfeld und von dem diesem jeweiligen herstellerspezifischen Block zugeordneten Blockfeld eine Adresse der für die Aktualisierung der mindestens einen Softwarekomponente zuständige Quelle ausgewählt. Die Aktualisierung der mindestens einen Softwarekomponente wird mit Hilfe der ausgewählten Quelle durchgeführt.
  • Eine in einem Blockfeld hinterlegte Adresse, welche im Folgenden auch als Slotadresse oder blockspezifische Adresse bezeichnet wird, gilt insbesondere für sämtliche Softwarekomponenten dieses Blocks. Eine in einem Komponentenfeld hinterlegte Adresse, welche im Folgenden auch als Komponentenadresse oder komponentenspezifische Adresse bezeichnet wird, gilt insbesondere nur für die diesem Komponentenfeld zugeordnete Softwarekomponente.
  • Wenn in dem Komponentenfeld einer Softwarekomponente keine Komponentenadresse hinterlegt ist, wird für diese Softwarekomponente insbesondere die in dem Blockfeld des jeweiligen Blocks hinterlegte Slotadresse ausgewählt. Zweckmäßigerweise können Komponentenadressen eine größere Relevanz besitzen als Slotadressen, d.h. wenn in dem Komponentenfeld einer Softwarekomponente eine Komponentenadresse hinterlegt ist und wenn in dem Blockfeld des jeweiligen Blocks dieser Softwarekomponente auch eine Slotadresse hinterlegt ist, wird insbesondere die Komponentenadresse für diese Softwarekomponente ausgewählt.
  • Alternativ ist es auch zweckmäßig, dass Slotadressen eine größere Relevanz besitzen als Komponentenadressen. Wenn in diesem Fall eine Slotadresse in einem Blockfeld hinterlegt ist, wird diese insbesondere für alle Softwarekomponenten dieses Blocks ausgewählt, auch wenn einer Softwarekomponente dabei gegebenenfalls eine von der Slotadresse abweichende Komponentenadresse zugeordnet ist. Wenn unter dieser ausgewählten Slotadresse in diesem Fall für eine Softwarekomponente keine Aktualisierung verfügbar ist, kann zweckmäßigerweise die in dem Komponentenfeld dieser Softwarekomponente hinterlegte Komponentenadresse kontaktiert werden.
  • Zweckmäßigerweise kann für jeden einzelnen Block und/oder für alle Blöcke gemeinsam vorgegeben werden, gemäß welcher der obig erläuterten Möglichkeiten Adressen ausgewählt werden sollen, also insbesondere ob die Komponentenadressen oder die Slotadressen größere Relevanz besitzen.
  • Nachdem die entsprechende Adresse der jeweiligen Quelle ausgewählt wurde, wird diese Quelle insbesondere kontaktiert und es wird zweckmäßigerweise eine sichere (vorzugsweise mittels üblicher Verschlüsselungsmethoden, wie z.B. https) Verbindung von dem Netzwerkteilnehmer zu der Quelle aufgebaut. Es wird überprüft, ob eine Aktualisierung für die Softwarekomponente vorhanden ist, insbesondere für die aktuelle Version der Softwarekomponente. Bei einer verfügbaren Aktualisierung wird diese insbesondere durchgeführt.
  • Durch das Verfahren wird eine Möglichkeit bereitgestellt, um eine effektive und schnelle Aktualisierung von Softwarekomponenten des Programmcodes durchzuführen. Da insbesondere für jede Softwarekomponente eine für deren Aktualisierung zuständige Quelle angegeben ist, in dem Blockfeld und/oder dem Komponentenfeld, kann zweckmäßigerweise auf einfache Weise eine Aktualisierung sämtlicher Softwarekomponenten automatisch durchgeführt werden.
  • Wie eingangs erwähnt, werden auf herkömmliche Weise von den an einem Programmcode beteiligten Herstellern lediglich Softwarekomponenten in den Programmcode eingebracht, ohne dass diese mit Informationen für nachfolgende Aktualisierungen versehen werden. Auf herkömmliche Weise führt jeder beteiligte Hersteller einzeln eine entsprechende Aktualisierung seines speziell erweiterten Programmcodes durch, welche dann vom übergeordneten Hersteller weiterverwendet wird. Im Gegensatz dazu kann durch das vorliegende Verfahren eine automatische Aktualisierung sämtlicher Softwarekomponenten durchgeführt werden.
  • Durch die Erfindung wird insbesondere eine Plattform bereitgestellt, mittels welcher beteiligte Hersteller festlegen können, wie die Aktualisierung ihrer Softwarekomponenten durchgeführt wird. Über die Block- und Komponentenfelder kann der entsprechende Hersteller seine in den Programmcode eingebrachten Softwarekomponenten in ausreichender Weise beschreiben, so dass diese für die Aktualisierung ausreichend klassifiziert sind.
  • Durch die hinterlegten Adressen kann vorgegeben werden, von welcher Quelle Aktualisierungen der jeweiligen Softwarekomponenten zu beziehen sind. Wenn z.B. ein Hersteller eine Softwarekomponente in den Programmcode einbringt und für diese im späteren Verlauf selbst Aktualisierungen durchführt, beispielsweise weil er selbst einen Update-Server betreibt oder Updates über eine Cloud bereitstellt, kann er dies in dem jeweiligen Block- bzw. Komponentenfeld entsprechend vorgegeben. Wenn ein anderer Hersteller eine Aktualisierung durchführen will, kann dies analog in seinem jeweiligen Block- bzw. Komponentenfeld vorgeben sein.
  • Beispielsweise kann auch der Fall vorliegen, dass ein Hersteller eine Softwarekomponente beispielsweise nicht selbst erstellt, sondern von einem Zulieferer bezieht und diese Softwarekomponente nur in den Programmcode einbringt. Falls der Zulieferer im späteren Verlauf die Aktualisierungen dieser Softwarekomponente durchführt, kann der Hersteller dies in dem jeweiligen Block- bzw. Komponentenfeld durch eine entsprechende Adresse der Zulieferer-Quelle definieren.
  • Gemäß einer vorteilhaften Ausführungsform werden Softwarekomponenten im Zuge eines Herstellungsprozesses in den Programmcode eingebracht. Dieser Herstellungsprozess findet insbesondere zu einem ersten Zeitpunkt statt, insbesondere bevor der Programmcode in den Netzwerkteilnehmer eingebracht und von diesem ausgeführt wird. Im Zuge dieses Herstellungsprozesses kann der Programmcode insbesondere von einem ursprünglicheren Hersteller erstellt werden, es kann also insbesondere eine Basissoftware und/oder eine entsprechende Plattform von dem ursprünglicheren Hersteller erstellt werden. Ebenso ist es denkbar, dass im Zuge des Herstellungsprozesses ein bereits bestehender ausführbarer Programmcode erweitert wird. Ein weiterer Hersteller kann in diesem Fall beispielsweise eine Erweiterung eines Programmcodes durchführen, den er beispielsweise direkt von dem ursprünglichen Hersteller des Programmcodes oder von einem anderen weiteren Hersteller bezogen hat.
  • Die Verfahrensschritte des Auswählens der Adresse und Durchführens der Aktualisierung finden insbesondere nach diesem Herstellungsprozess statt, insbesondere nachdem der Programmcode in den Netzwerkteilnehmer eingebracht ist, weiter insbesondere nachdem der Netzwerkteilnehmer in das entsprechende Netzwerk eingebracht ist und weiter insbesondere wenn der Programmcode von dem Netzwerkteilnehmer ausgeführt wird. Insbesondere werden diese Verfahrensschritte des Auswählens der Adresse und Durchführens der Aktualisierung zu einem zweiten Zeitpunkt durchgeführt, welcher zeitlich nach dem ersten Zeitpunkt liegt. Wann dieser zweite Zeitpunkt genau stattfindet, kann insbesondere während des Herstellungsprozesses zu dem ersten Zeitpunkt festgelegt werden. Beispielsweise kann der zweite Zeitpunkt durch ein Zeitintervall vorgegeben werden, nach dessen Ablauf nach Aktualisierungen gesucht werden soll.
  • Vorteilhafterweise hinterlegt im Zuge dieses Herstellungsprozesses ein Hersteller in dem Blockfeld seines herstellerspezifischen Blocks und/oder in wenigstens einem der Komponentenfelder seines herstellerspezifischen Blocks jeweils die Adresse der für die Aktualisierung zuständigen Quelle.
  • Falls der ursprüngliche Hersteller im Zuge dieses Herstellungsprozesses den Programmcode erstellt, kann diese wenigstens eine Softwarekomponente beispielsweise auch die erste Softwarekomponente oder eine der ersten Softwarekomponenten sein, welche in den Programmcode eingebracht wird. Falls beispielsweise ein weiterer Hersteller im Zuge dieses Herstellungsprozesses den Programmcode erweitert, kann bereits eine Vielzahl weiterer Softwarekomponenten von dem ursprünglichen Hersteller und gegebenenfalls von anderen Herstellern in dem Programmcode implementiert sein.
  • Bei Einbringen seiner Softwarekomponenten im Zuge des Herstellungsprozesses kann der jeweilige Hersteller somit jeder Softwarekomponente seines Blocks bzw. seines Slots Komponentenadressen bzw. Slotadressen zuordnen. Insbesondere gibt der jeweilige Hersteller somit bereits im Herstellungsprozess vor, welche Quelle(n) im späteren regulären Betrieb des Programmcodes die Aktualisierung der von ihm eingebrachten Softwarekomponenten durchführt/durchführen. Insbesondere wird somit bereits im Zuge des Herstellungsprozess für jede Softwarekomponente des Programmcodes vom jeweiligen Hersteller/OEM eine für die spätere Aktualisierung zuständige Quelle vorgegeben. Wie weiter oben erläutert, wird durch das vorliegende Verfahren somit eine Plattform bereitgestellt, mittels welcher Hersteller bereits beim Herstellungsprozess festlegen können, wie die Aktualisierung ihrer Softwarekomponenten im späteren Betrieb durchgeführt werden soll.
  • Gemäß einer besonders vorteilhaften Ausgestaltung der Erfindung wird die Möglichkeit bereitgestellt, dass ein Hersteller im Zuge des Herstellungsprozesses neue Softwarekomponente in den Programmcode einbringt und sowohl die Aktualisierung dieser Softwarekomponenten als auch die Aktualisierung anderer bereits im Programmcode vorhandener (d.h. also unterlagerter bzw. untergeordneter) Softwarekomponente von anderen Herstellern durchführt. Zu diesem Zweck kann dieser Hersteller in den Blockfeldern von bereits vorhandenen, d.h. also fremden herstellerspezifischen Blöcken Adressen von für die Aktualisierung zuständigen Quellen hinterlegen. Insbesondere kann also ein übergeordneter Hersteller bei Wunsch auch Updates für untergeordnete Softwarekomponenten (z.B. Treiber, Betriebssystemkomponenten) anbieten.
  • In den fremden Blockfeldern können bereits von einem untergeordneten Hersteller andere Adressen hinterlegt sein, welche dann überschrieben oder auch gelöscht werden. Wenn eine Adresse eines fremden Blocks beispielsweise gelöscht wird und das entsprechende Blockfeld dieses Blocks somit leer ist, kann für diesen fremden, untergeordneten Block insbesondere eine Adresse ausgewählt werden, welche in dem Blockfels des übergeordneten Blocks hinterlegt ist.
  • Wie erläutert, können die Blockfelder oder die Komponentenfeld jeweils auch leer sein und keine Informationen enthalten. Wenn ein Komponentenfeld keine Adresse enthält, kann das zugehörige Blockfeld die Adresse liefern. Wenn ein Blockfeld keine Adresse enthält, kann ein Blockfeld eines übergeordneten Blocks eine Adresse liefern. Insbesondere ergibt sich somit eine flexible Möglichkeit, unterschiedliche Adressen für Softwarekomponenten zu hinterlegen, wie nachfolgend erläutert wird.
  • Gemäß einer bevorzugten Ausführungsform können die Komponentenadressen eine größere Relevanz besitzen als die Slotadressen. Wenn in dem der wenigstens einen Softwarekomponente eines jeweiligen herstellerspezifischen Blocks zugeordneten Komponentenfeld eine Adresse hinterlegt ist, wird vorteilhafterweise diese Adresse für die Aktualisierung der mindestens einen Softwarekomponente ausgewählt und die Aktualisierung der mindestens einen Softwarekomponente mit Hilfe dieser ausgewählten Quelle durchgeführt. Für eine Softwarekomponente wird somit bei vorhandener Komponentenadresse diese ausgewählt, insbesondere auch dann, wenn in dem Blockfeld des entsprechenden Blocks eine Slotadresse hinterlegt ist, die gegebenenfalls von der vorhandenen Komponentenadresse abweicht. Die Slotadresse gilt in diesem Fall insbesondere für Softwarekomponenten, denen keine Komponentenadresse zugeordnet ist.
  • Wenn in dem der wenigstens einen Softwarekomponente eines jeweiligen herstellerspezifischen Blocks zugeordneten Komponentenfeld keine Adresse hinterlegt ist, wird vorteilhafterweise die in dem diesem jeweiligen herstellerspezifischen Block zugeordneten Blockfeld hinterlegte Adresse für die Aktualisierung dieser mindestens einen Softwarekomponente ausgewählt und die Aktualisierung der mindestens einen Softwarekomponente mit Hilfe dieser ausgewählten Quelle durchgeführt. Wie oben erläutert, gilt die Slotadresse in diesem Fall insbesondere für Softwarekomponenten, denen keine Komponentenadresse zugeordnet ist.
  • Beispielsweise kann es auf diese Weise ermöglicht werden, dass ein Hersteller eine Vielzahl von Softwarekomponenten in seinen Block einbringt und dass verschiedene Quellen für die Aktualisierung dieser eingebrachten Softwarekomponenten zuständig sind. Wenn ein Hersteller im Zuge des Herstellungsprozesses beispielsweise eine Vielzahl von Softwarekomponenten in den Programmcode einbringt und für all diese Softwarekomponenten die Aktualisierung vornimmt, kann dieser Hersteller beispielsweise keine Adresse in die einzelnen Komponentenfelder dieser Softwarekomponenten hinterlegen, sondern kann die jeweilige Adresse in dem Blockfeld seines Blocks hinterlegen. Somit wird diese Adresse in dem Blockfeld zweckmäßigerweise für alle Softwarekomponenten in diesem Block ausgewählt. Alternativ kann der Hersteller auch in jedem Komponentenfeld dieser Vielzahl von Softwarekomponenten dieselbe Adresse hinterlegen und in dem Blockfeld keine Adresse.
  • Beispielsweise kann ein Hersteller im Zuge des Herstellungsprozesses eigene Softwarekomponenten in den Programmcode einbringen, welche dieser Hersteller selbst erstellt hat, und fremde Softwarekomponenten, die er von einem Zulieferer bezogen hat. Für die eigenen Softwarekomponenten kann dieser Hersteller z.B. selbst die Aktualisierung übernehmen und dies entsprechend in den Komponentenfeldern dieser eigenen Softwarekomponenten hinterlegen. Wenn der Hersteller nicht die Aktualisierung der fremden Softwarekomponenten übernimmt, sondern beispielsweise der Zulieferer, kann der Hersteller dies entsprechend in den Komponentenfeldern dieser fremden Softwarekomponenten hinterlegen. Beispielsweise kann der Hersteller zu diesem Zweck die Adresse der jeweiligen Server oder der jeweiligen Clouds in dem jeweiligen Komponentenfeldern hinterlegen.
  • Alternativ ist es in diesem Fall auch denkbar, dass der Hersteller in den Komponentenfeldern derjenigen Softwarekomponenten, deren Aktualisierung er selbst übernimmt, keine Adresse hinterlegt und stattdessen in dem Blockfeld seines Blocks die Adresse derjenigen Quelle hinterlegt, die für die Aktualisierung dieser Softwarekomponenten zuständig ist. In den Komponentenfeldern der fremden Softwarekomponenten des Zulieferers, welcher auch die Aktualisierung übernimmt, kann der Hersteller dabei die jeweiligen Adressen der Quelle des Zulieferers hinterlegen.
  • Gemäß einer weiteren bevorzugten Ausführungsform können auch die Slotadressen eine größere Relevanz besitzen als die Komponentenadressen. Wenn in dem Blockfeld eines jeweiligen herstellerspezifischen Blocks eine Adresse hinterlegt ist, wird vorteilhafterweise diese Adresse für die Aktualisierung der mindestens einen Softwarekomponente dieses jeweiligen herstellerspezifischen Blocks ausgewählt und die Aktualisierung der mindestens einen Softwarekomponente wird mit Hilfe dieser ausgewählten Quelle durchgeführt. Bei vorhandener Slotadresse eines Blocks wird diese insbesondere für alle Softwarekomponenten dieses Blocks ausgewählt, auch wenn in Komponentenfeldern dabei gegebenenfalls von dieser Slotadresse abweichende Komponentenadressen hinterlegt sind.
  • Wenn jedoch unter dieser ausgewählten Slotadresse für eine Softwarekomponente keine Aktualisierung verfügbar ist, kann vorzugsweise die in dem Komponentenfeld dieser Softwarekomponente hinterlegte Komponentenadresse ausgewählt werden. Wenn für die mindestens eine Softwarekomponente unter der ausgewählten, in dem Blockfeld des jeweiligen herstellerspezifischen Blocks hinterlegten Adresse keine Aktualisierung verfügbar ist, wird vorteilhafterweise die in dem der wenigstens einen Softwarekomponente zugeordneten Komponentenfeld hinterlegte Adresse für die Aktualisierung der mindestens einen Softwarekomponente ausgewählt und die Aktualisierung der mindestens einen Softwarekomponente wird vorzugsweise mit Hilfe dieser ausgewählten Quelle durchgeführt. Vorteilhafterweise wird für jeden einzelnen Block und/oder für alle Blöcke gemeinsam vorgegeben, insbesondere im Zuge des Herstellungsprozesses, wie die Adressen ausgewählt werden und ob die Komponentenadressen oder die Slotadressen größere Relevanz besitzen. Alternativ oder zusätzlich handelt es dabei um eine frei - auch während des Betriebs- konfigurierbare Auswahl, die insbesondere im Zuge von Aktualisierungen veränderbar ist.
  • Gemäß einer bevorzugten Ausführungsform sind in den der mindestens einen Softwarekomponente zugeordneten Komponentenfeldern jeweils aktualisierungsspezifische Informationen hinterlegt. Diese aktualisierungsspezifischen Informationen werden insbesondere zum Durchführen der Aktualisierung benötigt. In einem Komponentenfeld können somit zweckmäßigerweise verschiedene Informationen gleichzeitig hinterlegt sein, insbesondere die Komponentenadresse und derartige aktualisierungsspezifische Informationen. Beispielsweise kann ein Komponentenfeld zu diesem Zweck unterschiedliche Einträge umfassen. Es ist auch denkbar, den Softwarekomponenten jeweils zwei oder mehrere unabhängige Komponentenfelder zuzuordnen, wobei in einem ersten dieser Komponentenfelder eine entsprechende Adresse hinterlegt werden kann und in einem zweiten Komponentenfeld entsprechende aktualisierungsspezifische Informationen.
  • Vorteilhafterweise sind in den der mindestens einen Softwarekomponente zugeordneten Komponentenfeldern jeweils Informationen über eine aktuelle Version dieser wenigstens einen Softwarekomponente als aktualisierungsspezifische Informationen hinterlegt. Insbesondere können diese aktualisierungsspezifischen Informationen eine eindeutige Kennung der jeweiligen Softwarekomponente umfassen, z.B. einen GUID (Globally Unique Identifier). Zweckmäßigerweise sind diese aktualisierungsspezifischen Informationen semantische Informationen und haben für den Hersteller eine semantische, also eine an sich selbsterklärende Bedeutung. Beispielsweise können die aktualisierungsspezifischen Informationen eine Version und/oder eine Versionsnummer der jeweiligen Softwarekomponente beschreiben.
  • Vorzugsweise wird die Aktualisierung der mindestens einen Softwarekomponente mit Hilfe der ausgewählten Quelle in Abhängigkeit von den in dem Komponentenfeld der wenigstens einen Softwarekomponente hinterlegten aktualisierungsspezifischen Informationen durchgeführt. Zweckmäßigerweise werden die aktualisierungsspezifischen Informationen zu diesem Zweck von dem Netzwerkteilnehmer an die ausgewählte Quelle übermittelt, welche daraufhin insbesondere überprüft, ob eine Aktualisierung für diese Version der Softwarekomponente vorliegt.
  • Vorteilhafterweise wird die Aktualisierung für alle Softwarekomponenten konsekutiv bzw. kaskadenartig durchgeführt, insbesondere nach einer vorgegebenen Reihenfolge. Vorzugsweise wird für jede Softwarekomponente beginnend mit einer hierarchisch höchsten Softwarekomponente bis zu einer hierarchisch niedrigsten Softwarekomponente jeweils in Abhängigkeit von dem der jeweiligen Softwarekomponente zugeordneten Komponentenfeld und von dem diesem jeweiligen herstellerspezifischen Block zugeordneten Blockfeld die Adresse der für die Aktualisierung der jeweiligen Softwarekomponente zuständigen Quelle ausgewählt und die Aktualisierung der jeweiligen Softwarekomponente wird mit Hilfe der ausgewählten Quelle durchgeführt. Die hierarchisch höchste Softwarekomponente ist insbesondere eine jüngste bzw. zuletzt in den Programmcode eingebrachte Softwarekomponente, z.B. ein Anwenderprogramm. Die hierarchisch niedrigste Softwarekomponente ist insbesondere eine älteste bzw. eine zuerst eingebrachte Softwarekomponente, z.B. ein Betriebssystem.
  • Insbesondere wird zu diesem Zweck für jede Softwarekomponente nacheinander die jeweilige ausgewählte Quelle kontaktiert. Insbesondere geht eine Aktualisierung somit stets von dem Netzwerkteilnehmer und nicht von der jeweiligen Quelle aus, wodurch ein Angriff auf den Netzwerkteilnehmer erschwert wird. Bei einer verfügbaren Aktualisierung für die jeweilige Softwarekomponente wird diese Aktualisierung von der Quelle vorzugsweise geladen, validiert und durchgeführt.
  • Vorteilhafterweise wird im Zuge der Aktualisierung der mindestens einen Softwarekomponente, insbesondere nach erfolgreich durchgeführter Aktualisierung, das der mindestens einen Softwarekomponente zugeordnete Komponentenfeld und/oder das dem jeweiligen herstellerspezifischen Block zugeordnete Blockfeld aktualisiert. Nach durchgeführter Aktualisierung werden vorzugsweise die aktualisierungsspezifischen Informationen der jeweiligen Softwarekomponente aktualisiert, insbesondere wird eine Kennung dieser neuesten aktualisierten Version der Softwarekomponente in den aktualisierungsspezifischen Informationen hinterlegt.
  • Vorzugsweise wird, wenn eine ausgewählte Quelle nicht erreichbar ist, eine sicherheitstechnische Maßnahme durchgeführt. Durch diese sicherheitstechnische Maßnahme kann insbesondere sichergestellt werden, dass keine Gefährdung des Netzwerkteilnehmers durch einen Angriff entsteht, da sein Programmcode nicht aktualisiert werden kann. Insbesondere wird als derartige sicherheitstechnische Maßnahme ein Fehlerzähler inkrementiert und/oder der Netzwerkteilnehmer wird in einen sicheren Zustand gebracht. Insbesondere wenn der Fehlerzähler einen Grenzwert erreicht, wird der Netzwerkteilnehmer in diesen sicheren Zustand gebracht und dabei beispielsweise von dem Netzwerk getrennt.
  • Vorteilhafterweise wird der Programmcode auf einem als „Internet of Things“-Gerät ausgebildeten Netzwerkteilnehmer ausgeführt. Als ein derartiges „Internet of Things“-Gerät (IoT-Gerät) ist insbesondere ein Gerät zu verstehen, welches über das Netzwerk, insbesondere das Internet, mit anderen derartigen IoT-Geräten vernetzt ist.
  • Insbesondere kann das IoT-Gerät als ein Sensor, ein Aktor, eine Steuerung oder eine andere Maschinenkomponenten einer Maschine bzw. Anlage ausgebildet sein, welches über das Netzwerk, insbesondere das Internet, mit anderen derartigen als IoT-Geräten ausgebildeten Maschinenkomponenten vernetzt ist, insbesondere im Zuge der sog. „Industrie 4.0“.
  • Eine derartige Steuerung kann beispielsweise als CNC-Steuerung (Computerized Numerical Control), NC-Steuerung (Numerical Control), speicherprogrammierbaren Steuerung (SPS) und/oder Motion-Logic-Steuerung (MC - Motion Control) ausgebildet sein.
  • Die Erfindung eignet sich für eine weite Bandbreite von Applikationen, beispielsweise für Tunnelbohrmaschinen, Hydraulik-Stanzen/Pressen, allgemeine Automatisierungen, Semiconductor-Handling, Robotik usw. Besonders eignet sich das Verfahren für Steuerungen von Maschinen. Eine derartige Maschine kann insbesondere als eine Werkzeugmaschine, wie beispielsweise ein Schweißsystem, ein Schraubsystem, eine Drahtsäge oder eine Fräsmaschine, oder als eine Bahnbearbeitungsmaschine, wie z.B. eine Druckmaschine, eine Zeitungsdruckmaschine, eine Tiefdruck-, Siebdruckmaschine, eine Inline-Flexodruckmaschine oder eine Verpackungsmaschine ausgebildet sein. Eine derartige Maschine kann auch als eine (Band-) Anlage zur Herstellung eines Automobils oder zur Herstellung von Komponenten eines Automobils (z.B. Verbrennungsmotoren oder Steuergeräte) ausgebildet sein.
  • Beispielsweise kann das IoT-Gerät auch als ein sog. „Smart Device“ ausgebildet sein, insbesondere als ein tragbares Handgerät, zweckmäßigerweise als ein Touchscreenhandgerät, z.B. als ein Smartphone oder als ein Tablet-PC.
  • Das IoT-Gerät kann insbesondere auch ein Haushaltsgerät eine Privathaushalts sein, welches über das Netzwerk, insbesondere das Internet, mit weiteren IoT-Geräten vernetzt ist, beispielsweise ein Kühlschrank, eine Waschmaschine, ein Fernsehgerät oder eine zweckmäßige Komponenten der Hausautomatisierung.
  • Eine erfindungsgemäße Recheneinheit, insbesondere ein derartiger Netzwerkteilnehmer bzw. ein derartiges IoT-Gerät, z.B. ein Steuergerät einer Druckmaschine, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
  • Auch die Implementierung des Verfahrens in Form eines Computerprogramms ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Steuergerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
  • Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
  • Es versteht sich, dass die vorstehend genannten und die nachfolgend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
  • Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung ausführlich besch rieben.
  • Figurenliste
    • 1 zeigt schematisch eine Maschine mit als IoT-Geräten ausgebildeten Maschinenkomponenten, die jeweils dazu eingerichtet sind, eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens auszuführen.
    • 2 zeigt schematisch einen Programmcode, der dazu eingerichtet ist, im Rahmen einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens aktualisiert zu werden.
    • 3 zeigt schematisch eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens als ein Blockdiagramm.
  • Detaillierte Beschreibung der Zeichnung
  • In 1 ist eine Maschine schematisch dargestellt und mit 100 bezeichnet, die beispielsweise als eine Bahnbearbeitungsmaschine zum Herstellen und/oder Bearbeiten von Werkstücken ausgebildet sein kann.
  • Die Maschine 100 weist eine Vielzahl von Maschinenkomponenten auf, beispielsweise eine Vielzahl von Sensoren 110, eine Vielzahl von Aktoren 120 und eine Vielzahl von Steuerungen 130, welche beispielsweise als speicherprogrammierbare Steuerungen (SPS) ausgebildet sein können. Die Steuerungen 130 können mit Sensoren 110 verbunden sein und Messwerte dieser Sensoren 110 empfangen und können weiterhin mit Aktoren 120 verbunden sein und Ansteuerbefehle an diese Aktoren 120 übermitteln. Beispielsweise können mittels dieser Sensoren 110 und Aktoren 120 Fließbänder bewegt und robotergeführte Werkzeuge angesteuert werden, um auf den Fließbändern bewegte Werkstücke zu bearbeiten.
  • Diese Maschinenkomponenten 110, 120, 130 sind beispielsweise als Komponenten der sog. Feld- und Steuerungsebene ausgebildet. Weiterhin kann die Maschine 100 Maschinenkomponenten 140 der sog. Leitebene aufweisen, beispielsweise Computer oder Smart-Devices wie Tablet-PCs oder Smartphones.
  • Diese einzelnen Maschinenkomponenten 110, 120, 130, 140 sind jeweils als IoT-Geräte ausgebildet und über ein Netzwerk 150, beispielsweise das Internet, miteinander vernetzt. Es versteht sich, dass die Maschine 100 noch weitere als IoT-Geräte ausgebildete Maschinenkomponenten aufweisen kann.
  • Beispielsweise können über diese Vernetzung Messwerte der Sensoren 110 direkt über das Internet 150 an einen Tablet-PC 140 eines Mitarbeiters übermittelt werden. Beispielsweise kann der Mitarbeiter über diesen Tablet-PC 140 die Maschine ansteuern, indem er z.B. SollWerte eingibt, die über das Internet 150 an eine SPS 130 übertragen werden, welche daraufhin Aktoren 120 gemäß diesen eingegebenen Soll-Werten ansteuert.
  • Auf diesen IoT-Geräten 110, 120, 130, 140 können jeweils spezielle Programmcodes ausgeführt werden. Da diese IoT-Geräte 110, 120, 130, 140 mit dem Internet 150 verbunden sind, ist es wichtig, dass der auf den IoT-Geräten 110, 120, 130, 140 ausgeführte Programmcode regelmäßig Sicherheitsupdates erhalt und auf dem aktuellsten Stand ist, damit die Maschine nicht anfällig für Angriffe wird. Daher sind die IoT-Geräte 110, 120, 130, 140 jeweils dazu eingerichtet, im Rahmen einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens aktualisiert zu werden, wie nachfolgend anhand der 2 und 3 erläutert wird.
  • In 2 ist ein Programmcode 200 schematisch dargestellt, der beispielsweise auf einem der IoT-Geräte 110, 120, 130, 140 aus 1 gespeichert und von diesem ausgeführt werden kann.
  • Der Programmcode 200 setzt sich aus einer Vielzahl von Softwarekomponenten 210, 220, 230, 240, 250 zusammen, welche von unterschiedlichen Herstellern stammen. Die Softwarekomponenten 210, 220, 230, 240, 250 sind daher herstellerspezifischen Blocks bzw. Bereichen 201, 202, 203, 204 zugeordnet, je nachdem von welchem Hersteller die Softwarekomponente 210, 220, 230, 240, 250 stammt.
  • Jedem dieser herstellerspezifischen Blöcke 201, 202, 203, 204 ist ein Blockfeld 201a, 202b, 203c, 204d für eine sog. blockspezifische Adresse bzw. Slotadresse zugeordnet. Weiterhin sind den einzelnen Softwarekomponenten 210, 220, 230, 240, 250 Komponentenfelder 211, 212, 221, 231, 241, 242, 251, 261, 262 zugeordnet, für sog. Komponentenadresse bzw. komponentenspezifische Adresse sowie für aktualisierungsspezifische Informationen
  • In Abhängigkeit von diesen Blockfeldern 201a, 202b, 203c, 204d und Komponentenfeldern 211, 212, 221, 231, 241, 242, 251, 261, 262 bzw. den darin hinterlegten Informationen wird eine Aktualisierung der Softwarekomponenten 210, 220, 230, 240, 250 im Rahmen einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens durchgeführt, wie nachfolgend in Bezug auf 3 beschrieben.
  • In 3 ist eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens schematisch als ein Blockdiagramm dargestellt.
  • Bevor der Programmcode 200 auf das jeweilige IoT-Gerät gebracht und zu einem zweiten Zeitpunkt 320 von diesem IoT-Gerät ausgeführt wird, wird der Programmcode zunächst im Zuge eines Herstellungsprozess im Rahmen einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens erstellt.
  • Zu einem ersten Zeitpunkt 310, der zeitlich also vor dem zweiten Zeitpunkt liegt, wird in Schritt 311 beispielsweise eine erste Softwarekomponente 210 als Basissoftware von einem ursprünglichen Hersteller des Programmcodes erstellt, zusammen mit einer entsprechenden Plattform. Diese erste Softwarekomponente 210 ist somit dem Slot 201 des ursprünglichen Herstellers zugeordnet. Der Hersteller ordnet zu diesem ersten Zeitpunkt 310 in Schritt 312 weiterhin dieser ersten Softwarekomponente 210 zwei Komponentenfelder 211 und 212 zu. In dem Komponentenfeld 211 hinterlegt der Hersteller aktualisierungsspezifische Informationen, welche Auskunft über eine Version dieser Softwarekomponente 210 geben. In dem Komponentenfeld 212 hinterlegt der Hersteller eine Adresse einer Quelle z.B. einer Cloud, welche Aktualisierungen dieser Softwarekomponente 210 zu dem zweiten Zeitpunkt 320 nach Inbetriebnahme des Programmcodes 200 durchführen kann. Beispielsweise bleiben das Blockfeld 201a in diesem Fall leer.
  • Es ist auch denkbar, dass zu dem ersten Zeitpunkt 310 nicht der ursprüngliche Hersteller den Programmcode erstellt, sondern dass zu dem ersten Zeitpunkt ein übergeordneter Hersteller (z.B. OEM) einen bereits existierenden Programmcode erweitert. Beispielsweise kann in diesem Fall zu dem ersten Zeitpunkt 310 in Schritt 311 ein erster OEM die Basissoftware und die Plattform mitsamt der ersten Softwarekomponente 210 von dem Hersteller beziehen und um die Softwarekomponenten 220 und 230 erweitern. Diese Softwarekomponenten 220 und 230 sind somit dem Slot 202 dieses ersten OEMs zugeordnet. Die zweite Softwarekomponente 220 kann beispielsweise von dem ersten OEM selbst erstellt worden sein, die dritte Softwarekomponente 230 kann der erste OEM beispielsweise von einem Zulieferer bezogen haben.
  • In Schritt 312 ordnet der erste OEM der zweiten Softwarekomponente 220 das Komponentenfeld 221 zu und hinterlegt darin aktualisierungsspezifische Informationen, welche beispielsweise Auskunft über die Version dieser Softwarekomponente 220 geben. Analog wird der dritten Softwarekomponente 230 das Komponentenfeld 231 zugeordnet und darin aktualisierungsspezifischen Informationen hinterlegt werden, welche z.B. Auskunft über die Version dieser Softwarekomponente 230 geben.
  • Der erste OEM kann die Aktualisierungen dieser beiden Softwarekomponente 220 und 230 selbst übernehmen. Daher hinterlegt der OEM in dem Blockfeld 201b in Schritt 312 eine Adresse z.B. einer Cloud des ersten OEMs, welche Aktualisierungen dieser beiden Softwarekomponenten 220 und 230 durchführt.
  • Beispielsweise kann dieser erste OEM ebenfalls Aktualisierungen der ersten Softwarekomponente 210 des ursprünglichen Herstellers durchführen. Daher verändert der erste OEM in einem Schritt 313 die in dem Blockfeld 201a dieses Blocks 201 hinterlegte Adresse und löscht sie oder setzt dort seine eigene ein.
  • Weiterhin ist es auch denkbar, dass zu dem ersten Zeitpunkt 310 ein weiterer zweiter OEM den von dem ersten OEM erweiterten Programmcode mit den Softwarekomponenten 210, 220 und 230 bezieht und um weitere Softwarekomponenten 240 und 250 erweitert. Der zweite OEM bringt in diesem Fall zu dem ersten Zeitpunkt 310 in Schritt 311 diese Softwarekomponenten 240 und 250 in den Programmcode ein.
  • Beispielsweise kann dieser zweite OEM diese vierte Softwarekomponente 240 von einem Zulieferer bezogen haben und ordnet dieser Softwarekomponente 240 in Schritt 312 in dem für ihn vorgesehenen Slot 203 die Komponentenfelder 241 und 242 zu. In dem Komponentenfeld 241 hinterlegt der zweite OEM aktualisierungsspezifische Informationen, welche Auskunft über eine Version der Softwarekomponente 240 geben. Beispielsweise kann der zweite OEM nicht selbst die Aktualisierung dieser Softwarekomponente 240 übernehmen, sondern der entsprechende Zulieferer. In diesem Fall hinterlegt der zweite OEM in Schritt 312 die Adresse der entsprechenden Quelle, z.B. der Cloud des Zulieferers, in dem Komponentenfeld 242.
  • Die fünfte Softwarekomponente 250 kann beispielsweise von dem zweiten OEM selbst erstellt worden sein und der zweiten OEM kann auch die Aktualisierung dieser fünften Softwarekomponente 250 übernehmen. Der zweite OEM ordnet der Softwarekomponente 250 in Schritt 312 das Komponentenfeld 251 zu und hinterlegt darin als aktualisierungsspezifische Informationen eine Version der Softwarekomponente 250. Weiterhin hinterlegt der zweite OEM in Schritt 312 in dem Blockfeld 203a die Adresse der Quelle, z.B. der eigenen Cloud, welche die Aktualisierung der eigenen Softwarekomponente 250 übernimmt.
  • Weiterhin gibt der zweite OEM vor, dass Komponentenadressen in seinem Block 203 höhere Relevanz besitzen als die Slotadresse. Somit gilt für die Softwarekomponente 240 die in dem Komponentenfeld 242 hinterlegte Komponentenadresse und nicht die Slotadresse. Da der Softwarekomponente 250 keine Komponentenadresse zugeordnet ist, der Softwarekomponente 240 hingegen schon, gilt die in dem Blockfeld 203a hinterlegte Slotadresse für die Softwarekomponente 250.
  • Alternativ könnte der zweite OEM beispielsweise auch vorgeben, dass die Slotadresse eine höhere Relevanz besitzt als die Komponentenadressen. In diesem Fall gilt die Slotadresse zunächst für alle Softwarekomponenten 240, 250 dieses Slots 203. Nur wenn unter dieser Slotadresse keine Aktualisierung für eine Softwarekomponente verfügbar ist, wird die Komponentenadresse für diese Softwarekomponente ausgewählt.
  • Der zweite OEM übernimmt keine Aktualisierungen der übrigen bereits vorhandenen Softwarekomponenten 210, 220 und 230 und lässt daher die bereits vorhandenen Blockfelder unverändert. Schritt 313 wird in diesem Fall daher nicht durchgeführt.
  • Nachdem der zweite OEM den Programmcode erweitert und eine finale Version des Programmcodes 200 erstellt hat, kann der Programmcode in Schritt 314 auf das jeweilige IoT-Gerät geladen werden. Insbesondere hat ein Endkunde an dieser Stelle die Möglichkeit, in einem für ihn vorgesehenen Slot 204 weitere Informationen zu hinterlegen. Beispielsweise kann der Endkunde in Komponentenfeld 261 eine Version des Programmcodes oder Eigenschaften des IoT-Geräts beschreiben und in Komponentenfeld 262 ein Zeitintervall, nach dessen Ablauf nach Aktualisierungen für das IoT-Gerät gesucht werden soll. Das Blockfeld 204a bleibt in diesem Beispiel leer.
  • Nachdem der Programmcode 200 in Schritt 315 auf dem IoT-Gerät gestartet wurde, das IoT-Gerät in das Netzwerk 150 eingebracht und mit den weiteren IoT-Geräten 110, 120, 130, 140 vernetzt wurde und das vorgegebene Zeitintervall abgelaufen ist, wird zu dem zweiten Zeitpunkt nach Aktualisierungen für den Programmcode 200 gesucht.
  • Dabei wird zu dem zweiten Zeitpunkt 320 für jede Softwarekomponente 210, 220, 230, 240, 250 des Programmcodes 200 beginnend mit einer hierarchisch höchsten Softwarekomponente bis zu einer hierarchisch niedrigsten Softwarekomponente konsekutiv bzw. kaskadenartig jeweils in Abhängigkeit von den jeweiligen Block- und Komponentenfeldern der jeweiligen Softwarekomponente 210, 220, 230, 240, 250 überprüft, ob eine Aktualisierung für die jeweilige Softwarekomponente 210, 220, 230, 240, 250 verfügbar ist.
  • Als hierarchisch höchste Softwarekomponenten sind in diesem Beispiel die zuletzt eingebrachten Softwarekomponente 240 und 250 des zweiten OEMs anzusehen.
  • Da der zweite OEM vorgegeben hat, dass in seinem Block 203 Komponentenadressen eine höherer Relevanz besitzen als die Slotadresse, wird in Schritt 321 zunächst geprüft, ob für die Softwarekomponente 240 und 250 Komponentenadressen vorhanden sind, ob also eine Adresse in einem Komponentenfeld hinterlegt ist. Da dies für die Softwarekomponente 240 der Fall ist, wird die in dem Komponentenfeld 242 hinterlegte Adresse ausgewählt und die entsprechende Quelle bzw. Cloud des entsprechenden Zulieferers wird kontaktiert. Ist die Adresse nicht erreichbar, wird in Schritt 322 als sicherheitstechnische Maßnahme ein Fehlerzähler inkrementiert. Erreicht der Fehlerzähler dabei einen Grenzwert, wird der Programmcode 200 und somit das IoT-Gerät von dem Internet 150 getrennt und in einen sicheren Zustand gebracht wird.
  • Wenn die Adresse bzw. die Cloud jedoch erreichbar ist, wird in Schritt 323 eine sichere Verbindung zu der Netzwerkadresse aufgebaut und die aktualisierungsspezifischen Informationen des Komponentenfeldes 241, welche die aktuelle Version der Softwarekomponente 240 beschreiben, werden an die Cloud übermittelt. Die Cloud überprüft daraufhin in Schritt 324, ob für diese Version der Softwarekomponente 240 eine Aktualisierung vorhanden ist. Wenn nicht, teilt die Cloud dies dem IoT-Gerät in Schritt 325 mit und die sichere Verbindung wird getrennt. Wenn jedoch eine Aktualisierung vorhanden ist, wird diese in Schritt 326 an das IoT-Gerät übermittelt, dort validiert und durchgeführt. Nach durchgeführter Aktualisierung werden die komponentenspezifischen aktualisierungsspezifischen Informationen im Komponentenfeld 241 in Schritt 327 aktualisiert und die neue Version der Softwarekomponente wird darin vermerkt. Die Verbindung zu der Cloud wird in Schritt 328 wird getrennt.
  • Nachdem somit alle Softwarekomponenten überprüft wurden, für die Komponentenadressen, also komponentenspezifischen Informationen mit darin hinterlegten Netzwerkadressen überprüft wurden, werden nun die Softwarekomponenten ohne derartige Komponentenadressen überprüft, namentlich die Softwarekomponente 250, und die Schritte 321 bis 328 werden für die Softwarekomponente 250 analog durchgeführt.
  • Für diese Softwarekomponente 250 wird die in dem Blockfeld 203a hinterlegte Adresse in Schritt 321 ausgewählt und die entsprechende Quelle, z.B. die Cloud des zweiten OEM wird kontaktiert. Analog zu obiger Beschreibung wird entweder in Schritt 322 ein Fehlerzähler inkrementiert, wenn die Cloud nicht antwortet, oder eine sichere Verbindung wird in Schritt 323 aufgebaut und die komponentenspezifischen Informationen des Komponentenfeldes 251 werden an die Cloud übermittelt. Diese überprüft in Schritt 324 daraufhin, ob für diese Version der Softwarekomponente 250 eine Aktualisierung vorhanden ist. Wenn dies der Fall ist, wird die Aktualisierung in Schritt 326 durchgeführt, die komponentenspezifischen Informationen 251 werden in Schritt 327 aktualisiert und die Verbindung zu der Cloud wird in Schritt 328 getrennt.
  • Wie oben erläutert hätte der zweite OEM auch vorgegeben können, dass in dem Slot 203 die Slotadresse eine höhere Relevanz besitzt als die Komponentenadressen. In diesem Fall wird für die Softwarekomponente 240 in Schritt 321 zunächst die Slotadresse des Blockfelds 302a ausgewählt und kontaktiert. Insbesondere wird zunächst eine sichere Verbindung zu der Cloud dieser Slotadresse aufgebaut und die aktualisierungsspezifischen Informationen der Softwarekomponente 240 werden an die Cloud übermittelt. Die Cloud teilt daraufhin mit, dass sie für die Aktualisierung dieser Softwarekomponente 240 nicht zuständig ist und keine Aktualisierungen verfügbar sind und die sichere Verbindung wird beendet. Daraufhin wird die in dem Komponentenfeld 242 der Softwarekomponente 240 hinterlegte Komponentenadresse ausgewählt und die Aktualisierung der Softwarekomponente 240 wird wie oben erläutert durchgeführt. Anschließend wird die Slotadresse auch für die Softwarekomponente 250 ausgewählt und diese Softwarekomponente 250 wird wie oben erläutert aktualisiert.
  • Nachdem somit nach Aktualisierungen für die Softwarekomponenten 240 und 250 des Slots 203 gesucht wurde, wird mit den hierarchisch nächst niedrigeren Softwarekomponenten fortgefahren, namentlich mit den Softwarekomponenten 220 und 230 des ersten OEMs und des Slots 202.
  • Da für diese Softwarekomponenten 220 und 230 nur eine Adresse bzw. Slotadresse in dem Blockfeld 202a hinterlegt ist, wird diese entsprechende Adresse in Schritt 231 ausgewählt und die Quelle, also die Cloud des ersten OEM wird kontaktiert.
  • Analog zu obiger Beschreibung wird in Schritt 322 ein Fehlerzähler inkrementiert, wenn die Cloud unter dieser Netzwerkadresse nicht erreichbar ist. Ansonsten wird in Schritt 323 eine sichere Verbindung aufgebaut und es werden zunächst die komponentenspezifischen Informationen des Komponentenfeldes 231 der Softwarekomponente 230 an die Cloud übermittelt, welche in Schritt 324 überprüft, ob für diese Version der Softwarekomponente 230 eine Aktualisierung vorhanden ist. Wenn dies der Fall ist, wird die Aktualisierung in Schnitt 326 durchgeführt und die komponentenspezifischen Informationen des Komponentenfeldes 231 werden in Schritt 327 aktualisiert. Auf analoge Weise wird daraufhin für die Softwarekomponente 220 verfahren. Anschließend wird in Schritt 328 die sichere Verbindung getrennt.
  • Anschließend wird für die hierarchisch geringste Softwarekomponente 210 nach Aktualisierungen gesucht. Zu diesem Zweck wird in Schritt 321 die in dem Komponentenfeld 212 hinterlegte Adresse bzw. Komponentenadresse ausgewählt und die entsprechende Quelle bzw. Cloud kontaktiert, welche dieselbe Quelle ist, die auch bezüglich der Softwarekomponenten 220 und 230 kontaktiert wurde, nämlich die Cloud des ersten OEM.
  • Analog zu obiger Beschreibung wird in Schritt 322 ein Fehlerzähler inkrementiert, wenn die Cloud nicht erreichbar ist. Ansonsten wird erneut in Schritt 323 eine sichere Verbindung aufgebaut und es werden die komponentenspezifischen Informationen des Komponentenfeldes 211 an die Cloud übermittelt. Diese überprüft in Schritt 324, ob für diese Version der Softwarekomponente 210 eine Aktualisierung vorhanden ist. Wenn dies der Fall ist, wird die Aktualisierung in Schritt 326 durchgeführt, die komponentenspezifischen Informationen 211 werden in Schritt 327 aktualisiert und die sichere Verbindung wird in Schritt 328 getrennt.
  • Sobald das vom Endkunden in den Informationen 262 hinterlegte Zeitintervall erneut abgelaufen ist, werden diese oben genannten Schritte des zweiten Zeitpunkts 320 erneut durchgeführt und es wird erneut nach Aktualisierungen für die Softwarekomponente 210, 220, 230, 240, 250 gesucht.

Claims (16)

  1. Verfahren zum Aktualisieren von Softwarekomponenten (210, 220, 230, 240, 250) eines Netzwerkteilnehmers (110, 120, 130, 140) eines Netzwerks (150), - wobei ein Programmcode des Netzwerkteilnehmers (110, 120, 130, 140) wenigstens zwei herstellerspezifische Blöcke (201, 202, 203, 204) aufweist, - wobei jeder dieser herstellerspezifischen Blöcke (201, 202, 203, 204) mindestens eine Softwarekomponente (210, 220, 230, 240, 250) aufweist, - wobei jedem herstellerspezifischen Block (201, 202, 203, 204) jeweils ein Blockfeld (201a, 202a, 203a, 204a) zugeordnet ist, - wobei der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) jedes herstellerspezifischen Blocks (201, 202, 203, 204) jeweils ein Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) zugeordnet ist, - wobei in wenigstens einem der Blockfelder (201a, 202a, 203a, 204a) und/oder in wenigstens einem der Komponentenfelder (211, 212, 221, 231, 241, 242, 251, 261, 262) jeweils eine Adresse einer für eine Aktualisierung zuständigen Quelle hinterlegt ist, - wobei für die mindestens eine Softwarekomponente (210, 220, 230, 240, 250) jedes herstellerspezifischen Blocks (201, 202, 203, 204) in Abhängigkeit von dem dieser mindestens einen Softwarekomponente (210, 220, 230, 240, 250) zugeordneten Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) und von dem diesem jeweiligen herstellerspezifischen Block (201, 202, 203, 204) zugeordneten Blockfeld (201a, 202a, 203a, 204a) eine Adresse der für die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) zuständige Quelle ausgewählt wird (321) und die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) mit Hilfe der ausgewählten Quelle durchgeführt wird (327).
  2. Verfahren nach Anspruch 1, wobei im Zuge eines Herstellungsprozesses (310), insbesondere bevor der Programmcode in den Netzwerkteilnehmer eingebracht ist, ein Hersteller in dem Blockfeld (201a, 202a, 203a, 204a) seines herstellerspezifischen Blocks (201, 202, 203, 204) und/oder in wenigstens einem der Komponentenfelder (211, 212, 221, 231, 241, 242, 251, 261, 262) seines herstellerspezifischen Blocks (201, 202, 203, 204) jeweils die Adresse der für die Aktualisierung zuständigen Quelle hinterlegt (312).
  3. Verfahren nach Anspruch 2, wobei der Hersteller im Zuge des Herstellungsprozesses in dem Blockfeld (201a, 202a, 203a, 204a) eines fremden herstellerspezifischen Blocks (201, 202, 203, 204) die Adresse der für die Aktualisierung zuständigen Quelle hinterlegt (313).
  4. Verfahren nach einem der vorstehenden Ansprüche, wobei, wenn in dem der wenigstens einen Softwarekomponente (210, 220, 230, 240, 250) eines jeweiligen herstellerspezifischen Blocks (201, 202, 203, 204) zugeordneten Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) eine Adresse hinterlegt ist, diese Adresse für die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) ausgewählt wird (321).
  5. Verfahren nach einem der vorstehenden Ansprüche, wobei, wenn in dem der wenigstens einen Softwarekomponente (210, 220, 230, 240, 250) eines jeweiligen herstellerspezifischen Blocks (201, 202, 203, 204) zugeordneten Komponentenfeld keine Adresse hinterlegt ist, die in dem diesem jeweiligen herstellerspezifischen Block (201, 202, 203, 204) zugeordneten Blockfeld (201a, 202a, 203a, 204a) hinterlegte Adresse für die Aktualisierung dieser mindestens einen Softwarekomponente (210, 220, 230, 240, 250) ausgewählt wird (321).
  6. Verfahren nach einem der vorstehenden Ansprüche, wobei, wenn in dem Blockfeld (201a, 202a, 203a, 204a) eines jeweiligen herstellerspezifischen Blocks (201, 202, 203, 204) eine Adresse hinterlegt ist, diese Adresse für die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) dieses jeweiligen herstellerspezifischen Blocks (201, 202, 203, 204) ausgewählt wird (321).
  7. Verfahren nach Anspruch 6, wobei, wenn für die mindestens eine Softwarekomponente (210, 220, 230, 240, 250) unter der ausgewählten, in dem Blockfeld (201a, 202a, 203a, 204a) des jeweiligen herstellerspezifischen Blocks (201, 202, 203, 204) hinterlegten Adresse keine Aktualisierung verfügbar ist, die in dem der wenigstens einen Softwarekomponente (210, 220, 230, 240, 250) zugeordneten Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) hinterlegte Adresse für die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) ausgewählt (321) wird.
  8. Verfahren nach Anspruch einem der vorstehenden Ansprüche, wobei in den der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) zugeordneten Komponentenfeldern (211, 212, 221, 231, 241, 242, 251, 261, 262) jeweils aktualisierungsspezifische Informationen hinterlegt sind, insbesondere Informationen über eine aktuelle Version der wenigstens einen Softwarekomponente (210, 220, 230, 240, 250).
  9. Verfahren nach Anspruch 8, wobei die Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) mit Hilfe der ausgewählten Quelle in Abhängigkeit von den in dem Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) der wenigstens einen Softwarekomponente (210, 220, 230, 240, 250) hinterlegten aktualisierungsspezifischen Informationen durchgeführt wird (326).
  10. Verfahren nach einem der voranstehenden Ansprüche, wobei für jede Softwarekomponente (210, 220, 230, 240, 250) beginnend mit einer hierarchisch höchsten Softwarekomponente (250) bis zu einer hierarchisch niedrigsten Softwarekomponente (210) jeweils in Abhängigkeit von dem der jeweiligen Softwarekomponente (210, 220, 230, 240, 250) zugeordneten Komponentenfeld (211, 212, 221, 231, 241, 242, 251, 261, 262) und von dem diesem jeweiligen herstellerspezifischen Block (201, 202, 203, 204) zugeordneten Blockfeld (201a, 202a, 203a, 204a) die Adresse der für die Aktualisierung der jeweiligen Softwarekomponente (210, 220, 230, 240, 250) zuständigen Quelle ausgewählt wird (321).
  11. Verfahren nach einem der voranstehenden Ansprüche, wobei im Zuge der Aktualisierung der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) das der mindestens einen Softwarekomponente (210, 220, 230, 240, 250) zugeordnete Komponentenfeld und/oder das dem jeweiligen herstellerspezifischen Block (201, 202, 203, 204) zugeordnete Blockfeld (201a, 202a, 203a, 204a) aktualisiert wird (327).
  12. Verfahren nach einem der voranstehenden Ansprüche, wobei, wenn die ausgewählte Quelle nicht erreichbar ist, eine sicherheitstechnische Maßnahme durchgeführt wird (325), insbesondere ein Fehlerzähler inkrementiert und/oder der Netzwerkteilnehmer (110, 120, 130, 140) in einen sicheren Zustand gebracht wird.
  13. Verfahren nach einem der voranstehenden Ansprüche, wobei der Programmcode (200) auf einem als Internet-of-Things-Gerät ausgebildeten Netzwerkteilnehmer (110, 120, 130, 140) ausgeführt wird.
  14. Recheneinheit (110, 120, 130, 140), die dazu eingerichtet ist, ein Verfahren nach einem der vorstehenden Ansprüche durchzuführen.
  15. Computerprogramm, das eine Recheneinheit (110, 120, 130, 140) veranlasst, ein Verfahren nach einem der Ansprüche 1 bis 13 durchzuführen, wenn es auf der Recheneinheit (110, 120, 130, 140) ausgeführt wird.
  16. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 15.
DE102017219188.0A 2017-10-26 2017-10-26 Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks Pending DE102017219188A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102017219188.0A DE102017219188A1 (de) 2017-10-26 2017-10-26 Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks
US16/156,011 US11106449B2 (en) 2017-10-26 2018-10-10 Method for updating software components of a network subscriber of a network
CN201811251461.0A CN109710282A (zh) 2017-10-26 2018-10-25 用于更新网络的网络参与者的软件组件的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102017219188.0A DE102017219188A1 (de) 2017-10-26 2017-10-26 Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks

Publications (1)

Publication Number Publication Date
DE102017219188A1 true DE102017219188A1 (de) 2019-05-02

Family

ID=66137748

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102017219188.0A Pending DE102017219188A1 (de) 2017-10-26 2017-10-26 Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks

Country Status (3)

Country Link
US (1) US11106449B2 (de)
CN (1) CN109710282A (de)
DE (1) DE102017219188A1 (de)

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6151643A (en) * 1996-06-07 2000-11-21 Networks Associates, Inc. Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer
US6928481B1 (en) * 2000-05-05 2005-08-09 International Business Machines Corporation Method, apparatus and program to optimize the network distribution of digital information based on hierarchical grouping of server topology and code distribution
US20020188934A1 (en) * 2001-06-12 2002-12-12 Nortel Networks Limited Method and system for upgrading existing firmware on third party hardware
US20050125489A1 (en) * 2003-11-26 2005-06-09 Hanes David H. System and method for determining messages on a server as relating to at least one functional component of a client system
US8566613B2 (en) * 2010-06-11 2013-10-22 Intel Corporation Multi-owner deployment of firmware images
US9158526B1 (en) * 2010-11-10 2015-10-13 Open Invention Network, Llc Application update using multiple network connections
US9256424B1 (en) * 2014-09-26 2016-02-09 Oracle International Corporation Managing software configurations across different target software deployments
US9584482B2 (en) * 2014-03-03 2017-02-28 Qualcomm Connected Experiences, Inc. Access control lists for private networks of system agnostic connected devices
WO2016051237A1 (en) * 2014-10-03 2016-04-07 Telefonaktiebolaget L M Ericsson (Publ) Dynamic generation of unique identifiers in a system of connected things
US10389756B2 (en) * 2015-06-09 2019-08-20 Intel Corporation System, apparatus and method for security interoperability path analysis in an internet of things (IOT) network
US9923881B2 (en) * 2015-10-14 2018-03-20 Mcafee, Llc System, apparatus and method for migrating a device having a platform group
WO2017172434A1 (en) * 2016-04-01 2017-10-05 Pcms Holdings, Inc. Internet of things software securtiy configuration
US10097563B2 (en) * 2016-05-04 2018-10-09 Gbs Laboratories, Llc Reliable and secure firmware update with a dynamic validation for internet of things (IoT) devices
US10284684B2 (en) * 2016-09-14 2019-05-07 Microsoft Technology Licensing, Llc IoT hardware certification
US10416991B2 (en) * 2016-12-14 2019-09-17 Microsoft Technology Licensing, Llc Secure IoT device update
US10338913B2 (en) * 2017-12-05 2019-07-02 Archemy, Inc. Active adaptation of networked compute devices using vetted reusable software components

Also Published As

Publication number Publication date
US20190129707A1 (en) 2019-05-02
US11106449B2 (en) 2021-08-31
CN109710282A (zh) 2019-05-03

Similar Documents

Publication Publication Date Title
EP3520350B1 (de) Manipulationssicheres speichern einer prozessgrösse in einem automatisierungssystem
EP1779203B1 (de) Parameteridentifikation für feldgeräte in der automatisierungstechnik
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
WO2018059855A1 (de) Verfahren zum manipulationssicheren speichern von daten eines feldgeräts
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
DE102017215508A1 (de) Automatisierungssystem mit mindestens einem Feldgerät und mindestens einer Steuereinheit
WO2017005783A1 (de) Computerimplementiertes verfahren zur bearbeitung von datenobjektvarianten
EP3001310A1 (de) Verfahren und Einrichtung zur Aktualisierung von Firmware für Komponenten einer industriellen Automatisierungsanordnung
EP2808749B1 (de) Verfahren zum Austausch von Steuerungsinformationen zwischen Bedien- und Beobachtungsgeräten eines industriellen Automatisierungssystems und industrielles Automatisierungssystem
EP2770382B1 (de) Verfahren zur Inbetriebnahme eines Automatisierungssystems
DE102015113379A1 (de) System zur Stromverteilung für ein Luftfahrzeug und entsprechendes Verfahren zum Steuern
EP3699704B1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
EP3485455A1 (de) Verfahren und vorrichtung zum bestimmen von optimalen losgrössen
EP3396479B1 (de) Engineering-system
DE102017219188A1 (de) Verfahren zum Aktualisieren von Softwarekomponenten eines Netzwerkteilnehmers eines Netzwerks
DE102016123599A1 (de) Robotersteuerung mit Funktion zur Kommunikation mit einer speicherprogrammierbaren Steuerung und Kommunikationssystem
DE102020119853B3 (de) Verfahren zum Steuern eines Automatisierungssystems mit Visualisierung von Programmobjekten eines Steuerprogramms des Automatisierungssystems und Automatisierungssystem
EP3285162A1 (de) Verfahren zum projektieren eines projektes sowie anordnung zur durchführung des verfahrens
EP1331534B1 (de) Automatisierungssystem und Verfahren zur Erzeugung einer Dokumentation
DE10330191A1 (de) System bzw. Verfahren zur Freigabe freigabebedürftigter Softwareprogramme
DE102019217844A1 (de) Verfahren zum Konfigurieren einer Speichereinheit einer Recheneinheit
DE102014118042A1 (de) Verfahren zur nachverfolgbaren Programmierung und Konfigurierung eines Geräts
EP3484127A1 (de) Verfahren und vorrichtung zur sicheren vergabe von adressen an module in einem netzwerk, adressierungseinrichtung, computerprogrammprodukt und industrielle anlage
DE102008004923B4 (de) Verfahren zur Aktualisierung eines Steuerungsablaufes einer Maschinensteuerung sowie Vorrichtung zur Durchführung des Verfahrens
EP2899603B1 (de) Projektieren eines Feldbussystems