EP1904923A1

EP1904923A1 - Method and software system for the configuration of a modular system

Info

Publication number: EP1904923A1
Application number: EP06764012A
Authority: EP
Inventors: Bernhard Weichel; Frank Neukam
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2005-07-14
Filing date: 2006-06-30
Publication date: 2008-04-02
Also published as: DE102005032944A1; US20090106546A1; CN101223506A; WO2007006671A1

Abstract

The aim of the invention is to be able to configure a system comprising at least one module in an especially simple and flexible manner. To this end, the inventive method comprises the following steps: at least one configuration file (1) independent of the implementation is created and/or information stored in the at least one configuration file (1) is modified; configuration data stored in a configuration data container (3) is automatically generated and/or automatically updated according to the information stored in the at least one configuration file (1) independent if the implementation; the at least one module is automatically configured according to the configuration data stored in the configuration data container; and configuration rules are used.

Description

Method and software system for configuring a modular system

The invention relates to a method and a software system for configuring a system comprising at least one module (modular system).

State of the art

Under at least one module comprehensive systems (modular systems) are to be understood in particular microprocessor programs of the type described below. In this case, module can be equated with functional unit. The method is not limited to microprocessor programs, but can generally be used to configure modular systems in which individual modules are configured and mated.

Microprocessors are used today in all major technology sectors. Their use is not limited to conventional personal computers (PCs), but also extends to many different electronic devices, such as measuring and control devices, etc., especially in the automotive industry.

Modern microprocessor or computer programs are predominantly programmed in such a way that they th field of application can be used. The scope of application is determined on the one hand by the provided functionalities, which in turn should cover as many user wishes as possible, and on the other by the underlying hardware on which the microprocessor program is to run. The underlying hardware designates different (computer) systems which are used in different areas, constructed of different components (for example processors or bus systems) and / or have different peripheral devices.

Different functionalities may result from different circumstances of the underlying hardware or from different user wishes. A

Adaptation, and thus specialization of a microprocessor program to an underlying hardware and to specific user requests, involves a so-called configuration of the microprocessor program.

A configuration includes, for example, activating or deactivating individual functions of the microprocessor program, setting start values for specific variables, or specifying and specifying certain types of variables.

It is known to declare the variables and functions used in a microprocessor program in a so-called header file and to carry out a configuration of the microprocessor program by modifying individual variables or function identifiers in the header file. For example, it is possible to use a variable used in the microprocessor program and declared in the header file. assign a special function depending on a particular configuration.

Usually, microprocessor programs in a so-called high-level language, for example C, C ++, Scheme or

JAVA, created. Usually, a microprocessor program created in a high-level language is called a source code. In order to be able to execute such a microprocessor program on a microprocessor, a so-called machine code has to be generated from the source code, which contains instructions that can be executed by the processor. Machine code can be generated by so-called interpreting or compiling the source code.

Typically, a microprocessor program includes a

Variety of functional units. The source code of one or more functional units is stored in a file. One or more such files are associated with a header file. Thus, a microprocessor program typically consists of a variety of files. A configuration of such a microprocessor program, which is carried out by changes within individual header files, is therefore very confusing and can often only be performed by the creator of the source code. In addition, a documentation of all header files must be created, which is very expensive, even the documentation is usually very confusing.

It is also known to assign a special functional unit to the configuration of a microprocessor program, by means of which a configuration of the entire microprocessor program is possible, for example by changing the values of predetermined parameters. The functional unit can be made, for example, from the running microprocess process. and executed to configure the microprocessor program. However, such a functional unit provided for the configuration of the microprocessor program permits only a configuration within predetermined range limits. A configuration of the microprocessor program, for example, to adapt the microprocessor program to a new hardware or to adapt the microprocessor program to new user wishes is not possible with such a functional unit. Furthermore, the functional unit used for configuration must be specially designed for the particular microprocessor program and can not be used for other microprocessor programs.

A first approach to overcoming these problems is described by the Applicant in the earlier, not pre-published 10 2004 005 730.3. In the method described, the configuration of a microprocessor program is improved and a resource-optimized implementation is achieved by providing an abstract description of the configuration to be executed between a user (configurator) and the microprocessor program in an implementation-independent configuration file on which the configuration is based. The implementation-independent configuration file automatically creates an implementation-dependent configuration file, which is then used to configure the microprocessor program. In order to ensure that the configuration process and, finally, the microprocessor program are error-free, multiple check processes are carried out during the creation of the implementation-dependent configuration files. The creation and integration of these test processes is difficult and expensive, especially since these are generated and programmed in program code. It is therefore the task to further simplify the configuration of microprocessor programs and to make it as clear and flexible as possible. This object is achieved by a method according to patent claim 1 and a system according to patent claim 13 as well as a corresponding software system product and a corresponding computer unit.

Advantages of the invention

The configuration-determining data is stored in one or more implementation-independent configuration files independently of an intended concrete implementation. The implementation independence of this configuration file allows in particular an abstract description of the stored information. This makes it possible to store the information relevant to the configuration of the microprocessor program in an especially legible manner and thus to simplify the configuration considerably. In particular, by making this configuration file independent of implementation, it is possible to easily implement a configuration of the microprocessor program so that the microprocessor program can run on a new computer system whose exact parameters are not yet known when the microprocessor program is created.

The configuration data container makes it possible to centrally store all data relevant for a configuration.

By means of the configuration data stored in the configuration data container, the at least one module is automatically configured. According to one embodiment of the method according to the invention, it is provided that at least one implementation-dependent configuration file is automatically generated by means of the configuration data stored in the configuration data container, wherein the automatic configuration of the at least one module is performed depending on information stored in the at least one implementation-dependent configuration file.

In each of the embodiments of this step, there is a concretization of one or more parameter values with respect to the implementation-independent configuration file. With such a specification, for example, relative values are replaced by absolute values. Likewise, individual data types or data areas can be assigned specific data types or structures.

The implementation-dependent configuration file takes into account implementation-dependent properties, such as one or more programming languages used in programming the source code, or properties of the hardware on which the microprocessor program is to run.

The configuration or updating of the configuration data container by means of the information stored in the implementation-independent configuration files can be carried out, for example, by means of so-called scripts. A script is a sequence of commands that can be executed by a special microprocessor program. Such special microprocessor programs are for example AWK or Perl. These special microprocessor programs can also be used in order to generate implementation-dependent configuration files or the configuration of the module from the configuration data stored in the configuration data container.

Furthermore, configuration rules are used in the method according to the invention. Typically, each configuration parameter has one or more configuration rules associated with it. For example, in the configuration rules, you can specify which data sources or groups of data sources are valid, necessary, or prohibited for a particular configuration parameter. When using the method for complex software systems, among data sources, in particular the components, e.g. Configuration data to understand this software system. In the automotive field, possible data sources for configuration data are software components, e.g. Lambda control, accelerator pedal conditioning, diagnostic system, etc. When specifying the valid data sources, quantity specifications such as "all sources without distinction" or "component X plus all subcomponents" be provided. The configuration rules stipulate in particular how the individual configuration parameters are to be designed in terms of form and content. Overall, this measure according to the invention makes it possible in a particularly simple way to avoid complex and distributed test processes and instead to implement them centrally and once (and thus consistently).

The comparison of the configuration parameters with the configuration rules can also be carried out by means of suitable scripts. The use of centralized configuration rules provides extensive capabilities for formal definition of the properties and constraints of configuration parameters. Thus, many and detailed Tests in a central place possible and intended. In contrast to previously described solutions, in which test runs had to be carried out and programmed separately in the respective scripts, a processor or script can now perform a control, structure and / or cross-reference check at a central location. The inventive measure, a transfer away from program code to rules is performed. By handling the configuration rules as part of a component interface (interface), extensive interface checks are performed as well

Visibility restrictions enabled. Conflicts in the exchange of individual components can be detected early and avoided.

An essential component of the invention is thus the recognition that the configuration of a modular system, in particular a microprocessor program, can be decisively improved by providing an abstract description of the configuration to be executed in the implementation-independent configuration file between a user (configurator) and the system is, which is based on the configuration. By using configuration rules, the configuration parameters can already be checked at an early time of the procedure, which advantageously reduces the effort required for this.

The implementation-independent configuration file can be used to automatically create an implementation-dependent configuration file, which is then used to configure the system. The system can also be configured without physically creating such files. Since the configuration parameters are subject to predetermined configuration rules, a simple and flexible adaptation to predetermined external parameters can be achieved become. The method according to the invention thus makes it possible to specify the information describing a configuration abstractly and thus particularly legibly. Due to the independence of any implementation details, a particularly high level of flexibility is achieved, which remains manageable and manageable due to the configuration rules.

Furthermore, there is the advantage of a decentralized configuration. For example, For example, the properties of a multichannel measuring system can be centrally stored not only centrally in a configuration file assigned to this measuring system, but also channel-specifically in a plurality of implementation-independent configuration files assigned to the respective sensors / channels. In the container, this information is then collected and can be evaluated centrally by scripts.

In addition, for example, in a work-sharing process, the configuration rule files lead to a secure handling of the implementation-independent configuration files. In particular, configuration elements with different configuration rule files can be contained in an implementation-independent configuration file, as a result of which the configuration requirements of various modules can be processed in bundled form.

In a particularly preferred embodiment of the method according to the invention, the configuration rules for automatic construction and / or automatic updating of the stored in the configuration data container configuration data and / or in the automatic configuration of the at least one module depending on the stored in the configuration data container Configuration data and / or the automatic generation of an implementation-dependent configuration file depending on the configuration data stored in the configuration data container used. It can also be provided to use the configuration rules already when creating the implementation-independent configuration files, as described below using the example of a configuration file editor. At the points mentioned, the integration of the configuration rules is particularly easy to perform. Here, therefore, a particularly favorable cost-benefit factor is achieved.

It is expedient if the configuration rules are stored in at least one configuration rule file. It makes sense to provide several configuration rule files, for example a configuration rule file for each functional unit or a configuration rule file for each configuration file. In such a configuration rule file, rules for the configuration parameters of the assigned functional unit are stored. This allows a high degree of clarity can be achieved. The individual rule files are expediently combined during the configuration process to form a central rule file. It goes without saying that likewise only one configuration rule file can be provided for all configuration parameters to be treated.

In a preferred embodiment of the method, at least one configuration rule is assigned to a configuration parameter, the configuration rule describing an authorization for processing the configuration parameter, a formal property, an existence-determining property or a value-determining property of the configuration parameter. As will be described below, as a further tere advantageous embodiment of the method according to the invention provided a configuration by dependency information. It is useful if this configuration rules are provided for a (processing) authorization. In this way, a hierarchy within the configuration parameters can be defined in a simple manner, which describes a mutual variability. In particular, it is possible to regulate which configuration parameter can or may be described or changed by which other configuration parameters. It makes sense to describe further properties of configuration parameters by configuration rules, such as

- a default value, which is used as a substitute value if no value was specified for a parameter; Thus, all configuration data processing downstream processes can rely on the existence of a configuration value;

a specification of valid reference targets if the associated configuration parameter represents a list of key-different sets of configuration settings;

- a permissible value range (eg minimum / maximum value, increment [eg only values 0, 0.1, 0.2, etc.], minimum / maximum text length for textual parameters, specified text type (eg iso date), sufficient for a specific text pattern Text or one of several predefined texts identical text);

- a rule to automatically convert one value into another; a conversion formula from an abstract / physical representation of a value into an internal representation and / or vice versa;

an indication of how a configuration value is to be displayed, for example, on a display (e.g., format string in a printf format);

a binding to another system property, e.g. a variable in a software system or microprocessor program, or a hardware property or resource;

a unit of the configuration value;

- a handling of blanks and page breaks in textual information.

For each configuration parameter, individual, several or all of the mentioned rules and others can be provided. By these measures, the degree of automation can be increased particularly well and a reliable configuration of the microprocessor program can be achieved. If a module or a functional unit, for example, provides for the acquisition of measured values, the associated rule can describe which sensors are provided by the hardware and which measuring accuracy is available. The parameter can only be set within these rules.

In an advantageous development of the method, at least one dependency information which describes a dependency of at least two configuration data present in the configuration data container is automatically generated. The at least one implementation-dependent The configuration file is generated depending on the at least one dependency information.

For example, dependency information can describe whether changing one configuration parameter affects another configuration parameter. If, for example, a resource is exclusively reserved for a module, it is not available to other functional units during the execution of the module / functional unit. Dependency information can be used to determine which functional units need a specific resource and thus can not run at the same time. Dependency information can therefore also be used for resource management. The dependency information is used to forward (forwarding) configuration information. During forwarding, a configuration processing instance assigned to a particular component derives configurations of other components from configuration requests or fine adjustments made to it by means of a freely selectable algorithm and forwards these settings thus determined to these other components. This advantageous measure can be used in particular for the automatic configuration of subcomponents. It is also a good idea to leave the intention of forwarding in configuration rules in order to be able to test before the time of the actual configuration whether circular routing (parameter A configures parameter B, which in turn configures parameter A) may result from this forwarding of configuration data , By storing them in configuration rules, dependencies between the individual components are formally described and are therefore available to other, further processing processes. In addition to the described procedure, forwarding can also provide a pending procedure. In a forwarding forwarding, a specification of a setting of a particular configuration parameter is made not only from a constant date, but also advantageously from a (possibly complex and / or conditional) expression containing references to the settings of other parameters. It is also advantageous to make a specification of a configuration parameter as a whole (ie the existence of this specification) in turn dependent on the setting of other configuration parameters - or possibly any complex expressions consisting of such settings. By using configuration rules, the forwarding order can be determined automatically, which enables the detection of possible loopholes already at the time of the interface check.

In a preferred embodiment of the method, a plurality of implementation-independent configuration files are created and each of the implementation-independent configuration files is assigned to at least one module or functional unit. This allows a particularly simple configuration in that the configuration parameters stored as information in the implementation-independent configuration files can be found and changed particularly easily. For example, it is possible to arrange the configuration-determining information, that is to say the configuration parameters, according to the functionality or hardware influenced by them. Furthermore, this allows a particularly simple adaptation of the implementation-independent configuration files to newly added functional units. In the simplest case, a newly added functional unit becomes a special implementation-independent configuration file and, for example, associated with a configuration rule file. Advantageously, several implementation-dependent configuration files are generated and each of the implementation-dependent configuration files is assigned to at least one functional unit. Such a structuring of the implementation-dependent configuration files increases the clarity of the generated implementation-dependent configuration files. If the source code is structured in such a way that one or more functional units are located in different files, then it can be achieved that each of the files of the source code is assigned an implementation-dependent configuration file. A particularly clear structuring can also be achieved by assigning an implementation-dependent configuration file to each implementation-independent configuration file.

Preferably, the at least one implementation-dependent configuration file is generated as a function of at least one property of a hardware on which an installation of at least part of the configured modular system as a microprocessor program is to be made possible. Such a hardware property may be, for example, the number of available processors or the type and number of sensors connected to the hardware. If such hardware properties are taken into account in the generation of the implementation-dependent configuration files, a particularly precise configuration of the microprocessor program can take place. This makes it possible, for example, to automatically create a configuration that is optimized with regard to execution speed and resource consumption, in particular with dependency information. In a further preferred embodiment, a documentation is automatically created. The documentation describes the information stored within the at least one implementation-independent configuration file and / or the at least one implementation-dependent configuration file and / or the configuration rules and / or the at least one configuration rule file. Such automatically generated documentation increases the maintainability of the microprocessor program on the one hand, and on the other hand, it makes it particularly easy to easily plan and prepare a configuration and to understand an executed configuration. The automatic generation of the documentation ensures that it matches the actual configuration or configuration rules. If a new configuration of the modular system is to be carried out, such documentation can be used to determine particularly simply which parameter values must or must be changed and which rules are subject to these.

It is expedient if in the method according to the invention for creating and / or changing the at least one implementation-independent configuration file a microprocessor program is used that takes into account the configuration rules. Such a computer or microprocessor program can be designated, for example, as a configuration file editor, which adequately describes the functionality for the person skilled in the art. By using the configuration rules already during the creation of the configuration files, the conformity of the configuration parameters with the configuration rules can be ensured right from the start. be ensured. Subsequent revision can be avoided.

Preferably, the at least one implementation-independent configuration file and / or the at least one configuration rule file is created in an XML-based format. XML (Extensible Markup Language) is a standardized metalanguage that allows you to create structured languages. If the at least one implementation-independent configuration file and / or the at least one configuration rule file are created in an XML-compliant, structured language, a configuration is facilitated by the fact that such a file is particularly easy to read. Furthermore, such a file is also particularly machine-readable. In particular, there are a large number of software tools (tools), some of which are also standardized, by means of which it is possible to process and process files created in an XML-based format.

In a preferred embodiment of the method, depending on the configuration data, it is automatically determined whether a module included in the modular system is needed by the modular system and configuration of that module is performed only if the module is needed by the modular system. This makes it possible to perform a configuration particularly quickly by actually configuring only such modules / functional units as are actually needed in an execution of the configured system. Furthermore, this ensures that the configured system takes up as little space as possible in the case of a microprocessor program, since, for example, a translation of source code into machine code is only possible for such a case. which functional units are to be actually used.

Advantageously, the method according to the invention is used to configure a microprocessor program. However, it may in principle be used to configure any systems consisting of modules (e.g., text, information, mechanical components, etc.).

The object is also achieved by a software system of the type mentioned. In this case, the software system, in particular a computer or microprocessor program, has:

- at least one configuration rule file;

- at least one implementation-independent configuration file;

a configuration data container having configuration data and / or means for creating a configuration data container as a function of information stored in the at least one implementation-independent configuration file;

- means for changing and / or reading configuration data from the configuration data container;

- Means for automatically configuring the at least one module in response to stored in the configuration data container configuration data.

In a preferred embodiment, the means for automatically configuring the at least one module depend on configuration data stored in the configuration data container:

Means for automatically generating at least one implementation-dependent configuration file as a function of configuration data stored in the configuration data container; and Means for automatically configuring the at least one functional unit in dependence on information stored in the implementation-dependent configuration file.

The software system preferably has means for carrying out the method according to the invention, in particular if the software system is executed on a computer, a microprocessor or a corresponding computer unit, in particular the computer unit according to the invention.

The realization of the invention in the form of a software system is of particular importance here. In this case, the software system can run on a computing device, in particular on a microprocessor, and is suitable for carrying out the method according to the invention. In this case, therefore, the invention is realized by the software system, so that the software system represents the invention in the same way as the method for the execution of which the software system is suitable.

Another software system or computer program according to the invention has program code means in order to create or modify configuration-independent configuration files taking account of configuration rules (configuration file editor).

The software system is preferably stored on a storage element (storage medium, data carrier). The storage element can be designed as random access memory, read-only memory or flash memory. The memory element can also be designed as a digital versatile disc (DVD), a compact disc (CD) or a hard disk (hard disc). A software system product according to the invention, in particular a computer or microprocessor program product, contains program code means which are stored on a memory element, in particular a machine-readable or computer-readable data carrier. Suitable data carriers are, in particular, floppy disks, hard disks, flash memories, EEPROMs, CD-ROMs, DVDs, RAM, ROM, etc. It is also possible to download a program via computer networks (Internet, intranet, etc.).

A computer unit according to the invention, in particular a control unit, has a microprocessor and is programmed to carry out a method according to the invention.

It is expedient to use a method according to the invention, a software system according to the invention, a software system product according to the invention or a computer unit according to the invention in the field of motor vehicle construction. It is understood that the use is not limited thereto.

Further advantages and embodiments of the invention will become apparent from the description and the accompanying drawings.

It is understood that the features mentioned above and those yet to be explained below can be used not only in the particular combination given, but also in other combinations or in isolation, without departing from the scope of the present invention.

The invention is illustrated schematically with reference to an embodiment in the drawing and will be described below in detail with reference to the drawings.

figure description FIG. 1 shows an embodiment of a software system for carrying out the method according to the invention; and

Figure 2 is a schematic flow diagram of an embodiment of the method according to the invention.

FIG. 1 shows a software system for carrying out the method according to the invention. The software system has several implementation-independent configuration files 1. Each configuration file 1 is assigned a file name. The implementation-independent configuration files illustrated in FIG. 1 carry, for example, the file names conf.sub.xml, conf.sup.2.xml, conf 3.xml to conf.sub.n. xml. The software system also has several configuration rules files Ib. Each configuration rule file Ib is assigned a file name. The configuration rule files shown in FIG. 1 bear, for example, the file names rule 1.xml, rule 2.xml, rule 3.xml to rule x. xml. The file extension xml indicates that the implementation-independent configuration files 1 and the configuration rules files Ib are present in an XML-based format. A text file in an XML-based format makes it possible to structure the text file according to specifiable rules. Such a structured text file can be read and processed particularly well manually and by machine.

The implementation-independent configuration files 1 and the configuration rules files Ib are fed to a script 2. The script 2 is designed, for example, as a so-called Perl script. Perl is an interpreter language whose syntax is based on the C programming language and the used by the respective operating system provided utilities.

By means of the script 2, the implementation-independent configuration files 1 are read and the information stored therein is extracted and stored in a configuration data container 3. The extraction of the configuration information or parameters takes place taking into account the configuration rules from the configuration backup files Ib. If configuration parameters contradict the configuration rules, this can already be detected and criticized at an early stage of the configuration. For this purpose, for example, the configuration rule files or Script 2 may contain corresponding notes or error texts which are output when a corresponding rule or a rule type is violated. At the same time, any existing dependencies on further configuration scripts 4 are determined and stored (forwarding). The arrangement of the configuration rule files Ib within the software system can be seen as an example. The configuration rules files Ib can be assigned to the scripts 4 in another embodiment of the software system, for example.

The further configuration scripts 4 are also, for example, Perl scripts. It is also conceivable that one or more of the further configuration scripts 4 is an executable microprocessor program (machine code) or is present in another scripting language, for example AWK.

The reference numeral 5 denotes implementation-dependent configuration files. The implementation-dependent configuration files 5 are, for example, in the Pro coded in which also the source code to be configured is programmed. Such implementation-dependent configuration files can be processed by a compiler 6.

The reference numeral 7, a microprocessor program is shown, which has a plurality of functional units 8. The operation of the software system according to the invention will be described with reference to the flowchart shown in FIG.

The flow chart of a method according to the invention for configuring a microprocessor program shown in FIG. 2 starts in a step 100. In a step 101, implementation-independent configuration files 1 are created or changed. The implementation-independent configuration files 1 are characterized in particular by the fact that it is possible to abstractly describe concrete configuration values or configuration parameters by means of the information stored there. Concrete configuration values can for example determine the measuring range of a sensor module for measuring an electrical voltage. For example, it is possible to specify a measuring range abstractly with the values 3 - 5 volts. However, the implementation-dependent values of the measuring range to be generated therefrom, as expected by the functional unit 8 to be configured, can be, for example, between 10,000 and 20,000. In this case, a functional unit 8 of the microprocessor program controlling the sensor module would have to be configured, for example, by means of the concrete configuration values 10,000 and 20,000 in order to enable a measurement in a measuring range of 3-5 volts. In addition, the configuration rule files Ib (rule l.xml to rule x.xml in FIG. 1) are also available to the method. Conventionally, the configuration rule files Ib are not created or changed each time the method is performed. The configuration rules files Ib describe the formal and content-related properties of the configuration parameters.

The implementation-independent configuration files 1 created or modified in step 101 and the configuration rules files 1b are created, for example, in an XML-based format. Such a format makes it particularly well possible to achieve a clear structuring of the implementation-independent configuration files 1 and of the configuration rules files 1b. This increases the readability of the implementation-independent configuration files 1 and the configuration rule files Ib and simplifies the change of the implementation-independent configuration files 1, for example, by allowing configuration data to be changed to be found quickly. It is possible to provide only a single implementation-independent configuration file or configuration rule file, even for a particularly large microprocessor program whose configuration requires a large number of configuration data. A structuring of the information stored in the implementation-independent configuration file 1 and the configuration rules stored in the configuration rule file Ib can be achieved by means of suitable XML structures. However, it is particularly advantageous to provide a plurality of implementation-independent configuration files and configuration rule files. Each of these implementation-independent configuration files 1 and configuration rules files 1 b can, for example, be assigned to one or more functional units. 8 be assigned. This makes it possible to carry out the creation or modification of the implementation-independent configuration files and configuration rule files particularly clearly. Furthermore, this increases the reusability of individual implementation-independent configuration files and configuration rule files. This is particularly advantageous for projects in which individual functional units 8 of the source code are to be reused.

In a step 102, the instructions listed in Script 2 are executed. Script 2 causes the independent configuration files 1 and configuration rules files Ib to be read. If the implementation-independent configuration files 1 and / or the configuration rules files 1 b are based on a structured format, for example an XML-based format, the syntax of the script 2 can be used to syntactically and / or semantically analyze the contents of the implementation-independent configuration files 1 and / or the configuration rule files Ib are performed. This can be used to detect (file) errors when specifying configuration data (missing characters, too many characters, wrong characters, etc.). Preferably, the XML-based format of the implementation-independent configuration files 1 and the configuration rules files Ib has a hierarchical structure, which is advantageously based on the structure of the functional units 8 themselves, their dependencies and / or their thematic proximity. Script 2 can be used to detect errors in the structure of this hierarchical structure and thus in the structure of the source code itself. Advantageously, step 102 includes a treatment of the errors found. This can be done for example by the output of error information. It is also conceivable that stochastic methods for eliminating errors can be used.

In step 102, the configuration parameters are also checked based on the configuration rules. In particular, it is checked whether the configuration parameters correspond in form and content to the associated configuration rules. If this is not the case, the method branches back to step 101, in which a change of the implementation-independent configuration files 1 is carried out with the purpose of a fault elimination. If no errors are detected in step 102, a branch is made to step 103 in which the configuration data container 3 is set up or updated.

In step 103, the script 2 extracts the configuration data present in the implementation-independent configuration files 1 and stores these in the configuration data container 3. The configuration data container 3 can be designed, for example, as a database. It is also conceivable that the configuration data container 3 is realized as a data structure held within a memory area within the software system according to the invention, it being ensured that the script 2 has write and read access to the configuration data stored in the configuration data container 3.

Dependencies are determined in a step 104. Such a dependency can for example describe which functional units 8 of the microprocessor program are involved actually have to be processed in the present configuration. By means of these dependencies it can be decided whether an implementation-dependent configuration file has to be generated in any of the following steps for a specific functional unit 8. Dependencies may also describe which specific configuration data depends on which abstract configuration data. Thus, it is conceivable that changing an abstract configuration data in an implementation-independent configuration file causes a change of a plurality of concrete configuration data.

Dependencies can also arise if the further scripts 4 in turn change the configuration container 3. Thus, the correct call sequence (activation sequence) of the scripts 4 must be determined and stored. Dependencies can also describe relationships between one or more hardware components and individual configuration data. This makes it possible, for example, to detect whether an intended configuration is actually executable on a specific hardware.

In a step 105, the implementation-dependent configuration files 5 are generated. For this purpose, the configuration data stored in the configuration data container 3 are first retrieved by means of a script 4 or a plurality of scripts 4. In the present embodiment, the scripts 4 are formed as Perl scripts. By means of the scripts 4, abstract configuration data stored in particular in the configuration data container 3 are converted into concrete configuration data, which are then stored in the implementation-dependent configuration files 5. Preferably, the dependencies determined in step 104 are also used. The implementation-dependent configuration files 5 generated in step 105 can be, for example, header files (file lh, file 2.h, file 3.h in FIG. 1). Likewise, the generated implementation-dependent configuration files 5 may also contain source code (file_2.c, file kc in FIG. 1). Typically, the specific configuration data generated by the scripts 4 from the abstract configuration data are realized by value assignments for variables and / or function parameters and as instructions in a programming language. The programming language corresponds to the programming language in which the functional units 8 of the microprocessor program 7 are coded. If the functional units 8 of the microprocessor program 7 are coded, for example, in the programming language C ++, then the specific configuration data can be realized for example by so-called define instructions or by the definition of constant variables. By means of the scripts 4, it is also possible, depending on the configuration data stored in the configuration data container 3, to generate functions which take over complex tasks, such as the initialization of hardware components or the test for the presence of individual software components or hardware components, and even as a source Code are realized in a higher programming language. This source code can then be stored in one or more implementation-dependent configuration files (file 2.c, file kc in FIG. 1). For this purpose, a script 4 may, for example, contain a so-called template, which consists for example of instructions in C ++, which are updated as a function of the configuration data stored in the configuration data container 3 and stored in an implementation-dependent configuration file 5. In a step 106, the functional units 8 of the microprocessor program 7 are updated. This can be done for example by the automatic call of a compiler 6, the present in a source code

Function units 8 translated into a machine code. For this purpose, the compiler 6 reads in the implementation-dependent configuration files 5 and controls the generation of the machine code as a function of the specific configuration data stored in the implementation-dependent configuration files 5. It is also conceivable that one or more functional units 8 are already present in machine code. In this case, the compiler can, for example, copy the source code generated by the scripts 4 (file 2.c, file kc in FIG. 1), taking into account the header files (file lh, file 2.h, file 3.h). translate into machine code and connect the machine code thus translated by means of a so-called linker assigned to the compiler 6 with the machine code representing the functional units 8.

In a step 107, the method ends. In this step, the microprocessor program 7 is configured such that the concrete configuration data stored in the implementation-independent configuration files are taken into account in the generated machine code.

It is possible that the script 2 and / or the scripts 4 are written in a different scripting language or are designed as executable programs. It is also possible to use the configuration rules only in connection with the scripts 4. It is understood that the execution steps shown in FIG. 2 can vary and the order of execution can be partially changed. In particular, the method can also start from one or more implementation-independent configuration files, have one or more scripts 2 that are executed, for example, one behind the other, have one or more scripts 4, each generating one or more implementation-dependent configuration files 5; processor program 7 have one or more functional units 8. With the method according to the invention, it is in particular possible to detect whether one or more of the functional units 8 are actually used in the configuration prescribed by the implementation-independent configuration files. Is not this the

Case, this can be detected by the configuration data container 3 associated, not shown software tool. This makes it possible that such a functional unit 8 is not configured and that the compiler 6 is caused by means of the implementation-dependent configuration files 5 not to take the functional unit 8 into the machine code to be generated. As a result, the method according to the invention can be carried out particularly quickly. The machine code generated by a microprocessor program which has been configured by means of the method according to the invention can be particularly compact and thus save storage space.

It is possible that the script 2 itself already causes the creation of one or more implementation-dependent configuration files 5. As a result, the method according to the invention can be carried out particularly quickly. This can be advantageous, for example, for abstract configurations. be ration data, which have no dependencies and differ from the concrete configuration data.

Claims

claims

1. A method for configuring a system comprising at least one module (modular system), in particular a microprocessor program, the following steps are included in the following:

Creating at least one implementation-independent configuration file (1) and / or changing information stored in the at least one implementation-independent configuration file (1);

Automatic construction and / or automatic updating of configuration data stored in a configuration data container (3) as a function of the information stored in the at least one implementation-independent configuration file (1);

Automatic configuration of the at least one module as a function of the configuration data stored in the configuration data container (3); Using configuration rules.

2. The method according to claim 1, characterized in that the step:

Automatic configuration of the at least one module as a function of the configuration data stored in the configuration data container (3); the following steps include:

Automatic generation of at least one implementation-dependent configuration file (5) depending on speed of the configuration data stored in the configuration data container (3);

Automatic configuration of the at least one module as a function of information stored in the at least one implementation-dependent configuration file;

3. The method according to any one of the preceding claims, characterized in that the configuration rules in the automatic construction and / or automatic updating of the stored in a configuration data container (3) configuration data and / or in the automatic configuration of the at least one module depending on in the Configuration data container (3) stored configuration data and / or the automatic generation of at least one implementation-dependent configuration file (5) depending on the configuration data in the container (3) stored configuration data can be used.

4. The method according to any one of the preceding claims, characterized in that the configuration rules are stored in at least one configuration rule file (Ib).

5. The method according to any one of the preceding claims, characterized in that a configuration parameter is associated with at least one configuration rule, wherein the configuration rule describes an authorization for editing the configuration parameter, a formal property, an existence-determining property or a value-determining property of the configuration parameter.

6. The method according to any one of the preceding claims, characterized in that at least one dependency information is automatically generated, which describes a dependency of at least two present in the configuration data container configuration data, and that the at least one implementation-dependent configuration file is generated in dependence of at least one dependency information.

7. The method according to claim 1, wherein the modular system has a plurality of modules, characterized in that a plurality of implementation-independent configuration files are created and each of the implementation-independent configuration files is assigned to at least one module.

8. The method according to claim 1, wherein the at least one implementation-dependent configuration file is generated as a function of at least one property of a hardware on which an installation of at least part of the configured modular system is to be made possible as a microprocessor program ,

9. The method according to any one of the preceding claims, characterized in that automatically a documentation is created and the documentation within the at least one implementation-independent configuration file and / or the at least one implementation-dependent configuration file and / or the configuration rules and / or the at least one The configuration rule file describes stored information.

10. The method according to any one of the preceding claims, character- ized in that for creating and / or changing the at least one implementation-independent configuration file, a microprocessor program is used that takes into account the configuration rules.

11. The method according to any one of the preceding claims, characterized in that the at least one implementation-independent configuration file and / or the at least one configuration rule file is created in an XML-based format.

12. The method according to any one of the preceding claims, characterized in that it is automatically determined depending on the configuration data, whether a module of the modular system module is required by the modular system and a configuration of this module is performed only if the module needed by the modular system.

13. Use of a method according to any one of the preceding claims for the configuration of a microprocessor program.

14. Software system for configuring a system comprising at least one module (modular system), characterized in that the software system comprises:

at least one configuration rule file; at least one implementation-independent configuration file; a configuration data container having configuration data and / or means for creating a configuration data container as a function of information stored in the at least one implementation-independent configuration file; Means for changing and / or reading configuration data from the configuration data container; and - means for automatically configuring the at least one module in dependence on configuration data stored in the configuration data container; The software system according to claim 13, wherein the means for automatically configuring the at least one functional unit depend on configuration data stored in the configuration data container:

Means for automatically generating at least one implementation-dependent configuration file as a function of configuration data stored in the configuration data container; and

Means for automatically configuring the at least one module in response to information stored in the implementation-dependent configuration file.

15. Software system according to claim 13 or -, characterized in that the software system comprises means for performing a method according to one of claims 1 to 12.

16. Software system with program code means to implement in consideration of configuration rules create or modify configuration-independent configuration files.

17. Software system product, characterized in that a software system according to one of claims 13 to 15 is stored on a memory element.

18. Computer unit, in particular control unit, which has a microprocessor, characterized in that the computer unit for performing a method according to one of claims 1 to 12 is programmed.

19. Use of a method, a software system, a software system product or a computer unit according to one of the preceding claims in the field of motor vehicle construction.