EP1665031A2 - Verfahren zur installation einer programmkomponente - Google Patents

Verfahren zur installation einer programmkomponente

Info

Publication number
EP1665031A2
EP1665031A2 EP04766589A EP04766589A EP1665031A2 EP 1665031 A2 EP1665031 A2 EP 1665031A2 EP 04766589 A EP04766589 A EP 04766589A EP 04766589 A EP04766589 A EP 04766589A EP 1665031 A2 EP1665031 A2 EP 1665031A2
Authority
EP
European Patent Office
Prior art keywords
program
program component
component
computing unit
version
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.)
Ceased
Application number
EP04766589A
Other languages
English (en)
French (fr)
Inventor
Erich Esders
Michael Uelschen
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
Publication of EP1665031A2 publication Critical patent/EP1665031A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • the invention relates to a method for installing a program component according to the preamble of the main claim. It is known to design computing units in such a way that certain program components can be subsequently installed or replaced by newer versions of the respective program components. For this purpose, it is known to check before installation whether the component to be installed is already present in the corresponding version on the computing unit, in order to avoid unnecessary installation effort.
  • Program components is checked before entering. This avoids an unnecessary installation process, since the installed software cannot run if it is incompatible with other program components. It also prevents an executable version of a program component from being overwritten by a version that is not due to run. It also ensures that the computing unit remains functional after the program component has been installed. Compatibility is understood here to mean that the software component present in the device and remaining unchanged can run together with the newly installed program component. Two components are considered to be compatible with one another in particular if all of their interfaces are compatible with one another. Runnability is understood to mean that a previously defined functionality is still provided by the computing unit even after the installation of a component. By installing the other program components, the functionality may be more extensive, but also more limited in relation to the original functional status.
  • the measures listed in the subclaims permit advantageous developments and improvements to the method for installing a program component specified in the main claim. It is particularly advantageous to determine the compatibility of two program components by checking the compatibility of the individual interfaces of the program components.
  • Comparison of the version key figures assigned to the program components A comparison of two program components is thus traced back to a comparison of version key figures and thus further simplified. In particular, this enables a quick comparison, with only a minimum amount of RAM being required. Especially compared to a comparison in which the compatibility of the individual interfaces are checked individually, considerable time savings are achieved. It is particularly advantageous to derive a version code of a program component from the interface configuration of the program component and thus to assign a version code to a program component as a function of its interface configuration. It is also particularly advantageous to assign lists with version key figures to the individual program components, from which the corresponding versions can be seen, to which the respective program component is compatible.
  • the method according to the invention can be used for remedial computing units and thus for any technical devices with computing units. It is particularly advantageous to use the method according to the invention in a motor vehicle which has a computing unit with embedded systems incorporated therein. Because programs are usually developed faster than that
  • Motor vehicle is replaced, in particular a subsequent installation of program components with the inventive method can be carried out safely without a user running the risk that the vehicle will not work afterwards or that e.g. B.
  • data that is no longer available can be overwritten by an incorrect installation.
  • FIG. 1 shows a driver information device in a vehicle with various program components installed
  • FIG. 3 shows a sequence of a method according to the invention for installing a
  • Program component on a computing unit.
  • the invention is explained below using the example of a driver information device in a vehicle.
  • the method can accordingly be transferred to any other computing units.
  • FIG. 1 shows a computing unit 1 on which a first program component 11, a second program component 12 and a third program component 13 are installed.
  • the program components interact in such a way that they have interfaces implemented in software, in which data and parameters are transferred from one program component to another program component.
  • the individual interfaces are each unidirectional, and a large number of individual interfaces can be provided between two program components. This multitude of interfaces can be unidirectionally aligned overall, but it can also allow data transmission in both directions.
  • a first interface 131 and a second interface 132 are provided between the third program component 13 and the first program component 11, with which data can be transmitted from the third program component 13 to the first program component 11.
  • a third interface 133 is provided, with which data can be transmitted from the first program component 11 to the third program component 13. Furthermore, a first interface 121 is provided between the first program component 11 and the second program component 12, which serves to transfer data from the second program component 12 to the first
  • Transfer program component 11 A second interface 122 is used for data transport in the opposite direction.
  • the program components 11, 12, 13 are processed by a processor unit of the computing unit 1, not shown in FIG. 1.
  • the interfaces can e.g. also include function calls that require a specific parameter set for the execution of the function by the other program component, which is required for processing the function in the other program component.
  • the program components are stored in a memory assigned to the computing unit 1 for the execution of the program components, which is not shown in FIG. 1.
  • the memory can be a magnetic memory, for. B. a hard drive, but can also be used as an overwritable memory cell, e.g. B. an EEPROM.
  • an installation of the program components can be understood as a pure copying of data into the memory of the computing unit.
  • the installed program components can be integrated into an operating system installed on the computing unit 1, that is to say an operating program for providing the basic functions of the computing unit. For this it is necessary that in addition to the program component e.g. System files are transferred to the computing unit 1.
  • the computing unit 1 can be transmitted with registration data for managing the program component.
  • the computing unit 1 is designed as a navigation device in a vehicle.
  • the first program component serves in this case as an operating system for the computing unit, which can also take on further functions, the program components of which are also stored in the computing unit 1, but are not shown in FIG. 1.
  • the second program component 12 serves, for example, as a route calculation function, while the third program component contains a data provision function of road map data on the one hand and multimedia data on the other hand. Both with the route calculation function and with the data provision function, it is likely that these program components will change during the use of the computing unit, that is to say during the lifetime of the vehicle. The reasons for this could be extended data to be provided, for example the tourist
  • the computing unit has an air interface 2, which e.g. represents an interface to a data network or to a mobile radio network.
  • the data of the program component are made available to the computing unit 1 via the air interface.
  • Wireless transmission from a computer in the vehicle is also possible, e.g. via a so-called Bluetooth interface.
  • the computing unit 1 has a plug contact 3 for connecting another one
  • the computing unit 1 has a data carrier drive 14 into which a data carrier with a correspondingly updated software component can be inserted for installation.
  • the third program component 13 could have a fourth interface 134, which is still open in the illustration in FIG. 1, to which, however, a further program component to be installed can be attached.
  • an existing program component, for example the second program component, for the route calculation function 12 is replaced by a newly installed program component during installation.
  • FIG. 3 An installation of such a program component is shown in FIG. 3.
  • a version code of a component already installed on the computing unit 1 is determined.
  • This version key figure is determined by the fact that each time an interface configuration is changed, a respective
  • Program component is assigned a new version number.
  • the version code is possible by simply reading out a corresponding parameter value of the respective program component.
  • each program component is assigned a list for each program component that can be connected to it, each of which has all the version key figures of the versions of the other program component that are compatible with the program component.
  • a subsequent first test step 22 it is checked whether the version code of the component to be installed is present in the list of the component already present on the computing unit or whether the version code of the component present on the computer is present in the list of the component to be installed. If one of these two conditions is already met, the compatibility of the two program components with one another is ensured.
  • a branch is made to a second test step 23, in which it is checked whether the component to be installed must be compatible with other program components already present on the computer in addition to this first program component. This would be e.g. the case if according to
  • a branch is made to an abort step 25 and an acoustic signal is generated via a display 4 or a loudspeaker 5 of the computing unit 1 and / or an optical warning signal is output to a user. It is indicated that an installation has not been carried out. It is also preferably communicated which software version is required for an installation.
  • first and second program components 11, 12 are exchanged, it may be necessary to first install a new version of the first program component and then a new version of the second program component, since the second program component to be installed may already have to be installed on the computing unit existing first program component 11 may not be compatible.
  • FIGS. 2a, 2b and 2c show various examples of an update of the first and second program components 11, 12.
  • the first program component and the second program component are connected via the first and second interfaces 121, 122.
  • Program component 11, 12 each assigned the version number 1.
  • the first program component 11 has a version code number list 6 in which all versions of the second program component are stored which are compatible with the present version of the first program component 11. In the present embodiment, this is only version number 1 of the second
  • the second program component 12 has a corresponding version code list 7, in which those version code numbers of the first program component 11 are stored to which the second program component 12 is compatible with the version code number 1.
  • this is only version number 1.
  • a newer version 110 of the first program component 11 and a newer version 120 of the second program component 12 are now shown in FIG. 2b.
  • the program components differ in that the first interface 121 has been replaced by a newer interface 123.
  • the two interfaces can differ, for example, in that an additional parameter is provided by the new first program component 110 for processing by the new second program component 120 compared to the first interface 121.
  • the new first program component 110 thus receives the version code 2, as does the new second program component 120.
  • Program component 110 only contains the version code 2, while the version code list 70 of the new second program component 120 contains the version codes 1 and 2. If, based on the configuration according to FIG. 2b, an attempt is now made to replace the new second program component 120 with the second program component 12 in the original version, an incompatibility is found when the version code lists are compared. This is because only the version code 1 is present in the version code list of the second program component 12, but the new second program component 110 has the version code 2. However, only the version code 2 is also stored in the version code list 60 of this new first program component 110. Since the other component cannot be found in either of the two version code lists, an installation is canceled.
  • the compatibility comparison is preferably provided for devices in which the various program components are integrated into a single large program package. However, it is also possible e.g. check the compatibility of programs on different computing units that are connected to one another and in which at least one computing unit is to be installed, accordingly.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Es wird ein Verfahren zur Installation einer Progranunkomponente auf einer Recheneinheit vorgeschlagen, das zur Sicherstellung der Kompatibilität von Softwareeinheiten und Komponenten insbesondere in eingebetteten Systemen dient, die durch einen Nachladevorgang aktualisiert werden können. Hierbei wird vor der Installation überprüft, ob die zu installierende Programmkomponente zu einer auf der Recheneinheit bereits vorhandenen Programmkomponente kompatibel ist. Eine Installation wird nur bei einer positiven Überprüfung der Kompatibilität ausgeführt.

Description

Verfahren zur Installation einer Programmkomponente
Stand der Technik
Die Erfindung geht aus von einem Verfahren zur Installation einer Programmkomponente nach der Gattung des Hauptanspruchs. Es ist bekannt, Recheneinheiten so auszuführen, dass bestimmte Programmkomponenten nachträglich installiert oder durch neuere Versionen der jeweiligen Programmkomponente ersetzt werden können. Hierzu ist es bekannt, vor der Installation zu überprüfen, ob die zu installierende Komponente bereits auf der Recheneinheit in der entsprechenden Version vorliegt, um einen unnötigen Installationsaufwand zu vermeiden.
Vorteile der Erfindung
Das erfindungsgemäße Verfahren zur Installation einer Programmkomponente mit den Merkmalen des Hauptanspruchs hat demgegenüber den Vorteil, dass zudem die Kompatibilität einer Programmkomponente zu auf der Recheneinheit bereits vorhandenen
Programmkomponenten vor der Eingabe überprüft wird. Hierdurch wird ein unnötiger Installationsvorgang vermieden, da die installierte Software bei einer Inkompatibilität zu übrigen Programmkomponenten nicht lauffähig ist. Darüber hinaus wird vermieden, dass eine lauffähige Version einer Programmkomponente durch eine nicht lauffällige Version überschrieben wird. Zudem wird sichergestellt, dass die Recheneinheit nach Installation der Programmkomponente lauffähig bleibt. Unter Kompatibilität ist hierbei zu verstehen, dass die in dem Gerät vorhandene und ungeändert verbleibende Softwarekomponente zusammen mit der neu installierten Programmkomponente lauffähig ist. Zwei Komponenten werden insbesondere dann als kompatibel zueinander angesehen, wenn alle ihre Schnittstellen jeweils zueinander kompatibel sind. Unter Lauffähigkeit ist zu verstehen, dass eine zuvor definierte Funktionalität auch nach der Installation einer Komponente durch die Recheneinheit noch bereitgestellt wird. Durch die Installation der weiteren Programmkomponente kann die Funktionalität gegebenenfalls umfangreicher, aber auch eingeschränkter bezogen auf den ursprünglichen Funktionsstand sein.
Durch die in den Unteransprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im Hauptanspruch angegebenen Verfahrens zur Installation einer Programmkomponente möglich. Besonders vorteilhaft ist, eine Kompatibilität zweier Programmkomponenten durch eine ύberprüfung der Kompatibilität der einzelnen Schnittstellen der Programmkomponenten zu bestimmen.
Hierdurch kann z.B. auf eine Untersuchung des Codes der einzelnen Programmlcomponenten selbst verzichtet werden. Hierdurch wird die Kompatibilitätsprüfung vereinfacht.
Ferner ist es vorteilhaft, eine Kompatibilität von Programmlcomponenten durch einen
Vergleich von den Programmkomponenten zugeordneten Versionskennzahlen zu ennitteln. Ein Vergleich zweier Programmkomponenten wird damit auf einen Vergleich von Versionskennzahlen zurückgeführt und damit weiter vereinfacht. Insbesondere wird hierdurch ein schneller Vergleich möglich, wobei nur ein Mindestmaß an Arbeitsspeicher benötigt wird. Insbesondere gegenüber einem Vergleich, bei dem die Kompatibilität der einzelnen Schnittstellen jeweils für sich überprüft werden, wird eine erhebliche Zeitersparnis erreicht. Besonders vorteilhaft ist, eine Versionskennzahl einer Programmkomponente aus der Schnittstellenkonfiguration der Programmkomponente herzuleiten und damit in Abhängigkeit von ihrer Sc nittstellenkonfiguration einer Programmkomponente eine Versionskennzahl zuzuordnen. Es ist ferner besonders vorteilhaft, den einzelnen Programmkomponenten Listen mit Versionskennzahlen zuzuordnen, aus denen die entsprechenden Versionen ersichtlich sind, zu der die jeweilige Programmkomponente kompatibel ist. Da bei einer Aktualisierung möglicherweise zukünftige Programmkomponenten nicht bekannt sind, ist es ferner vorteilhaft, als Kriterium für eine Kompatibilität lediglich zu verlangen, dass es ausreicht, wenn bereits eine der beiden Programmkomponenten in einer Liste der jeweiligen anderen Programmkomponente enthalten ist. Die Programmkomponente selbst muss dann keinen Hinweis auf die andere Programmkomponente mehr umfassen, um eine Kompatibilität festzustellen. Das vorgestellte Verfahren ist insbesondere dann vorteilhaft, wenn die einzelnen Programmkomponenten eine Vielzahl von unabhängigen Schnittstellen aufweisen, wobei die Programmkomponenten gegenseitig auf die Schnittstellen zugreifen. Es ist femer vorteilhaft, die zu installierende Programmkomponente zum Austausch einer bereits auf der Recheneinheit vorhandenen Programmkomponente zu installieren. Durch die erfindungsgemäße Installation nur bei vorliegender Kompatibilität wird sichergestellt, dass ein möglicherweise nicht mehr verfügbarer Datensatz einer ursprünglich installierten Programmkomponente nicht durch eine Programmkomponente ersetzt wird, die mit den übrigen Programmkomponenten nicht lauffähig ist. Das erfindungsgemäße Verfahren erlaubt es dabei eine Kompatibilitätsprüfung durchzuführen, wenn zum einen eine Programmkomponente durch eine neuere Version ausgetauscht wird, und zum anderen, wenn eine Programmkomponente durch eine ältere Version ersetzt wird.
Es ist ferner vorteilhaft, bei der Installation von Anwendungsprogrammen, die gegebenenfalls des öfteren aktualisiert werden, jeweils bei der Installation eine Kompatibilitätsprüfung durchzuführen.
Sollte eine Installation nicht erfolgt sein, so wird vorteilhaft eine Fehlermeldung ausgegeben, durch die ein Benutzer auf die nicht erfolgte Installation hingewiesen wird. Das erfindungsgemäße Verfahren kann für behebige Recheneinheiten und damit für beliebige technische Geräte mit Recheneinheiten verwendet werden. Besonders vorteilhaft ist die Verwendung des erfindungsgemäßen Verfahrens in einem Kraftfahrzeug, das eine Recheneinheit mit darin eingebrachten eingebetteten Systemen aufweist. Da in der Regel Programme schneller entwickelt werden, als dass ein
Kraftfahrzeug ersetzt wird, kann insbesondere eine Nachinstallation von Programmkomponenten mit dem erfindungsgemäßen Verfahren sicher durchgeführt werden, ohne dass ein Benutzer Gefahr läuft, dass das Fahrzeug hinterher nicht mehr funktioniert oder dass z. B. bei einer vor Ort auftretenden Störung nicht mehr verfügbare Daten durch eine falsche Installation überschrieben werden.
Zeichnung
Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigen
Figur 1 eine Fahrerinformationsvorrichtung in einem Fahrzeug mit verschiedenen installierten Programmkomponenten,
Figur 2a bis 2c Programmkomponenten verschiedener Versionen, die miteinander in Verbindung stehen, Figur 3 ein Ablauf eines erfindungsgemäßen Verfahrens zur Installation einer
Programmkomponente auf einer Recheneinheit.
Beschreibung des Ausführungsbeispiels
Im Folgenden wird die Erfindung am Beispiel einer Fahrerinformationsvorrichtung in einem Fahrzeug erläutert. Das Verfahren ist entsprechend auf beliebige andere Recheneinheiten übertragbar.
Figur 1 zeigt eine Recheneinheit 1, auf der eine erste Programmkomponente 11, eine zweite Prograrnmkomponente 12 und eine dritte Programmkomponente 13 installiert sind. Die Programmkomponenten interagieren dabei in der Weise, dass sie über in Software realisierte Schnittstellen verfügen, bei denen Daten und Parameter von einer Programmkomponente an eine andere Programmkomponente übertragen werden. Die einzelnen Schnittstellen sind jeweils unidirektional ausgeführt, wobei zwischen zwei Programmkomponenten eine Vielzahl einzelner Schnittstellen vorgesehen sein kann. Diese Vielzahl von Schnittstellen kann dabei insgesamt unidirektional ausgerichtet sein, sie kann jedoch auch eine Datenübertragung in beide Richtungen zulassen. Zwischen der dritten Programmkomponente 13 und der ersten Programmkomponente 11 sind eine erste Schnittstelle 131 und eine zweite Schnittstelle 132 vorgesehen, mit denen Daten von der dritten Programmkomponente 13 an die erste Programmkomponente 11 übertragen werden können. Ferner ist eine dritte Schnittstelle 133 vorgesehen, mit der Daten von der ersten Programmkomponente 11 an die dritte Programmkomponente 13 übertragen werden können. Ferner ist eine erste Schnittstelle 121 zwischen der ersten Programmkomponente 11 und der zweiten Programmkomponente 12 vorgesehen, die dazu dient, Daten von der zweiten Programmkomponente 12 an die erste
Programmkomponente 11 zu übertragen. Eine zweite Schnittstelle 122 dient zum Datentransport in die umgekehrte Richtung. Die Programmkomponenten 11, 12, 13 werden von einer in der Figur 1 nicht gezeigten Prozessoreinheit der Recheneinheit 1 abgearbeitet.
Die Schnittstellen können dabei z.B. auch Funktionsaufrufe umfassen, die für eine Ausführung der Funktion durch die jeweils andere Programmkomponente einen bestimmten Parametersatz erfordern, der für die Bearbeitung der Funktion in der anderen Programmkomponente erforderlich ist.
Die Programmkomponenten sind in einem der Recheneinheit 1 zugeordneten Speicher für die Ausführung der Programmkomponenten abgelegt, der in der Figur 1 nicht gezeigt ist. Der Speicher kann einerseits ein Magnetspeicher sein, z. B. ein Festplattenlaufwerk, kann aber auch als eine überschreibbare Speicherzelle, z. B. ein EEPROM, ausgeführt sein. Unter einer Installation der Programmkomponenten kann einerseits ein reines Kopieren von Daten in den Speicher der Recheneinheit verstanden werden. Darüber hinaus ist es auch möglich, dass die installierten Programmkomponenten in ein auf der Recheneinheit 1 installiertes Betriebssystem, also ein Betriebsprogramm zur Bereitstellung der Grundfunktionen der Recheneinheit, eingebunden werden. Hierzu ist es erforderlich, dass zusätzlich zu der Programmkomponente z.B. Systemdateien an die Recheneinheit 1 übertragen werden. Ferner ist es auch möglich, dass der Recheneinheit 1 Registrierungsdaten zum Verwalten der Programmkomponente mitübertragen werden.
Die Recheneinheit 1 ist in dem hier dargestellten Ausfuhrungsbeispiel als eine Navigationsvorrichtung in einem Fahrzeug ausgeführt. Die erste Programmkomponente dient in diesem Fall als Betriebssystem für die Recheneinheit, die noch weitere Funktionen übernehmen kann, deren Programmkomponenten ebenfalls in der Recheneinheit 1 abgelegt, in der Figur 1 jedoch nicht dargestellt sind. Die zweite Programmkomponente 12 dient z.B. als eine Routenbereclmungsfunktion, während die dritte Programmkomponente eine Datenbereitstellungsfunktion von Straßenkartendaten einerseits und Multimediadaten andererseits beinhaltet. Sowohl bei der Routenbereclmungsfunktion, als auch bei der Datenbereitstellungsfunktion ist es wahrscheinlich, dass sich diese Programmkomponenten während der Nutzung der Recheneinheit, also während der Lebensdauer des Fahrzeugs, ändern werden. Gründe hierfür könnten erweiterte, bereitzustellende Daten sein, bei der z.B. die touristischen
Hinweisfunktionen erweitert werden. Ferner ist es auch möglich, dass ein optimierter Routenermittlungsalgorithmus zur Verfügung steht, der entweder schneller eine zu fahrende Route ermitteln kann oder der z.B. in der Lage ist, die aktuelle Verkehrssituation in die Routenberechnung mit einzubeziehen, wenn dies bisher noch nicht der Fall war.
Will ein Benutzer nun eine derartige neue Programmkomponente auf der Recheneinheit 1 installieren, so sind hierfür verschiedene Installationsmöglichkeiten vorhanden, die an einer Recheneinheit jeweils ausschließlich, aber auch zur Auswahl realisiert werden können. In einer ersten Ausfuhrungsform weist die Recheneinheit eine Luftschnittstelle 2 auf, die z.B. eine Schnittstelle zu einem Datennetz oder zu einem Mobilfunknetz darstellt. Die Daten der Programmkomponente werden der Recheneinheit 1 über die Luftschnittstelle zur Verfügung gestellt. Ferner ist auch eine drahtlose Übertragung von einem Rechner im Fahrzeug möglich, z.B. über eine sogenannte Bluetooth-Schnittstelle. Ferner weist die Recheneinheit 1 einen Steckkontakt 3 zum Anschluss eines weiteren
Rechners auf, von dem die Daten übertragbar sind. In einer weiteren Ausführungsform weist die Recheneinheit 1 ein Datenträgerlaufwerk 14 auf, in das ein Datenträger mit einer entsprechend aktualisierten Softwarekomponente zur Installation eingelegt werden kann.
Bei der Installation ist es einerseits möglich, dass eine neue, zusätzliche Programmkomponente in der Recheneinheit 1 installiert wird. Hierzu könnte z.B. die dritte Programmkomponente 13 eine vierte Schnittstelle 134 aufweisen, die bei der Darstellung in der Figur 1 noch offen ist, an die jedoch eine zu installierende, weitere Programmkomponente angehängt werden kann. In einer bevorzugten Ausführungsform wird bei der Installation eine bereits vorhandene Programmkomponente, z.B. die zweite Programmkomponente, für die Routenbereclmungsfunktion 12, durch eine neu installierte Programmkomponente ersetzt.
Eine Installation einer derartigen Programmkomponente ist in der Figur 3 gezeigt.
Ausgehend von einem Initialisierungsschritt 20, mit dem eine Installation gestartet wird, wird in einem Ermittlungsschritt 21 sowohl eine Versionskennzahl einer auf der Recheneinheit 1 bereits installierten Komponente, als auch eine Versionskennzahl der zu installierenden Komponente ermittelt. Diese Versionskennzahl wird dadurch bestimmt, dass bei jeder Änderung einer Schnittstellenkonfiguration einer jeweiligen
Programmkomponente eine neue Versionskennzahl zugewiesen wird. Die Versionskennzahl ist durch ein einfaches Auslesen eines entsprechenden Parameterwertes der jeweiligen Programmkomponente möglich. Ferner ist jeder Programmkomponente eine Liste für jede mit ihr verbindbare Programmkomponente zugeordnet, die jeweils alle Versionskennzahlen der zu der Programmkomponente kompatiblen Versionen der anderen Programmkomponente aufweist. In einem anschließenden ersten Prüfschritt 22 wird überprüft, ob die Versionskennzahl der zu installierenden Komponente in der Liste der auf der Recheneinheit bereits vorhandenen Komponente vorhanden ist oder ob die Versionskennzahl der auf dem Rechner vorhandenen Komponente in der Liste der zu installierenden Komponente vorhanden ist. Ist bereits eine dieser beiden Bedingungen erfüllt, so ist die Kompatibilität der beiden Programmkomponenten zueinander sichergestellt. In diesem Fall wird zu einem zweiten Prüfschritt 23 weiterverzweigt, in dem überprüft wird, ob die zu installierende Komponente außer zu dieser ersten Programmkomponente noch zu weiteren, auf dem Rechner bereits vorhandenen Programmkomponenten kompatibel sein muss. Dies wäre z.B. der Fall, wenn gemäß dem
Ausfuhrungsbeispiel der Figur 1 die erste Programmkomponente 11 durch eine neuere Version zu ersetzen würde, da diese sowohl mit der zweiten, als auch mit der dritten Programmkomponente 12, 13 in Wechselwirkung steht. In diesem Fall wird zu dem Ermittlungsschritt 21 zurückverzweigt und es wird derselbe Vergleich zwischen der zu installierenden Programmkomponente und der weiteren, auf dem Rechner bereits vorhandenen Programmkomponente durchgeführt. Gibt es keine weiteren zu überprüfenden Programmkomponenten, so wird zu einem Installationsschritt 24 verzweigt, in dem die zu installierende Programmkomponente in den Speicher der Recheneinheit 1 übertragen wird, wobei die dort bereits vorhandene Programmkomponente entweder überschrieben wird, zumindest aber aus der Abarbeitung des Programms herausgenommen wird.
Wird in dem ersten Prüfschritt 22 festgestellt, dass die zu installierende Komponente nicht kompatibel zu einer in der Recheneinheit 1 bereits vorhandenen Komponente ist, so wird zu einem Abbruchschritt 25 verzweigt und es wird über eine Anzeige 4 oder über einen Lautsprecher 5 der Recheneinheit 1 ein akustisches und/oder optisches Warnsignal an einen Benutzer ausgegeben. Es wird daraufhingewiesen, dass eine Installation nicht erfolgt ist. Bevorzugt wird auch mitgeteilt, welcher Softwarestand für eine Installierung erforderlich ist.
Sollte eine Installierung umfangreicher sein, kann es gegebenenfalls erforderlich sein, bestimmte Komponenten in einer vorgegebenen Reihenfolge so zu installieren, dass stets nur zueinander kompatible Programmkomponenten auf der Recheneinheit vorliegen. Sollen nun z.B. die erste und die zweite Programmkomponente 11, 12 ausgetauscht werden, kann es gegebenenfalls erforderlich sein, zuerst eine neue Version der ersten Programmkomponente und dann eine neue Version der zweiten Programmkomponente zu installieren, da gegebenenfalls die neu zu installierende zweite Programmkomponente zu der auf der Recheneinheit bereits vorhandenen ersten Programmkomponente 11 nicht kompatibel sein mag.
In den Figuren 2a, 2b und 2c sind verschiedene Beispiele für eine Aktualisierung der ersten und der zweiten Programmkomponente 11, 12 dargestellt. In der Figur 2a stehen die erste Programmkomponente und die zweite Programmkomponente über die erste und die zweite Schnittstelle 121, 122 in Verbindung. Hierbei ist der ersten und der zweiten
Programmkomponente 11, 12 jeweils die Versionskennzahl 1 zugeordnet. Die erste Programmkomponente 11 weist eine Versionskennzahlliste 6 auf, in der alle Versionen der zweiten Programmkomponente abgelegt sind, die zu der vorliegenden Version der ersten Programmkomponente 11 kompatibel sind. In dem hier vorliegenden Ausführungsbeispiel ist dies lediglich die Versionskennzahl 1 der zweiten
Programmkomponenten. Ebenso weist die zweite Programmkomponente 12 eine entsprechende Versionskennzahlliste 7 auf, in der diejenigen Versionskennzahlen der ersten Programmkomponente 11 abgelegt sind, zu denen die zweite Programmkomponente 12 mit der Versionskennzahl 1 kompatibel ist. Dies ist hier ebenfalls nur die Versionskennzahl 1. In der Figur 2b ist nun eine neuere Version 110 der ersten Programmkomponente 11 und eine neuere Version 120 der zweiten Programmkomponente 12 dargestellt. Die Programmkomponenten unterscheiden sich dadurch, dass die erste Schnittstelle 121 durch eine neuere Schnittstelle 123 ersetzt wurde. Die beiden Schnittstellen können sich z.B. dadurch unterscheiden, dass gegenüber der ersten Scl ittstelle 121 ein zusätzlicher Parameter von der neuen ersten Programmkomponente 110 zur Bearbeitung durch die neue zweite Programmkomponente 120 bereitgestellt wird. Die neue erste Programmkomponente 110 erhält damit die Versionskennzahl 2, ebenso wie die neue zweite Programmkomponente 120. In einer Versionskennzahlliste 60 der neuen ersten
Programmkomponente 110 ist lediglich die Versionskennzahl 2 enthalten, während in der Versionskennzahlliste 70 der neuen zweiten Programmkomponente 120 die Versionskennzahlen 1 und 2 enthalten sind. Wird nun ausgehend von der Konfiguration gemäß der Figur 2b versucht, die neue zweite Programmkomponente 120 durch die zweite Programmkomponente 12 in der ursprünglichen Ausfuhrung zu ersetzen, wird bei einem Vergleich der Versionskennzahllisten eine Inkompatibilität festgestellt. Denn in der Versionskennzahlliste der zweiten Programmkomponente 12 ist lediglich die Versionskennzahl 1 vorhanden, die neue zweite Programmkomponente 110 hat jedoch die Versionskennzahl 2. In der Versionskennzahlliste 60 dieser neuen ersten Programmkomponente 110 ist jedoch ebenfalls lediglich die Versionskennzahl 2 abgelegt. Da die jeweils andere Komponente in keiner der beiden Versionskennzahllisten aufgefunden werden kann, wird eine Installation abgebrochen.
Wird dagegen versucht, ausgehend von der Konfiguration gemäß der Figur 2a die zweite Programmkomponente 12 durch die neue zweite Programmkomponente 120 zu ersetzen, so wäre dies möglich, da in deren Versionskennzahlliste 70 auch die Versionskennzahl 1 vorhanden ist. Ausgehend von der Konfiguration in der Figur 2a wäre also ein Austausch der zweiten Programmkomponente 12 durch die neue zweite Programmkomponente 120 möglich. Eine entsprechende Konfiguration ist in der Figur 2c dargestellt. Mit dem Bezugszeichen 121 ' ist hiermit die Schnittstelle von der ersten Komponente 11 zu der neuen zweiten Programmkomponente 120 bezeichnet. Dies könnte z.B. dadurch realisiert werden, dass der von der ersten Programmkomponente 11 nicht bereitgestellte, zusätzliche Parameter entweder auf einen Standardwert eingestellt wird oder ganz ignoriert wird. Gegebenenfalls wäre es auch möglich, von der Konfiguration in der Figur 2b ebenfalls zu der Konfiguration in der Figur 2c zu gelangen. Gegebenenfalls kann ein Benutzer vor der Installation noch davor gewarnt werden, dass eine aktuellere Version durch eine ältere Version einer Programmkomponente ersetzt werden soll.
Für einen Vergleich ist es damit ausreichend, den Inhalt der Versionskennzahllisten 6, 60, 7, 70 mit den Versionskennzahlen der jeweils anderen Programmkomponente zu vergleichen.
Der Kompatibilitätsvergleich ist bevorzugt für Geräte vorgesehen, bei denen die verschiedenen Programmkomponenten in ein einziges großes Programmpaket eingebunden sind. Jedoch ist es auch möglich, z.B. die Kompatibilität von Programmen auf verschiedenen Recheneinheiten, die miteinander verbunden sind und bei denen zumindest auf einer Recheneinheit eine Installation erfolgen soll, entsprechend zu überprüfen.
Neben einer Verwendung für die Überprüfung bei einem Endnutzer ist es jedoch auch möglich, bereits während der Fertigung die Funktionalität des Systems dadurch zu überprüfen, dass das erfrndungsgemäße stallationsverfahren bei der Erstinstallation von Software auf einem Gerät berücksichtigt wird und die Kompatibilität z.B. zu einem auf dem System bereits vorhandenen Betriebssystem jeweils überprüft wird.

Claims

Ansprüche
1. Verfahren zur Installation einer Programmkomponente auf einer Recheneinheit, wobei auf der Recheneinheit bereits mindestens eine weitere Programmkomponente installiert ist, dadurch gekennzeichnet, dass eine Installation der Programmkomponente nur dann erfolgt, wenn die zu installierende Programmkomponente zu der bereits installierten mindestens einen Programmkomponente auf der Recheneinheit kompatibel ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Programmkomponenten dann zueinander kompatibel sind, wenn die Schnittstellen der Programmkomponenten zueinander kompatibel sind.
3. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Kompatibilität von Programmkomponenten durch einen Vergleich von den Programmkomponenten zugeordneten Versionskennzahlen ermittelt wird.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass einer ersten Programmkomponente zur Bestimmung der Kompatibilität zu einer zweiten Programmkomponente eine Liste mit Versionen der zweiten Programmkomponente zugeordnet ist, die zu der ersten Programmkomponente kompatibel sind.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass zwei Programmkomponenten bereits dann kompatibel zueinander sind, wenn in einer Liste kompatibler Versionen, insbesondere in einer Liste kompatibler Versionskennzahlen, einer der beiden Programmkomponenten, die Version oder die Versionskennzahl der anderen Komponente enthalten ist.
6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die zu installierende Programmkomponente zum Austausch einer bereits auf der Recheneinheit vorhandenen Programmkomponente installiert wird.
7. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die auf der Recheneinheit vorhandene Programmkomponente ein Betriebsprogramm der Recheneinheit ist und dass die zu installierende Komponente ein Anwendungsprogramm ist.
8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass bei einer aufgrund mangelnder Kompatibilität nicht durchgeführten Installation eine Fehlermeldung ausgegeben wird.
9. Verwendung eines Verfahrens nach einem der vorherigen Ansprüche für die
Installation von Programmkomponenten in einem Fahrerinformationssystem in einem Kraftfahrzeug, insbesondere in einer Navigationsvorrichtung.
EP04766589A 2003-09-02 2004-08-25 Verfahren zur installation einer programmkomponente Ceased EP1665031A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10340372A DE10340372A1 (de) 2003-09-02 2003-09-02 Verfahren zur Installation einer Programmkomponente
PCT/EP2004/051894 WO2005022382A2 (de) 2003-09-02 2004-08-25 Verfahren zur installation einer programmkomponente

Publications (1)

Publication Number Publication Date
EP1665031A2 true EP1665031A2 (de) 2006-06-07

Family

ID=34202327

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04766589A Ceased EP1665031A2 (de) 2003-09-02 2004-08-25 Verfahren zur installation einer programmkomponente

Country Status (4)

Country Link
US (1) US8095926B2 (de)
EP (1) EP1665031A2 (de)
DE (1) DE10340372A1 (de)
WO (1) WO2005022382A2 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7735079B1 (en) * 2005-02-04 2010-06-08 Symantec Corporation Securely hooking installations for compatibility with other applications
US7506336B1 (en) * 2005-06-29 2009-03-17 Emc Corporation System and methods for version compatibility checking
WO2007113550A1 (en) * 2006-03-31 2007-10-11 British Telecommunications Public Limited Company Exception handler for the upgrade of java objects in a distributed system
WO2007113533A1 (en) * 2006-03-31 2007-10-11 British Telecommunications Public Limited Company Xml-based transfer and a local storage of java objects
US9032390B2 (en) * 2008-07-29 2015-05-12 Qualcomm Incorporated Framework versioning
US8832676B2 (en) * 2009-09-30 2014-09-09 Zynga Inc. Apparatuses, methods and systems for a social networking application updater
US8631398B2 (en) * 2010-09-20 2014-01-14 Sony Corporation Method and apparatus for facilitating creation of a network interface
US20130042231A1 (en) * 2011-08-10 2013-02-14 Ford Global Technologies, Llc Methods and Apparatus for Software Updating
US9342298B2 (en) 2013-03-14 2016-05-17 Microsoft Technology Licensing, Llc Application compatibility checking in a distributed computing environment
JP7043783B2 (ja) * 2017-10-20 2022-03-30 富士フイルムビジネスイノベーション株式会社 ソフトウエア管理装置、ソフトウエア管理システム及びプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5579509A (en) 1991-02-08 1996-11-26 International Business Machines Corporation Apparatus and method for verifying compatibility of system components
EP0710914B1 (de) * 1994-11-04 2000-05-03 Canon Information Systems, Inc. Intelligente Wiederprogrammierung eines Flash-Speichers
US5951639A (en) * 1996-02-14 1999-09-14 Powertv, Inc. Multicast downloading of software and data modules and their compatibility requirements
JP2001067232A (ja) * 1999-08-31 2001-03-16 Hitachi Ltd ソフトウエアの配信システムおよびソフトウエアの受信端末装置
JP2001331324A (ja) 2000-05-19 2001-11-30 Sony Corp 情報処理方法および装置、ならびに、記録媒体
JP2002318692A (ja) * 2001-04-19 2002-10-31 Sony Corp インストール支援システム、インストール支援装置、インストール支援方法、インストールを支援するためのプログラムおよびそのプログラムを記録した記録媒体
US6971093B1 (en) * 2001-05-14 2005-11-29 Cisco Technology, Inc. Techniques for maintaining compatibility of a software core module and an interacting module
US7350207B2 (en) * 2001-05-25 2008-03-25 Tellabs Operations, Inc. Rule-based system and method for downloading computer software over a network
DE10158991A1 (de) * 2001-11-30 2003-06-12 Bosch Gmbh Robert Verfahren und Installation von einem Softwaremodul in einem Gerät

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005022382A3 *

Also Published As

Publication number Publication date
US8095926B2 (en) 2012-01-10
DE10340372A1 (de) 2005-03-24
WO2005022382A3 (de) 2005-09-29
US20070234352A1 (en) 2007-10-04
WO2005022382A2 (de) 2005-03-10

Similar Documents

Publication Publication Date Title
DE102019109672A1 (de) Rückgängigmachung nach einem teilausfall in mehreren elektronischen steuergeräten mittels over-the-air-updates
DE112019002411T5 (de) Fahrzeuggebundene Aktualisierungseinrichtung, Aktualisierungsprozessverfahren und Aktualisierungsprozessprogramm
DE69521508T2 (de) Verfahren zum bereitstellen von informationen über die fähigkeiten eines slave-gerätes in einem master-gerät
WO2006100078A1 (de) Vergleich von schnittstellen zwischen softwarekomponenten
WO2012149951A1 (de) System zur diagnose einer komponente in einem fahrzeug
WO2019068375A1 (de) Verfahren und zentrale datenverarbeitungsvorrichtung zum aktualisieren von software in einer vielzahl von fahrzeugen
DE102018103209A1 (de) Verfahren und vorrichtung zur handhabung der übereinstimmung von mehrzyklischen fahrzeugsoftwareaktualisierungen
DE112012003795T5 (de) Fahrzeugnetwerksystem und Fahrzeug-Informationsverarbeitungsverfahren
WO2013171122A2 (de) Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts
WO2003003200A1 (de) Verfahren zum übertragen von software-modulen
DE102018214999A1 (de) Vorrichtung zur Absicherung von Diagnosebefehlen an ein Steuergerät und entsprechendes Kraftfahrzeug
DE102015216265A1 (de) Verfahren und Teilsystem zum Installieren eines Softwareupdates in einem Fahrzeug
WO2005022382A2 (de) Verfahren zur installation einer programmkomponente
DE102022110251A1 (de) Ota-master, center, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE102022113922A1 (de) Ota-master, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
DE102022104321A1 (de) Center, aktualisierungsmanagementverfahren und nicht-transitorisches speichermedium
DE102007006614A1 (de) Anwendung einer verteilten Diagnosearchitektur in AUTOSAR
DE102019004612A1 (de) Verfahren zum Betreiben eines Fahrzeugs mit einem Steuergerät
DE102022110824A1 (de) Ota-master, system, verfahren, nicht-transitorisches speichermedium und fahrzeug
EP3797352B1 (de) Verfahren zum austauschen eines ersten ausführbaren programm-codes und eines zweiten ausführbaren programm-codes und steuergerät
DE102009002898A1 (de) Verfahren zur Aktualisierung eines Steuergeräts eines Fahrzeugs
DE102009047974B4 (de) Verfahren zur Programmierung eines Steuergeräts
WO2009103728A1 (de) Verfahren und vorrichtung zum speichern von informationsdaten
DE102021128988A1 (de) Center, aktualisierungsmanagementverfahren und nicht-transitorisches speichermedium
EP1739559A2 (de) Behandlung von Fehlerereignissen bei einem tragbarem Datenträger

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060403

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB IT

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT

17Q First examination report despatched

Effective date: 20070226

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20100119