-
Die vorliegende Erfindung betrifft ein Verfahren sowie ein System auf dem technischen Gebiet der Softwareaktualisierung auf einer beliebigen Geräteeinheit bzw. einem Fahrzeug.
-
Der Einsatz von Software nimmt, nicht zuletzt durch das „Internet of Things“ und M2M-Kommunikation, in allen Bereichen des Lebens immer mehr zu. Durch selbstfahrende Fahrzeuge wird die unmittelbare Abhängigkeit von funktionierender Software schon bald in der Praxis für jedermann erlebbar gemacht. Mit der stetigen Zunahme des Einsatzes von Software steigt aber auch der Bedarf diese möglichst immer aktuell zu halten. So müssen im Rahmen der selbstfahrenden Autos die Verkehrserkennungsalgorithmen und das Kartenmaterial ständig aktualisiert werden, um die Fahrzeuge noch sicher zu machen. In wenigen Jahren werden „smarte“ Implantate das Leben nicht nur von körperlich beeinträchtigten Menschen bereichern. Diese Implantate benötigen aktuelle Software. Sicherheitslücken müssen überdies immer wieder geschlossen werden. Die Aktualität und Integrität von Software wird bei einer ständig zunehmenden Digitalisierung in allen Lebensbereichen deshalb immer wichtiger und wird gegebenenfalls sogar zu einem überlebenswichtigen Faktor.
-
Aktuelle und integre Software ist aus mannigfaltigen Gründen wichtig. Bei heutigen Smartphones ist es ein Kauf- und Einsatzkriterium geworden, dass für diese Geräte dauerhaft Softwareupdates bereitgestellt werden. Bei Smartphones geht es vordringlich jedoch „nur“ um die Sicherheit, der auf dem Gerät vorhandenen oder darüber erfassbaren Daten und Informationen, bei einem Auto jedoch um das Thema Verkehrssicherheit bzw. Gefährdungsvermeidung, bei einem Implantat sogar direkt um das Leben der Person, wenn das Implantat z. B. eine implantierte Insulinpumpe oder künstliche Organe steuert oder ein Herzschrittmacher ist.
-
Die auf einem Gerät oder in einem Fahrzeug installierte aktuelle Softwareversion kann also fehlerhaft und deswegen sehr kritisch sein. Die Software vermittels einer Mobilfunkverbindung oder Internet „over the air“ upzudaten birgt allerdings viele Risiken. Selbst wenn die hohen dazu notwendigen Datenvolumina im Bereich von Giga- bis Terabyte über zukünftige Mobilfunknetze übertragbar und dies auch noch bezahlbar wäre, besteht hierdurch immer das Risiko, das über die Mobilfunkverbindung ein Angriff auf das Fahrzeug/Gerät durchgeführt wird. Ein Angreifer könnte so z. B. ein Fahrzeug in seine Gewalt bringen, Erpressungsversuche starten oder sogar Leib und Leben von Personen gefährden. Der „Killer“ der Zukunft bräuchte nur manipulierte Software auf ein Fahrzeug aufzubringen, die bei Erreichen einer höheren Geschwindigkeit (z. B. 150 Km/h) Gaspedal, Bremspedal und/oder Lenkung des Fahrzeugs gezielt verändert und sich optional nach dieser Aktivität automatisch löscht oder verschlüsselt. Es könnten implantierte medizinische Geräte, die lebenswichtig sind, auf vergleichbare Art sabotiert werden.
-
Es ist also erforderlich ein Softwareupdate möglichst zeitnah zu erhalten und zugleich die Integrität, also die Echtheit und Vollständigkeit der Software sicherzustellen und zu verhindern, dass Angreifer einen Zugriff auf die Übertragungsschnittstelle der Geräte bzw. der Fahrzeuge erlangen. Da niemand vorhersagen kann, ob in fünf oder zehn Jahren, die zurzeit als sicher anzusehende kryptographischen Verfahren auch noch in der Zukunft relativ sichere Softwareupdates ermöglichen, kommt dem integren Bereitstellungsweg eines Softwareupdates eine sehr große Bedeutung zu.
-
Der vorliegenden Erfindung liegt daher die Aufgabe zu Grunde, innovative Konzepte und Verfahren anzugeben, um den Softwarestand aktuell zu halten und die Integrität der Software zu gewährleisten.
-
Diese Aufgabe wird gelöst durch ein Verfahren des unabhängigen Anspruchs 1 und ein System des unabhängigen Anspruchs 10.
-
Das erfindungsgemäße Verfahren zur Erhöhung der Sicherheit beim Aufspielen von Softwareupdates auf einer Geräteeinheit umfasst folgende Schritte:
- - Die Softwareupdates werden durch einen Hersteller oder optional durch ein anderes autorisiertes Unternehmen bereitgestellt.
- - Die Softwareupdates werden auf eine autorisierte Verteilerplattform mit einer Geräteschnittstelle bzw. Fahrzeugschnittstelle übertragen.
- - Die Geräteeinheit wird mit der Geräteschnittstelle der Verteilerplattform zur Einrichtung eines Datenkanals verbunden, wobei dieser Datenkanal zum Aufspielen des Softwareupdates vorgesehen und ausgebildet ist.
- - Der Datenkanals zur Datenübertragung von der Verteilerplattform auf die Geräteeinheit wird autorisiert.
- - Das Softwareupdate wird auf die Geräteeinheit aufgespielt bzw. hochgeladen.
-
Im Folgenden umfasst der Begriff Geräteeinheit sowohl kleine Endgeräte wie Smartphones, Implantate wie auch beliebige Fahrzeuge und Maschinen. Die nachfolgende Verwendung einer der Begriffe Geräte, Geräteeinheit oder Fahrzeug ist nicht beschränkend aufzufassen, sondern schließt die anderen Begriffe ein. Vorgenanntes ist das Ziel des erfindungsgemäßen Verfahrens. Die Verwendung des Begriffs Softwareupdate soll den Anwendungsfall einer Erstinstallation oder der Installation einer Zusatzsoftware bzw. eines Updates oder Sicherheitspatches umfassen.
-
Geräte, wie z. B. Fahrzeuge, Implantate und Maschinen sind nicht selten zehn oder mehr Jahre im Betrieb. Das erfindungsgemäße Verfahren ermöglicht durch sein zumindest zweistufig ausgeprägtes Sicherheitskonzept, dass eine sichere Softwareaktualisierung über den gesamten Lebenszyklus der Geräte ermöglicht wird. Bei bereits angewendeten Sicherheitskonzepten wird die Software hinsichtlich ihrer Authentizität und Integrität vor der Installation von dem Gerät selbst überprüft wird. Dieser Schutz kann allerdings technisch von Angreifern mitunter umgangen werden, wenn diese z.B. per Mobilfunk auf das Gerät zugreifen. Es kann damit nicht sichergestellt werden, dass das verwendete Gerät auch in 5 oder 10 Jahren noch zweifelsfrei erkennen kann, ob eine neue Software noch integer ist, da die verbauten Bauteile nicht mehr in der Lage sind einen dann zeitgemäßen Signaturschlüssel mit höherer Länge verarbeiten zu können.
-
Erfindungsgemäß wird schon diese erste Sicherheitsmaßnahme durch das erfindungsgemäße Verfahren erhöht, da die Hersteller bzw. die autorisierten Unternehmen die Software „direkt“ an die autorisierte Verteilerplattform übertragen. Es kann technisch verhindert werden, dass sich ein Angreifer in diese Übertragung zwischenschaltet. Die zweite Sicherheitsmaßnahme ist durch einen integren und möglichst nicht manipulierbaren Weg zur Bereitstellung des Softwareupdates ausgezeichnet, indem das Softwareupdate eben nur vermittels der Verteilerplattform durchführbar ist. Die Verteilerplattform gewährleistet hierbei im Prinzip dieselbe Sicherheit als wenn das Gerät direkt zum Hersteller gebracht werden würde. Dieser Weg lässt sich vergleichsweise einfach auf einem aktuellen und als sicher anzusehenden Niveau halten, zudem kann er für eine Vielzahl von Updates ggf. auch für unterschiedliche Geräte zur Anwendung kommen.
-
Bevorzugt erfolgt die Übertragung des Softwareupdates auf die Verteilerplattform durch einen physischen Datenträger, kabelgebunden oder über eine weitere technische Sicherheitsmaßnahme. Hierfür können physische bzw. mechanische Komponenten zum Einsatz kommen. Ein physischer Datenträger kann beispielsweise als USB-Stick oder Blueray-DVD ausgebildet sein. Es kann vorgesehen sein, dass ein Kontakt betätigt werden muss. Ein physisches Kontaktschloss kann z.B. eine speziell geformte Schnittstelle sein, in die ein Kontaktschlüssel passgenau eingebracht werden muss, um eine Datenübertragung zu starten. Auch ortsabhängige Faktoren, z. B. Auswertung der GPS-, Galileo- und/oder Glonass-Koordinaten, bestehenden Funkverbindungen, festlegen von berechtigten Funkzellen und/oder auswerten der aktuellen Funkzelle im Mobilfunk, können technisch als weitere Sicherheitsmaßnahme ausgewertet werden. Eine eigens zu der Verteilerplattform eingerichtete Standleitung bzw. bedarfsgerecht per Stream bereitgestellte Software auf einem hoch performanten integren Übertragungsweg (z. B. per Glasfaser) kann ebenfalls ein hohes Maß an Sicherheit bieten.
-
Vorzugsweise ist die Verteilerplattform als Tankstelle, Werkstatt, Arztpraxis, Krankenhaus, Serviceunternehmen-/techniker oder autorisierter Softwarevertrieb ausgestaltet. Diese Verteilerplattformen werden von den Nutzern der Geräte meist ohnehin regelmäßig aufgesucht, sodass beim Aufspielen der Softwareupdates der zusätzliche Aufwand reduziert wird. Zusammen mit einer hohen Sicherheit kann an diesen Verteilerplattformen eine Art „Schnelladefunktion“ für die Software implementiert werden. Die Schnelladefunktion soll es ermöglichen im Zeitraum von wenigen Minuten (z. B. während eines Tankvorgangs, Arztbesuchs, Techniker-Aufenthalts) auch das Softwareupdate zu erhalten - z. B. über ein lokales Glasfaserkabel-netzwerk, per Funk- oder optischer kabellosen Verbindung. Die Verteilerplattform (z. B. Tankstelle, Arztpraxis, Aufenthalt in einem Funknetz, mitgeführtes Gerät eines Servicetechnikers) bemerkt das Gerät selbsttätig, z. B. per NFC oder Aufenthalt im lokalen Funknetz und erkennt, dass ein Softwareupdate ansteht und/oder eine für das Endgerät verantwortliche Person wird darüber informiert (z. B. Tankstellenbetreiber, Servicetechniker, Arztpraxis). Wenn das Gerät nicht selbsttätig über den aktuellen Softwarestand informiert, kann die Erkennung, dass ein Softwareupdate ansteht auch über eine zentrale Datenbank in Erfahrung gebracht werden, welche den aktuellen Softwarestand das Gerät beinhaltet.
-
Zweckmäßig wird die Schnittstelle der Geräteeinheit zur Ermöglichung des Downloads der Software auf das Gerät aktiviert und freigeschaltet. Um einen weiteren Angriffspunkt auszuschließen, ist es möglich und in Abhängigkeit von der verwendeten Art des Datenkanals, also des Übertragungsmediums, auch angezeigt dass die Aktivierung der Schnittstelle für den Download des Softwareupdates zuvor gezielt hierfür freigeschaltet werden muss. Beim verwendeten Medium „Lichtwellenleiter“, Massenspeicher (z. B. USB-Stick) und auch anderen kabelgebundenen Konnektivitäten als Datenkanal ist die gezielte Freischaltung der Schnittstelle nicht unbedingt notwendig, wenn man, um diesen anzuschließen, einen direkten physischen Kontakt zum Gerät benötigt.
-
Bei dem für eine Funkverbindung verwendeten Medium „Luft“ ist die Luftschnittstelle dagegen ein potentieller Angriffspunkt und muss deshalb abgesichert werden. Für die Freischaltung der Schnittstelle empfiehlt es sich ggf. auch konkrete Aktivitäten bei einem Fahrzeug vom Fahrzeugführer einzufordern (z. B. Betätigung eines Schalters oder Auslösen einer Funktion) und/oder Standardaktivitäten des Fahrers auszuwerten (z. B. das Öffnen der Fahrertür und/oder der Tankklappe). Vergleichbares gilt für Implantate oder andere Geräte, bei denen zusätzlich noch ein Kontakt betätigt, Schalter umgelegt oder das Gerät oder ein Teil davon in eine besondere Position oder Stellung gebracht werden muss.
-
Der Einsatz spezieller Token wie RFID/NFC kann alternativ oder ergänzend die zum Softwareupdate benötigte Schnittstelle freischalten. Diese Token könnten z. B. direkt an der Zapfpistole für die Abgabe des Treibstoffs (z. B. Benzin, Gas, Strom) an das Fahrzeug angebracht sein, sich an einem Stuhl befinden, auf dem der Träger eines Implantates zum Update sitzen muss oder am Stecker des Kabels (oder am Servicekoffer) angebracht sein, wenn ein Servicetechniker ein Gerät mit dem Softwareupdate versieht. Eine dementsprechende Lesereinheit muss am Gerät angebracht sein, um den Token auszulesen. Auch der beidseitige Einsatz dieser speziellen Token kann zur Anwendung kommen, damit das Gerät sowohl seine Identität alternativ oder ergänzend angeben kann als wohl auch der Datenkanal bzw. die von ihm verwendete Schnittstelle für das Übertragen der Software auf das Gerät seine Identität alternativ oder ergänzend preis gibt.
-
In einer bevorzugten Ausgestaltung der Erfindung wird das Softwareupdate von der Verteilerplattform überprüft und autorisiert. Bereits vor dem Download des Softwareupdates auf das Gerät (z. B. auf das Fahrzeug, Maschine, Implantat oder Endgerät) bzw. dem Download des Softwareupdates seitens der Verteilerplattform, sollte die Integrität des Updates überprüft und sichergestellt werden, sodass nur ein als „sicheres“ und verifiziertes Softwareupdates in den Zwischenspeicher des Gerätes übertragen werden kann. Spätestens, wenn das Softwareupdate sich bereits im Zwischenspeicher befindet, sollte eine erneute Validierung der Software erfolgen, z. B. hinsichtlich der Aktualität der Softwareversion (d. h. Softwareversion muss „neuer“ sein), der Vertrauenswürdigkeit des Erstellers der Software (z. B. bestätigte Identität des Hersteller) und/oder der Integrität der Software (d. h. das Update ist vollständig und wurde nicht verändert).
-
Zur Feststellung der Authentizität, Vertrauenswürdigkeit und Integrität des Softwareupdates haben sich kryptographische Verfahren etabliert, bei denen das Softwareupdate in Verbindung mit einer Signatur bereitgestellt wird. Auf Basis der Signatur sind sowohl der Ersteller der Software, als auch die das Zertifikat ausstellende vertrauenswürdige Instanz und auch der zum Softwareupdate korrespondierende Hash-Wert bekannt. Die das Zertifikat ausstellende und vom Gerät (z. B. Fahrzeug, Implantat oder Endgerät) als vertrauenswürdig angesehene Instanz sollte in einem speziell abgesicherten Bereich des Geräts (TPM, Trusted Plattform Modul) sicher und vor Manipulation geschützt, abgelegt sein. Dort kann zusätzlich der konkrete Hersteller des Geräts, der Ersteller des Softwareupdates, der Softwareverteiler, die Verteilerplattform und/oder der Softwaretreuhänder als vertrauenswürdig bzw. berechtigt hinterlegt sein.
-
Bei der Verifikation wird die Identität der das Zertifikat ausstellenden Instanz (CA) und ggf. noch der Ersteller der Software als berechtigt überprüft, inwieweit diese auch als vertrauenswürdig bzw. berechtigt im Gerät hinterlegt sind. Die Gültigkeit des zur Signatur verwendeten Zertifikats muss bestätigt werden (z. B. per Sperrlisten- oder OCSP-Prüfung) und auch der für das Softwareupdate vor Ort ermittelte Hashwert muss mit dem im Signaturzertifikat angegebenen verglichen werden. Ergibt der Vergleich eine Übereinstimmung und treffen auch die anderen vorgenannten Eigenschaften zu, dann ist die Software als verifiziert zu betrachten und kann auf dem Gerät installiert werden. Alternativ kann auch die Verifikation mittels Blockchain geschehen, die dann die für die Verifikation benötigten Angaben (z. B. zum Ersteller der Software, der Versionsnummer und dem Hashwert der Software) beinhaltet.
-
Bevorzugt werden die Aktualität und der Zustand der Software auf der Geräteeinheit oder einer anderen Stelle angezeigt. Da die Software und unter Umständen auch deren Aktualität die Verkehrssicherheit eines Fahrzeuges, die Gesundheit von Personen und/oder die Funktionstüchtigkeit einer kritischen Infrastruktur beeinflussen kann, sollte die Aktualität der installierten Softwarestände (jedenfalls bzgl. der Prioritätsstufe 1) nachprüfbar erfasst werden. Für diese Aufgabe bieten sich mindestens folgende Stellen an: a) das jeweilige Gerät (z. B. Fahrzeug, Implantat, Endgerät); b) der Hersteller des Geräts (z. B. Fahrzeugs, Implantat, Endgerät); c) die für die Zulassung eines Geräts (z. B. bei Fahrzeugen Kraftfahrtbundesamt) bzw. Implantaten (z. B. Gesundheitsamt/-ministerium) verantwortliche Stelle.
-
Da die Information der installierten Softwarestände z. B. im Falle eines Unfalls oder Unglücks relevant ist, muss sie revisionssicher erfasst und vor Manipulationen geschützt aufbewahrt werden. Hierfür können kryptographische Verfahren zur Signatur dieser Informationen ebenso zur Anwendung kommen, wie die ergänzende oder alternative Verwendung eines speziell gesicherten Bereiches, deren Sicherheit ggf. auch von einer unabhängigen Instanz bestätigt wird (z. B. TÜV-Zertifikat). Der speziell gesicherte Bereich kann bei einem Fahrzeug oder einer Maschine in einer Art Black-Box bestehen, wie sie vergleichbar auch bei Verkehrsflugzeugen eine wichtige Rolle spielt. Bei Implantaten oder Endgeräten kann dies insbesondere in einem speziellen Chip (TPM, Trusted Plattform Modul) geschehen. Bei Fahrzeugen hat sich etabliert, dass bevorstehende oder ein bereits erfolgtes Versagen von wichtigen Funktionen des Fahrzeuges mindestens dem Fahrzeugführer angezeigt werden. Kontrollleuchten für den Öldruck, den Öl- oder Benzinstand sind aus heutigen Fahrzeugen deshalb nicht mehr wegzudenken. Das Verfahren sieht insbesondere vor, Defizite im Softwarestand von Geräten geeignet zur Anzeige und zur Meldung zu bringen. Bei Fahrzeugen kann der Softwarestand, der für die Verkehrssicherheit kritischer Komponenten dem Fahrzeugführer angezeigt und/oder mitgeteilt werden. Bei Polizeikontrollen könnte zudem mit einer vergleichbar leicht ablesbaren Anzeige die Aktualität der Software kritischer Komponenten und somit die Fahrsicherheit überprüft werden. Analog zu Fahrzeugen kann dies auch bei Implantaten oder Endgeräten umgesetzt werden, wenn diese mittels einer zusätzlichen Anzeige (z. B. nicht leuchtende LED) auf einen nicht ausreichenden bzw. bei einer „normalen“ Anzeige (z. B. blinkende oder dauernd leuchtenden LED) auf einen ausreichenden Softwarestand hinweisen.
-
Bevorzugt wird durch das Verfahren die Geräteeinheit autorisiert bzw. verifiziert. Damit Software oder Softwareupdates nicht an Unberechtigte gelangen und so gegebenenfalls zur Vorbereitung von Angriffen per Reverse Engineering verwendet werden können, ist es zweckmäßig, eine Software nur dann zum Download bereitzustellen bzw. weiterzugeben, wenn die Identität des für den Empfang eines Softwaredownloads vorgesehenen Empfängers oder der Geräteeinheit ebenfalls bestätigt ist. So kann auch verhindert werden, dass durch sehr viele gleichzeitige Downloads an unverifizierte Empfänger, die Verfügbarkeit des Dienstes in Form einer (D)DoS-Attacke beeinträchtigt wird. Für die Überprüfung der Identität des Softwareempfängers haben sich kryptographische Verfahren etabliert, bei der insbesondere auf Basis eines Zertifikats die Identität des Softwareempfängers ermittelt werden kann. Die Einbeziehung einer zur Identifikation des Gerätes schon heute verwendeten Nummer (z. B. Fahrzeug-Identifizierungsnummer oder einer Seriennummer) bietet sich hierbei ebenso an wie auch die Verifikation von MAC- und IP-Adressen, sofern eine IP-Verbindung mit dem Gerät besteht.
-
Ist das Zertifikat von einer dem Softwareverteiler als vertrauenswürdig bekannten Stelle (CA, Certificate Authority) ausgestellt und diese für den Softwareempfänger auch noch als gültig überprüft worden (überprüfbar z. B. per Sperrlistenüberprüfung oder OCSP), dann kann von einer bestätigten Authentizität des Empfängers ausgegangen werden. Alternativ oder ergänzend kann auch eine Blockchain zur Bestätigung der Identität des Empfängers einer Software verwendet werden, damit kann z. B. überprüft werden, ob die vom Empfänger angegebene Identität (z. B. Seriennummer ggf. auch als Teil des Zertifikats) in dieser enthalten ist.
-
Der Softwareempfänger ist in aller Regel entweder das Gerät, das das Update benötigt oder ein Softwaretreuhänder oder lokaler Softwareverteiler. Beide Funktionen können eine nach dem vorstehend Verfahren betriebene Tankstelle, eine Arztpraxis oder ein Servicetechniker bieten. Softwareverteiler, also Verteilerplattform, ist z. B. eine Tankstelle dann, wenn Sie gezielt für ein bestimmtes Fahrzeug die „Beschaffung“ der Software durchführt und beim nächsten Besuch des Fahrzeugs dieses Softwareupdate bereitstellt (Softwareverteiler). Vergleichbares gilt auch für eine Arztpraxis in Bezug auf das Softwareupdate eines Implantats.
-
Als lokaler Softwareverteiler bzw. Verteilerplattform fungiert die Tankstelle, wenn sie alle Softwareupdates, die es für Fahrzeuge gibt oder nur für bestimmte Fahrzeugmarken (z. B. VW und Audi) zum Update bereitstellt. Vergleichbares gilt auch für Fachabteilungen von Krankhäusern, so kann dort z. B. die Kardiologie nur Software für Herzschrittmacher bereitstellen. Dies ist insbesondere deshalb vorteilhaft, da die Software bei den lokalen Verteilerplattformen immer für den Download bereitstehen kann, unabhängig von der momentanen Anbindung an einen zentralen Softwareverteiler. Der Download von Software vom zentralen zum lokalen Softwareverteiler kann auch über wenig leistungsstarke Leitungen erfolgen, z. B. mit 50Mb/s, während dann der spätere Download dieses Updates in das Fahrzeug, die Geräteeinheit oder (in Abhängigkeit von Art und Umfang ggf.) in das Implantat, z. B. per Funkverbindung, Glasfaser- oder drahtloser optischer Verbindung, mit 50Gb/s erfolgen kann.
-
Da ein Softwareupdate im Regelfall nicht nur für ein konkretes Gerät bereitgestellt wird, kann ein beim lokalen Softwareverteiler einmal vorhandenes Softwareupdate dementsprechend auch vielfach für vergleichbare Updatevorgänge bei baugleichen Geräten oder in diesen verwendeten Komponenten bereitgestellt werden. Dies kann den Datenverkehr im Internet allgemein und insbesondere zum Softwareverteiler bzw. der Verteilerplattform deutlich reduzieren.
-
In einer vorteilhaften Ausgestaltung der Erfindung wird die Geräteeinheit von der Verteilerplattform informiert, dass ein Softwareupdate bereitgestellt ist. Mittels eines über eine Internetverbindung erhaltenen Signals, via Mobilfunk oder kabelgebunden, spätestens aber beim Aufsuchen einer hierfür vorgesehenen Stelle (Verteilerplattform) wird der Geräteeinheit die Information zugänglich gemacht, dass ein Softwareupdate verfügbar ist. Via Mobilfunk kann diese Information den Geräteeinheiten besonders schnell zugänglich gemacht werden. Da die Integrität des Softwareupdates durch das Verfahren sichergestellt ist, führt die Benachrichtigung via Mobilfunk nicht zu einer Erhöhung des Sicherheitsrisikos. Ein Angreifer hätte im Regelfall keinen Vorteil davon, Nutzer über ein Softwareupdate zu informieren, das nicht vorhanden ist. Die Übertragung erfolgt nämlich erfindungsgemäß über die Verteilerplattform, sodass einem Angreifer die Möglichkeit genommen wird, sich dazwischenzuschalten.
-
Technisch kann auf verschiedenen Wegen ermittelt werden, ob ein Softwareupdate vorliegt bzw. eine entsprechende Benachrichtigung an das Gerät gesendet werden sollte oder sogar muss.
-
Eine bekannte Möglichkeit ist das PUSH-Verfahren: Die für die Aktualisierung der Software verantwortliche Stelle, z. B. der Hersteller des Fahrzeugs, der Maschine, des Implantats, des Endgeräts oder eine von diesen hierfür beauftragte und autorisierte Stelle, sendet eine Information, dass ein Softwareupdate vorliegt. Eine Prioritätsstufe für das Softwareupdate kann dabei ebenfalls mitgesendet werden. Diese Information kann über das Mobilfunknetz übertragen werden und z. B. als Broadcast-Signal ausgesendet werden. Nur dort, wo die Information zum Vorliegen eines Softwareupdates zu dem verwendeten Fahrzeugtyp, Maschinentyp, Implantat oder Endgerät und dem zurzeit installierten Softwarestand passt, hat diese Information jedoch eine Relevanz. Die Information über eine neue Software bzw. ein Softwareupdate kann aber auch in Form eines besonderen PUSH-Verfahrens gezielt nur an die Fahrzeuge, Implantate oder Endgeräte des für die Verwendung des Softwareupdates überhaupt in Frage kommenden Typs übermittelt werden.
-
Eine weitere bekannte Möglichkeit ist das PULL-Verfahren: Zeit- und/oder aktionsabhängig (z. B. alle 24 Stunden und/oder bei jedem Start des Fahrzeugs, der Maschine oder beim Einschalten des Geräts) erkundigt sich die Geräteeinheit automatisch bei einer zentralen Stelle, ob ein Softwareupdate ansteht - gegebenenfalls in Abhängigkeit der Prioritätsstufe.
-
Eine andere Möglichkeit ist ein spezielles PUSH- oder PULL-Verfahren: Abhängig vom Ort des Fahrzeuges, der Maschine, der Person, des Geräts und den zurzeit verfügbaren Funknetzen mit einer definierten Kennung (z. B. WLAN mit der SSID „Softwarestatus“) und/oder einer gerade stattfindenden Aktivität (z. B. Betätigung eines Kontakts) und/oder eines aktuell empfangenen oder auslesbaren Freischaltcodes (z. B. per Blockchain), kommt ein PULL- und/oder PUSH-Verfahren zum Erhalt einer Information zur Anwendung, das auf ein ausstehendes Update hinweist.
-
Die vorgenannten Verfahren können einzeln, aber auch in Kombination miteinander zur Anwendung kommen.
-
In Abhängigkeit der Priorität, die das Softwareupdate aufweist, kann eine Aktualisierung durchgeführt werden. Die Priorität kann ebenfalls auf der Geräteeinheit angezeigt werden. Softwareupdates haben in der Regel mindestens die folgenden Prioritätsstufen:
- - Prioritätsstufe 1: Die Software muss sofort heruntergeladen und auch installiert werden.
- - Prioritätsstufe 2: Die Software muss sofort heruntergeladen und kann zu einem Zeitpunkt im Ermessen eines Verantwortlichen (z. B. Fahrzeug-/Maschinenführer, Servicetechniker, Arzt), jedoch spätestens nach einer Zeit X (z. B. 24 Stunden) installiert werden.
- - Prioritätsstufe. 3: Die Software ist optional, d. h. sie kann im Ermessen eines Verantwortlichen (z. B. Fahrzeug-/Maschinenführer, Servicetechniker, Arzt) heruntergeladen und auch installiert werden.
-
In Abhängigkeit der Prioritätsstufe des Softwareupdates kann das Softwareupdate von einem Verantwortlichen gezielt gestartet (Prioritätsstufe. 3) oder selbsttätig installiert werden (Prioritätsstufe 1). Welche Prioritätsstufe des Softwareupdates zum Tragen kommt, bestimmen die hiervon betroffenen Funktionsarten und auch die Art („Kritikalität“) des Endgeräts. Sind z. B. Funktionen betroffen, die die Verkehrssicherheit, die Gesundheit eines Menschen oder die Sicherheit einer kritischen Infrastruktur direkt oder indirekt beeinflussen, so muss das Update nach den Prioritätsstufen 1 oder 2 durchgeführt werden. Ist hingegen ein für die Verkehrssicherheit, Gesundheit eines Menschen oder funktionieren einer kritischen Infrastruktur/Maschine eher „unwichtiges“ Gerät betroffen (z. B. das Entertainmentsystem bei einem Fahrzeug; ein Steuergerät, das für die Bewegung eines Armes bei einer Armprothese nur „hilfreich“ ist; ein Endgerät zur Erfassung von Wetterdaten), genügt es dieses Softwareupdate mit einer geringen Priorität wie der der Prioritätsstufe 3 durchzuführen.
-
Folgende von einem Softwareupdate betroffenen Funktionsarten werden im Regelfall mindestens unterschieden und bestimmen somit die Prioritätsstufe, d. h. die Erforderlichkeit zur Aktualisierung und Installation dieser Software:
- - Funktionsart 1: Sicherheitstechnisch wichtige, funktionswichtige und/oder überlebenswichtige Geräte sind vom Softwareupdate betroffen, z.B. ein Fahrzeug ist nicht mehr fahrbereit oder ein lebenswichtiges Organ droht auszufallen. Die Software muss möglichst schnell und zugleich sicher heruntergeladen und auch installiert werden. Prioritätsstufe 1: Beispiele: Softwareupdates für ein ABS-System oder einen Herzschrittmacher verhindert eine Fehlfunktion oder das Stromnetz an einem Ort droht sonst auszufallen.
- - Funktionsart 2: Sicherheitstechnisch, funktionswichtig und/oder überlebenswichtige Geräte sind vom Update nicht direkt betroffen, d. h. ein Fahrzeug ist z. B. weiterhin fahrbereit oder eine Gefahr für das Leben eines Menschen besteht nicht. Es wird dennoch empfohlen, ein Update zeitnah und sicher durchzuführen. Prioritätsstufe 2: Beispiele: Neue Software zur Steuerung der Scheibenwischer bietet ein neues Wischintervall an, das automatisch die aktuelle Regenmenge und auch die Fahrgeschwindigkeit des Fahrzeuges berücksichtigt. Neue Software zur Steuerung des Herzschrittmachers senkt dessen Batterieverbrauch um 5%. Eine kritische Infrastruktur, wie z. B. das Stromnetz könnte nur unter ganz besonderen Umständen dadurch beeinträchtigt werden.
- - Funktionsart 3: Keine sicherheitstechnisch, funktions- oder überlebenswichtigen Geräte sind vom Softwareupdate betroffen. Prioritätsstufe 3: Beispiele: Software des Entertainmentsystems bietet ein neues farbiges Layout zur Auswahl der Funktionen auf dem Display an. Software für ein Steuergerät einer Armprothese erlaubt nun Drehungen des Armes um zusätzliche 10 Grad. Eine kritische Infrastruktur, wie z. B. das Stromnetz erhält eine neue Tarifierung, um Ökostrom noch genauer abrechnen zu können.
-
In Abhängigkeit der Prioritätsstufe des Softwareupdates kann die Installation der Software stattfinden. Hierfür wird die Software von dem Ort, wo sie nach dem Download abgelegt wurde (Zwischenspeicher) auf den Speicher des Wirksystems des Geräts übertragen und das für das Softwareupdate relevante IT-System (Gerät oder Teil des Geräts) dann mit der neuen Software gestartet. Zuvor kann noch eine weitere Überprüfung der Authentizität und Integrität der Software (z. B. im Bootloader) erfolgen.
-
Zweckmäßig wird der Erfolg der Installation, d. h. das erfolgreiche oder nicht erfolgreiche Durchführen des Softwareupdates, z. B. dem Fahrer des Fahrzeuges, Führer der Maschine, dem Träger des Implantats oder dem Servicetechniker/Arzt mitgeteilt. Alternativ kann dies auch der Verteilerplattform mitgeteilt werden. Zentralen und lokalen Softwareverteilern und/oder dem Ersteller des Softwareupdates (z. B. Herstellers des Fahrzeugs, Implantat, Endgerät) sollte diese Information bei Bedarf ebenfalls mitgeteilt werden, damit diese beispielweise bei einem erfolgreich durchgeführten Update ggf. Zusatzkosten für die erbrachte Dienstleistung in Rechnung stellen können oder so erfahren, dass eine fehlerfreie Installation ggf. nicht möglich ist und dann sofort beginnen dem Fehler nachzugehen und ggf. beginnen an einem erneuten Softwareupdate zu arbeiten.
-
Vorzugsweise überprüft die Geräteeinheit die Softwareversion des Softwareupdates und autorisiert und verifiziert das Softwareupdate. Selbst wenn die für die Pflege der Software verantwortliche Stelle (z. B. Hersteller des Fahrzeugs, des Implantats oder Endgeräts) das Softwareupdate konkret für ein Gerät bereitgestellt hat, sollte überprüft werden, ob diese Softwareversion wirklich eine aktuellere Version darstellt, als die zurzeit installierte. Hierfür ist es erforderlich, dass vor der Installation der Software die Softwareversion auf Basis eines dem Gerät bekannten Algorithmus verglichen wird, um eine neuere Version zweifelsfrei erkennen zu können. Ein hierzu sehr gebräuchlicher Algorithmus ist das Hochzählen einer Zahl oder Zahlenkombination, anhand der erkannt werden kann, dass eine neue Softwareversion vorhanden ist. Hiernach ist beispielsweise eine Softwareversion mit der Nummer V1.123 aktueller, als die zurzeit installierte Software mit der Versionsnummer V1.122. Auch Kombinationen mit Buchstaben, Zahlen und/oder Sonderzeichen sind zweckmäßig. Informationen darüber, ob ein Softwareupdate für ein konkretes Gerät vorliegt, sollten hinsichtlich ihrer Identität von einer autorisierten Stelle, nachfolgend auch Softwareverteiler genannt, stammen. Für die Überprüfung der Identität des Softwareverteilers haben sich kryptographische Verfahren etabliert, bei denen beispielsweise auf Basis eines Zertifikats die Identität des Softwareverteilers ermittelt werden kann. Ist das Zertifikat von einer dem Gerät als vertrauenswürdig bekannten Stelle (CA, Certificate Authority) ausgestellt worden und dieses für den Softwareverteiler auch noch gültig (überprüfbar z. B. per Sperrlistenüberprüfung oder OCSP), dann kann von einer bestätigten Authentizität des Softwareverteilers ausgegangen werden. Alternativ kann auch eine Blockchain zur Bestätigung der Identität des Bereitstellers einer Software und/oder der Validierung der aktuellen Softwareversion verwendet werden.
-
Softwareersteller und Softwareverteiler können identisch sein. Analog zum Softwareverteiler muss auch der Softwareersteller sicherstellen, dass die erstellte Software integer ist. Hierfür können die zuvor bereits erwähnten kryptographischen Verfahren zur Anwendung kommen.
-
Bevorzugt werden die Softwareupdates von der Verteilerplattform mittels eines physischen Datenträger bzw. eines physischen Datenkanals auf die Geräteeinheit bzw. das Gerät übertragen. Der physische Datenträger kann als USB-Stick oder Blueray-DVD oder als vergleichbares Medium ausgestaltet sein und der physischen Datenkanal als Glasfaserkabel oder eine sonstige Kabelverbindung. Die Daten können aber auch über eine Funkverbindung im Nahbereich (z. B. Bluetooth/WLAN) oder auch per optischer kabelloser Verbindung zum Gerät übertragen werden. Wenn ein physischer Datenträger verwendet wird oder das Softwareupdate als Datei bei der Verteilerplattform vor Ort abgespeichert vorliegt, wird ermöglicht, dass die Verteilerplattform die Softwareupdates auch unabhängig von einer gerade bestehenden Internetverbindung durchführen kann. Bei der Verwendung eines physischen Mediums muss dieses lediglich mit der Geräteschnittstelle kompatibel sein. Der Vorgang zum Update der Software erfolgt möglichst durch vorherige Freigabe und/oder Verwendung eines physischen Kontakts, hergestellt zwischen dem Gerät, das das Update benötigt und der Stelle (z. B. Tankstelle, Servicetechniker, Arztpraxis), die das Update unmittelbar bereitstellt. Damit sichergestellt ist, dass es Angreifern nicht möglich ist Software auf einem anderen als dem vorgeschrieben Weg zu installieren, sollten spezielle Hardwarekomponenten verbaut, bereits verbaute Hardwarekomponenten mitbenutzt werden und/oder von der Lokalität bedingte Informationen Verwendung finden. Bei der Verwendung von Funknetzen als Datenkanal der Verteilerplattformen können Freischaltcodes in der Form, dass der „Auftrag“ zur Installation über einen anderen logischen oder physikalischen Weg erteilt wird, verwendet werden. Diese Freischaltcodes können zur Überprüfung der Integrität dienen, sie erhalten z. B. das Installationssignal für ein konkretes Gerät, die Identifikationsnummer der Software und dessen Hashwert. Hierfür können z. B. QR-Codes, Token und auch Einträge in einer Blockchain zur Anwendung kommen.
-
In Abhängigkeit der Menge die an Daten übertragen werden, bieten sich nach internationalen Standards gefertigte Schnittstellen (z. B. USB3.0) ebenso an, wie Lichtwellenleiter, Funkverbindungen (z. B. WLAN, Bluetooth) und optische Verbindungen (z. B. IR, Laser), damit in einer angemessenen Zeit die Software (Daten) übertragen werden kann. Sollte das Gerät die Daten nicht direkt verarbeiten können, oder ein zusätzlicher Verifikationsprozess für die Software vorgesehen sein, so empfiehlt es sich ggf. einen schnellen Zwischenspeicher zu verwenden, z. B. einen Flash-Speicher. Bei Verwendung eines Lichtwellenleiters oder einer kabellosen optischen Verbindung besteht in Abhängigkeit der konkreten Umgebung in der die Daten übertragen werden sollen der Vorteil, dass keine Funken im Kontext des Updates entstehen können, die Dämpfe (z. B. von Treibstoffen) oder Gase entzünden, bzw. zur Explosion bringen könnten.
-
Gemäß eines weiteren Aspekts der Erfindung wird ein System angegeben, das zur Durchführung des vorstehend beschriebenen Verfahrens geeignet ist.
-
Weitere vorteilhafte Ausgestaltungsmerkmale der vorliegenden Erfindung sind in den abhängigen Patentansprüchen genannt.
-
Im Folgenden werden bevorzugte Ausführungsbeispiele der vorliegenden Erfindung unter Bezugnahme auf die begleitenden Figuren und die in den Figuren dargestellten Bezugszeichen erläutert:
- 1: zeigt ein erstes Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zum Aufspielen von Softwareupdates auf Geräteeinheiten.
- 2: zeigt ein zweites erfindungsgemäßes Ausführungsbeispiel des Verfahrens zum Aufspielen von Softwareupdates auf Geräteeinheiten.
- 3: zeigt ein Ausführungsbeispiel einer ersten Ausgestaltung eines erfindungsgemäßen Systems.
- 4: zeigt ein Ausführungsbeispiel einer zweiten Ausgestaltung des erfindungsgemäßen Systems.
- 5: zeigt ein Ausführungsbeispiel einer dritten Ausgestaltung des erfindungsgemäßen Systems.
-
Nachfolgend werden zahlreiche Merkmale der vorliegenden Erfindung anhand von bevorzugten Ausführungsformen ausführlich erläutert. Die vorliegende Offenbarung ist dabei nicht auf die konkret genannten Merkmalskombinationen beschränkt. Vielmehr lassen sich die hier genannten Merkmale beliebig zu erfindungsgemäßen Ausführungsformen kombinieren, sofern dies nachfolgend nicht ausdrücklich ausgeschlossen ist.
-
1 zeigt ein erfindungsgemäßes Verfahren zum Aufspielen von Softwareupdates auf Geräteeinheiten anhand eines ersten Prozessablaufs. Der nachfolgende Prozess aus 1 zeigt die grundlegenden Abhängigkeiten bei der Erstellung und Verteilung eines Softwareupdates, bis direkt in das für das Update vorgesehene Gerät, z. B. Fahrzeug, Maschine, Implantat oder Endgerät. Aus Gründen der Vereinfachung wird nachfolgend bei dem das Softwareupdate erhaltende technische Gerät oft nur noch von „Gerät“ gesprochen. Der Begriff „Gerät“ ist als Oberbegriff zu verstehen und steht stellvertretend für alle Arten von technischen Geräten und Einrichtungen die mittels einer Software gesteuert und/oder betrieben werden, wie z. B. Fahrzeuge (z. B. Auto, Motorrad, LKW), wie z. B. autonome Maschinen (z. B. Baumaschinen, Roboter), wie z. B. Implantate (z. B. motorisierte Arm- oder Beinimplantate/-prothesen) und wie z. B. Endgeräte (z. B. IoT-Endgeräte, Medizinische Geräte, alle anderen Arten prozessorgesteuerter Maschinen, Komponenten von kritischen Infrastrukturen).
-
Bei den nachfolgend dargestellten Prozessen sind Verzweigungen angezeigt. Auf Verzweigungen wertet ein Algorithmus entweder mit einem Ja oder einem Nein aus. In 1 wird das „Ja“ 185 durch eine „1“ und das „Nein“ durch eine „0“ 180 repräsentiert.
-
Das Bezugszeichen 100 repräsentiert den Start des ersten Prozesses. Der Algorithmus läuft in Schritt 101, welcher eine Erstellung des Softwareupdates repräsentiert. Es folgt mit dem Bezugszeichen 120 eine Abnahme und Freigabe des Softwareupdates. Diese Abnahme und Freigabe kann sowohl von dem Ersteller der Software, Hersteller des Geräts, als auch von dem Betreiber der zentralen bzw. ersten Verteilerplattform oder in einer Kooperation zwischen den vorgenannten Parteien durchgeführt werden. Eine mögliche Ausgestaltung ist, dass das Softwareupdate bei dem Hersteller des Gerätes erzeugt wird und ein Mitarbeiter das Softwareupdate auf einem physischen Datenträger persönlich bei der Verteilerplattform abliefert oder über eine geschützte Verbindung dieser zur Verfügung stellt. In Schritt 130 wird das Softwareupdate auf eine Verteilerplattform hochgeladen. Als nächstes erfolgt eine Benachrichtigung an das Gerät, ob ein Softwareupdate vorliegt oder nicht. Dies kann mittels eines PUSH-Verfahrens 140 oder mittels eines PULL-Verfahrens 145 ausgeführt werden liegt kein Softwareupdate vor, so wird der Prozess in einem Schritt 199 beendet. Liegt ein Softwareupdate vor, wird in der Folge auf das PUSH-Verfahren 140 eine automatische Information über eine Existenz des Software-Updates an das Gerät gesendet. Nun kann das Softwareupdate entweder zum lokalen Softwareverteiler 160 downgeloadet werden oder das Softwareupdate wird direkt auf das Gerät 170 downgeloadet. In dem Schritt 199 wird der Prozess dann abgebrochen. Entlang der Pfade, die dem PULL-Verfahren 145 Folgen, verläuft der weitere Prozessablauf im Wesentlichen analog mit dem Unterschied, dass erst auf Nachfrage Informationen über die Existenz des Software-Updates zugänglich gemacht werden - dies betrifft den Prozessschritt 155.
-
2 zeigt ein zweites detaillierteres erfindungsgemäßes Ausführungsbeispiel des Verfahrens zum Aufspielen von Softwareupdates auf Geräteeinheiten. In 2 wird das „Ja“ 285 durch eine „1“ und das „Nein“ durch eine „0“ 280 repräsentiert.
-
Bei Bezugszeichen 200 wird der Prozess gestartet. In Schritt 205 wird ein signiertes Softwareupdate zur Weitergabe bzw. Verteilung bereitgestellt. In Schritt 207 wird dies an die Verteilerplattform verteilt. In der Verzweigung 215 wird überprüft, ob ein Softwareupdate vorliegt. Wird dies verneint, so wird der Prozess beendet; Schritt 299. Liegt ein Softwareupdate vor, folgt ein 2-stufigerVerifikationsprozess. Zum einen wird in Schritt 220 der Verteiler des Softwareupdates verifiziert und zum anderen in Schritt 225 der Empfänger des Softwareupdates verifiziert. In der Verzweigung 230 wird überprüft, ob beide Verifikationen bestätigt werden können, ist dies nicht der Fall, so wird der Prozess in Schritt 299 abgebrochen. Werden beide Verifikationen bestätigt, können zwei alternierende Pfade von dem Algorithmus beschritten werden. In der ersten Alternative wird in Schritt 250 das Softwareupdate auf das Gerät downgeloadet. In Schritt 252 wird dieses Softwareupdate auf Authentizität und Integrität hin verifiziert. Kann diese Verifikation in der Verzweigung 231 nicht bestätigt werden, so wird der Algorithmus abgebrochen. Kann die Verifikation bestätigt werden, so erfolgt in Schritt 255 die Installation des Softwareupdates auf dem Gerät. In der zweiten Alternative erfolgte zunächst in Schritt 260 ein Download der Software zu einem lokalen Softwareverteiler. In Prozessschritt 265 wird die Authentizität und Integrität des Softwareupdates verifiziert. Kann dies nicht bestätigt werden, so wird in Schritt 299 der Algorithmus abgebrochen. Kann die Verifikation bestätigt werden, werden in zwei parallel verlaufenden Prozessen 270, 275 sowohl der Verteiler des Softwareupdates verifiziert als auch der Empfänger des Softwareupdates verifiziert. Werden beide Verifikationen verneint, wird der Prozess wiederum abgebrochen. Können beide Verifikationen bejaht werden, so läuft die zweite Alternative in den Prozessschritt 250 der erste Alternative ein. Der hierauf folgende Verlauf ist analog zu der ersten Alternative.
-
3 zeigt ein Ausführungsbeispiel einer ersten Ausgestaltung eines erfindungsgemäßen Systems, das mit dem erfindungsgemäßen Verfahren „betrieben“ wird. 1 zeigt eine Lokalität 301, die insbesondere eine herkömmliche Tankstelle, Werkstatt, Arztpraxis, Betriebsgelände oder ganz allgemein ein geographisch definierter Bereich sein kann.
-
Ein Softwareupdate wird erstellt und entweder vom Ersteller, einer zwischengeschalteten Verifizierungsinstanz oder einer zentralen Verteilplattform 302 signiert und über die zentrale Verteilplattform 302 zum Download bereitgestellt. In der zentralen Verteilplattform 302 ist das Softwareupdate in einer zentralen Datenhaltung 309 abgelegt. Eine zentrale Steuereinheit 305 kann über ein neues Softwareupdate per PUSH-Funktion ebenso informieren, wie auf per PULL-Funktion erhaltene Anfragen nach einem Softwareupdate reagieren.
-
Die zentrale Verteilplattform 302 steht mit ihrer Schnittstelle 307 über eine Geräteschnittstelle 306 in direktem Kontakt mit dem Gerät 308. Alternativ oder ergänzend kann dieser Kontakt aber auch unter Zuhilfenahme einer lokalen Verteilplattform 303 hergestellt werden. In diesem Fall wird das Softwareupdate von der zentralen Verteilplattform 302 über die Schnittstelle 307 an die lokale Verteilplattform 303 übertragen und dort in einer weiteren lokalen Datenhaltung 310 abgelegt. Die lokale Steuereinheit 304 steuert hierbei im Zusammenspiel mit der zentralen Steuereinheit 305 den Download der Software. Der erfolgreiche Download und auch die möglichst genaue Identität, des mit dem Softwareupdate versehenen Geräts, wird der Steuereinheit zentral 305 zurückgemeldet, z. B. auf Basis der Nummer der Softwareversion, des Status zum Erfolg des Downloads (z. B. „ok“) und einer Geräteidentifikation, z. B. der FIN des Fahrzeugs bzw. der Seriennummer der Maschine, des Implantats oder des Endgeräts.
-
Die lokale Steuereinheit 304 hat zudem die Aufgabe im Zusammenspiel mit der Steuereinheit 311 des Geräts 308 Informationen darüber auszutauschen, ob ein Softwareupdate vorliegt und falls „JA“, dass dieses auch korrekt auf das Gerät 308 übertragen wird. Wird per PUSH- und/oder PULL-Funktion festgestellt, dass ein Softwareupdate vorliegt, wird dieses unter Verwendung der Schnittstelle 306 des Geräts 308 an einen Zwischenspeicher 312 des Geräts 308 übertragen. Die Steuereinheit 311 prüft die Integrität und Authentizität der Software und steuert den Installationsvorgang in Abhängigkeit der mit dem Softwareupdate übertragenen Prioritätsstufe. Bei einer Prioritätsstufe 1 muss das Softwareupdate sofort durchgeführt werden. Dies kann in Abhängigkeit des Geräts 308 eine sofortige Installation ohne jegliche weitere Fahrmöglichkeit eines Fahrzeuges oder Weiterbetrieb einer Maschine, sofortige Installation auf einem Implantat ohne die Möglichkeit zum Verlassen der Arztpraxis oder bei einem Endgerät die sofortige Installation der Software unter Einstellung der betroffenen Funktionen bedeuten.
-
Die Installation des Softwareupdates erfolgt so, dass die Steuereinheit 311 des Gerät 308 die hinsichtlich ihrer Authentizität und Integrität bestätigte Software direkt in den Speicher der Wirkanwendung 313 oder einen ggf. diesem noch vorgeschalteten Bootloader (in der Zeichnung nicht dargestellt) überträgt und dass von dem Softwareupdate betroffene IT-System des Geräts 308 mit dieser Software danach neu gestartet wird (bootet). Sollte es hierbei zu Fehlern kommen, wird im Regelfall die alte Software aus dem Speicher Wirkanwendung 313 weiterhin verwendet. Kann dagegen das vom Softwareupdate betroffene IT-System mit der neuen Software fehlerfrei starten, so wird diese zukünftig verwendet und das erfolgreich durchgeführte Softwareupdate dementsprechend im Speicher 314 des Geräts 308 vermerkt. Dass das Softwareupdate erfolgreich durchgeführt wurde, kann vom Gerät 308 z. B. beim nächsten Tankvorgang, Arztbesuch oder Besuch des Servicetechnikers (unter Zuhilfenahme der Lokalität 301), an die zentrale Verteilplattform 302 oder eine andere hierfür vorgesehen Stelle übertragen werden. Alternativ oder in Ergänzung hierzu kann diese Information aber auch direkt vom Gerät 308 an die zentrale Verteilplattform 302 oder eine andere hierfür vorgesehene Stelle übertragen werden.
-
Die Schnittstelle 306 des Geräts 308 kann als eine sehr hochbitratige Funkverbindung (z. B. WLAN nach IEEE 802.11 ad oder schneller), Kabelverbindung (z. B. USB 3.0 oder höher) aber auch mittels Verwendung eines Lichtwellenleiters oder einer kabellosen optischen Verbindung ausgestaltet sein.
-
4 zeigt das System aus 3 exemplarisch für das „Gerät“ Fahrzeug. Es ist eine Zapfpistole im Quer- und Längsschnitt gezeigt, so wie sie gewöhnlich an Tankstellen im Einsatz ist. Am Zapfpistolenkörper 401 befindet sich ein Griff (in der Zeichnung nicht dargestellt) an dem der Zapfpistolenkörper 401 von einer Person, die den Tankvorgang durchführt, gehalten werden kann. Durch das Zapfrohr 404 fließt der Treibstoff in den hierfür vorgesehenen Tank des Fahrzeugs und die Fühlerdüse 405 beendet den Tankvorgang automatisch, sobald diese mit einer Flüssigkeit auch nur kurzzeitig „verschlossen“ wird (Status: „Tank voll“). Ergänzt wird diese Zapfpistole beim erfindungsgemäßen System durch einen Konnektor 402, der fest am Zapfpistolenkörper 401 fest ist. Im Konnektor 402 verläuft eine Datenleitung 403 über die das Softwareupdate vermittels einer geeignet ausgebildeten Schnittstell an das Fahrzeug übertragen wird. Analog zur in der Figur dargestellt Zapfpistole für Treibstoff kann selbstverständlich auch ein E-Stecker im erfindungsgemäßen Verfahren verwendet werden, zum „Auftanken“ von batteriebetriebenen Fahrzeugen.
-
5 zeigt ein weiteres Ausführungsbeispiel für das Fahrzeug. In 5 ist rechts eine Zapfpistole und links die dementsprechend dafür vorgesehene Öffnung am Fahrzeug gezeigt. Das Zapfrohr 504 wird beim Tankvorgang in einen Tankanschluss 508 des Geräts eingeführt. Sobald dies geschieht erfolgt eine Verbindung des Fahrzeugs mit der für das Softwareupdate vorgesehen Datenleitung 503. Der Konnektor 502 wird hierbei zuerst mit einer Zentrierscheibe 507 in Kontakt gebracht, um eine genaue Justierung der Datenleitung 503 zu erreichen. Hierbei kann der Konnektor 503 flexibel ausgeführt sein, insbesondere ist jedoch die Zentrierscheibe 507 und/oder die Aufnahmeöffnung 506 des Konnektor 502 flexibel (z. B. verschiebbar) gelagert. Durch die Flexibilität der Verbindung, wird eine direkte optische Verbindung zwischen der Datenleitung 303, der Zapfpistole und der Datenleitung 503 des Fahrzeugs (in der 5 nicht dargestellt) ermöglicht, über die das Softwareupdate mit einer hohen Datenrate übertragen werden kann. Da eine Zapfpistole im Regelfall in unterschiedlichen Positionen in die Tanköffnung verbracht werden kann, ist es erforderlich eine Position konkret vorzugeben, was durch eine mechanische Führung der Zapfpistole beim Einstecken in den Tankanschluss 308 des Geräts realisiert wird. Auf diese Weise ist eine Datenübertragung über die Datenleitung 503 sichergestellt. Alternativ können aber auch mehrere Kombinationen aus Zentrierscheibe 507 und Aufnahmeöffnung 506 des Konnektor 302 (mit daran angeschlossenen Datenleitungen des Fahrzeugs) vorhanden sein, um beim Tankvorgang unterschiedliche Positionen des Zapfpistolenkörpers 501 zu ermöglichen. Bei der in der 5 dargestellten Anordnung kann der Zapfpistolenkörper sowohl senkrecht eingebracht werden, aber auch versetzt um bis zu +/- 90 Grad zur Senkrechten. Analog zur in der Figur dargestellt Zapfpistole zum Auftanken von Treibstoff kann selbstverständlich auch ein E-Stecker im erfindungsgemäßen Verfahren verwendet werden, zum „Auftanken“ von batteriebetrieben Fahrzeugen.
