WO2005048102A1

WO2005048102A1 - Device and method for software management in a heterogeneous hardware system

Info

Publication number: WO2005048102A1
Application number: PCT/EP2004/052415
Authority: WO
Inventors: Thorsten SCHÖLER
Original assignee: Benq Mobile Gmbh & Co. Ohg; Benq Corporation
Priority date: 2003-11-13
Filing date: 2004-10-04
Publication date: 2005-05-26
Also published as: EP1683012A1

Abstract

The invention relates to a device and method for software administration in a heterogeneous hardware system comprising an evaluation unit (1) for the production of configuration parameters (KP) according to hardware characteristic data (HW-MD) describing available hardware resources of the heterogeneous hardware system and software request data (SW-MD) describing the required hardware resources for the at least one software module to be processed. An allocation unit (2) distributes software modules (A, B, C) of a software system according to configuration parameters (KP) of the evaluation (1) to various data processing units of the heterogeneous hardware system. As a result, it is possible to obtain optimum placement of software in a complex hardware system.

Description

description

Device and method for software management in a heterogeneous hardware system

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.

The implementation of 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.

In particular, 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. However, this process is time consuming and therefore costly.

In addition, an update of the overall system with new software from a network is of increasing importance, particularly in the case of mobile telecommunication terminals, with optimal software configuration or distribution rarely taking place, particularly for telecommunication terminals with a heterogeneous hardware system.

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.

According to the invention, this object is achieved in terms of the device by the features of patent claim 1 and in terms of the method by the measures of patent claim 14.

in particular through the use of 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, and 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.

If the hardware characteristics of the hardware system are not previously known, a hardware analysis unit can also be provided for analyzing the hardware system and for generating hardware characteristics. In particular in connection with a test assignment of the software modules to be distributed to the hardware system, 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. In this case, energy optimization, an effective processing rate and / or an effective memory availability of the hardware system are preferably considered as hardware optimization data.

Furthermore, 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.

To implement an additional user control of the evaluation unit, 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. Furthermore, 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. As a result, "old" application programs can also be optimally distributed to a hardware system.

Although the software modules preferably have data processing unit-independent program codes such as JAVA ™, 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. In the same way, however, the configuration unit can also be used as a development tool for more efficient software management in heterogeneous hardware systems.

With regard to the method, 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.

Further advantageous configurations of the invention are characterized in the further subclaims.

The invention is described below with reference to exemplary embodiments with reference to the drawing.

Show it:

Figure 1 is a simplified block diagram of an overall system with an inventive device for software management;

Figure 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; and 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.

According to FIG. 1, 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.

To implement such a software system on an actual hardware platform or a hardware system HS, a configuration unit KE is now proposed, which 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.

More precisely, 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. To describe the hardware system HS, this can, for example, be hardware Have characteristic data HW-MD (Hard Ware Meta Data) that describe the existing hardware resources in detail.

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. According to the object-related representation, 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). Furthermore, 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. 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.

In the same way, 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.

According to FIG. 1, in the best case, 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 From these hardware characteristics and software request data, the software modules are appropriately assigned to the available data processing units DV1 to DV3 and the programs can be executed. In the broadest sense, 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. In contrast to conventional processor-based data processing units, in which software is essentially stored in a working memory and then processed, such synthesizing data processing units change their actual appearance, essentially creating new hardware.

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.

According to FIG. 2, 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. In a similar way, 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.

Furthermore, 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.

More precisely, 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.

In this way, using a single software system SS or using a single application program, even with a wide variety of hardware systems HS, an optimal placement of the software or software modules on the available hardware resources and in particular on the available data processing units can be realized. If this configuration unit is used in a development tool for software implementation in heterogeneous hardware systems, the effort for a software implementation can also be significant. lent to be reduced. In addition, when using the configuration unit KE in user terminals, there is increased user convenience, since the tedious comparison between the software requirements and the hardware resources available in the terminal is eliminated.

According to FIG. 2, 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.

In particular to implement hardware optimization, 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.

To implement hardware optimization, 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. Using this test assignment and with the aid of the hardware analysis unit 3, 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.

Taking this additional hardware optimization data HW-OD into account, 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. Using such an optimization or control process, the software management or assignment can accordingly be further optimized, whereby an actual behavior of the hardware system can also be taken into account.

According to FIG. 2, 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. As a result, not only can software modules be optimally distributed within a heterogeneous hardware system, but also beyond a selection or selection of software modules that are alternatively available in a software system SS, for example.

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.

According to FIG. 6, 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.

As available hardware systems, 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. In contrast, 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. As a simplified view, 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). In this example, software module C is embedded on CPUs DVl and DV10. In the same way, 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.

Accordingly, alternative software modules AI and A2 as well as B1 and B2 exist in the software system for realizing the actual MP3 application program. Since the hardware system 1 has a modem hardware with MP3 support, the assignment of the software module B1 to implement a hardware MP3 decoder or driver is completely sufficient, while the hardware system 2 with its standard modem hardware does not enables such implementation. However, since the hardware system 2 has a very powerful application CPU, the selection unit 4 described above, to implement the MP3 player in a terminal with higher-quality performance or equipment, uses the software module A2 and to implement an associated software MP3 decoder the software module B2 placed in the data processing unit DV10.

On the other hand, 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. In this way, 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.

Accordingly, although both terminals are equipped with playback software for MP3 audio files, 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. In addition, according to FIG. 2, 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.

Furthermore, 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. Although usually modern application programs or software systems

SS already have such software request data and deliver it, so to speak, with such a software analysis unit, conventional or “old” application programs that do not contain any software request data can also be selected and assigned.

Programming languages independent of data processing units, such as JAVA ™, 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. In principle, 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. In this context, 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.

According to FIG. 7, 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. As already described above, 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 If a user now installs a new program via the network N on his mobile telecommunications terminal MT, 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. Using 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. In this way, 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.

Although 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.

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.

In a further optional step S2 can be similar

An analysis of the hardware system HS to generate hardware characteristics can be performed.

In 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. In a step S4, 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.

Finally, the software distributed in the hardware system is made executable in a step S6 and the hardware configuration or software implementation is finally completed. The method ends in step S7.

As already described above, before evaluating in step S3, 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.

In this way, a method for the management of software modules is obtained, which enables the software to be optimally placed on the available hardware resources even with different hardware systems. Furthermore, this can reduce the effort required for software implementation during a development phase for a device or overall system, thereby reducing the costs. Finally, there is also increased user convenience, since there is no need for a laborious comparison of predefined software requirements with the respectively available end device or hardware resources.

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.

Claims

claims

1. Device for software management in a heterogeneous hardware system (HS), which has a multiplicity of different data processing units (DVl - DV3) for processing at least one application program with at least one software module (A, B, C) has, with an evaluation unit (1) for generating configuration parameters (KP) as a function of hardware characteristics (HW-MD) that describe the existing hardware resources of the heterogeneous hardware system, and from

Software request data (SW-MD) describing the hardware resources required for the at least one software module (A, B, C) to be processed; and an assignment unit (2) which distributes the at least one software module of the at least one application program to the different data processing units (DV1-DV3) and executes them as a function of the configuration parameters (KP) of the evaluation unit (1).

2. Device according to patent claim 1, a hardware analysis unit (3) for analyzing the hardware system (HS) and for generating the hardware characteristic data (HW-MD).

3. Device according to claim 2, characterized in that the assignment unit (2) first carries out at least one test assignment of the at least one software module, the hardware analysis unit (3) hardware optimization data (HW-OD) depending on of the test assignment carried out, and the evaluation unit (1) also takes the hardware optimization data (HW-OD) into account when generating the configuration parameters (KP).

4. Device according to claim 3, characterized in that the hardware optimization data (HW-OD) indicate energy consumption, an effective processing rate and / or an effective memory availability.

5. Device according to one of the claims 1 to 4, characterized in that the software request data (SW-MD) or the hardware characteristic data (HW-MD) required request data or existing characteristic data for data processing (DV1-DV3), a storage capacity ( Ml) and / or communication channels (CCl).

6. Device according to one of the claims 1 to 5, characterized by a software-off selection unit (4) for selecting at least one software module from a variety of alternative software modules (Al, A2) the at least one application program ^¬ in Depending ness of the configuration parameters (KP) of the evaluation unit (1), whereby only the selected software modules are made available to the assignment unit (2).

7. Device according to one of the claims 1 to 6, a user input unit (5) for realizing an additional user control of the evaluation unit (1).

8. Device according to one of claims 1 to 7, a software analysis unit (6) for analyzing a software system (SS) and for generating the software request data (SW-MD).

9. Device according to one of the claims 1 to 8, so that the at least one software module has a program code that is independent of data processing units.

10. Device according to one of the claims 1 to 8, characterized by an adaptation unit for adapting a data processing unit-specific program code of the at least one software module to the different data processing units and / or the different data processing units to the data processing unit-specific program code of the at least one software module.

11. Device according to one of the claims 1 to 10, d a d u r c h g e k e n n z e i c h n e t that it is implemented in a mobile telecommunications terminal (MT).

12. The device according to claim 11, characterized by a download manager (DM) for downloading software modules (A) and associated software request data (SW-MD) of an external software system (SS) via a download server (DS) in a telecommunications network (N).

13. Device according to one of the claims 1 to 10, d a d u r c h g e k e n n z e i c h n e t that it is implemented in a development tool for heterogeneous hardware systems.

14. Method for software management in a heterogeneous hardware system (HS), which has a multiplicity of different data processing units (DV1-DV3) for processing at least one application program with at least one software module (A, B, C) the steps: a) evaluating hardware characteristic data (HW-MD), which describe existing hardware resources of the heterogeneous hardware system, and software requirement data (SW-MD), the hardware resources required for the at least one to be processed describe processing software module (A, B, C) for generating configuration parameters (S3); b) distributing the at least one software module (A, B, C) as a function of the configuration parameters (KP) to the different data processing units (S5); and c) making the at least one distributed software module (A, B, C) executable in the hardware system (S6).

15. The method as claimed in claim 14, so that prior to step a) the further step a1) analyzing a software system for generating the software request data (S1) is carried out.

16. The method according to claim ^ or 15, d a d u r c h g e k e n n e e c h n e t that before step a) the further step a2) analyzing the hardware system for generating hardware characteristic data (S2) is carried out.

17. The method according to claim 16, characterized in that in step a2) hardware optimization data (HW-OD) are generated as a function of a test assignment of the at least one software module in the hardware system, and in step a) the configuration parameters ( KP) can also be generated as a function of the hardware optimization data generated.

18. The method according to claim 17, so that the hardware optimization data (HW-OD) indicate energy consumption, an effective processing rate and / or an effective memory availability.

19. The method according to any one of the claims 14 to 18, characterized in that the software request data (SW-MD) or the hardware characteristic data (HW-MD) required requirement data or existing characteristic data for data processing, storage capacity and / or communication channels.

20. The method according to any one of claims 14 to 19, d a d u r c h g e k e n n z e i c h n t that before

Step b) the further step bl) selection of at least one software module from a plurality of alternative software modules (AI, A2) of the at least one application program is carried out depending on the configuration parameters of the evaluation unit (S4).

21. The method according to claim 14, so that the at least one software module has a program code that is independent of data processing units.

22. The method according to any one of claims 14 to 20, characterized in that before step b), the further step b2) adapting a data processing unit-specific program code of the at least one software module to the different data processing units and / or the different data processing units on the data processing work unit-specific program code of the at least one software module is carried out.