DE10105454A1 - Verfahren zur automatischen Ergänzung von Software - Google Patents

Verfahren zur automatischen Ergänzung von Software

Info

Publication number
DE10105454A1
DE10105454A1 DE10105454A DE10105454A DE10105454A1 DE 10105454 A1 DE10105454 A1 DE 10105454A1 DE 10105454 A DE10105454 A DE 10105454A DE 10105454 A DE10105454 A DE 10105454A DE 10105454 A1 DE10105454 A1 DE 10105454A1
Authority
DE
Germany
Prior art keywords
software
test
module
software module
application
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.)
Withdrawn
Application number
DE10105454A
Other languages
English (en)
Inventor
Boer Gerrit De
Oliver Dominguez Lorenzo
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 DE10105454A priority Critical patent/DE10105454A1/de
Priority to PCT/DE2002/000051 priority patent/WO2002063464A2/de
Priority to EP02701181A priority patent/EP1360588B1/de
Priority to US10/467,510 priority patent/US7424707B2/en
Priority to DE50210071T priority patent/DE50210071D1/de
Priority to JP2002563343A priority patent/JP2004518230A/ja
Publication of DE10105454A1 publication Critical patent/DE10105454A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

Es wird ein Verfahren zur automatischen Ergänzung von Software vorgeschlagen, das dazu dient, Software, die auf einem System läuft, durch neue Softwaremodule zu ergänzen, wobei diese Softwaremodule zunächst getestet werden und von diesen Softwaremodulen dann Applikationsmodule abgeleitet werden. Mit den Applikationsmodulen wird die eigentliche neue Funktion ausgeführt. Die Softwaremodule können vorteilhafterweise über eine Funkschnittstelle empfangen werden. Insbesondere für die Anwendung von Software in einem Fahrzeug ist das erfindungsgemäße Verfahren besonders geeignet. Die Ableitung des Applikationsmoduls aus dem Softwaremodul erfolgt üblicherweise durch das Prinzip der Vererbung. Das Softwaremodul wird durch einen Aufruf mit Testparametern getestet.

Description

Stand der Technik
Die Erfindung geht aus von einem Verfahren zur automatischen Ergänzung von Software nach der Gattung des unabhängigen Patentanspruchs.
Es ist bereits bekannt, im Betrieb befindliche Software durch Softwaremodule zu ergänzen. Um diese Softwaremodule zu testen, ist der Einsatz von sogenannten Testvektoren be­ kannt, die eine abgeschirmte Testumgebung verlangen.
Vorteile der Erfindung
Das erfindungsgemäße Verfahren zur automatischen Ergänzung von Software mit den Merkmalen des unabhängigen Patentan­ spruchs hat demgegenüber den Vorteil, dass diese Ergänzung abgeschirmt von dem Benutzer während des Betriebs mit einem Test durchgeführt wird. Dadurch werden insbesondere Unter­ brechungen des Betriebs bei dem Erneuern der Software ver­ mieden. Weiterhin ist es von Vorteil, dass von dem Software­ modul, das zum Test verwendet wird, wenigstens ein Applika­ tionsmodul abgeleitet wird, das dann in der Software letzt­ lich zum Einsatz kommt. Dies spart Code sowie Ressourcen und führt zu einem schnelleren Laden des Softwaremoduls.
Darüber hinaus ist es von Vorteil, dass dieser Test beliebig skalierbar ist. Außerdem ist der Test immer wieder wieder­ holbar, ohne den Betrieb der Software zu stören. Der Test wird insbesondere vor der Verwendung von neuen Applikations­ modulen durchgeführt, so dass der Einsatz nur von getesteten Applikationsmodulen stattfindet. Das erfindungsgemäße Ver­ fahren vereinfacht auch die schrittweise Erweiterung der Software, ohne dass es zu Beeinträchtigungen für einen Nut­ zer kommt. Der Test ist weiterhin durch eine Applikation, die aufgerufen wird, steuerbar und schont damit die System­ verwaltung.
Es ist weiterhin von Vorteil, dass das erfindungsgemäße Verfahren die Verwendung des aus der objektorientierten Programmierung bekannten Vererbungsprinzips ermöglicht. Mit diesem Vererbungsprinzip können von den Softwaremodulen, die neu empfangen werden, die Applikationsmodule in einfacher Weise abgeleitet werden. Zusätzlich können dann den Applika­ tionsmodulen Funktionen hinzugefügt werden, die nicht gete­ stet werden müssen. Dazu zählen z. B. Zugriffe auf Ausgabeme­ dien wie Bildschirme oder Lautsprecher.
Durch die in den abhängigen Ansprüchen aufgeführten Maßnah­ men und Weiterbildungen sind vorteilhafte Verbesserungen des im unabhängigen Patentanspruch angegebenen Verfahrens zur Ergänzung von Software möglich.
Besonders vorteilhaft ist, dass das Softwaremodul, mit dem die Software ergänzt wird, über eine Funkschnittstelle emp­ fangen wird. Damit ist das erfindungsgemäße Verfahren vor­ teilhafterweise für den mobilen Empfang geeignet. Beispiels­ weise kann das Softwaremodul über ein digitales Rundfunk- Übertragungsverfahren wie es DAB (Digital Audio Broadcasting) ist, empfangen werden und wird dann der Rundfunk-Empfängersoftware hinzugefügt. Das erfindungsgemäße Verfahren ist jedoch nicht auf Rundfunkempfänger beschränkt, sondern kann auch für Rundfunksender oder alle anderen Sy­ steme verwendet werden, die Software einsetzen, die ergänz­ bar ist und die eine Ladevorrichtung aufweisen wie bei­ spielsweise eine Funkschnittstelle. Es muß also eine Schnittstelle zur Außenwelt bestehen. Das erfindungsgemäße Verfahren ist damit vor allem für Plattform-unabhängige Software anwendbar, wobei jedoch auf ein Compilieren, also die Erzeugung eines lauffähigen Codes, verzichtet werden soll. Es ist alternativ möglich, ein erfindungsgemäßen Soft­ wareupdate auch über einen drahtgebundenen Zugang durchzu­ führen. Beispiele dafür sind vernetzte Rechner.
Weiterhin ist es von Vorteil, dass bei der Ableitung des wenigstens einen Applikationsmoduls aus dem Softwaremodul Test-eigene Funktionen überschrieben werden. Das sind dann solche Funktionen, die nur für den Test geeignet sind, aber für den normalen Betrieb nicht notwendig oder unzureichend sind. Beispielsweise wird während dem Test nicht das Schrei­ ben in eine Datei getestet, sondern nur das Prüfen des Zu­ griffrechts auf das Schreiben.
Der Test des Softwaremoduls wird vorteilhafterweise durch einen Aufruf mit Testparametern durchgeführt. Testparameter legen damit fest, in welchen Situationen das Softwaremodul getestet wird. Damit können insbesondere kritische Situatio­ nen getestet werden, auch wenn diese Situationen nur mit einer geringen Wahrscheinlichkeit auftreten werden.
Darüber hinaus ist es von Vorteil, dass die Software den Test des Softwaremoduls durch das Setzen einer Variablen überwacht und in Abhängigkeit vom Inhalt dieser Variable den Test wiederholt. Somit kann auch ein zufällig fehlerhafter Test durch ein wiederholtes Durchführen des Tests verifi­ ziert oder widerlegt werden.
Schließlich ist es auch von Vorteil, dass eine Vorrichtung zur Durchführung des Verfahrens vorliegt, die einen Prozes­ sor, auf dem die Software abläuft und der das erfindungsge­ mäße Verfahren durchführt, und einen Speicher zum Zwischen­ speichern oder permanenten Abspeichern von Daten aufweist, sowie eine Ladevorrichtung, die zum Laden des Softwaremoduls ausgebildet ist. Als Ladevorrichtung kann vorteilhafterweise eine Funkschnittstelle verwendet werden, so dass über Funksignale das Softwaremodul empfangbar ist. Dabei ist es insbesondere von Vorteil, dass die Vorrichtung sich in einem Fahrzeug befindet, um so Software des Fahrzeugs für die verschiedenen Komponenten zu erneuern bzw. zu ergänzen. Dies setzt dann voraus, dass die Komponenten im Fahrzeug mitein­ ander vernetzt sind. Dazu kann beispielsweise ein Bussystem verwendet werden, über das dann die Softwaremodule auf die einzelnen Komponenten verteilt werden. Bei zeitkritischen Fahrzeugkomponenten wie einem Antiblockiersystem (ABS) ist es dann natürlich notwendig, dass die Ergänzung der Software während des Betriebs erfolgen kann. Ein Unterbrechen der Funktionsweise des ABS-Systems ist nicht akzeptabel, so dass hier das erfindungsgemäße Verfahren insbesondere geeignet ist.
Zeichnung
Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und werden in der nachfolgenden Beschreibung näher erläutert. Es zeigt Fig. 1 ein Blockschaltbild einer erfindungsgemäßen Vorrichtung, hier ein Rundfunkempfänger und Fig. 2 ein Flußdiagramm des erfindungsgemäßen Verfah­ rens.
Beschreibung
Durch die weitere Verbreitung von Prozessoren in immer mehr Systemen, beispielsweise in Fahrzeugsystemen, und durch die immer größere Leistungsfähigkeit dieser Systeme wird es notwendig, die Software auf diesen Prozessorsystemen regel­ mäßig zu ergänzen bzw. zu ersetzen. Viele dieser Systeme, beispielsweise im Fahrzeug, sind miteinander vernetzt und weisen eine Schnittstelle zur Außenwelt, beispielsweise eine Funkschnittstelle über einen Rundfunkempfänger oder ein Mobiltelephon, auf. Auch Systeme wie Überwachungseinrichtun­ gen oder Haustechniksysteme sind miteinander vernetzt und weisen Schnittstellen auf, die entweder als Funkschnittstel­ len ausgebildet sind oder über Draht gebundene Kommunikati­ onswege mit der Außenwelt verbunden sind. Über diese Schnittstellen können dann neue Softwaremodule empfangen werden und auf die entsprechenden Systeme gebracht werden, um so die Software zu erneuern. Um Sicherheitsaspekten, wie dem Zugriff auf diese Systeme, Rechnung zu tragen, ist es notwendig, dass die Funktionalität des neuen Softwaremoduls überprüft wird, so dass das System, die laufende Software, darunter nicht leidet, also durch das neue Softwaremodul nicht geschädigt wird. Bei laufenden Systemen wie einem Fahrzeug ist es notwendig, dass dieser Software-Update wäh­ rend des Betriebs möglich ist. Damit muss auch ein Testen dieser neuen Softwaremodule abgeschirmt vom Nutzer stattfin­ den. Erfindungsgemäß wird daher dieses neue Softwaremodul während des Betriebs der Software getestet, wobei dann in Abhängigkeit vom Ergebnis des Tests wenigstens ein Applika­ tionsmodul abgeleitet wird und das Applikationsmodul von der Software zum Betrieb verwendet wird.
Fig. 1 zeigt ein Blockschaltbild einer erfindungsgemäßen Vorrichtung zur Durchführung des erfindungsgemäßen Verfah­ rens zur automatischen Ergänzung von Software. Hier wird beispielhaft ein Rundfunkempfänger gezeigt, es ist jedoch auch möglich, dass jedes andere System, das eine Schnitt­ stelle nach außen aufweist und mit einer Software betrieben wird, zur Durchführung des erfindungsgemäßen Verfahrens verwendet wird. Beispielsweise vernetzte Haushaltsgeräte oder Satelliten oder andere isolierte Systeme mit wenigstens einer Schnittstelle.
Eine Antenne 5 ist an einen Eingang eines Hochfrequenzemp­ fängers 4 angeschlossen. Ein Datenausgang des Hochfrequen­ zempfängers 4 ist an einen Dateneingang einer Signalverar­ beitung 3 angeschlossen. Die Signalverarbeitung 3 ist wie­ derum an einen Dateneingang eines Prozessors 1 angeschlos­ sen. Der Prozessor 1 ist über einen Daten-Ein/Ausgang mit einem Speicher 2 verbunden. Über einen ersten Datenausgang ist der Prozessor 1 mit einer Signalverarbeitung 6 verbun­ den. Über einen zweiten Datenausgang ist der Prozessor mit einer Signalverarbeitung 8 verbunden. Die Signalverarbeitung 6 weist einen Ausgang zu einem Lautsprecher 7 auf. Die Si­ gnalverarbeitung 8 weist einen Ausgang zu einer Anzeige 9 auf.
Auf dem Prozessor 1 läuft eine Software zum Betrieb des Rundfunkempfängers, die im Speicher 2 abgespeichert ist. Der Speicher 2 dient weiterhin zur Zwischenspeicherung von Zwi­ schenergebnissen, die während des Ablaufs der Software auf­ treten. Der Speicher 2 wird also sowohl als permanenter als auch als temporärer Speicher verwendet. Dabei kann es sein, dass der Speicher 2 verschiedene physikalische Medien auf­ weist, beispielsweise einen Halbleiterspeicher für die tem­ poräre Speicherung und einen Magnetspeicher, beispielsweise eine Festplatte, für die permanente Speicherung. Ein neues Softwaremodul wird nun mittels Rundfunksignalen, die hier digital sind, über die Antenne 5 empfangen. Als digitale Rundfunk-Übertragungsverfahren zur Übertragung von Daten sind insbesondere DAB (Digital Audio Broadcasting) aber auch DVB (Digital Video Broadcasting), DRM (Digital Radio Mondia­ le) und andere digitale Rundfunk-Übertragungsverfahren ge­ eignet, da bei diesen Rundfunkübertragungsverfahren neben den eigentlichen Audioprogrammen und gegebenenfalls Fernseh­ programmen auch andere Multimediadaten oder Textdaten über­ tragbar sind. Diese Rundfunübertragungsverfahren sind ver­ gleichsweise breitbandig, so dass eine Übertragung von zu­ sätzlichen Daten neben den eigentlichen Rundfunkprogrammen leicht möglich ist, und sie weisen eine Rahmenstruktur auf, die fast beliebige Datenformate zu übertragen gestattet. Zu diesen Daten gehören auch Softwareteile wie das Softwaremo­ dul, das der Software, die auf dem Prozessor 1 läuft, hinzu­ gefügt werden soll.
Im Hochfrequenzempfänger 4 werden dann die digitalen Rund­ funksignale gefiltert, verstärkt und in eine Zwischenfre­ quenz umgesetzt. Dann folgt eine Digitalisierung der empfan­ genen Rundfunksignale. Der so entstandene digitale Daten­ strom wird dann an die Signalverarbeitung 3 übertragen, die eine Kanal- und Quellendekodierung durchführt. Die Nutzdaten aus dem digitalen Datenstrom werden dann an den Prozessor 1 übertragen. Es kann alternativ sein, dass die Aufgaben der Signalverarbeitung 3 auf den Prozessor 1 und den Hochfre­ quenzempfänger 4 verteilt werden. Weiterhin ist es möglich, dass die Analogdigitalwandlung von dem Hochfrequenzempfänger 4 auf die Signalverarbeitung 3 übertragen wird.
Der Prozessor 1 verarbeitet nun die empfangenen Daten und führt sie gegebenenfalls den Wiedergabemitteln, dem Laut­ sprecher 7 und der Anzeige 9, zu. Durch eine entsprechende Dekodierung entdeckt der Prozessor 1, dass sich auch das Softwaremodul zur Erneuerung der eigenen Software unter den Daten befindet. Dieses Softwaremodul wird nun während des Betriebs der eigentlichen Software getestet. Dazu wird ein Objekt aufgerufen, das das Softwaremodul anwenden möchte. Verbessert beispielsweise das Softwaremodul die Ansteuerung der Anzeige 9, dann ruft der Prozessor 1 ein Objekt auf, das eine Anzeige von Daten durchführt.
Mit Testparametern wird dann ein Test des Softwaremoduls durchgeführt. Ist der Test erfolgreich, wird eine entspre­ chende Variable im Speicher 2 gesetzt, und von dem Software­ modul wird wenigstens ein Applikationsmodul abgeleitet, das dann die neuen Funktionen ausführt. Dann wird dieses Appli­ kationsmodul durch das Objekt ausgeführt und steht auch später immer wieder zur Verfügung. Der Test ist wiederhol­ bar, beispielsweise wenn ein erster Testdurchlauf negativ abläuft.
Bei der Ableitung des wenigstens einen Applikationsmoduls können Test-eigene Funktionen im Softwaremodul überschrieben werden. Die Ableitung wird durch das aus der Informatik bekannte Prinzip der Vererbung durchgeführt.
In Fig. 2 ist als Flußdiagramm das erfindungsgemäße Verfah­ ren zur automatischen Ergänzung von Software dargestellt. In Verfahrensschritt 10 wird die Software auf dem Prozessor 1 gestartet. In Verfahrensschritt 11 wird ein neues Software­ modul über die Antenne 5 empfangen und dem Prozessor 1 als Datenstrom übergeben. Durch einen Aufruf eines Objekts, das dieses Softwaremodul benötigt, wird nun erkannt, dass dieses Softwaremodul neu ist und gegebenenfalls ein Test notwendig ist. Im Verfahrensschritt 12 wird nun überprüft, ob dieser Test notwendig ist. Ist das der Fall, wird in Verfahrens­ schritt 13 ein Test des Softwaremoduls mit Testparametern durchgeführt. Wurde in Verfahrensschritt 14 erkannt, dass dieser Test positiv verlaufen ist, dann wird in Verfahrens­ schritt 15 eine Variable im Speicher 2 gesetzt, dass der Test in Ordnung war. Im Verfahrensschritt 16 wird nun von dem Softwaremodul wenigstens ein Applikationsmodul abgelei­ tet, das dann von der Software zur Durchführung der neuen Funktion verwendet wird. In Verfahrensschritt 17 wird dann die Anwendung mit diesem neuen Applikationsmodul gestartet. Wurde in Verfahrensschritt 14 erkannt, dass der Test negativ verlaufen ist, dann wird in Verfahrensschritt 18 die Varia­ ble im Speicher 2 entsprechend gesetzt und im Verfahrens­ schritt 19 wird das Testergebnis ausgegeben, beispielsweise auf der Anzeige 9. Verfahrensschritt 20 beendet das Verfah­ ren. Wurde in Verfahrensschritt 12 erkannt, dass kein Test notwendig ist, dann wird sofort zu Verfahrensschritt 17 gesprungen, um die Anwendung zu starten. Dann kann sofort mit dem Softwaremodul die Applikation gestartet werden, da dann ein Ableiten nicht mehr notwendig ist.
Wie dargestellt, ist das Prinzip der Vererbung geeignet, um aus dem Softwaremodul wenigstens ein Applikationsmodul abzu­ leiten. Als besonders wichtig hat sich dabei die objektori­ entierte Sprache JAVA gezeigt. Hier werden auch JAVA- Quellcode, sogenannte Klassendateien, erzeugt, die dann auf jedem System mit einer sogenannten JAVA-virtuellen Maschine lauffähig sind. Die durch eine solche Klasse implementierten Funktionen und Routinen werden auch als Methoden bezeichnet.
Ein wesentliches Merkmal des Verfahrens ist die Nutzung der Vererbungseigenschaft zur Vermeidung von Mehrfachübertragung von Codes. Den Klassen der bestehenden tatsächlichen Soft­ ware werden eine oder mehrere Klassen mit entsprechenden Test-Routinen zugeordnet. Es werden für die Installation der Software dann alle Klassen, im einfachsten Fall zwei, Test­ klasse und Applikationsklasse, geladen. Die Testklasse bein­ haltet alle auf dem Zielsystem testbaren Methoden der Appli­ kation, beispielsweise Dateizugriffsberechtigungen sowie zusätzliche Testmethoden, mit denen im Betrieb auftretenden kritischen Situationen vorab überprüft werden sollen. Dies wird wie oben dargestellt durch Testaufrufe der Basismetho­ den mit entsprechenden Testparametern erreicht. Da in der Testklasse im wesentlichen die Grundfunktionalitäten der Applikationsklasse definiert sind, wäre für diese Klasse auch der Begriff Basisklasse zutreffend.
Die eigentliche Applikationsklasse wird durch Vererbung aus dieser Klasse erzeugt. Sie verfügt damit über alle Methoden der Testklasse und wird ergänzt durch zusätzliche Methoden, die auf dem Zielsystem nicht testbar sind oder nicht gete­ stet werden sollen. In dieser Klasse können auch Methoden aus der Testklasse überschrieben werden, die in letzterer aus Gründen zur Durchführung des Tests eventuell nicht voll­ ständig oder nur modifiziert implementiert wurden. Die Ap­ plikationsklasse startet weiterhin den in der Testklasse definierten Test, falls dies erforderlich sein sollte. Die Erfindung ist dadurch gekennzeichnet, dass Applikationsklas­ se und Testklasse durch die Vererbung einander logisch zuge­ ordnet sind, wobei die Applikationsklasse (Applikationsmo­ dul) die Methoden der Testklasse (Softwaremodul) in weitem Maße wieder verwendet. Hierdurch wird Code eingespart, was verglichen mit zusätzlich geladenen unabhängigen Testmodulen die Zeit zum Laden der Software herunter setzt als auch die Systemressourcen schont. Eine vererbte Klasse erbt Eigen­ schaften wie Variablen und Funktionen von der vererbenden Klasse. Dies spart die unnötige Wiederholung von Pro­ grammcode.

Claims (8)

1. Verfahren zur automatischen Ergänzung von Software, wobei die Software um ein Softwaremodul ergänzt wird, dadurch gekennzeichnet, dass das Softwaremodul während des Betriebs der Software getestet wird, dass aus dem Softwaremodul in Abhängigkeit von einem Ergebnis des Tests wenigstens ein Applikationsmodul abgeleitet wird und dass das Applikationsmodul von der Software zum Be­ trieb verwendet wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Softwaremodul über eine Funkschnittstelle empfangen wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeich­ net, dass bei der Ableitung des wenigstens einen Appli­ kationsmoduls aus dem Softwaremodul Test-eigene Funk­ tionen überschrieben werden.
4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekenn­ zeichnet, dass das Softwaremodul durch einen Aufruf mit Testparametern getestet wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, dass die Software den Test des Softwaremoduls durch das Setzen einer Variablen über­ wacht und in Abhängigkeit vom Inhalt der Variablen den Test wiederholt.
6. Vorrichtung zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Vorrichtung einen Prozessor (1) und einen Speicher (2) zum Betrieb der Software und eine Ladevorrichtung (5) zum Laden des Softwaremoduls aufweist.
7. Vorrichtung nach Anspruch 6, dadurch gekennzeichnet, dass die Ladevorrichtung als Funkschnittstelle (5) aus­ gebildet ist.
8. Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, dass die Vorrichtung in einem Fahrzeug vorhanden ist.
DE10105454A 2001-02-07 2001-02-07 Verfahren zur automatischen Ergänzung von Software Withdrawn DE10105454A1 (de)

Priority Applications (6)

Application Number Priority Date Filing Date Title
DE10105454A DE10105454A1 (de) 2001-02-07 2001-02-07 Verfahren zur automatischen Ergänzung von Software
PCT/DE2002/000051 WO2002063464A2 (de) 2001-02-07 2002-01-10 Verfahren zur automatischen ergänzung von software
EP02701181A EP1360588B1 (de) 2001-02-07 2002-01-10 Verfahren zur automatischen ergänzung von software
US10/467,510 US7424707B2 (en) 2001-02-07 2002-01-10 Method for automatic updating of software
DE50210071T DE50210071D1 (de) 2001-02-07 2002-01-10 Verfahren zur automatischen ergänzung von software
JP2002563343A JP2004518230A (ja) 2001-02-07 2002-01-10 ソフトウェアを自動的に補完する方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10105454A DE10105454A1 (de) 2001-02-07 2001-02-07 Verfahren zur automatischen Ergänzung von Software

Publications (1)

Publication Number Publication Date
DE10105454A1 true DE10105454A1 (de) 2002-08-29

Family

ID=7673107

Family Applications (2)

Application Number Title Priority Date Filing Date
DE10105454A Withdrawn DE10105454A1 (de) 2001-02-07 2001-02-07 Verfahren zur automatischen Ergänzung von Software
DE50210071T Expired - Lifetime DE50210071D1 (de) 2001-02-07 2002-01-10 Verfahren zur automatischen ergänzung von software

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE50210071T Expired - Lifetime DE50210071D1 (de) 2001-02-07 2002-01-10 Verfahren zur automatischen ergänzung von software

Country Status (5)

Country Link
US (1) US7424707B2 (de)
EP (1) EP1360588B1 (de)
JP (1) JP2004518230A (de)
DE (2) DE10105454A1 (de)
WO (1) WO2002063464A2 (de)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004014130A1 (de) * 2004-03-23 2005-10-20 Axis Engineering Gmbh Verfahren und Vorrichtungen zur Übertragung von Daten an eine mobile Einheit
DE102014221972A1 (de) 2014-10-28 2016-05-12 Robert Bosch Gmbh Subsystem, Kraftfahrzeug, und System zum Übertragen von Softwareupdates an ein Kraftfahrzeug
DE102015203766A1 (de) 2015-03-03 2016-09-08 Robert Bosch Gmbh Teilsystem für ein Fahrzeug und entsprechendes Fahrzeug
DE102012023647B4 (de) * 2012-12-03 2016-09-22 Audi Ag Verfahren und System zum Aktualisieren eines Steuergeräts eines Kraftwagens
DE102015216265A1 (de) 2015-08-26 2017-03-02 Robert Bosch Gmbh Verfahren und Teilsystem zum Installieren eines Softwareupdates in einem Fahrzeug
DE102015221330A1 (de) 2015-10-30 2017-05-04 Robert Bosch Gmbh Verfahren und Vorrichtung zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle
DE102016201279A1 (de) 2016-01-28 2017-08-03 Robert Bosch Gmbh Verfahren und Vorrichtung zum Überwachen einer Aktualisierung eines Fahrzeuges
DE102016211772A1 (de) 2016-06-29 2018-01-04 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aktualisieren mehrerer Steuergeräte über einen gemeinsamen Feldbus
WO2019179779A1 (de) 2018-03-20 2019-09-26 Audi Ag Verfahren zum durchführen eines updates einer softwareapplikation in einem gerät, das sich im betrieb befindet, sowie gerät und kraftfahrzeug

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10161321A1 (de) * 2001-12-13 2003-06-26 Siemens Ag Verfahren zur Aktualisierung von elektronisch modifizierbaren Komponenten eines Automatisierungsgerätes
JP2007502034A (ja) * 2003-07-24 2007-02-01 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 電子システム、及び、電子システムに追加的機能特徴を与える方法
US7913242B2 (en) * 2003-11-04 2011-03-22 Gm Global Technology Operations, Inc. Low cost, open approach for vehicle software installation/updating and on-board diagnostics
CN101339516A (zh) * 2004-05-11 2009-01-07 微软公司 有效地打补丁
CN101080693B (zh) * 2004-12-14 2010-07-28 宝马股份公司 用于在具有更新装置的汽车中使用至少一个移动终端设备的***
CN100430893C (zh) * 2005-02-18 2008-11-05 乐金电子(惠州)有限公司 利用无线信道的产品升级***及其方法
WO2006110991A1 (en) * 2005-04-18 2006-10-26 Research In Motion Limited Method and system for controlling software version updates
KR20080007889A (ko) * 2006-07-18 2008-01-23 삼성전자주식회사 방송수신장치 및 방송수신장치의 소프트웨어 갱신방법
US20090106749A1 (en) * 2007-10-23 2009-04-23 Wolfgang Daum System, method, and computer software code for determining whether a change in a subsystem is compatible with a system
US8397228B2 (en) * 2007-11-14 2013-03-12 Continental Automotive Systems, Inc. Systems and methods for updating device software
US20120117555A1 (en) * 2010-11-08 2012-05-10 Lsi Corporation Method and system for firmware rollback of a storage device in a storage virtualization environment
US8655514B2 (en) 2010-11-18 2014-02-18 General Electric Company Systems and methods for communications based rail vehicle control
US20130117005A1 (en) * 2011-11-08 2013-05-09 International Business Machines Corporation Coverage analysis for multiple test methodologies

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1186028A (en) * 1982-06-23 1985-04-23 Microdesign Limited Method and apparatus for scrambling and unscrambling data streams using encryption and decryption
EP0496494A3 (en) 1991-01-22 1993-05-12 International Business Machines Corporation Software maintenance system
US5410703A (en) * 1992-07-01 1995-04-25 Telefonaktiebolaget L M Ericsson System for changing software during computer operation
US5724272A (en) * 1994-05-04 1998-03-03 National Instruments Corporation Method and apparatus for controlling an instrumentation system
US5847955A (en) * 1994-05-04 1998-12-08 National Instruments Corporation System and method for controlling an instrumentation system
US5699275A (en) * 1995-04-12 1997-12-16 Highwaymaster Communications, Inc. System and method for remote patching of operating code located in a mobile unit
US5732074A (en) * 1996-01-16 1998-03-24 Cellport Labs, Inc. Mobile portable wireless communication system
US5940074A (en) * 1996-06-03 1999-08-17 Webtv Networks, Inc. Remote upgrade of software over a network
US6044224A (en) * 1996-06-26 2000-03-28 Sun Microsystems, Inc. Mechanism for dynamically associating a service dependent representation with objects at run time
US6366898B2 (en) * 1998-09-21 2002-04-02 Sun, Microsystems, Inc. Method and apparatus for managing classfiles on devices without a file system
US6546553B1 (en) * 1998-10-02 2003-04-08 Microsoft Corporation Service installation on a base function and provision of a pass function with a service-free base function semantic
US7162642B2 (en) * 1999-01-06 2007-01-09 Digital Video Express, L.P. Digital content distribution system and method
US6883163B1 (en) * 2000-04-28 2005-04-19 Sun Microsystems, Inc. Populating resource-constrained devices with content verified using API definitions
US7245719B2 (en) * 2000-06-30 2007-07-17 Matsushita Electric Industrial Co., Ltd. Recording method and apparatus, optical disk, and computer-readable storage medium
US6996809B2 (en) * 2000-07-10 2006-02-07 Microsoft Corporation Method and apparatus for providing instrumentation data to an instrumentation data source from within a managed code environment
US20020089410A1 (en) * 2000-11-13 2002-07-11 Janiak Martin J. Biometric authentication device for use with a personal digital assistant
US20020104004A1 (en) * 2001-02-01 2002-08-01 Bruno Couillard Method and apparatus for synchronizing real-time clocks of time stamping cryptographic modules
US20020141582A1 (en) * 2001-03-28 2002-10-03 Kocher Paul C. Content security layer providing long-term renewable security

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004014130B4 (de) * 2004-03-23 2008-12-18 Axis Engineering Gmbh Verfahren und Vorrichtungen zur Übertragung von Daten an eine mobile Einheit
US7583967B2 (en) * 2004-03-23 2009-09-01 Axis Engineering Gmbh Method and devices for transferring data to a mobile unit
DE102004014130A1 (de) * 2004-03-23 2005-10-20 Axis Engineering Gmbh Verfahren und Vorrichtungen zur Übertragung von Daten an eine mobile Einheit
DE102012023647B4 (de) * 2012-12-03 2016-09-22 Audi Ag Verfahren und System zum Aktualisieren eines Steuergeräts eines Kraftwagens
DE102014221972A1 (de) 2014-10-28 2016-05-12 Robert Bosch Gmbh Subsystem, Kraftfahrzeug, und System zum Übertragen von Softwareupdates an ein Kraftfahrzeug
US10007504B2 (en) 2015-03-03 2018-06-26 Robert Bosch Gmbh Modular subsystem for a vehicle for updating and device management
DE102015203766A1 (de) 2015-03-03 2016-09-08 Robert Bosch Gmbh Teilsystem für ein Fahrzeug und entsprechendes Fahrzeug
DE102015216265A1 (de) 2015-08-26 2017-03-02 Robert Bosch Gmbh Verfahren und Teilsystem zum Installieren eines Softwareupdates in einem Fahrzeug
CN106484456A (zh) * 2015-08-26 2017-03-08 罗伯特·博世有限公司 用于在车辆中安装软件更新的方法和子***
DE102015221330A1 (de) 2015-10-30 2017-05-04 Robert Bosch Gmbh Verfahren und Vorrichtung zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle
US10248405B2 (en) 2015-10-30 2019-04-02 Robert Bosch Gmbh Method and device for the robust updating of firmware of a vehicle via an air interface
DE102016201279A1 (de) 2016-01-28 2017-08-03 Robert Bosch Gmbh Verfahren und Vorrichtung zum Überwachen einer Aktualisierung eines Fahrzeuges
DE102016211772A1 (de) 2016-06-29 2018-01-04 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aktualisieren mehrerer Steuergeräte über einen gemeinsamen Feldbus
WO2019179779A1 (de) 2018-03-20 2019-09-26 Audi Ag Verfahren zum durchführen eines updates einer softwareapplikation in einem gerät, das sich im betrieb befindet, sowie gerät und kraftfahrzeug
DE102018204188A1 (de) 2018-03-20 2019-09-26 Audi Ag Verfahren zum Durchführen eines Updates einer Softwareapplikation in einem Gerät, das sich im Betrieb befindet, sowie Gerät und Kraftfahrzeug

Also Published As

Publication number Publication date
EP1360588B1 (de) 2007-05-02
WO2002063464A2 (de) 2002-08-15
WO2002063464A3 (de) 2003-02-06
EP1360588A2 (de) 2003-11-12
DE50210071D1 (de) 2007-06-14
JP2004518230A (ja) 2004-06-17
US20050102661A1 (en) 2005-05-12
US7424707B2 (en) 2008-09-09

Similar Documents

Publication Publication Date Title
DE10105454A1 (de) Verfahren zur automatischen Ergänzung von Software
DE102008045724B4 (de) Abstimmungstechniken für Schleifenfilter von zeitkontinuierlichen Sigma-Delta-Modulatoren
DE102005044084A1 (de) Zufallsbitgenerator und Zufallszahlengenerator
DE112005003597T5 (de) Bedienung eines Mobilgeräts
EP3217236B1 (de) Verfahren und system zur generierung eines bedienprogramms in form einer auf einem mobilen gerät lauffähigen mobilen applikation
EP1284065B1 (de) Verfahren zum hinzufügen eines geräts in einem fahrzeugkommunikationsnetz
DE60208545T2 (de) Verfahren zur steuerung von über ein bussystem miteinander verbundenen netzwerkgeräten
EP1497719B1 (de) Verfahren zur installation von einem softwaremodul in einem gerät
DE102014114357A1 (de) Kalibrierungsdatenauswahl
DE60008764T2 (de) Verfahren und system zur automatischen bereinigung von kodeobjekten, die durch herunterladen aktualisiert werden
DE102005000653A1 (de) Skriptbasierte Software-Installation über Broadcast-Transportmedien
DE60123082T2 (de) Digitale automatische Verstärkungsregelung
DE102017210103A1 (de) Verfahren und Vorrichtung zum Betreiben eines Analog-Digital-Wandlers zur Wandlung eines Signals
DE60220619T2 (de) Rundfunk-Empfangsgerät
DE102021002488A1 (de) Verfahren zur Fehleranalyse einer von einem eingebetteten System bereitgestellten Funktionalität auf einem Entwicklersystem
WO2001093490A2 (de) Verfahren zur korrektur von taktabweichungen bei audiodaten
EP1349384B1 (de) Verfahren für die Verwaltung von Software für ein Fernsehgerät
DE102004037916A1 (de) Empfangsschaltung zum Empfangen von OFDM-Signalen und Verfahren hierzu
DE69021951T2 (de) Verfahren zum Erzeugen eines Maskierungsbits während eines dynamischen Vergleichs eines seriellen Datenstroms mit einer Referenz.
DE102015121512A1 (de) Verfahren und Vorrichtung für Analog/Digital-Wandlung von Signalen sowie entsprechendes Gerät
DE19944299A1 (de) Verfahren und Anordnung zum Laden einer Funktionalität
DE60112898T2 (de) RDS Dekoder
DE10103134A1 (de) Dekodiereinrichtung, Dekodierverfahren und Kraftfahrzeugaudiosystem mit einer derartigen Dekodiereinrichtung
DE102018000913A1 (de) Etablierung verschiedener eUICC-Modi
DE102013216715A1 (de) Verfahren zum Erstellen einer Konfigurationsplattform eines Fahrzeugs und Audiomanagementplattform

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8139 Disposal/non-payment of the annual fee