EP1683012A1 - Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system - Google Patents

Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system

Info

Publication number
EP1683012A1
EP1683012A1 EP04791127A EP04791127A EP1683012A1 EP 1683012 A1 EP1683012 A1 EP 1683012A1 EP 04791127 A EP04791127 A EP 04791127A EP 04791127 A EP04791127 A EP 04791127A EP 1683012 A1 EP1683012 A1 EP 1683012A1
Authority
EP
European Patent Office
Prior art keywords
software
hardware
data
data processing
unit
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
EP04791127A
Other languages
English (en)
French (fr)
Inventor
Thorsten SCHÖLER
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.)
Qisda Corp
Original Assignee
Siemens AG
BenQ Mobile GmbH and Co OHG
BenQ Corp
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 Siemens AG, BenQ Mobile GmbH and Co OHG, BenQ Corp filed Critical Siemens AG
Priority to EP04791127A priority Critical patent/EP1683012A1/de
Publication of EP1683012A1 publication Critical patent/EP1683012A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation

Definitions

  • the present invention relates to a device and a method for software management in a heterogeneous hardware system and in particular to a configuration unit implemented in a mobile telecommunications terminal or a development tool for configuring a heterogeneous hardware system, with a multitude of different ones Data processing units communicating software modules can be optimally distributed.
  • complex software systems is usually based on a complex hardware system equipped with several data processing units (CPUs, DSPs, etc.), with individual software parts or software modules being distributed to these different data processing units and communicating with one another.
  • CPUs central processing units
  • DSPs digital signal processors
  • future mobile telecommunication terminals will use heterogeneous hardware systems that have a large number of different data processing units, such as an application CPU, a modem CPU and a modem DSP (digital signal processor).
  • Future application programs for such mobile telecommunication terminals have a large number of partially alternative software modules which have to be optimally distributed to the different data processing units in order to implement a predetermined functionality.
  • Such software modules are usually distributed as a manual step within the development phase or implementation phase, provided that the system is delivered in its entirety, ie software and hardware cannot be changed by the manufacturer. be held to map or distribute the software modules to the hardware resources of the hardware system in order to enable the program to be optimally executed on the hardware system.
  • this process is time consuming and therefore costly.
  • the invention is therefore based on the object of providing a device and a method for software management in a heterogeneous hardware system, it being possible for the existing hardware resources of the hardware system to be used optimally.
  • an evaluation unit for generating configuration parameters as a function of hardware characteristic data that describe existing hardware resources of the heterogeneous hardware system, and of software request data that describe required hardware resources for a software module to be processed
  • one Assignment unit which distributes the software module depending on the configuration parameters of the evaluation unit to the various data processing units and makes it executable, allows complex software systems or complex application programs with a large number of software modules to be optimally adapted to an existing heterogeneous hardware Syste be distributed, which can significantly improve performance.
  • a hardware analysis unit can also be provided for analyzing the hardware system and for generating hardware characteristics.
  • the hardware analysis unit generating hardware optimization data as a function of the test assignment carried out, and further consideration of this hardware optimization data when generating the Configuration parameters by the evaluation unit, an automatic optimization in the distribution of software modules can also be realized.
  • energy optimization, an effective processing rate and / or an effective memory availability of the hardware system are preferably considered as hardware optimization data.
  • a software selection unit can be provided for selecting a software module from a large number of alternative software modules of a software system or application program depending on the configuration parameters of the evaluation unit, only the selected software modules being made available to the assignment unit , In this way, not only an optimal allocation, but also an optimal selection of available software modules can be carried out on the different data processing units, whereby the overall performance of the system can be further improved.
  • a user input unit can also be provided, which ensures manual influencing of the automatic selection or assignment process. This significantly increases the flexibility of the overall system.
  • a software analysis unit can be provided for analyzing a software system and for generating the software request data, provided, for example, that the software system or the software modules to be distributed do not already have corresponding software request data.
  • "old" application programs can also be optimally distributed to a hardware system.
  • the software modules preferably have data processing unit-independent program codes such as JAVA TM, data processing unit-specific program codes can also be used, but an adaptation unit for adapting a program code of the software module to the different data processing units and / or the different ones Data processing units to the respective program code of the software module is required.
  • data processing unit-independent program codes such as JAVA TM
  • data processing unit-specific program codes can also be used, but an adaptation unit for adapting a program code of the software module to the different data processing units and / or the different ones Data processing units to the respective program code of the software module is required.
  • the configuration unit according to the invention is preferably implemented in a mobile telecommunications terminal, it being possible for the mobile phone to be optimally configured at any time using a download manager for downloading software modules and associated software request data via a download server in a telecommunications network.
  • the configuration unit can also be used as a development tool for more efficient software management in heterogeneous hardware systems.
  • an evaluation of hardware characteristic data, which describe existing hardware resources of the heterogeneous hardware system, and of software request data, which describe required hardware resources for the software module to be distributed and processed, is first of all used to generate configuration parameters carried out, the software module then depending on the generated configuration parameters to the different Data processing units are distributed and finally made executable.
  • FIG. 1 is a simplified block diagram of an overall system with an inventive device for software management
  • FIG 2 is a simplified block diagram of the inventive device for software management, as shown in Figure 1;
  • FIG. 3 shows a simplified graphic representation of a software system and associated software modules with their respective software requirement data
  • FIG. 4 shows a simplified graphical representation of a hardware system with associated hardware resources and associated hardware characteristic data
  • FIGS. 5A and 5B show a simplified block diagram to illustrate hardware optimization
  • FIG. 6 shows a simplified block diagram to illustrate a distribution process as a function of available hardware resources
  • FIG. 7 shows a simplified graphical illustration to illustrate a download process for software modules in a telecommunications network
  • FIG. 8 shows a simplified flow chart to illustrate essential steps in the implementation of the software management method in a heterogeneous hardware system.
  • FIG. 1 shows a simplified block diagram to illustrate a device according to the invention and a method for software management in a heterogeneous hardware system.
  • SS denotes a software system such as, for example, a complex application program or a database with a large number of application programs, each of which can have at least one software module in the described case, at least software modules A, B and C.
  • the software modules A, B and C can represent partial functionalities of an application program or a complex software system and also offer alternative solutions with regard to their functionality.
  • a configuration unit KE maps the software or the different software objects or software modules into the different data processing units DV1, DV2 and DV3 of the hardware system HS takes over.
  • the heterogeneous hardware system HS has, for example, an application CPU (Application Central Processing Unit) DV1, a modem CPU (Modem Central Processing Unit) DV2 and a modem DSP (Modem Digital Signal Processor) DV3 that communicate with each other and have other hardware resources such as memory and communication channels, not shown.
  • an application CPU Application Central Processing Unit
  • modem CPU Modem Central Processing Unit
  • DSP Modem Digital Signal Processor
  • HW-MD Hard Ware Meta Data
  • FIG. 4 shows a simplified graphic object representation of the hardware system HS with associated hardware resources DV1, DV2, DV3 and CC and associated hardware characteristic data or hardware metadata HW-MD.
  • the hardware system HS has a category of data processing units DV1 to DV3 which, for example, represent an application CPU, a modem CPU and a modem DSP.
  • Each of these data processing units has certain characteristic features which are stored in the characterizing hardware characteristic data DV-MD of the data processing units. These include, for example, a processor type, a number of processor cores and a data processing rate MIPS (million instructions per second).
  • the hardware system HS has a category communication channel CC, which in turn has associated communication channel characteristic data CC-MD with corresponding values for, for example, a bandwidth, a delay, a jitter, etc.
  • CC-MD communication channel characteristic data
  • the entirety of this characteristic data or metadata is summarized in the hardware characteristic data or hardware metadata HW-MD and accordingly describes or characterizes very precisely existing hardware resources of a hardware system.
  • FIG. 3 shows an object-related representation of the software system SS according to FIG. 1, a complex application program consisting, for example, of a multiplicity of software modules A, B, C and D, each of which uses software request data SW-MD describe the hardware resources required for the at least one software module to be processed or the entire application program.
  • These software request data or software metadata SW-MD essentially correspond to the same characteristic data as the hardware characteristic data and consequently relate in particular to a computing power or CPU requirement required by the software. Performance, a required communication bandwidth, a required storage space etc.
  • both these hardware characteristic data HW-MD and the software request data SW-MD of the hardware system and of at least one software module A, B and C are available, which is why the configuration unit KE is dependent
  • the software modules are appropriately assigned to the available data processing units DV1 to DV3 and the programs can be executed.
  • making executable is understood here to mean loading or installing a software module in a data processing unit, for example when using what are known as FPGAs (Field Programmable Gate Array) is also understood to mean synthesizing the software in a novel type of hardware.
  • FPGAs Field Programmable Gate Array
  • FIG. 2 shows a simplified block diagram of the configuration unit KE according to FIG. 1, as it can be used for software management of a complex software system SS in a heterogeneous hardware system HS.
  • the same reference numerals designate the same or corresponding elements, which is why a repeated description is omitted below.
  • the configuration unit KE has an evaluation unit 1 for generating configuration parameters as a function of the hardware characteristic data HW-MD described above and of software request data SW-MD.
  • the hardware characteristics HW-MD describe the hardware System HS existing hardware resources such as an actually existing bandwidth, a data processing rate, etc.
  • the software request data SW-MD describe the hardware resources required for a software module A, B or C to be processed, such as again a required bandwidth for a communication channel or a required data processing rate or computing power.
  • the configuration unit KE has an assignment unit 2 which, depending on the configuration parameters KP determined by the evaluation unit 1, distributes and executes the software module to be distributed or mapped to the different data processing units DV1 to DV3.
  • the configuration unit KE carries out a target / actual comparison of the different available hardware resources as well as the hardware resources requested by the software, the respective software modules being optimally configured in the respective ones depending on this result different data processing units DVl to DV3 distributed and made executable.
  • This target / actual comparison is preferably carried out iteratively, as a result of which further improved software images are obtained.
  • the configuration unit KE can also have a hardware analysis unit 3 for analyzing the hardware system HS and for generating hardware characteristic data HW-MD, as a result of which, in particular, hardware systems that change due to software implementations are automatically detected and can be described.
  • This hardware characteristic data HW-MD is in turn made available to the evaluation unit 1 for comparison with the software request data SW-MD.
  • this hardware analysis unit 3 can also be used to generate hardware optimization data HW-OD as a function of a test assignment of software modules in the hardware system.
  • FIGS. 5A and 5B show a simplified block diagram to illustrate such a hardware optimization, the same reference numerals again designating the same elements and a repeated description being omitted below.
  • a test assignment is first carried out by the configuration unit KE using the hardware characteristics HW-MD and the software requirement data SW-MD, which are usually present, in accordance with FIG. 5A, a software module A being used, for example, in the application -CPU DVl the software modules B and D are stored in the modem CPU DV2 and the software module C in the modem DSP DV3 and made executable.
  • a short test run is now carried out, for example Software carried out under the distribution shown, resulting in the hardware optimization data HW-OD.
  • Such hardware optimization data HW-OD can, for example, an energy consumption of the hardware system, an effective processing rate, that is, an actual data processing rate taking into account the distributed software modules and the used communication channels between the data processing units and / or an effective Memory availability that results for the program in this distribution are output.
  • the evaluation unit 1 can now determine, for example, a final assignment of the software modules according to FIG. 5B, the software module D being used for certain optimization reasons, such as energy consumption, an effective processing rate and / or effective memory availability is shifted from the data processing unit DV2 to the data processing unit DV1.
  • the software management or assignment can accordingly be further optimized, whereby an actual behavior of the hardware system can also be taken into account.
  • the configuration unit KE can furthermore have a software selection unit 4 for selecting software modules from a multiplicity of alternative software modules of a software system or a complex application program depending on the configuration parameters KP of the evaluation unit 1, the assignment unit 2 finally only the selected software modules are made available for further distribution to the data processing units.
  • a software selection unit 4 for selecting software modules from a multiplicity of alternative software modules of a software system or a complex application program depending on the configuration parameters KP of the evaluation unit 1
  • the assignment unit 2 finally only the selected software modules are made available for further distribution to the data processing units.
  • FIG. 6 shows a simplified block diagram to illustrate such a selection functionality, with the same reference symbols denoting the same elements and a repeated description being omitted below.
  • an MP3 application is to be distributed or implemented as a complex application program on different hardware systems, the MP3 application as software module AI, for example a LowEndMP3 player, as software module A2 a HighEndMP3 player, as software -Module B2 has a software MP3 decoder and as a software module B1 a hardware MP3 decoder.
  • software module AI for example a LowEndMP3 player
  • software module A2 a HighEndMP3 player
  • software -Module B2 has a software MP3 decoder and as a software module B1 a hardware MP3 decoder.
  • a hardware system 1 has, for example, an application CPU DV1 with low power, a modem DSP DV2 with low power and a modem hardware DV3 with MP3 support.
  • a powerful hardware system 2 has an application CPU DV10 with high performance, a modem DSP DV20 with average performance and standard modem hardware DV30.
  • the network functionality is usually implemented in a complex software component.
  • this software component is now divided into two: a part that implements the higher protocol layers (upper protocol stack, here software module C) and a part that implements the lower protocol layers (lower protocol stack, here software Module D).
  • software module C is embedded on CPUs DVl and DV10.
  • the software modules D for realizing a lower one are in the modem DSPs DV2 and DV20 Protocol stacks are embedded and are connected to the upper protocol stack of software module C.
  • the selection unit 4 based on a hardware system 1, will place the alternative software module AI for realizing an MP3 player on a device with lower performance or equipment in the data processing unit DV1 and make it executable.
  • the largely alternative software modules made available by complex application programs can be optimally distributed in a respective hardware environment or a respective hardware system HS, which enables optimum performance in each case.
  • the MP3 decoder in particular is stored in the powerful device as a pure software MP3 decoder in the application CPU, while in the underperforming terminal, which is a hardware-assisted has MP3 component, only a ru ⁇ dimentärer hardware MP3 decoder is stored.
  • the configuration unit KE can also have a user input unit 5 for realizing an additional user control of the evaluation unit 1. In this way, increased user comfort and, in particular, increased flexibility are obtained, with a user being able to influence automatic selection and / or assignment of software modules according to their respective needs.
  • the configuration unit KE can have a software analysis unit 6 for analyzing a software system SS or the software modules A, B or C present therein, which generates software request data SW-MD.
  • a software analysis unit 6 for analyzing a software system SS or the software modules A, B or C present therein, which generates software request data SW-MD.
  • Programming languages independent of data processing units are preferably used for the software system or the software modules of the complex application program, as a result of which it is particularly easy to select and assign the software modules to the different data processing units.
  • the program code of the software modules or of the software system can also be data processing unit-specific, but an adaptation unit (not shown) is provided for adapting a program code of the software module to the different data processing units and / or the different data processing units to the program code of the software module have to be.
  • an adaptation unit not shown
  • particular emphasis is placed on translation units for compiling (so-called compiler) software for special hardware platforms or the realization of virtual machines and emulators.
  • FIG. 7 shows a simplified block diagram of a mobile telecommunication terminal MT with a configuration unit KE according to the invention, as is typically embedded in a communication network N, the same reference symbols denoting identical or corresponding elements and a repeated description being omitted below.
  • the mobile telecommunication terminal MT for example a cell phone, in turn has a heterogeneous hardware system HS with different data processing units DV1 and further hardware resources such as a memory unit M1 and a communication channel CCl.
  • each of these hardware resources in turn has associated hardware characteristics M-MD, CC-MD and DV-MD for describing the respective existing hardware resource.
  • the mobile telecommunications terminal MT is connected via a telecommunications network N (for example GSM or UMTS) to, for example, a download server DS in the network N which contains a large number of complex application programs or associated software modules A with associated software request data SW-MD
  • a download server DS in the network N which contains a large number of complex application programs or associated software modules A with associated software request data SW-MD
  • the corresponding configuration parameters KP are first determined and taken into account, taking into account the software request data made available via the network and the hardware characteristics available in the terminal passed this on to a download manager DM.
  • the download manager DM which essentially corresponds to an extended software selection unit 4
  • software modules made available via a network N can now also be downloaded and optimally distributed in the hardware system.
  • a download server DS with a single complex application program SS Supply a variety of different mobile telecommunication terminals MT with regard to the desired software modules. This can significantly reduce software development effort.
  • FIG. 7 describes a mobile telecommunications terminal MT embedded in a telecommunications network N with a configuration unit according to the invention
  • the configuration unit according to the invention can also be located in a development tool for heterogeneous hardware systems, as a result of which a development effort can be significantly reduced.
  • FIG. 8 shows a simplified flow diagram to illustrate essential steps in the implementation of the software management method in a heterogeneous hardware system.
  • step SO After a start in step SO a analysis of the software system SS for generating software request data, in a step Sl first be performed, thereby also 'software modules or application programs, which have no such request data may be further processed.
  • step S2 can be similar
  • An analysis of the hardware system HS to generate hardware characteristics can be performed.
  • a step S3 the hardware characteristics described above, which describe the existing hardware resources of the heterogeneous hardware system, and the software requirement data, which describe the hardware resources required by the software modules, are now evaluated.
  • Configuration parameters KP as described above, are generated as the evaluation result.
  • software modules can then be selected from a multiplicity of alternative software modules AI, A2, B1, B2 of the application program as a function of the configuration parameters KP of the evaluation unit 1, in a step S5 a distribution of the Available software modules depending on the configuration parameters KP on the different data processing units in the hardware system.
  • step S6 the software distributed in the hardware system is made executable in a step S6 and the hardware configuration or software implementation is finally completed.
  • a hardware optimization data record can again be generated as a function of a test assignment of the software modules in the hardware system, the configuration parameters also being dependent on the hardware generated in step S3. Optimization data are generated.
  • the invention was described above using a mobile telecommunication terminal and a development tool for heterogeneous rogene hardware systems described. However, it is not limited to this and in the same way also includes other devices in which complex software systems have to be mapped into heterogeneous hardware systems.

Abstract

Die Erfindung betrifft eine Vorrichtung und ein Verfahren zur Software-Verwaltung in einem heterogenen Hardware-System mit einer Auswerteeinheit (1) zum Erzeugen von Konfigurationsparametern (KP) in Abhängigkeit von Hardware-Kenndaten (HW­MD), die vorhandene Hardware-Ressourcen des heterogenen Hardware-Systems (HS) beschreiben, und von Software-­Anforderungsdaten (SW-MD), die benötigte Hardware-Ressourcen für das zumindest eine abzuarbeitende Software­Modul beschreiben. Eine Zuordnungseinheit (2) verteilt Software-Module (A, B, C) eines Software-Systems in Abhängigkeit von den Konfigurationsparametern (KP) der Auswerteeinheit (1) auf unterschiedliche Datenverarbeitungseinheiten des heterogenen Hardware-Systems. Auf diese Weise erhält man jeweils eine optimale Platzierung einer Software in einem komplexen Hardware-System.

Description

Beschreibung
Vorrichtung und Verfahren zur Software-Verwaltung in einem heterogenen Hardware-System
Die vorliegende Erfindung bezieht sich auf eine Vorrichtung und ein Verfahren zur Software-Verwaltung in einem heterogenen Hardware-System und insbesondere auf eine in einem mobilen Telekommunikationsendgerät oder einem Entwicklungstool realisierte Kon igurationseinheit zum Kon igurieren eines heterogenen Hardware-Systems, wobei auf eine Vielzahl von unterschiedlichen Datenverarbeitungseinheiten miteinander kommunizierende Software-Module optimal verteilt werden.
Bei der Implementierung von komplexen Software-Systemen wird meist ein komplexes, mit mehreren Datenverarbeitungseinheiten (CPUs, DSPs usw.) ausgestattetes Hardware-System zu Grunde gelegt, wobei einzelne Softwareteile bzw. Software-Module auf diese unterschiedlichen Datenverarbeitungseinheiten verteilt werden und miteinander kommunizieren.
Insbesondere in zukünftigen mobilen Telekommunikationsendgeräten werden heterogene Hardware-Systeme verwendet, die eine Vielzahl von unterschiedlichen Datenverarbeitungseinheiten wie beispielsweise einer Applikations-CPU, einer Modem-CPU und einem Modem-DSP (Digital Signal Processor) aufweisen. Zukünftige Anwendungsprogramme für derartige mobile Telekommunikationsendgeräte weisen hierbei eine Vielzahl von teilweise alternativen Software-Modulen auf, die zur Realisierung einer vorbestimmten Funktionalität auf den unterschiedlichen Datenverarbeitungseinheiten optimal verteilt werden müssen.
Üblicherweise erfolgt die Verteilung derartiger Software- Module als manueller Schritt innerhalb der Entwicklungsphase bzw. Implementierungsphase, sofern das System komplett, d.h. Software und Hardware vom Hersteller unveränderlich, ausgeliefert wird, insbesondere ein Softwareentwickler ist demzu- folge gehalten, die Abbildung bzw. das Verteilen der Software-Module auf die Hardware-Ressourcen des Hardware-Systems vorzunehmen, um eine optimale Ausführbarkeit des Programms auf dem Hardware-System zu ermöglichen. Dieser Vorgang ist jedoch zeitaufwändig und demzufolge kostenintensiv.
Darüber hinaus hat insbesondere bei mobilen Telekommunikationsendgeräten eine Aktualisierung des Gesamtsystems mit neuer Software aus einem Netzwerk eine zunehmende Bedeutung, wobei insbesondere für Telekommunikationsendgeräte mit einem heterogenen Hardware-System in den seltensten Fällen eine optimale Software-Konfiguration bzw. -Verteilung stattfindet.
Der Erfindung liegt daher die Aufgabe zu Grunde eine Vorrich- tung und ein Verfahren zur Software-Verwaltung in einem heterogenen Hardware-System zu schaffen, wobei die vorhandenen Hardware-Ressourcen des Hardware-Systems optimal genutzt werden können .
Erfindungsgemäß wird diese Aufgabe hinsichtlich der Vorrichtung durch die Merkmale des Patentanspruchs 1 und hinsichtlich des Verfahrens durch die Maßnahmen des Patentanspruchs 14 gelöst.
insbesondere durch die Verwendung einer Auswerteeinheit zum Erzeugen von Konfigurationsparameterή in Abhängigkeit von Hardware-Kenndaten, die vorhandene Hardware-Ressourcen des heterogenen Hardware-Systems beschreiben, und von Software- Anforderungsdaten, die benötigte Hardware-Ressourcen für ein abzuarbeitendes Software-Modul beschreiben, und einer Zuordnungseinheit, welche das Software-Modul in Abhängigkeit von den Konfigurationsparametern der Auswerteeinheit auf die unterschiedlichen Datenverarbeitungseinheiten verteilt und ausführbar macht, können komplexe Software-Systeme bzw. komplexe Anwendungsprogramme mit einer Vielzahl von Software-Modulen optimal auf ein jeweils vorhandenes heterogenes Hardware- Syste verteilt werden, wodurch sich die Leistungsfähigkeit wesentlich verbessern lässt.
Falls die Hardware-Kenndaten des Hardware-Systems nicht vor- bekannt sind, kann ferner eine Hardware-Analyseeinheit zum Analysieren des Hardware-Systems und zum Erzeugen von Hardware-Kenndaten vorgesehen werden. Insbesondere in Verbindung mit einer Test-Zuordnung der zu verteilenden Software-Module auf das Hardware-System, wobei die Hardware-Analyseeinheit Hardware—Optimierungsdaten in Abhängigkeit von der durchgeführten Test-Zuordnung erzeugt, und einer weiteren Berücksichtigung dieser Hardware-Optimierungsdaten bei der Erzeugung der Konfigurationsparameter durch die Auswerteeinheit, kann ferner eine automatische Optimierung bei der Verteilung von Software-Modulen realisiert werden. Als Hardware-Optimierungsdaten werden hierbei vorzugsweise ein Energieverbrauch, eine effektive Verarbeitungsrate und/oder eine effektive Speicherverfügbarkeit des Hardware-Systems betrachtet.
Ferner kann eine Software-Auswahleinheit zum Auswählen eines Software—Moduls aus einer Vielzahl von alternativen Software- Modulen eines Software-Systems bzw. Anwendungsprogramms in Abhängigkeit von den Konfigurationsparametern der Auswerteeinheit vorgesehen sein, wobei der Zuordnungseinheit nur die ausgewählten Software-Module zur Verfügung gestellt werden. Auf diese Weise kann nicht nur eine optimale Zuordnung, sondern auch eine optimale Auswahl von zur Verfügung stehenden Software-Modulen auf die unterschiedlichen Datenverarbeitungseinheiten durchgeführt werden, wodurch sich eine Gesamt- Performance des Systems weiter verbessern lässt.
Zur Realisierung einer zusätzlichen Benutzersteuerung der Auswerteeinheit kann ferner eine Benutzer-Eingabeeinheit vorgesehen sein, wodurch eine manuelle Beein lussung des automa- tischen Auswahl- oder Zuordnungsvorgangs gewährleistet ist. Die Flexibilität des Gesamtsystems wird dadurch wesentlich gesteigert . Ferner kann eine Software-Analyseeinheit zum Analysieren eines Software-Systems und zum Erzeugen der Software—Anforderungsdaten vorgesehen werden, sofern beispielsweise das Soft- ware-System bzw. die zu verteilenden Software-Module nicht bereits über entsprechende Software-Anforderungsdaten verfügen. Demzufolge können auch „alte" Anwendungsprogramme optimal auf ein Hardware-System verteilt werden.
Obwohl vorzugsweise die Software-Module datenverarbeitungs- einheiten-unabhängige Programmcodes wie beispielsweise JAVA™ aufweisen, können auch datenverarbeitungseinheiten-spezifi- sche Programmcodes verwendet werden, wobei jedoch eine Anpassungseinheit zum Anpassen eines Programmcodes des Software- Moduls an die unterschiedlichen Datenverarbeitungseinheiten und/oder der unterschiedlichen Datenverarbeitungseinheiten an den jeweiligen Programmcode des Software-Moduls benötigt wird.
Vorzugsweise ist die erfindungsgemäße Konfigurationseinheit in einem mobilen Telekommunikationsendgerät implementiert, wobei unter Verwendung eines Download-Managers zum Herunterladen von Software-Modulen und zugehörigen Software-Anforderungsdaten über einen Download-Server in einem Telekommunika- tionsnetzwerk jederzeit das Handy optimal konfiguriert werden kann. In gleicher Weise ist die Konfigurationseinheit jedoch auch als Entwicklungstool zur effizienteren Software-Verwaltung in heterogenen Hardware-Systemen einsetzbar.
Hinsichtlich des Verfahrens wird zunächst ein Auswerten von Hardware-Kenndaten, die vorhandene Hardware-Ressourcen des heterogenen Hardware-Systems beschreiben, und von Software- Anforderungsdaten, die benötigte Hardware-Ressourcen für das zu verteilende und abzuarbeitende Software-Modul beschreiben, zum Erzeugen von Konfigurationsparametern durchgeführt, wobei anschließend das Software-Modul in Abhängigkeit von den erzeugten Konfigurationsparametern auf die unterschiedlichen Datenverarbeitungseinheiten verteilt und abschließend ausführbar gemacht wird.
In den weiteren Unteransprüchen sind weitere vorteilhafte Ausgestaltungen der Erfindung gekennzeichnet.
Die Erfindung wird nachstehend anhand von Ausführungsbeispie- len unter Bezugnahme auf die Zeichnung näher beschrieben.
Es zeigen:
Figur 1 eine vereinfachte Blockdarstellung eines Gesamtsystems mit einer erfindungsgemäßen Vorrichtung zur Software- Verwaltung;
Figur 2 eine vereinfachte Blockdarstellung der er indungsgemäßen Vorrichtung zur Software-Verwaltung, wie sie in Figur 1 dargestellt ist;
Figur 3 eine vereinfachte graphische Darstellung eines Software-Systems sowie zugehörigen Software-Modulen mit ihren jeweiligen Software-Anforderungsdaten;
Figur 4 eine vereinfachte graphische Darstellung eines Hard- ware-Syste s mit zugehörigen Hardware-Ressourcen und zugehörigen Hardware-Kenndaten;
Figuren 5A und 5B eine vereinfachte Blockdarstellung zur Veranschaulichung einer Hardware-Optimierung;
Figur 6 eine vereinfachte Blockdarstellung zur Veranschaulichung eines Verteilungsvorgangs in Abhängigkeit von zur Verfügung stehenden Hardware-Ressourcen;
Figur 7 eine vereinfachte graphische Darstellung zur Veranschaulichung eines Download-Vorgangs von Software-Modulen in einem Telekommunikationsnetzwerk; und Figur 8 ein vereinfachtes Flussdiagramm zur Veranschaulichung wesentlicher Schritte bei der Durchführung des Verfahrens zur Software-Verwaltung in einem heterogenen Hardware-System.
Figur 1 zeigt eine vereinfachte Blockdarstellung zur Veranschaulichung einer erfindungsgemäßen Vorrichtung sowie eines Verfahrens zur Software-Verwaltung in einem heterogenen Hardware-System.
Gemäß Figur 1 bezeichnet SS ein Software-System wie beispielsweise ein komplexes Anwendungsprogramm bzw. eine Datenbank mit einer Vielzahl von Anwendungsprogrammen, die jeweils zumindest ein Software-Modul im beschriebenen Fall zumindest Software-Module A, B und C aufweisen können. Die Software- Module A, B und C können hierbei Teil-Funktionalitäten eines Anwendungsprogramms oder eines komplexen Software-Systems darstellen und darüber hinaus hinsichtlich ihrer Funktionalität alternative Lösungen anbieten.
Zur Realisierung eines derartigen Software—Systems auf einer tatsächlichen Hardware-Plattform bzw. einem Hardware-System HS wird nunmehr eine Konfigurationseinheit KE vorgeschlagen, die eine Abbildung der Software bzw. der unterschiedlichen Software-Objekte bzw. Software-Module in die unterschiedlichen Datenverarbeitungseinheiten DVl, DV2 und DV3 des Hardware-Systems HS übernimmt.
Genauer gesagt weist das heterogene Hardware-System HS bei- spielsweise eine Applikations-CPU (Application Central Processing Unit) DVl, eine Modem-CPU (Modem Central Processing Unit) DV2 und einen Modem-DSP (Modem Digital Signal Proces- sor) DV3 auf, die untereinander kommunizieren und weitere Hardware-Ressourcen aufweisen wie beispielsweise nicht darge- stellte Speicher und Kommunikationskanäle. Zur Beschreibung des Hardware-Systems HS kann dieses beispielsweise Hardware- Kenndaten HW-MD (Hard Ware Meta Data) aufweisen, die die vorhandenen Hardware-Ressourcen im Einzelnen beschreiben.
Figur 4 zeigt eine vereinfachte graphische Objekt-Darstellung des Hardware-Systems HS mit zugehörigen Hardware-Ressourcen DVl, DV2, DV3 und CC sowie zugehörigen Hardware-Kenndaten bzw. Hardware-Metadaten HW-MD. Gemäß der objektbezogenen Darstellung weist das Hardware-System HS eine Kategorie von Datenverarbeitungseinheiten DVl bis DV3 auf, die beispielsweise eine Applikations-CPU, eine Modem-CPU und einen Modem-DSP darstellen. Jede dieser Datenverarbeitungseinheiten besitzt bestimmte charakteristische Merkmale, welche in den charakterisierenden Hardware-Kenndaten DV-MD der Datenverarbeitungs- einheiten abgelegt sind. Hierzu gehören beispielsweise ein Prozessortyp, eine Anzahl von Prozessorkernen sowie eine Datenverarbeitungsrate MIPS (Million Instructions per Second) . Ferner weist das Hardware-System HS eine Kategorie Kommunikations-Kanal CC auf, die wiederum zugehörige Kommunikations- Kanal-Kenndaten CC-MD mit entsprechenden Werten für bei- spielsweise eine Bandbreite, eine Verzögerung, einen Jitter usw. aufweisen. Die Gesamtheit dieser Kenndaten bzw. Metadaten werden in den Hardware-Kenndaten bzw. Hardware-Metadaten HW-MD zusammengefasst und beschreiben bzw. charakterisieren demzufolge sehr genau jeweils vorhandene Hardware-Ressourcen eines Hardware-Systems.
In gleicher Weise zeigt Figur 3 eine o jektbezogene Darstellung des Software-Systems SS gemäß Figur 1, wobei ein komplexes Anwendungsprogramm beispielsweise aus einer Vielzahl von Software-Modulen A, B, C und D besteht, welche jeweils über Software-Anforderungsdaten SW-MD die für das zumindest eine abzuarbeitende Software-Modul oder das gesamte Anwendungsprogramm benötigten Hardware-Ressourcen beschreiben. Im Wesentlichen entsprechen diese Software-Anforderungsdaten bzw. Software-Metadaten SW-MD den gleichen Kenndaten wie die Hardware-Kenndaten und beziehen sich demzufolge insbesondere auf eine von der Software geforderte Rechenleistung bzw. CPU- Leistung, eine geforderte Kommunikationsbandbreite, einen geforderten Speicherplatz usw.
Gemäß Figur 1 liegen im günstigsten Fall sowohl diese Hard- ware-Kenndaten HW-MD als auch die Software-Anforderungsdaten SW-MD des Hardware-Systems sowie von zumindest einem Software-Modul A, B und C vor, weshalb die Konfigurationseinheit KE in Abhängigkeit von diesen Hardware-Kenndaten und Software-Anforderungsdaten eine geeignete Zuordnung der Software- Module auf die zur Verfügung stehende Datenverarbeitungseinheiten DVl bis DV3 durchführt und die Programme ausführbar macht. Unter einem Ausführbarmachen wird hierbei im weitesten Sinne der Begriff eines Ladens oder Installierens eines Software—Moduls in einer Datenverarbeitungseinheit verstanden, wobei beispielsweise bei Verwendung von sogenannten FPGAs (Field Programmable Gate Array) auch eine Synthetisierung der Software in einer neuartigen Hardware verstanden wird. Im Gegensatz zu herkömmlichen Prozessor-basierten Datenverarbeitungseinheiten, in denen eine Software im Wesentlichen in ei- nem Arbeitsspeicher abgelegt und dann abgearbeitet wird, verändern derartige synthetisierende Datenverarbeitungseinheiten ihr tatsächliches Aussehen, wobei im Wesentlichen eine neue Hardware entsteht.
Figur 2 zeigt eine vereinfachte Blockdarstellung der Konfigurationseinheit KE gemäß Figur 1, wie sie zur Software—Verwaltung von einem komplexen Software-System SS in einem heterogenen Hardware-System HS verwendet werden kann. Gleiche Bezugszeichen bezeichnen hierbei gleiche oder entsprechende Elemente, weshalb auf eine wiederholte Beschreibung nachfolgend verzichtet wird.
Gemäß Figur 2 weist die Konfigurationseinheit KE eine Auswerteeinheit 1 zum Erzeugen von Konfigurationsparametern in Ab— hängigkeit von den vorstehend beschriebenen Hardware-Kenndaten HW-MD und von Software-Anforderungsdaten SW-MD auf. Die Hardware-Kenndaten HW-MD beschreiben hierbei die im Hardware- System HS vorhandenen Hardware-Ressourcen wie beispielsweise eine tatsächlich vorhandene Bandbreite, eine Datenverarbeitungsrate usw. In ähnlicher Weise beschreiben die Software- Anforderungsdaten SW-MD die für ein abzuarbeitendes Software- Modul A, B oder C benötigten Hardware-Ressourcen wie beispielsweise wiederum eine geforderte Bandbreite für einen Kommunikationskanal oder eine geforderte Datenverarbeitungsrate bzw. Rechenleistung.
Ferner weist die Kon igurationseinheit KE eine Zuordnungseinheit 2 auf, welche das zu verteilende bzw. abzubildende Software-Modul in Abhängigkeit von den von der Auswerteeinheit 1 ermittelten Konfigurationsparametern KP auf die unterschiedlichen Datenverarbeitungseinheiten DVl bis DV3 verteilt und ausführbar macht.
Genauer gesagt wird durch die Konfigurationseinheit KE ein Soll-/Ist-Vergleich über die unterschiedlichen zur Verfügung stehenden Hardware-Ressourcen sowie von der Software angefor- derten Hardware-Ressourcen durchgeführt, wobei in Abhängigkeit von diesem Ergebnis die jeweiligen Software-Module optimal in den jeweiligen unterschiedlichen Datenverarbeitungseinheiten DVl bis DV3 verteilt und ausführbar gemacht werden. Dieser Soll-/Ist-Vergleich wird vorzugsweise iterativ durch- geführt, wodurch man weiter verbesserte Software-Abbildungen erhält .
Auf diese Weise kann unter Verwendung eines einzigen Software-Systems SS bzw. unter Nutzung eines einzigen Anwendungs- programms auch bei unterschiedlichsten Hardware-Systemen HS jeweils eine optimale Platzierung der Software bzw. der Software-Module auf den verfügbaren Hardware-Ressourcen und insbesondere auf den zur Verfügung stehenden Datenverarbeitungseinheiten realisiert werden. Wird diese Konfigurationseinheit in einem Entwicklungstool zur Software-Implementierung in heterogenen Hardware-Systemen verwendet, so kann dadurch ebenfalls der Aufwand für eine Software-Implementierung wesent- lieh verkleinert werden. Darüber hinaus erhält man bei der Verwendung der Konfigurationseinheit KE in Benutzer-Endgeräten einen erhöhten Benutzerkomfort, da der mühselige Abgleich zwischen den Software-Anforderungen und den zur Verfügung stehenden Hardware-Ressourcen im Endgerät entfällt.
Gemäß Figur 2 kann die Konfigurationseinheit KE ferner eine Hardware-Analyseeinheit 3 zum Analysieren des Hardware-Systems HS und zum Erzeugen von Hardware-Kenndaten HW-MD aufwei- sen, wodurch insbesondere sich auf Grund von Software—Implementierungen ändernde Hardware-Systeme automatisch erfasst und beschrieben werden können. Diese Hardware-Kenndaten HW-MD werden wiederum der Auswerteeinheit 1 zum Vergleich mit den Software-Anforderungsdaten SW-MD zur Verfügung gestellt.
Insbesondere zur Realisierung einer Hardware-Optimierung kann diese Hardware-Analyseeinheit 3 ferner zum Erzeugen von Hardware-Optimierungsdaten HW-OD in Abhängigkeit von einer durchgeführten Test-Zuordnung von Software-Modulen im Hardware- System ausgenutzt werden.
Figuren 5A und 5B zeigen eine vereinfachte Blockdarstellung zur Veranschaulichung einer derartigen Hardware-Optimierung, wobei gleiche Bezugszeichen wiederum gleiche Elemente be- zeichnen und auf eine wiederholte Beschreibung nachfolgend verzichtet wird.
Zur Realisierung einer Hardware-Optimierung wird gemäß Figur 5A zunächst eine Test-Zuordnung von der Konfigurationseinheit KE unter Verwendung der üblicherweise vorhandenen Hardware- Kenndaten HW-MD und der Software-Anforderungsdaten SW-MD durchgeführt, wobei ein Software-Modul A beispielsweise in der Applikations-CPU DVl die Software-Module B und D in der Modem-CPU DV2 und das Software-Modul C im Modem-DSP DV3 abge- legt und ausführbar gemacht werden. Unter Verwendung dieser Test-Zuordnung und unter Zuhilfenahme der Hardware-Analyseeinheit 3 wird nunmehr beispielsweise ein kurzer Testlauf der Software unter der dargestellten Verteilung durchgeführt, wobei sich die Hardware-Optimierungsdaten HW-OD ergeben.
Derartige Hardware-Optimierungsdaten HW-OD können beispiels- weise einen Energieverbrauch des Hardware-Systems, eine effektive Verarbeitungsrate, das heißt eine tatsächliche Datenverarbeitungsrate unter Berücksichtigung der verteilten Software-Module und der in Anspruch genommenen Kommunikationska- näle zwischen den Datenverarbeitungseinheiten und/oder einer effektiven Speicherverfügbarkeit, die sich für das Programm in dieser Verteilung ergibt, ausgegeben werden.
Unter Berücksichtigung dieser zusätzlichen Hardware-Optimierungsdaten HW-OD kann die Auswerteeinheit 1 nunmehr bei- spielsweise eine endgültige Zuordnung der Software—Module gemäß Figur 5B ermitteln, wobei das Software-Modul D aus bestimmten Optimierungsgründen wie beispielsweise einem Energieverbrauch, einer effektiven Verarbeitungsrate und/oder einer effektiven Speicherverfügbarkeit von der Datenverarbei- tungseinheit DV2 in die Datenverarbeitungseinheit DVl verschoben wird. Unter Verwendung eines derartigen Optimierungs— bzw. Regel-Vorgangs kann demzufolge die Software-Verwaltung bzw. -Zuordnung weiter optimiert werden, wobei auch ein tatsächliches Verhalten des Hardware-Systems berücksichtigt wer- den kann.
Gemäß Figur 2 kann die Konfigurationseinheit KE ferner eine Software-Auswahleinheit 4 zum Auswählen von Software-Modulen aus einer Vielzahl von alternativen Software-Modulen eines Software-Systems bzw. eines komplexen Anwendungsprogramms in Abhängigkeit von den Konfigurationsparametern KP der Auswerteeinheit 1 aufweisen, wobei der Zuordnungseinheit 2 schließlich nur die ausgewählten Software-Module zur weiteren Verteilung auf die Datenverarbeitungseinheiten zur Verfügung ge- stellt werden. Demzufolge lässt sich nicht nur eine Verteilung von Software-Modulen innerhalb eines heterogenen Hardware-Systems optimal realisieren, sondern darüber hinaus auch eine Auswahl bzw. Selektion von in einem Software-System SS beispielsweise alternativ zur Verfügung stehender Software- Module .
Figur 6 zeigt eine vereinfachte Blockdarstellung zur Veranschaulichung einer derartigen Auswahl-Funktionalität, wobei gleiche Bezugszeichen gleiche Elemente bezeichnen und auf eine wiederholte Beschreibung nachfolgend verzichtet wird.
Gemäß Figur 6 soll als komplexes Anwendungsprogramm eine MP3- Applikation auf unterschiedliche Hardware-Systeme verteilt bzw. implementiert werden, wobei die MP3-Applikation als Software-Modul AI beispielsweise einen LowEndMP3-Player, als Software-Modul A2 einen HighEndMP3-Player, als Software-Modul B2 einen SoftwareMP3Dekoder und als Software-Modul Bl einen HardwareMP3Dekoder aufweist.
Als zur Verfügung stehende Hardware-Systeme weist ein Hardwaresystem 1 beispielsweise eine Applikations-CPU DVl mit kleiner Leistung, einen Modem-DSP DV2 mit kleiner Leistung sowie eine Modem—Hardware DV3 mit MP3-Unterstützung auf. Demgegenüber weist ein leistungsfähiges Hardwaresystem 2 eine Applikations-CPU DV10 mit hoher Leistung, einen Modem-DSP DV20 mit durchschnittlicher Leistung und eine Standard-Modem- Hardware DV30 auf.
Die Netzwerkfunktionalität wird normalerweise in einer komplexen Software-Komponente realisiert. Als vereinfachte Betrachtung wird diese Software-Komponente nun zweigeteilt: In einen Teil, der die höheren Protokollschichten implementiert (oberer Protokoll-Stack, hier Software-Modul C) und einen Teil, der die niedrigeren Protokollschichten implementiert (unterer Protokoll-Stack, hier Software-Modul D) . In diesem Beispiel wird Software-Modul C auf den CPUs DVl und DV10 ein- gebettet. In gleicher Weise sind in den Modem-DSPs DV2 und DV20 die Software-Module D zur Realisierung eines unteren Protokoll-Stacks eingebettet und stehen mit dem oberen Protokoll-Stack des Software-Moduls C in Verbindung.
Zur Realisierung des eigentlichen MP3-Anwendungsprogramms existieren demzufolge alternative Software-Module AI und A2 sowie Bl und B2 im Software-System. Da das HardwareSystem 1 eine Modem-Hardware mit MP3-Unterstützung aufweist, ist die Zuteilung des Softwaremoduls Bl zur Realisierung eines Hard- ware-MP3-Dekoders bzw. Treibers vollkommen ausreichend, wäh- rend das Hardwaresystem 2 mit ihrer Standard—Modem—Hardware keine derartige Implementierung ermöglicht. Da das Hardware- System 2 jedoch eine sehr leistungsfähige Applikations-CPU aufweist, wird von der vorstehend beschriebenen Auswahleinheit 4 zur Realisierung des MP3—Players in einem Endgerät mit höherwertiger Leistung bzw. Ausstattung das Software-Modul A2 und zur Realisierung eines zugehörigen SoftwareMP3—Dekoders das Software-Modul B2 in die Datenverarbeitungseinheit DV10 gelegt .
Andererseits wird die Auswahleinheit 4 bei Zugrundeliegen eines Hardwaresystems 1 das alternative Software-Modul AI zur Realisierung eines MP3—Players auf einem Engeräte mit niedrigerer Leistung bzw. Ausstattung, in die Datenverarbeitungseinheit DVl legen und ausführbar machen. Auf diese Weise kön- nen die von komplexen Anwendungsprogrammen zur Verfügung gestellten größtenteils alternativen Software-Module optimal in einer jeweiligen Hardware-Umgebung bzw. einem jeweiligen Hardware-System HS verteilt werden, wodurch jeweils eine optimale Performance ermöglicht wird.
Obwohl demzufolge beide Endgeräte mit einer Wiedergabe-Software für MP3-Audiodateien ausgestattet sind, wird insbesondere der MP3-Dekoder im leistungsfähigen Gerät als reiner Soft- ware-MP3-Dekoder in der Applikations-CPU abgelegt, während in dem leistungsschwachen Endgerät, welches jedoch eine hard- ware-unterstützte MP3-Komponente aufweist, lediglich ein ru¬ dimentärer Hardware-MP3-Dekoder abgelegt ist. Darüber hinaus kann gemäß Figur 2 die Konfigurationseinheit KE auch über eine Benutzer-Eingabeeinheit 5 zur Realisierung einer zusätzlichen Benutzer-Steuerung der Auswerteeinheit 1 verfügen. Auf diese Weise erhält man einen erhöhten Benutzerkomfort und insbesondere eine erhöhte Flexibilität, wobei ein Benutzer entsprechend seinen jeweiligen Bedürfnissen eine automatische Auswahl und/oder Zuordnung von Software-Modulen beeinflussen kann.
Ferner kann die Konfigurationseinheit KE eine Software-Analyseeinheit 6 zum Analysieren eines Software-Systems SS bzw. der darin vorhandenen Software-Module A, B oder C aufweisen, die Software-Anforderungsdaten SW-MD erzeugt. Obwohl übli- cherweise moderne Anwendungsprogramme bzw. Software-Systeme
SS bereits derartige Software-Anforderungsdaten aufweisen und sozusagen mitliefern, können mit einer derartigen Software- Analyseeinheit auch herkömmliche bzw. „alte" Anwendungsprogramme, welche keine Software-Anforderungsdaten beinhalten, ausgewählt und zugeordnet werden.
Vorzugsweise werden für das Software-System bzw. die Software-Module des komplexen Anwendungsprogramms datenverarbei— tungseinheiten-unabhängige Programmiersprachen wie beispiels- weise JAVA™ verwendet, wodurch ein Auswählen und Zuordnen der Software-Module auf die unterschiedlichen Datenverarbeitungseinheiten besonders einfach realisiert werden kann. Grundsätzlich kann der Programmcode der Software-Module bzw. des Software-Systems auch datenverarbeitungseinheiten-spezifisch sein, wobei jedoch eine nicht dargestellte Anpassungseinheit zum Anpassen eines Programmcodes des Software-Moduls an die unterschiedlichen Datenverarbeitungseinheiten und/oder der unterschiedlichen Datenverarbeitungseinheiten an den Programmcode des Softwaremoduls vorgesehen sein muss. In diesem Zusammenhang wird insbesondere auf Übersetzungseinheiten zum Kompilieren (sogenannte Compiler) einer jeweiligen Software für spezielle Hardware-Plattformen oder an die Realisierung von virtuellen Maschinen sowie Emulatoren hingewiesen.
Figur 7 zeigt eine vereinfachte Blockdarstellung eines mobilen Telekommunikationsendgeräts MT mit erfindungsgemäßer Konfigurationseinheit KE, wie sie typischerweise in einem Kommunikationsnetzwerk N eingebettet ist, wobei gleiche Bezugszeichen gleiche oder entsprechende Elemente bezeichnen und auf eine wiederholte Beschreibung nachfolgend verzichtet wird.
Gemäß Figur 7 weist das mobile Telekommunikationsendgerät MT wie beispielsweise ein Handy wiederum ein heterogenes Hardware-System HS mit unterschiedlichen Datenverarbeitungseinheiten DVl sowie weitern Hardware—Ressourcen wie beispiels— weise einer Speichereinheit Ml und einem Kommunikationskanal CCl auf. Wie vorstehend bereits beschrieben wurde, weist jede dieser Hardware-Ressourcen wiederum zugehörige Hardware-Kenndaten M-MD, CC-MD und DV-MD zur Beschreibung der jeweiligen vorhandenen Hardware-Ressource auf. Das mobile Telekommunika- tionsendgerät MT ist über ein Telekommunikationsnetzwerk N (z.B. GSM oder UMTS) mit beispielsweise einem Download-Server DS im Netzwerk N verbunden, der eine Vielzahl von komplexen Anwendungsprogrammen bzw. zugehörige Software-Module A mit zugehörigen Software-Anforderungsdaten SW-MD zur Verfügung stellt, ill nunmehr ein Benutzer ein neues Programm über das Netzwerk N auf seinem mobilen Telekommunikationsendgerät MT installieren, so werden zunächst unter Berücksichtigung der über das Netzwerk zur Verfügung gestellten Software-Anforderungsdaten und der im Endgerät vorliegenden Hardware- Kenndaten entsprechende Konfigurationsparameter KP ermittelt und diese an einen Download-Manager DM weitergegeben. Unter Verwendung des Download-Managers DM, der im Wesentlichen einer erweiterten Software-Auswahleinheit 4 entspricht, können nunmehr auch über ein Netzwerk N zur Verfügung gestellte Software-Module heruntergeladen und im Hardware-System optimal verteilt werden. Auf diese Weise kann ein Download-Server DS mit einem einzigen komplexen Anwendungsprogramm SS eine Vielzahl von unterschiedlichen mobilen Telekommunikationsendgeräten MT hinsichtlich gewünschter Software-Module versorgen. Ein Software-Entwicklungsaufwand kann dadurch wesentlich verringert werden.
Obwohl Figur 7 ein in ein Telekommunikationsnetzwerk N eingebettetes mobiles Telekommunikationsendgerät MT mit erfindungsgemäßer Konfigurationseinheit beschreibt, kann sich die erfindungsgemäße Kon igurationseinheit auch in einem Entwick- lungstool für heterogene Hardware-Systeme befinden, wodurch ein Entwicklungsaufwand wesentlich verringert werden kann.
Figur 8 zeigt ein vereinfachtes Flussdiagramm zur Veranschaulichung wesentlicher Schritte bei der- Durchführung des Ver— fahrens zur Software-Verwaltung in einem heterogenen Hardware-System.
Nach einem Start in Schritt SO kann in einem Schritt Sl zunächst eine Analyse des Software-Systems SS zum Erzeugen von Software-Anforderungsdaten durchgeführt werden, wodurch auch' Software-Module bzw. Anwendungsprogramme, welche keinen derartigen Anforderungsdaten aufweisen, weiter verarbeitet werden können .
In einem weiteren optionalen Schritt S2 kann in ähnlicher
Weise eine Analyse des Hardware-Systems HS zum Erzeugen von Hardware-Kenndaten durchgeführt werden.
In einem Schritt S3 erfolgt nunmehr ein Auswerten der vorste- hend beschriebenen Hardware-Kenndaten, die die vorhandenen Hardware-Ressourcen des heterogenen Hardware-Systems beschreiben, sowie der Software-Anforderungsdaten, die die von den Software-Modulen benötigten Hardware-Ressourcen beschreiben. Als Auswerteergebnis werden hierbei Konfigurationspara- meter KP, wie vorstehend beschrieben wurde, erzeugt. In einem Schritt S4 kann anschließend ein Auswählen von Software-Modulen aus einer Vielzahl von alternativen Software- Modulen AI, A2, Bl, B2 des Anwendungsprogramms in Abhängigkeit von den Konfigurationsparametern KP der Auswerteeinheit 1 durchgeführt werden, wobei in einem Schritt S5 ein Verteilen der zur Verfügung stehenden Software-Module in Abhängigkeit von den Konfigurationsparametern KP auf die unterschiedlichen Datenverarbeitungseinheiten im Hardware-System erfolgt.
Abschließend wird in einem Schritt S6 die im Hardware-System verteilte Software ausführbar gemacht und letztendlich die Hardware-Konfiguration bzw. Software-Implementierung abgeschlossen. Das Verfahren endet in Schritt S7.
Wie vorstehend bereits beschrieben wurde, kann vor dem Auswerten in Schritt S3 wiederum in Abhängigkeit von einer Test- Zuordnung der Software-Module im Hardware-System ein Hardware-Optimierungsdatensatz erzeugt werden, wobei im Schritt S3 die Konfigurationsparameter ferner in Abhängigkeit von den erzeugten Hardware—Optimierungsdaten erzeugt werden.
Auf diese Weise erhält man ein Verfahren zur Verwaltung von Software-Modulen, welches auch bei unterschiedlichen Hard- are-Systemen jeweils eine optimale Platzierung der Software auf den zur Verfügung stehenden Hardware—Ressourcen ermöglicht. Ferner kann dadurch ein Aufwand für eine Software- Implementierung während einer Entwicklungsphase für ein Gerät bzw. Gesamtsystem verringert werden, wodurch sich die Kosten reduzieren. Schließlich ergibt sich auch ein erhöhter Benutzerkomfort, da ein üblicherweise mühseliger Abgleich von jeweils vorgegebenen Software-Anforderungen mit jeweils zur Verfügung stehenden Endgeräte- bzw. Hardware-Ressourcen entfällt.
Die Erfindung wurde vorstehend anhand eines mobilen Telekommunikationsendgeräts sowie eines Entwicklungstools für hete- rogene Hardware-Systeme beschrieben. Sie ist jedoch nicht darauf beschränkt und umfasst in gleicher Weise auch weitere Geräte, in denen komplexe Software-Systeme in heterogene Hardware-Systeme abgebildet werden müssen.

Claims

Patentansprüche
1. Vorrichtung zur Software-Verwaltung in einem heterogenen Hardware-System (HS) , welches eine Vielzahl von unters chied- liehen Datenverarbeitungseinheiten (DVl - DV3) zum Abarbeiten von zumindest einem Anwendungsprogramm mit zumindest einem Software-Modul (A, B, C) aufweist, mit einer Auswerteeinheit (1) zum Erzeugen von Konfigurationsparametern (KP) in Abhängigkeit von Hardware-Kenndaten (HW-MD) , die vorhandene Hardware-Ressourcen des heterogenen Hardware- Systems beschreiben, und von
Software-Anforderungsdaten (SW-MD) , die benötigte Hardware- Ressourcen für das zumindest eine abzuarbeitende Software- Modul (A, B, C) beschreiben; und einer Zuordnungseinheit (2) , welche das zumindest eine Softwaremodul des zumindest einen Anwendungsprogramms in Abhängigkeit von den Konfigurationsparametern (KP) der Auswerteeinheit (1) auf die unterschiedlichen Datenverarbeitungseinheiten (DV1-DV3) verteilt und ausführbar macht.
2. Vorrichtung nach Patentanspruch 1, g e k e n n z e i c h n e t d u r c h eine Hardware—Analy— seeinheit (3) zum Analysieren des Hardware-Systems (HS) und zum Erzeugen der Hardware-Kenndaten (HW-MD) .
3. Vorrichtung nach Patentanspruch 2, d a d u r c h g e k e n n z e i c h n e t, dass die Zuordnungseinheit (2) zunächst zumindest eine Test-Zuordnung des zumindest einen Software-Moduls durchführt, wobei die Hard- ware-Analyseeinheit (3) Hardware-Optimierungsdaten (HW-OD) in Abhängigkeit von der durchgeführten Test-Zuordnung erzeugt, und die Auswerteeinheit (1) ferner die Hardware-Optimierungsdaten (HW-OD) bei der Erzeugung der Konfigurationsparameter (KP) berücksichtigt.
4. Vorrichtung nach Patentanspruch 3, d a d u r c h g e k e n n z e i c h n e t, dass die Hardware-Optimierungsdaten (HW-OD) einen Energieverbrauch, eine effektive Verarbeitungsrate und/oder eine effektive Speicherverfügbarkeit angeben .
5. Vorrichtung nach einem der Patentansprüche 1 bis 4, d a d u r c h g e k e n n z e i c h n e t, dass die Software-Anforderungsdaten (SW-MD) oder die Hardware-Kenndaten (HW-MD) benötigte Anforderungsdaten oder vorhandene Kenndaten für eine Datenverarbeitung (DV1-DV3) , ein Speichervermögen (Ml) und/oder Kommunikations-Kanäle (CCl) aufweisen.
6. Vorrichtung nach einem der Patentansprüche 1 bis 5, g e k e n n z e i c h n e t d u r c h eine Software-Aus- wahleinheit (4) zum Auswählen von zumindest einem Software- Modul aus einer Vielzahl von alternativen Software—Modulen (AI, A2) des zumindest einen Anwendungsprogramms in Abhängig¬ keit von den Konfigurationsparametern (KP) der Auswerteeinheit (1), wobei der Zuordnungseinheit (2) nur die ausgewähl- ten Software-Module zur Verfügung gestellt werden.
7. Vorrichtung nach einem der Patentansprüche 1 bis 6, g e k e n n z e i c h n e t d u r c h eine Benutzer-Eingabeeinheit (5) zur Realisierung einer zusätzlichen Benutzer- Steuerung der Auswerteeinheit (1) .
8. Vorrichtung nach einem der Patentansprüche 1 bis 7, g e k e n n z e i c h n e t d u r c h eine Software-Analyseeinheit (6) zum Analysieren eines Software-Systems (SS) und zum Erzeugen der Software-Anforderungsdaten (SW-MD) .
9. Vorrichtung nach einem der Patentansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t, dass das zumindest eine Software-Modul einen datenverarbeitungseinheiten- unabhängigen Programmcode aufweist.
10. Vorrichtung nach einem der Patentansprüche 1 bis 8, g e k e n n z e i c h n e t d u r c h eine Anpassungseinheit zum Anpassen eines datenverarbeitungseinheiten- spezifischen Programmcodes des zumindest einen Software- Moduls an die unterschiedlichen Datenverarbeitungseinheiten und/oder der unterschiedlichen Datenverarbeitungseinheiten an den datenverarbeitungseinheiten-spezifischen Programmcode des zumindest einen Softwaremoduls.
11. Vorrichtung nach einem der Patentansprüche 1 bis 10, d a d u r c h g e k e n n z e i c h n e t, dass sie in einem mobilen Telekommunikationsendgerät (MT) implementiert ist .
12. Vorrichtung nach Patentanspruch 11, g e k e n n z e i c h n e t d u r c h einen Download-Manager (DM) zum Herunterladen von Software-Modulen (A) und zugehörigen Software-Anforderungsdaten (SW-MD) eines externen Software-Systems (SS) über einen Download-Server (DS) in einem Telekommunikationsnetzwerk (N) .
13. Vorrichtung nach einem der Patentansprüche 1 bis 10, d a d u r c h g e k e n n z e i c h n e t, dass sie in einem Entwicklungstool für heterogene Hardware-Systeme implementiert ist.
14. Verfahren zur Software—Verwaltung in einem heterogenen Hardware-System (HS) , welches eine Vielzahl von unterschiedlichen Datenverarbeitungseinheiten (DV1-DV3) zum Abarbeiten von zumindest einem Anwendungsprogramm mit zumindest einem Software-Modul (A, B, C) aufweist, mit den Schritten: a) Auswerten von Hardware-Kenndaten (HW-MD) , die vorhandene Hardware-Ressourcen des heterogenen Hardware-Systems beschreiben, und von Software—Anforderungsdaten (SW-MD) , die benötigte Hardware-Ressourcen für das zumindest eine abzuar- beitende Software-Modul (A, B, C) beschreiben, zum Erzeugen von Konfigurationsparametern (S3) ; b) Verteilen des zumindest einen Software-Moduls (A, B, C) in Abhängigkeit von den Konfigurationsparametern (KP) auf die unterschiedlichen Datenverarbeitungseinheiten (S5) ; und c) Ausführbarmachen des zumindest einen verteilten Soft- ware-Moduls (A, B, C) im Hardware-System (S6) .
15. Verfahren nach Patentanspruch 14, d a d u r c h g e k e n n z e i c h n e t, dass vor Schritt a) der weitere Schritt al) Analysieren eines Software-Systems zum Erzeugen der Software-Anforderungsdaten (Sl) durchgeführt wird.
16. Verfahren nach Patentanspruch^ oder 15, d a d u r c h g e k e n n z e i c h n e t, dass vor Schritt a) der weitere Schritt a2) Analysieren des Hardware—Systems zum Erzeugen von Hardware-Kenndaten (S2) durchgeführt wird.
17. Verfahren nach Patentanspruch 16, d a d u r c h g e k e n n z e i c h n e t, dass in Schritt a2) Hardware-Optimierungsdaten (HW-OD) in Abhängigkeit von einer Test-Zuordnung des zumindest einen Software-Moduls im Hardware-System erzeugt werden, und in Schritt a) die Konfigurationsparameter (KP) ferner in Ab- hängigkeit von den erzeugten Hardware-Optimierungsdaten erzeugt werden.
18. Verfahren nach Patentanspruch 17, d a d u r c h g e k e n n z e i c h n e t, dass die Hard- ware-Optimierungsdaten (HW-OD) einen Energieverbrauch, eine effektive Verarbeitungsrate und/oder eine effektive Speicherverfügbarkeit angeben.
19. Verfahren nach einem der Patentansprüche 14 bis 18, d a d u r c h g e k e n n z e i c h n e t, dass die Software-Anforderungsdaten (SW-MD) oder die Hardware-Kenndaten (HW-MD) benötigte Anforderungsdaten oder vorhandene Kenndaten für eine Datenverarbeitung, ein Speichervermögen und/oder Kommunikations-Kanäle aufweisen.
20. Verfahren nach einem der Patentansprüche 14 bis 19, d a d u r c h g e k e n n z e i c h n e t, dass vor
Schritt b) der weitere Schritt bl) Auswählen von zumindest einem Software-Modul aus einer Vielzahl von alternativen Software-Modulen (AI, A2) des zumindest einen Anwendungsprogramms in Abhängigkeit von den Konfigurationsparametern der Auswerteeinheit (S4) durchgeführt wird.
21. Verfahren nach einem der Patentansprüche 14 bis 20, d a d u r c h g e k e n n z e i c h n e t, dass das zumin- dest eine Software-Modul einen datenverarbeitungseinheiten- unabhängigen Programmcode aufweist .
22. Verfahren nach einem der Patentansprüche 14 bis 20, d a d u r c h g e k e n n z e i c h n e t, dass vor Schritt b) der weitere Schritt b2) Anpassen eines datenverarbeitungseinheiten-spezi ischen Programmcodes des zumindest einen Software-Moduls an die unterschiedlichen Datenverarbeitungseinheiten und/oder der unterschiedlichen Datenverarbeitungseinheiten an den datenver- arbeitungseinheiten-spezifischen Programmcode des zumindest einen Software-Moduls durchgeführt wird.
EP04791127A 2003-11-13 2004-10-04 Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system Withdrawn EP1683012A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04791127A EP1683012A1 (de) 2003-11-13 2004-10-04 Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP03026119 2003-11-13
EP04791127A EP1683012A1 (de) 2003-11-13 2004-10-04 Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system
PCT/EP2004/052415 WO2005048102A1 (de) 2003-11-13 2004-10-04 Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system

Publications (1)

Publication Number Publication Date
EP1683012A1 true EP1683012A1 (de) 2006-07-26

Family

ID=34585872

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04791127A Withdrawn EP1683012A1 (de) 2003-11-13 2004-10-04 Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system

Country Status (2)

Country Link
EP (1) EP1683012A1 (de)
WO (1) WO2005048102A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070061813A1 (en) * 2005-08-30 2007-03-15 Mcdata Corporation Distributed embedded software for a switch

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742829A (en) * 1995-03-10 1998-04-21 Microsoft Corporation Automatic software installation on heterogeneous networked client computer systems
US5951639A (en) * 1996-02-14 1999-09-14 Powertv, Inc. Multicast downloading of software and data modules and their compatibility requirements
DE19933192A1 (de) * 1999-05-21 2000-11-23 Bosch Gmbh Robert Verfahren zum kundenindividuellen Anpassen eines Autoradios

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2005048102A1 *

Also Published As

Publication number Publication date
WO2005048102A1 (de) 2005-05-26

Similar Documents

Publication Publication Date Title
DE69822935T2 (de) Vorrichtung und Verfahren zur dynamischen Regelung der Betriebsmittelzuweisung in einem Computersystem
DE60205755T2 (de) System und verfahren um einen softwarekodeabschnitt eines drahtlosen kommunikationsgerätes herunterzuladen
DE69837676T2 (de) Fernladung von software mit automatischer anpassung für datenzugriffskomptabilität
DE60225293T2 (de) System und verfahren zum organisieren der software eines im feld aktualisierbaren drahtlosen kommunikationsgerätes
WO2006066880A1 (de) System und verfahren zum automatischen aktualisieren von funktionalitäten in einem verteilten netzwerk
DE102013213094B4 (de) System, Verfahren und Computer-Programm-Produkt zum Berechnen von Einstellungen für ein Gerät, unter Benutzung von einer oder mehreren Einschränkungen
CN1126409C (zh) 蜂窝式电话网络的重新配置
EP2799983B1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
DE112010004772T5 (de) Verfahren und System zum Verwalten von Konfigurationen von Systemverwaltungsagentenin einer Verteilten Umgebung
EP3128383B1 (de) Feldgerät
DE102007001147A1 (de) Tragbare elektronische Vorrichtung und Verfahren zum Laden von Ressourcendaten der elektronischen Vorrichtung
CN106020777A (zh) 一种数据处理方法、装置及系统
EP1604278B1 (de) Verfahren zur ablaufsteuerung von sequentiellen objektorientierten systemsimulationen
DE102018110018A1 (de) Verfahren zum Bereitstellen eines integrierten Prozesses für die Steuergerätentwicklung und Simulationsvorrichtung für die Steuergerätentwicklung
DE10303054A1 (de) Verifizieren einer Programmversion
DE69938223T2 (de) Mobiles Agentsystem und Verfahren zum Steuern eines mobilen Agentsystems
EP1683012A1 (de) Vorrichtung und verfahren zur software-verwaltung in einem heterogenen hardware-system
DE112017001421T5 (de) Flexibel optimiertes Datenhandling in Systemen mit mehreren Speichern
DE112017003226B4 (de) Toneinstellungsvorrichtung, elektronisches Musikinstrumentensystem und Toneinstellungsverfahren
DE102018116742A1 (de) Verfahren und System zur Simulation
DE60117600T2 (de) Anordnung und verfahren zum vorprogrammieren des speichers eines elektronischen geräts
EP0918425A2 (de) Softwaregesteuertes Teilnehmerendgerät, Server zum Bereitstellen eines Steuerprogrammes und Verfahren zum Betrieb des Softwaregesteuerten Teilnehmerendgerätes
DE102007023048A1 (de) Intelligentes System zur Bestimmung einer optimalen Partitionsgrösse in einer auf Bestellung fertigenden Umgebung
EP3668132B1 (de) Inkrementelles aktualisieren einer firmware
DE112020002678T5 (de) Verfahren, Vorrichtung und System zur Audioverarbeitung

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: 20060510

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BENQ MOBILE GMBH & CO. OHG

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BENQ CORPORATION

Owner name: BENQ MOBILE GMBH & CO. OHG

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

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

Designated state(s): DE FR GB

19U Interruption of proceedings before grant

Effective date: 20070101

19W Proceedings resumed before grant after interruption of proceedings

Effective date: 20070702

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: QISDA CORPORATION

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BENQ MOBILE GMBH & CO. OHG

Owner name: BENQ CORPORATION

19W Proceedings resumed before grant after interruption of proceedings

Effective date: 20090701

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BENQ CORPORATION

Owner name: BENQ MOBILE GMBH & CO. OHG

GRAC Information related to communication of intention to grant a patent modified

Free format text: ORIGINAL CODE: EPIDOSCIGR1

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: QISDA CORPORATION

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091103