EP1904923A1 - Verfahren und softwaresystem zur konfiguration eines modularen systems - Google Patents

Verfahren und softwaresystem zur konfiguration eines modularen systems

Info

Publication number
EP1904923A1
EP1904923A1 EP06764012A EP06764012A EP1904923A1 EP 1904923 A1 EP1904923 A1 EP 1904923A1 EP 06764012 A EP06764012 A EP 06764012A EP 06764012 A EP06764012 A EP 06764012A EP 1904923 A1 EP1904923 A1 EP 1904923A1
Authority
EP
European Patent Office
Prior art keywords
configuration
implementation
file
configuration data
stored
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP06764012A
Other languages
English (en)
French (fr)
Inventor
Bernhard Weichel
Frank Neukam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP1904923A1 publication Critical patent/EP1904923A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • microprocessor programs in a so-called high-level language for example C, C ++, Scheme or
  • 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.
  • 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.
  • 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.
  • 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.
  • multiple check processes are carried out during the creation of the implementation-dependent configuration files.
  • the configuration data container makes it possible to centrally store all data relevant for a configuration.
  • 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 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.
  • the integration of the configuration rules is particularly easy to perform. Here, therefore, a particularly favorable cost-benefit factor is achieved.
  • 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;
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Um ein mindestens ein Modul umfassendes System besonders einfach und flexibel zu konfigurieren, wird ein Verfahren vorgestellt, das die folgenden Schritte aufweist: Erstellen mindestens einer implementierungsunabhängigen Konfigurationsdatei (1) und/oder Ändern von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei (1) abgelegten Informationen; Automatischer Aufbau und/oder automatische Aktualisierung von in einem Konfigurationsdatencontainer (3) abgelegten Konfigurationsdaten in Abhängigkeit von den in der mindestens einen implementierungsunabhängigen Konfigurationsdatei (1) abgelegten Informationen; Automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten; Verwenden von Konfigurationsregeln.

Description

Verfahren und Softwaresystem zur Konfiguration eines modu- laren Systems
Die Erfindung betrifft ein Verfahren sowie ein Softwaresystem zur Konfiguration eines mindestens ein Modul umfassenden Systems (modulares System) .
Stand der Technik
Unter mindestens ein Modul umfassenden Systemen (modulare Systeme) sind insbesondere Mikroprozessorprogramme der nachfolgend beschriebenen Art zu verstehen. In diesem Fall kann Modul mit Funktionseinheit gleichgesetzt werden. Das Verfahren ist aber nicht auf Mikroprozessorprogramme beschränkt, sondern kann allgemein zur Konfiguration von mo- dularen Systemen verwendet werden, bei denen einzelne Module konfiguriert und zusammengefügt werden.
Mikroprozessoren kommen in der heutigen Zeit in allen wesentlichen Technologiesparten zum Einsatz . Ihre Verwendung beschränkt sich dabei nicht auf herkömmliche Personal Computer (PCs), sondern erstreckt sich darüber hinaus auf viele unterschiedliche elektronischen Geräte, beispielsweise Mess-, Steuergeräte usw., insbesondere im Automobilbau.
Moderne Mikroprozessor- bzw. Computerprogramme werden überwiegend so programmiert, dass sie in einem möglichst brei- ten Anwendungsbereich einsetzbar sind. Der Anwendungsbereich wird einerseits durch die zur Verfügung gestellten Funktionalitäten, die wiederum möglichst viele Benutzerwünsche abdecken sollen, und andererseits durch die zugrunde- liegende Hardware, auf der das Mikroprozessorprogramm ablaufen soll, bestimmt. Die zugrundeliegende Hardware bezeichnet hierbei unterschiedliche (Computer-) Systeme, die in unterschiedlichen Bereichen eingesetzt werden, aus unterschiedlichen Komponenten (beispielsweise Prozessoren o- der Bussystemen) aufgebaut sind und/oder über unterschiedliche Peripheriegeräte verfügen.
Unterschiedliche Funktionalitäten können sich aus unterschiedlichen Gegebenheiten der zugrundeliegenden Hardware oder aus unterschiedlichen Benutzerwünschen ergeben. Eine
Anpassung und damit eine Spezialisierung eines Mikroprozessorprogramms an eine zugrundeliegende Hardware und an bestimmte Benutzerwünsche umfasst eine sogenannte Konfiguration des Mikroprozessorprogramms.
Eine Konfiguration umfasst beispielsweise das Aktivieren oder Deaktivieren einzelner Funktionen des Mikroprozessorprogramms, das Setzen von Startwerten für bestimmte Variablen oder das Vorgeben und Spezifizieren bestimmter Vari- ablentypen.
Es ist bekannt, die in einem Mikroprozessorprogramm verwendeten Variablen und Funktionen in einer sogenannten Header- Datei zu deklarieren und eine Konfiguration des Mikropro- zessorprogramms durchzuführen, indem einzelne Variablen o- der Funktionsbezeichner in der Header-Datei verändert werden. Beispielsweise ist es möglich, einem in dem Mikroprozessorprogramm verwendeten und in der Header-Datei dekla- rierten Funktionsbezeichner in Abhängigkeit von einer bestimmten Konfiguration eine spezielle Funktion zuzuweisen.
Üblicherweise werden Mikroprozessorprogramme in einer soge- nannten Hochsprache, beispielsweise C, C++, Scheme oder
JAVA, erstellt. Üblicherweise wird ein in einer Hochsprache erstelltes Mikroprozessorprogramm als Source-Code bezeichnet. Um ein derartiges Mikroprozessorprogramm auf einem Mikroprozessor ausführen zu können, muss aus dem Source- Code ein sogenannter Maschinencode erzeugt werden, der Anweisungen enthält, die von dem Prozessor ausführbar sind. Maschinencode kann durch sogenanntes Interpretieren oder Kompilieren des Source-Codes erzeugt werden.
Typischerweise umfasst ein Mikroprozessorprogramm eine
Vielzahl von Funktionseinheiten. Der Source-Code einer oder mehrerer Funktionseinheiten ist dabei in einer Datei abgespeichert. Einer oder mehrerer derartiger Dateien ist eine Header-Datei zugeordnet. Somit besteht ein Mikroprozessor- programm typischerweise aus einer Vielzahl von Dateien. Eine Konfiguration eines derartigen Mikroprozessorprogramms, die durch Änderungen innerhalb einzelner Header-Dateien durchgeführt wird, ist deshalb sehr unübersichtlich und kann häufig nur von dem Ersteller des Source-Codes durchge- führt werden. Zudem muss eine Dokumentation aller Header- Dateien erstellt werden, was sehr aufwendig ist, wobei selbst die Dokumentation meist sehr unübersichtlich ist.
Es ist auch bekannt, zur Konfiguration eines Mikroprozes- sorprogramms diesem eine spezielle Funktionseinheit zuzuordnen, mittels der eine Konfiguration des gesamten Mikroprozessorprogramms beispielsweise durch Änderung der Werte von vorgegebenen Parametern möglich ist. Die Funktionseinheit kann beispielsweise aus dem ablaufenden Mikroprozes- sorprogramm heraus aufgerufen und zur Konfiguration des Mikroprozessorprogramms ausgeführt werden. Eine derartige für die Konfiguration des Mikroprozessorprogramms vorgesehene Funktionseinheit erlaubt jedoch nur eine Konfiguration innerhalb vorgegebener Bereichsgrenzen. Eine Konfiguration des Mikroprozessorprogramms beispielsweise zur Anpassung des Mikroprozessorprogramms auf eine neue Hardware oder zur Anpassung des Mikroprozessorprogramms an neue Benutzerwünsche ist mit einer derartigen Funktionseinheit nicht mög- lieh. Ferner muss die zur Konfiguration verwendete Funktionseinheit speziell für das betreffende Mikroprozessorprogramm entwickelt werden und kann nicht für andere Mikroprozessorprogramme verwendet werden.
Einen ersten Ansatz zur Überwindung dieser Probleme beschreibt die Anmelderin in der prioritätsälteren, nicht vorveröffentlichten 10 2004 005 730.3. Bei dem beschriebenen Verfahren wird die Konfiguration eines Mikroprozessorprogramms verbessert und eine ressourcenoptimierte Imple- mentierung erreicht, indem zwischen einem Benutzer (Konfi- gurator) und dem Mikroprozessorprogramm eine abstrakte Beschreibung der auszuführenden Konfiguration in einer implementierungsunabhängigen Konfigurationsdatei vorgesehen ist, die der Konfiguration zugrundegelegt wird. Anhand der implementierungsunabhängigen Konfigurationsdatei wird automatisch eine implementierungsabhängige Konfigurationsdatei erstellt, die dann zur Konfiguration des Mikroprozessorprogramms herangezogen wird. Um die Fehlerfreiheit des Konfigurationsprozesses und schließlich des Mikroprozessorpro- gramms zu gewährleisten, werden bei der Erstellung der implementierungsabhängigen Konfigurationsdateien vielfache Prüfprozesse durchgeführt. Die Erstellung und Einbindung dieser Prüfprozesse ist schwierig und aufwendig, besonders da diese in Programmcode generiert und programmiert werden. Es stellt sich daher die Aufgabe, die Konfiguration von Mikroprozessorprogrammen weiter zu vereinfachen und möglichst übersichtlich und flexibel zu gestalten. Diese Auf- gäbe wird gelöst durch ein Verfahren gemäß dem Patentanspruch 1 und ein System gemäß dem Patentanspruch 13 sowie ein entsprechendes Softwaresystemprodukt und eine entsprechende Rechnereinheit.
Vorteile der Erfindung
Die eine Konfiguration bestimmenden Daten werden unabhängig von einer beabsichtigten konkreten Implementierung in einer oder mehreren implementierungsunabhängigen Konfigurations- dateien abgelegt. Die Implementierungsunabhängigkeit dieser Konfigurationsdatei ermöglicht insbesondere eine abstrakte Beschreibung der abgelegten Informationen. Dies ermöglicht es, die für die Konfiguration des Mikroprozessorprogramms relevanten Informationen besonders gut lesbar abzulegen und damit die Konfiguration deutlich zu vereinfachen. Dadurch, dass diese Konfigurationsdatei implementierungsunabhängig ist, ist es insbesondere möglich, auf einfache Weise eine Konfiguration des Mikroprozessorprogramms zu realisieren, so dass das Mikroprozessorprogramm beispielsweise auf einem neuen Computersystem ablauffähig ist, dessen genaue Parameter bei der Erstellung des Mikroprozessorprogramms noch gar nicht bekannt sind.
Der Konfigurationsdatencontainer ermöglicht es, alle für eine Konfiguration relevanten Daten zentral vorzuhalten.
Mittels der in dem Konfigurationsdatencontainer abgelegten Konfigurationsdaten wird automatisch das mindestens eine Modul konfiguriert. Gemäß einer Ausführung des erfindungsgemäßen Verfahrens ist vorgesehen, dass mittels der in dem Konfigurationsdatencontainer abgelegten Konfigurationsdaten automatisch mindes- tens eine implementierungsabhängige Konfigurationsdatei erzeugt wird, wobei die automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von in der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen durchgeführt wird.
Bei jeder der Ausführungsformen dieses Schritts findet bezüglich der implementierungsunabhängigen Konfigurationsdatei eine Konkretisierung einzelner oder mehrere Parameterwerte statt. Bei einer derartigen Konkretisierung werden beispielsweise relative Werte durch absolute Werte ersetzt. Ebenso können einzelnen Werten oder Datenbereichen bestimmte Datentypen oder -strukturen zugeordnet werden.
Die implementierungsabhängige Konfigurationsdatei berück- sichtigt implementierungsabhängige Eigenschaften, wie beispielsweise eine oder mehrere bei der Programmierung des Source-Codes verwendete Programmiersprachen oder Eigenschaften der Hardware, auf der das Mikroprozessorprogramm ablaufen soll.
Der Aufbau beziehungsweise die Aktualisierung des Konfigurationsdatencontainers mittels der in den implementierungsunabhängigen Konfigurationsdateien abgelegten Informationen kann beispielsweise mittels sogenannter Scripte durch- geführt werden. Dabei bezeichnet ein Script eine Sequenz von Befehlen, die von einem speziellen Mikroprozessorprogramm ausgeführt werden können. Derartige spezielle Mikroprozessorprogramme sind beispielsweise AWK oder Perl. Diese speziellen Mikroprozessorprogramme können auch eingesetzt werden, um aus den in dem Konfigurationsdatencontainer abgelegten Konfigurationsdaten implementierungsabhängige Konfigurationsdateien oder die Konfiguration des Moduls zu erzeugen.
Weiterhin werden bei dem erfindungsgemäßen Verfahren Konfigurationsregeln verwendet. Dabei sind typischerweise jedem Konfigurationsparameter eine oder mehrere Konfigurationsregeln zugehörig. In den Konfigurationsregeln kann beispiels- weise festgelegt werden, welche Datenquellen oder Gruppen von Datenquellen für einen bestimmten Konfigurationsparameter gültig, notwendig oder verboten sind. Bei der Verwendung des Verfahrens für komplexe Softwaresysteme sind unter Datenquellen insbesondere die Komponenten, z.B. Konfigura- tionsdaten, dieses Softwaresystems zu verstehen. Im Kraftfahrzeugbereich sind mögliche Datenquellen für Konfigurationsdaten Softwarekomponenten, z.B. Lambdaregelung, Fahrpedalaufbereitung, Diagnosesystem, usw. Bei der Angabe der gültigen Datenquellen können Mengenspezifikationen wie z.B. "alle Quellen ohne Unterschied" oder "Komponente X zzgl. aller Subkomponenten" vorgesehen sein. In den Konfigurationsregeln wird insbesondere festgeschrieben, wie die einzelnen Konfigurationsparameter formal und inhaltlich zu gestalten sind. Insgesamt ermöglicht diese erfindungsgemäße Maßnahme auf besonders einfache Weise, aufwendige und verteilte Prüfprozesse zu vermeiden und sie statt dessen zentral und einmalig (und damit konsistent) zu implementieren.
Der Vergleich der Konfigurationsparameter mit den Konfigu- rationsregeln kann ebenfalls mittels geeigneter Scripte durchgeführt werden. Die Verwendung von zentralen Konfigurationsregeln bietet umfassende Möglichkeiten zur formalen Definition der Eigenschaften und Einschränkungen von Konfigurationsparametern. Somit werden viele und detaillierte Prüfungen an zentraler Stelle ermöglicht und bezweckt. Im Gegensatz zu bisher beschriebenen Lösungen, bei denen Prüfläufe in den jeweiligen Scripten separat durchgeführt und programmiert werden mussten, kann nun ein Prozessor oder Script eine Regel-, Struktur- und/oder Querbeziehungsprü- fung an zentraler Stelle durchführen. Durch die erfindungsgemäße Maßnahme wird ein Transfer weg von Programmcode hin zu Regeln durchgeführt. Durch Behandlung der Konfigurationsregeln als Teil einer Komponentenschnittstelle (inter- face) werden weitgehende Schnittstellen-Prüfungen sowie
Sichtbarkeitseinschränkungen ermöglicht. Damit können Konflikte beim Austausch von Einzelkomponenten früh erkannt und vermieden werden.
Ein wesentlicher Bestandteil der Erfindung ist also die Erkenntnis, dass die Konfiguration eines modularen Systems, insbesondere Mikroprozessorprogramms, entscheidend verbessert werden kann, indem zwischen einem Benutzer (Konfigura- tor) und dem System eine abstrakte Beschreibung der auszu- führenden Konfiguration in der implementierungsunabhängigen Konfigurationsdatei vorgesehen ist, die der Konfiguration zugrundegelegt wird. Durch die Verwendung von Konfigurationsregeln können die Konfigurationsparameter bereits zu einem frühen Verfahrenszeitpunkt überprüft werden, was den dazu notwendige Aufwand vorteilhaft reduziert.
Anhand der implementierungsunabhängigen Konfigurationsdatei kann automatisch eine implementierungsabhängige Konfigurationsdatei erstellt werden, die dann zur Konfiguration des Systems herangezogen wird. Das System kann aber ebenso konfiguriert werden, ohne derartige Dateien physikalisch zu erstellen. Da die Konfigurationsparameter vorgegebenen Konfigurationsregeln unterliegen, kann eine einfache und flexible Anpassung an vorgegebene externe Parameter erreicht werden. Das erfindungsgemäße Verfahren ermöglicht es also, die eine Konfiguration beschreibenden Informationen abstrakt und damit besonders gut lesbar anzugeben. Durch die Unabhängigkeit jeglicher Implementierungsdetails wird fer- ner eine besonders hohe Flexibilität erreicht, die durch die Konfigurationsregeln überschaubar und beherrschbar bleibt.
Weiterhin bietet sich der Vorteil einer dezentralen Konfi- guration. Z.B. können die Eigenschaften eines mehrkanaligen Messsystems nicht nur zentral in einer diesem Messsystem zugeordneten Konfigurationsdatei, sondern auch kanalspezifisch in mehreren den jeweiligen Sensoren/Kanälen zugeordneten implementierungsunabhängigen Konfigurationsdateien zentral abgelegt werden. Im Container werden diese Informationen dann gesammelt und können von Skripten zentral ausgewertet werden.
Darüber hinaus führen beispielsweise in einem arbeitsteili- gen Prozess die Konfigurationsregeldateien zu einer sicheren Handhabung der implementierungsunabhängigen Konfigurationsdateien. Insbesondere können in einer implementierungsunabhängigen Konfigurationsdatei Konfigurationselemente mit verschiedenen Konfigurationsregeldateien enthalten sein, wodurch die Konfigurationsanforderungen verschiedener Module gebündelt bearbeitet werden können.
In einer besonders bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens werden die Konfigurationsregeln beim automatischen Aufbau und/oder beim automatischen Aktualisieren der in dem Konfigurationsdatencontainer abgelegten Konfigurationsdaten und/oder bei der automatischen Konfiguration des mindestens einen Moduls in Abhängigkeit von den in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten und/oder beim automatischen Erzeugen einer implementierungsabhängigen Konfigurationsdatei in Abhängigkeit von den in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten verwendet. Es kann ebenso vorgesehen sein, die Konfigurationsregeln bereits bei der Erstellung der implementierungsunabhängigen Konfigurationsdateien zu verwenden, wie es weiter unten am Beispiel eines Konfigurationsdateien-Editors beschrieben wird. An den genannten Punkten ist die Einbindung der Konfigurationsregeln besonders einfach durchzuführen. Hier wird demnach ein besonders günstiger Kosten-Nutzen-Faktor erreicht.
Es ist zweckmäßig, wenn die Konfigurationsregeln in mindestens einer Konfigurationsregeldatei abgelegt sind. Dabei bietet es sich an, mehrere Konfigurationsregeldateien vorzusehen, beispielsweise eine Konfigurationsregeldatei für jede Funktionseinheit oder eine Konfigurationsregeldatei für jede Konfigurationsdatei. In einer derartigen Konfigurationsregeldatei sind Regeln für die Konfigurationsparame- ter der zugeordneten Funktionseinheit abgelegt. Dadurch kann eine hohe Übersichtlichkeit erreicht werden. Die einzelnen Regeldateien werden während des Konfigurationsverfahrens zweckmäßigerweise zu einer zentralen Regeldatei zusammengeführt. Es versteht sich, dass ebenso nur eine Kon- figurationsregeldatei für alle zu behandelnden Konfigurationsparameter vorgesehen sein kann.
In einer bevorzugten Ausgestaltung des Verfahrens ist einem Konfigurationsparameter wenigstens eine Konfigurationsregel zugeordnet, wobei die Konfigurationsregel eine Berechtigung zum Bearbeiten des Konfigurationsparameters, eine formale Eigenschaft, eine existenzbestimmende Eigenschaft oder eine wertbestimmende Eigenschaft des Konfigurationsparameters beschreibt. Wie weiter unten beschrieben wird, ist als wei- tere vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens eine Konfiguration durch Abhängigkeitsinformationen vorgesehen. Es ist zweckmäßig, wenn dabei Konfigurationsregeln betreffend eine (Bearbeitungs-) Berechtigung vorgesehen sind. Damit kann auf einfache Weise eine Hierarchie innerhalb der Konfigurationsparameter festgelegt werden, welche eine gegenseitige Veränderbarkeit beschreibt. Insbesondere ist regelbar, welcher Konfigurationsparameter von welchen anderen Konfigurationsparametern beschrieben oder verändert werden kann oder darf. Es bietet sich an, weitere Eigenschaften von Konfigurationsparametern durch Konfigurationsregeln zu beschreiben, wie z.B.
- einen Standard-Wert (default) , der als Ersatzwert verwen- det wird, wenn kein Wert für einen Parameter angegeben wurde; damit können sich alle Konfigurationsdaten verarbeitenden nachgeschalteten Prozesse auf die Existenz eines Konfigurationswertes verlassen;
- eine Spezifikation gültiger Referenzziele, falls der zugehörige Konfigurationsparameter eine Liste von durch Schlüssel zu unterscheidenden Mengen von Konfigurationseinstellungen darstellt;
- einen zulässigen Wertebereich (z.B. minimaler/maximaler Wert, Inkrement [z.B. nur Werte 0, 0,1, 0,2 usw.], minimale/maximale Textlänge bei textuellen Parametern, festgelegter Texttyp (z.B. Iso-Datum) , einem bestimmten Textmuster genügender Text oder einem von mehreren vorgegebenen Texten identischer Text) ;
- eine Vorschrift zur automatischen Umsetzung eines Wertes in eine andere Darstellung; - eine Umrechnungsformel von einer abstrakten/physikalischen Repräsentation eines Wertes in eine interne Darstellung und/oder umgekehrt;
- eine Angabe, wie ein Konfigurationswert bspw. auf einem Display angezeigt werden soll (z.B. Format-String in einem printf-Format) ;
- eine Bindung an eine andere Systemeigenschaft, z.B. eine Variable in einem Softwaresystem bzw. Mikroprozessorprogramm, oder eine Hardwareeigenschaft oder Resource;
- eine Einheit des Konfigurationswerts;
- eine Behandlung von Leerzeichen und Seitenumbrüchen bei textuellen Informationen.
Für jeden Konfigurationsparameter können dabei einzelne, mehrere oder alle der genannten Regeln sowie weitere vorge- sehen sein. Durch diese Maßnahmen kann der Automatisierungsgrad besonders gut erhöht werden und eine zuverlässige Konfiguration des Mikroprozessorprogramms erreicht werden. Sieht eine Modul bzw. eine Funktionseinheit beispielsweise eine Erfassung von Messwerten vor, so kann in der zugehöri- gen Regel beschrieben werden, welche Sensoren von der Hardware bereitgestellt werden und welche Messgenauigkeit zur Verfügung steht. Der Parameter kann nur innerhalb dieser Regeln gesetzt werden.
In einer vorteilhaften Weiterbildung des Verfahrens wird mindestens eine Abhängigkeitsinformation, die eine Abhängigkeit von mindestens zwei in dem Konfigurationsdatencontainer vorliegenden Konfigurationsdaten beschreibt, automatisch erzeugt. Die mindestens eine implementierungsabhängi- ge Konfigurationsdatei wird in Abhängigkeit der mindestens einen Abhängigkeitsinformation erzeugt.
Abhängigkeitsinformationen können beispielsweise beschreiben, ob sich die Änderung eines Konfigurationsparameters auf einen anderen Konfigurationsparameter auswirkt. Wird zum Beispiel für ein Modul eine Resource ausschließlich reserviert, so steht sie während der Ausführung des Moduls/Funktionseinheit anderen Funktionseinheiten nicht zur Verfügung. Mit Abhängigkeitsinformationen kann ermittelt werden, welche Funktionseinheiten eine bestimmte Resource benötigen und damit nicht gleichzeitig ablaufen können. Abhängigkeitsinformationen können folglich auch zur Resour- cenverwaltung verwendet werden. Die Abhängigkeitsinformationen werden zur Weiterleitung (Forwarding) von Konfigurati- onsinformationen verwendet. Beim Forwarding leitet eine einer bestimmten Komponente zugeordnete Konfigurations- Bearbeitungs-Instanz aus an sie gestellten Konfigurationsanforderungen bzw. -feineinstellungen durch einen frei wählbaren Algorithmus Konfigurationen anderer Komponenten ab und leitet diese so ermittelten Einstellungen an diese anderen Komponenten weiter. Diese vorteilhafte Maßnahme kann insbesondere zur automatischen Konfiguration von Sub- komponenten verwendet werden. Es bietet sich daneben an, die Intention des Forwardings in Konfigurationsregeln abzu- legen, um bereits vor dem Zeitpunkt der eigentlichen Konfiguration prüfbar zu machen, ob durch diese Weiterleitung von Konfigurationsdaten möglicherweise Kreisschlüsse (Parameter A konfiguriert Parameter B, der wiederum Parameter A konfiguriert) entstehen. Durch das Ablegen in Konfigurati- onsregeln werden weiterhin Abhängigkeiten zwischen den einzelnen Komponenten formal beschrieben und stehen daher anderen, weiterverarbeitenden Prozessen zur Verfügung. Das Forwarding kann neben der beschriebenen bringenden Verfahrensweise auch eine holende Verfahrensweise vorsehen. Bei einem holenden Forwarding erfolgt eine Spezifikation einer Einstellung eines bestimmten Konfigurationsparameters nicht nur aus einem konstanten Datum, sondern vorteilhafterweise auch aus einem (möglicherweise komplexen und/oder bedingten) Ausdruck, der Referenzen auf die Einstellungen anderer Parameter enthält. Auch ist es vorteilhaft vorzusehen, eine Spezifikation eines Konfigurationsparameters als ganzes (d.h. die Existenz dieser Spezifikation) wiederum von der Einstellung anderer Konfigurationsparameter - oder möglicherweise beliebig komplexen Ausdrücken bestehend aus solchen Einstellungen - abhängig zu machen. Durch die Verwendung von Konfigurationsregeln kann eine automatische Festlegung der Forwarding-Reihenfolge erfolgen, wodurch eine Erkennung von eventuellen Kreisschlüssen schon zum Zeitpunkt der Schnittstellen-Prüfung ermöglicht wird.
In einer bevorzugten Ausführungsform des Verfahrens werden mehrere implementierungsunabhängige Konfigurationsdateien erstellt und jede der implementierungsunabhängigen Konfigurationsdateien wird mindesten einem Modul bzw. einer Funktionseinheit zugeordnet. Dies ermöglicht eine besonders einfache Konfiguration dadurch, dass die als Informationen in den implementierungsunabhängigen Konfigurationsdateien abgelegten Konfigurationsparameter besonders einfach aufgefunden und verändert werden können. Beispielsweise ist es möglich, die eine Konfiguration bestimmenden Informationen, also die Konfigurationsparameter, nach der von diesen be- einflussten Funktionalität oder Hardware zu ordnen. Ferner wird dadurch eine besonders einfache Anpassung der implementierungsunabhängigen Konfigurationsdateien an neu hinzugekommene Funktionseinheiten ermöglicht. Im einfachsten Fall wird einer neu hinzugekommenen Funktionseinheit eine spezielle implementierungsunabhängige Konfigurationsdatei sowie beispielsweise eine Konfigurationsregeldatei zugeordnet. Vorteilhafterweise werden mehrere implementierungsabhängige Konfigurationsdateien erzeugt und es wird jede der implementierungsabhängigen Konfigurationsdateien mindestens einer Funktionseinheit zugeordnet. Eine derartige Strukturierung der implementierungsabhängigen Konfigurationsdateien erhöht die Übersichtlichkeit der erzeugten implementierungsabhängigen Konfigurationsdateien. Ist der Source-Code derartig strukturiert, dass sich eine oder mehrere Funktionseinheiten in unterschiedlichen Dateien befinden, so kann erreicht werden, dass jeder der Dateien des Source-Codes eine implementierungsabhängige Konfigurationsdatei zugeordnet ist. Eine besonders übersichtliche Strukturierung kann auch dadurch erreicht werden, dass jeder implementierungsunabhängigen Konfigurationsdatei je eine implementierungsabhängige Konfigurationsdatei zugeordnet ist.
Vorzugsweise wird die mindestens eine implementierungsab- hängige Konfigurationsdatei in Abhängigkeit von mindestens einer Eigenschaft einer Hardware, auf der eine Installation zumindest eines Teils des konfigurierten modularen Systems als Mikroprozessorprogramm ermöglicht werden soll, erzeugt. Eine derartige Hardwareeigenschaft kann beispielsweise die Anzahl von zur Verfügung stehenden Prozessoren oder Art und Anzahl von an die Hardware angeschlossenen Sensoren sein. Werden derartige Hardwareeigenschaften bei der Erzeugung der implementierungsabhängigen Konfigurationsdateien berücksichtigt, so kann eine besonders präzise Konfiguration des Mikroprozessorprogramms erfolgen. Damit ist es beispielsweise möglich, insbesondere mit Abhängigkeitsinformationen eine hinsichtlich der Ausführungsgeschwindigkeit und Ressourcenverbrauch optimierte Konfiguration automatisch zu erstellen. In einer weiteren bevorzugten Ausführungsform wird automatisch eine Dokumentation erstellt. Die Dokumentation beschreibt die innerhalb der mindestens einen implementie- rungsunabhängigen Konfigurationsdatei und/oder der mindestens einen implementierungsabhängigen Konfigurationsdatei und/oder der Konfigurationsregeln und/oder der mindestens einen Konfigurationsregeldatei abgelegten Informationen. Derartig automatisch erzeugte Dokumentationen erhöhen die Wartbarkeit des Mikroprozessorprogramms einerseits und ermöglichen es andererseits besonders einfach, eine Konfiguration auf einfache Weise zu planen und vorzubereiten und eine durchgeführte Konfiguration nachzuvollziehen. Durch die automatische Erzeugung der Dokumentation ist sicherge- stellt, dass diese mit der tatsächlichen Konfiguration bzw. den Konfigurationsregeln übereinstimmt. Soll eine neue Konfiguration des modularen Systems durchgeführt werden, so kann anhand einer derartigen Dokumentation besonders einfach festgestellt werden, welche Parameterwerte geändert werden müssen oder dürfen und welchen Regeln diese unterliegen.
Es ist zweckmäßig, wenn bei dem erfindungsgemäßen Verfahren zum Erstellen und/oder Ändern der mindestens einen imple- mentierungsunabhängigen Konfigurationsdatei ein Mikroprozessorprogramm verwendet wird, dass die Konfigurationsregeln berücksichtigt. Ein solches Computer- oder Mikroprozessorprogramm kann beispielsweise als Konfigurationsdateien-Editor bezeichnet werden, was für den Fachmann die Funk- tionalität ausreichend beschreibt. Durch die Verwendung der Konfigurationsregeln bereits bei der Erstellung der Konfigurationsdateien kann von Anfang an die Übereinstimmung der Konfigurationsparameter mit den Konfigurationsregeln si- chergestellt werden. Eine nachträgliche Überarbeitung kann vermieden werden.
Vorzugsweise wird die mindestens eine implementierungsunab- hängige Konfigurationsdatei und/oder die mindestens eine Konfigurationsregeldatei in einem XML-basierten Format erstellt. XML (Extensible Markup Language) ist eine standardisierte Metasprache, die es ermöglicht, strukturierte Sprachen zu erzeugen. Ist die mindestens eine implementie- rungsunabhängige Konfigurationsdatei und/oder die mindestens eine Konfigurationsregeldatei in einer XML-konformen, strukturierten Sprache erstellt, so wird eine Konfiguration dadurch erleichtert, dass eine derartige Datei besonders gut lesbar ist. Ferner ist eine derartige Datei auch beson- ders gut maschinenlesbar. Insbesondere existiert eine Vielzahl von teilweise ebenfalls standardisierten Software- Werkzeugen (Tools), mittels derer eine Bearbeitung und Verarbeitung von in einem XML-basierten Format erstellten Dateien möglich ist.
In einer bevorzugten Ausführungsform des Verfahrens wird in Abhängigkeit von den Konfigurationsdaten automatisch ermittelt, ob ein von dem modularen System umfasstes Modul von dem modularen System benötigt wird und eine Konfiguration dieses Moduls nur durchgeführt, falls das Modul von dem modularen System benötigt wird. Dies ermöglicht es, eine Konfiguration besonders schnell durchzuführen dadurch, dass nur derartige Module/Funktionseinheiten tatsächlich konfiguriert werden, die bei einer Ausführung des konfigurierten Systems tatsächlich benötigt werden. Des weiteren wird dadurch erreicht, dass das konfigurierte System, wenn es sich um eine Mikroprozessorprogramm handelt, möglichst wenig Speicherplatz in Anspruch nimmt, da beispielsweise eine Ü- bersetzung von Source-Code in Maschinencode nur für derar- tige Funktionseinheiten veranlasst wird, die tatsächlich angewendet werden sollen.
Vorteilhafterweise wird das erfindungsgemäße Verfahren zur Konfiguration eines Mikroprozessorprogramms verwendet. Es kann aber prinzipiell zur Konfiguration jeglicher Systeme, die aus Modulen (z.B. Texte, Informationen, mechanische Bauteile usw.) bestehen, verwendet werden.
Die Aufgabe wird auch durch ein Softwaresystem der eingangs genannten Art gelöst. Dabei weist das Softwaresystem, insbesondere ein Computer- oder Mikroprozessorprogramm, auf:
- mindestens eine Konfigurationsregeldatei;
- mindestens eine implementierungsunabhängige Konfigurati- onsdatei;
- einen Konfigurationsdaten aufweisenden Konfigurationsdatencontainer und/oder Mittel zum Erstellen eines Konfigurationsdatencontainers in Abhängigkeit von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei ab- gelegten Informationen;
- Mittel zum Ändern und/oder Auslesen von Konfigurationsdaten aus dem Konfigurationsdatencontainer;
- Mittel zum automatischen Konfigurieren des mindestens einen Moduls in Abhängigkeit von in dem Konfigurationsdaten- Container abgespeicherten Konfigurationsdaten.
In einer bevorzugten Ausgestaltung weisen die Mittel zum automatischen Konfigurieren des mindestens einen Moduls in Abhängigkeit von in dem Konfigurationsdatencontainer abge- speicherten Konfigurationsdaten auf:
- Mittel zum automatischen Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten; und - Mittel zum automatischen Konfigurieren der mindestens einen Funktionseinheit in Abhängigkeit von in der implementierungsabhängigen Konfigurationsdatei abgelegten Informationen.
Vorzugsweise weist das Softwaresystem Mittel zur Durchführung des erfindungsgemäßen Verfahrens auf, insbesondere wenn das Softwaresystem auf einem Computer, einem Mikroprozessor oder einer entsprechenden Rechnereinheit, insbeson- dere der erfindungsgemäßen Rechnereinheit, ausgeführt wird.
Die Realisierung der Erfindung in Form eines Softwaresystems ist hierbei von besonderer Bedeutung. Dabei ist das Softwaresystem auf einem Rechengerät, insbesondere auf ei- nem Mikroprozessor ablauffähig und zur Ausführung des erfindungsgemäßen Verfahrens geeignet. In diesem Fall wird also die Erfindung durch das Softwaresystem realisiert, so dass das Softwaresystem in gleicher Weise die Erfindung darstellt wie das Verfahren, zu dessen Ausführung das Soft- waresystem geeignet ist.
Ein weiteres erfindungsgemäßes Softwaresystem bzw. Computerprogramm weist Programmcodemittel auf, um unter Berücksichtungen von Konfigurationsregeln implementierungsunab- hängige Konfigurationsdateien zu erstellen oder zu verändern (Konfigurationsdateien-Editor) .
Das Softwaresystem ist vorzugsweise auf einem Speicherelement (Speichermedium, Datenträger) abspeicherbar. Das Spei- cherelement kann als Random-Access-Memory, Read-Only-Memory oder Flash-Memory ausgebildet sein. Das Speicherelement kann auch als Digital Versatile Disc (DVD) , Compact Disc (CD) oder als Festplatte (Hard Disc) ausgebildet sein. Ein erfindungsgemäßes Softwaresystemprodukt, insbesondere eine Computer- bzw. Mikroprozessorprogrammprodukt, beinhaltet Programmcodemittel, die auf einem Speicherelement, insbesondere einem maschinen- bzw. computerlesbaren Datenträ- ger, gespeichert sind. Geeignete Datenträger sind insbesondere Disketten, Festplatten, Flash-Speicher, EEPROMs, CD- ROMs, DVDs, RAM, ROM u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich .
Eine erfindungsgemäße Rechnereinheit, insbesondere Steuergerät, weist einen Mikroprozessor auf und ist zur Durchführung eines erfindungsgemäßen Verfahrens programmiert.
Es ist zweckmäßig, ein erfindungsgemäßes Verfahren, ein erfindungsgemäßes Softwaresystem, ein erfindungsgemäßes Softwaresystemprodukt oder eine erfindungsgemäße Rechnereinheit im Bereich des Kraftfahrzeugbaus zu verwenden. Es versteht sich, dass die Verwendung nicht hierauf beschränkt ist.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, dass die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand eines Ausführungsbeispiels in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnung ausführlich beschrieben.
Figurenbeschreibung Figur 1 zeigt eine Ausführungsform eines Softwaresystems zur Durchführung des erfindungsgemäßen Verfahrens; und
Figur 2 ein schematisiertes Ablaufdiagramm einer Ausführungsform des erfindungsgemäßen Verfahrens.
In Figur 1 ist ein Softwaresystem zur Durchführung des er- findungsgemäßen Verfahrens dargestellt. Das Softwaresystem weist mehrere implementierungsunabhängige Konfigurationsdateien 1 auf. Jeder Konfigurationsdatei 1 ist ein Dateiname zugeordnet. Die in Figur 1 dargestellten implementierungsunabhängigen Konfigurationsdateien tragen beispielsweise die Dateinamen conf l.xml, conf 2. xml, conf 3.xml bis conf n . xml . Das Softwaresystem weist ebenfalls mehrere Konfigurationsregeldateien Ib auf. Jeder Konfigurationsregeldatei Ib ist ein Dateiname zugeordnet. Die in Figur 1 dargestellten Konfigurationsregeldateien tragen beispielsweise die Dateinamen rule l.xml, rule 2. xml, rule 3. xml bis ru- Ie x . xml . Die Dateiendung xml weist darauf hin, dass die implementierungsunabhängigen Konfigurationsdateien 1 und die Konfigurationsregeldateien Ib in einem XML-basierten Format vorliegen. Eine in einem XML-basierten Format vor- liegende Text-Datei ermöglicht es, die Text-Datei nach vorgebbaren Regeln zu strukturieren. Eine derartig strukturierte Text-Datei kann besonders gut manuell und maschinell gelesen und verarbeitet werden.
Die implementierungsunabhängigen Konfigurationsdateien 1 und die Konfigurationsregeldateien Ib werden einem Script 2 zugeführt. Das Script 2 ist beispielsweise als sogenanntes Perl-Script ausgebildet. Perl ist eine Interpretersprache, deren Syntax auf der Programmiersprache C basiert und die von dem jeweiligen Betriebssystem zur Verfügung gestellte Dienstprogramme verwendet.
Mittels des Scripts 2 werden die implementierungsunabhängi- gen Konfigurationsdateien 1 gelesen und die darin abgelegten Informationen extrahiert und in einem Konfigurationsdatencontainer 3 abgelegt. Die Extrahierung der Konfigurationsinformationen bzw. -parameter erfolgt unter Berücksichtigung der Konfigurationsregeln aus den Konfigurationsre- geldateien Ib. Wenn Konfigurationsparameter den Konfigurationsregeln widersprechen, kann dies somit bereits zu einem frühen Stadium der Konfiguration erkannt und bemängelt werden. Dazu können beispielsweise in den Konfigurationsregeldateien oder in Script 2 entsprechende Hinweis- oder Feh- lertexte enthalten sein, die bei der Verletzung einer entsprechenden Regel oder eines Regeltyps ausgegeben werden. Gleichzeitig werden auch eventuell vorhandene Abhängigkeiten zu weiteren Konfigurationsscripten 4 bestimmt und abgelegt (Forwarding) . Die Anordnung der Konfigurationsregelda- teien Ib innerhalb des Softwaresystems ist beispielhaft zu sehen. Die Konfigurationsregeldateien Ib können in einer anderen Ausführungsform des Softwaresystems beispielsweise den Scripten 4 zugeordnet sein.
Bei den weiteren Konfigurationsscripten 4 handelt es sich ebenfalls bspw. um Perl-Scripte . Es ist ebenso vorstellbar, dass eines oder mehrere der weiteren Konfigurationsscripte 4 ein ausführbares Mikroprozessorprogramm (Maschinencode) ist oder in einer anderen Scriptsprache, beispielsweise AWK, vorliegt.
Mit dem Bezugszeichen 5 sind implementierungsabhängige Konfigurationsdateien bezeichnet. Die implementierungsabhängigen Konfigurationsdateien 5 sind beispielsweise in der Pro- grammiersprache codiert, in der auch der zu konfigurierende Source-Code programmiert ist. Derartige implementierungsabhängige Konfigurationsdateien können von einem Compiler 6 verarbeitet werden.
Mit dem Bezugszeichen 7 ist ein Mikroprozessorprogramm dargestellt, das mehrere Funktionseinheiten 8 aufweist. Die Funktionsweise des erfindungsgemäßen Softwaresystems wird anhand des in Figur 2 dargestellten Ablaufdiagramms be- schrieben.
Das in Figur 2 dargestellte Ablaufdiagramm eines erfindungsgemäßen Verfahrens zur Konfiguration eines Mikroprozessorprogramms startet in einem Schritt 100. In einem Schritt 101 werden implementierungsunabhängige Konfigurationsdateien 1 erstellt beziehungsweise geändert. Die implementierungsunabhängigen Konfigurationsdateien 1 zeichnen sich insbesondere dadurch aus, dass es möglich ist, mittels der dort abgelegten Informationen konkrete Konfigurations- werte beziehungsweise Konfigurationsparameter abstrakt zu beschreiben. Konkrete Konfigurationswerte können beispielsweise den Messbereich eines Sensormoduls zur Messung einer elektrischen Spannung bestimmen. Beispielsweise ist es möglich, einen Messbereich abstrakt mit den Werten 3 - 5 Volt anzugeben. Die daraus zu erzeugenden, implementierungsabhängigen Werte des Messbereichs, so wie es die zu konfigurierende Funktionseinheit 8 erwartet, können jedoch beispielsweise zwischen 10.000 und 20.000 liegen. Eine das Sensormodul steuernde Funktionseinheit 8 des Mikroprozes- sorprogramms müsste in diesem Fall beispielsweise mittels der konkreten Konfigurationswerte 10.000 und 20.000 konfiguriert werden, um eine Messung in einem Messbereich von 3 - 5 Volt zu ermöglichen. Dem Verfahren stehen zusätzlich auch die Konfigurationsregeldateien Ib (rule l.xml bis rule x.xml in Figur 1) zur Verfügung. Herkömmlicherweise werden die Konfigurationsregeldateien Ib nicht bei jeder Durchführung des Verfahrens erstellt oder geändert. Die Konfigurationsregeldateien Ib beschreiben die formalen und inhaltlichen Eigenschaften der Konfigurationsparameter .
Die in dem Schritt 101 erstellten beziehungsweise geänder- ten implementierungsunabhängigen Konfigurationsdateien 1 und die Konfigurationsregeldateien Ib sind beispielsweise in einem XML-basierten Format erstellt. Ein derartiges Format ermöglicht es besonders gut, eine übersichtliche Strukturierung der implementierungsunabhängigen Konfigurations- dateien 1 und der Konfigurationsregeldateien Ib zu erreichen. Dies erhöht die Lesbarkeit der implementierungsunabhängigen Konfigurationsdateien 1 und der Konfigurationsregeldateien Ib und vereinfacht die Änderung der implementierungsunabhängigen Konfigurationsdateien 1 beispielsweise dadurch, dass zu ändernde Konfigurationsdaten schnell aufgefunden werden können. Es ist möglich, auch für ein besonders großes Mikroprozessorprogramm, für dessen Konfiguration eine Vielzahl von Konfigurationsdaten notwendig ist, nur eine einzige implementierungsunabhängige Konfigurationsda- tei oder Konfigurationsregeldatei vorzusehen. Eine Strukturierung der in der implementierungsunabhängigen Konfigurationsdatei 1 abgelegten Informationen und der in der Konfigurationsregeldatei Ib abgelegten Konfigurationsregeln kann dabei durch geeignete XML-Strukturen erreicht werden. Be- sonders vorteilhaft jedoch ist es, mehrere implementierungsunabhängige Konfigurationsdateien und Konfigurationsregeldateien vorzusehen. Jede dieser implementierungsunabhängigen Konfigurationsdateien 1 und Konfigurationsregeldateien Ib kann beispielsweise einer oder mehreren Funktionseinhei- ten 8 zugeordnet sein. Dadurch ist es möglich, das Erstellen beziehungsweise Ändern der implementierungsunabhängigen Konfigurationsdateien und Konfigurationsregeldateien besonders übersichtlich durchzuführen. Des weiteren wird dadurch eine Wiederverwendbarkeit einzelner implementierungsunabhängiger Konfigurationsdateien und Konfigurationsregeldateien erhöht. Dies ist insbesondere für Projekte vorteilhaft, bei denen auch einzelne Funktionseinheiten 8 des Source-Codes wiederverwendet werden sollen.
In einem Schritt 102 werden die in dem Script 2 aufgelisteten Anweisungen abgearbeitet. Das Script 2 veranlasst, dass die unabhängigen Konfigurationsdateien 1 und die Konfigurationsregeldateien Ib eingelesen werden. Liegt den implemen- tierungsunabhängigen Konfigurationsdateien 1 und/oder den Konfigurationsregeldateien Ib ein strukturiertes Format, beispielsweise ein XML-basiertes Format zugrunde, so kann mittels des Scripts 2 besonders gut eine syntaktische und/oder semantische Analyse des Inhalts der implementie- rungsunabhängigen Konfigurationsdateien 1 und/oder der Konfigurationsregeldateien Ib durchgeführt werden. Damit können beispielsweise (Datei-) Fehler bei der Angabe von Konfigurationsdaten erkannt werden (Fehlende Zeichen, zu viele Zeichen, falsche Zeichen usw.). Vorzugsweise weist das XML- basierte Format der implementierungsunabhängigen Konfigurationsdateien 1 und der Konfigurationsregeldateien Ib eine hierarchische Struktur auf, die sich vorteilhafterweise an der Struktur der Funktionseinheiten 8 selbst, deren Abhängigkeiten und/oder deren thematischer Nähe orientiert. Mit- tels des Scripts 2 können Fehler beim Aufbau dieser hierarchischen Struktur und damit auch beim Aufbau des Source- Codes selbst erkannt werden. Vorteilhafterweise weist der Schritt 102 eine Behandlung der aufgefundenen Fehler auf. Dies kann beispielsweise durch die Ausgabe von Fehlerinformationen geschehen. Es ist ebenso vorstellbar, dass stochastische Verfahren zur Besei- tigung von Fehlern eingesetzt werden.
In dem Schritt 102 werden auch die Konfigurationsparameter anhand der Konfigurationsregeln überprüft. Dabei wird insbesondere überprüft, ob die Konfigurationsparameter formal und inhaltlich den zugehörigen Konfigurationsregeln entsprechen. Ist dies nicht der Fall, so wird in den Schritt 101 zurückverzweigt, in welchem eine Änderung der implementierungsunabhängigen Konfigurationsdateien 1 mit dem Zwecke einer Fehlerbeseitigung durchgeführt wird. Werden in dem Schritt 102 keine Fehler erkannt, so wird zu einem Schritt 103 verzweigt, in dem der Konfigurationsdatencontainer 3 aufgebaut beziehungsweise aktualisiert wird.
Das Script 2 extrahiert in dem Schritt 103 die in den im- plementierungsunabhängigen Konfigurationsdateien 1 vorhandenen Konfigurationsdaten und speichert diese in dem Konfigurationsdatencontainer 3 ab. Der Konfigurationsdatencontainer 3 kann dabei beispielsweise als Datenbank ausgebildet sein. Es ist ebenso vorstellbar, dass der Konfigurati- onsdatencontainer 3 als in einem Speicherbereich vorgehaltene Datenstruktur innerhalb des erfindungsgemäßen Softwaresystems realisiert ist, wobei gewährleistet ist, dass das Script 2 schreibenden und lesenden Zugriff auf die in dem Konfigurationsdatencontainer 3 abgelegten Konfigurati- onsdaten hat.
In einem Schritt 104 werden Abhängigkeiten ermittelt. Eine derartige Abhängigkeit kann beispielsweise beschreiben, welche Funktionseinheiten 8 des Mikroprozessorprogramms bei der vorliegenden Konfiguration tatsächlich abgearbeitet werden müssen. Mittels dieser Abhängigkeiten kann entschieden werden, ob in einem der folgenden Schritte für eine bestimmte Funktionseinheit 8 überhaupt eine implementierungs- abhängige Konfigurationsdatei erzeugt werden muss. Abhängigkeiten können ferner beschreiben, welche konkreten Konfigurationsdaten von welchen abstrakten Konfigurationsdaten abhängen. So ist es vorstellbar, dass die Änderung eines abstrakten Konfigurationsdatums in einer implementierungsu- nabhängigen Konfigurationsdatei eine Änderung einer Mehrzahl von konkreten Konfigurationsdaten bewirkt.
Abhängigkeiten können sich auch ergeben, wenn die weiteren Scripte 4 ihrerseits den Konfigurationscontainer 3 verän- dern. Somit muss die richtige Aufrufreihenfolge (Aktivierungssequenz) der Scripte 4 ermittelt und abgelegt werden. Abhängigkeiten können auch Beziehungen zwischen einer oder mehrerer Hardwarekomponenten und einzelner Konfigurationsdaten beschreiben. Dies ermöglicht es beispielsweise zu er- kennen, ob eine vorgesehene Konfiguration auf einer bestimmten Hardware tatsächlich ablauffähig ist.
In einem Schritt 105 werden die implementierungsabhängigen Konfigurationsdateien 5 erzeugt. Dazu werden mittels eines Scripts 4 oder einer Mehrzahl von Scripten 4 zunächst die in dem Konfigurationsdatencontainer 3 abgelegten Konfigurationsdaten abgerufen. In dem vorliegenden Ausführungsbeispiel sind die Scripte 4 als Perl-Scripte ausgebildet. Mittels der Scripte 4 werden insbesondere in dem Konfigurati- onsdatencontainer 3 abgelegte abstrakte Konfigurationsdaten in konkrete Konfigurationsdaten umgewandelt, die dann in den implementierungsabhängigen Konfigurationsdateien 5 abgelegt werden. Vorzugsweise werden dabei auch die in dem Schritt 104 ermittelten Abhängigkeiten verwendet. Die in dem Schritt 105 erzeugten implementierungsabhängigen Konfigurationsdateien 5 können beispielsweise Header- Dateien (file l.h, file 2.h, file 3.h in Figur 1) sein. E- benso können die erzeugten implementierungsabhängigen Konfigurationsdateien 5 auch Source-Code enthalten (file_2.c, file k.c in Figur 1) . Typischerweise sind die von den Scripten 4 aus den abstrakten Konfigurationsdaten erzeugten konkreten Konfigurationsdaten durch Wertzuweisungen für Va- riablen und/oder Funktionsparameter sowie als Anweisungen in einer Programmiersprache realisiert. Dabei entspricht die Programmiersprache der Programmiersprache, in der die Funktionseinheiten 8 des Mikroprozessorprogramms 7 codiert sind. Sind die Funktionseinheiten 8 des Mikroprozessorpro- gramm 7 beispielsweise in der Programmiersprache C++ codiert, so können die konkreten Konfigurationsdaten beispielsweise durch so genannte Define-Anweisungen oder durch die Definition konstanter Variablen realisiert werden. Mittels der Scripte 4 ist es auch möglich, in Abhängigkeit der in dem Konfigurationsdatencontainer 3 abgespeicherten Konfigurationsdaten Funktionen zu erzeugen, die komplexe Aufgaben - wie beispielsweise die Initialisierung von Hardwarekomponenten oder die Prüfung auf das Vorhandensein einzelner Softwarekomponenten oder Hardwarekomponenten - über- nehmen und selbst als Source-Code in einer höheren Programmiersprache realisiert sind. Dieser Source-Code kann dann in einer oder mehreren implementierungsabhängigen Konfigurationsdateien (file 2. c, file k.c in Figur 1) abgelegt werden. Dazu kann ein Script 4 beispielsweise ein sogenann- tes Template enthalten, das beispielsweise aus Anweisungen in C++ besteht, die in Abhängigkeit der in dem Konfigurationsdatencontainer 3 abgespeicherten Konfigurationsdaten aktualisiert werden und in einer implementierungsabhängigen Konfigurationsdatei 5 abgelegt werden. In einem Schritt 106 werden die Funktionseinheiten 8 des Mikroprozessorprogramms 7 aktualisiert. Dies kann beispielsweise durch den automatischen Aufruf eines Compilers 6 geschehen, der die in einem Source-Code vorliegenden
Funktionseinheiten 8 in einen Maschinencode übersetzt. Dazu liest der Compiler 6 die implementierungsabhängigen Konfigurationsdateien 5 ein und steuert die Erzeugung des Maschinencodes in Abhängigkeit der in den implementierungsab- hängigen Konfigurationsdateien 5 abgelegten konkreten Konfigurationsdaten. Es ist auch vorstellbar, dass eine oder mehrere Funktionseinheiten 8 bereits in Maschinencode vorliegen. In diesem Fall kann der Compiler beispielsweise den von den Scripten 4 erzeugten Source-Code (file 2.c, fi- Ie k.c in Figur 1) unter Berücksichtigung der Header- Dateien (file l.h, file 2.h, file 3.h) in Maschinencode ü- bersetzen und den so übersetzten Maschinencode mittels eines dem Compiler 6 zugeordneten sogenannten Linkers mit dem die Funktionseinheiten 8 repräsentierenden Maschinencode verbinden.
In einem Schritt 107 endet das Verfahren. In diesem Schritt ist das Mikroprozessorprogramm 7 derart konfiguriert, dass die in den implementierungsunabhängigen Konfigurationsda- teien abgelegten konkreten Konfigurationsdaten in dem erzeugten Maschinencode berücksichtigt werden.
Es ist möglich, dass das Script 2 und/oder die Scripte 4 in einer anderen Scriptsprache geschrieben sind oder als aus- führbare Programme ausgestaltet sind. Ebenso ist es möglich, die Konfigurationsregeln erst im Zusammenhang mit den Scripten 4 zu verwenden. Es versteht sich, dass die in Figur 2 dargestellten Ausführungsschritte variieren können und die Reihenfolge der Abarbeitung teilweise verändert werden kann. Das Verfahren kann insbesondere auch von einer oder mehreren implementie- rungsunabhängigen Konfigurationsdateien ausgehen, ein oder mehrere Scripte 2 aufweisen, die beispielsweise hintereinander ausgeführt werden, ein oder mehrere Scripte 4 aufweisen, die jeweils ein oder mehrere implementierungsabhängige Konfigurationsdateien 5 erzeugen und ebenso kann das Mikro- prozessorprogramm 7 ein oder mehrere Funktionseinheiten 8 aufweisen. Mit dem erfindungsgemäßen Verfahren ist es insbesondere möglich zu erkennen, ob eine oder mehrere der Funktionseinheiten 8 bei der durch die implementierungsunabhängigen Konfigurationsdateien vorgegebenen Konfigurati- on tatsächlich zur Anwendung kommen. Ist dies nicht der
Fall, kann dies durch ein dem Konfigurationsdatencontainer 3 zugeordnetes, nicht dargestelltes Softwaretool erkannt werden. Dies ermöglicht es, dass eine derartige Funktionseinheit 8 nicht konfiguriert wird und mittels der implemen- tierungsabhängigen Konfigurationsdateien 5 der Compiler 6 veranlasst wird, die Funktionseinheit 8 nicht mit in den zu erzeugenden Maschinencode zu übernehmen. Dadurch kann das erfindungsgemäße Verfahren besonders schnell durchgeführt werden. Der von einem Mikroprozessorprogramm, das mittels des erfindungsgemäßen Verfahrens konfiguriert wurde, erzeugte Maschinencode kann dabei besonders kompakt sein und somit Speicherplatz einsparen.
Es ist möglich, dass das Script 2 selbst bereits die Erzeu- gung einer oder mehrerer implementierungsabhängiger Konfigurationsdateien 5 veranlasst. Dadurch kann das erfindungsgemäße Verfahren besonders schnell durchgeführt werden. Dies kann beispielsweise vorteilhaft für abstrakte Konfigu- rationsdaten sein, die keine Abhängigkeiten aufweisen und sich von den konkreten Konfigurationsdaten unterscheiden.

Claims

Ansprüche
1. Verfahren zur Konfiguration eines mindestens ein Modul umfassenden Systems (modulares System) , insbesondere eines Mikroprozessorprogramms, g e k e n n z e i c h n e t d u r c h folgende Schritte :
Erstellen mindestens einer implementierungsunabhängigen Konfigurationsdatei (1) und/oder Ändern von in der mindestens einen implementierungsunabhängigen Konfigu- rationsdatei (1) abgelegten Informationen;
Automatischer Aufbau und/oder automatische Aktualisierung von in einem Konfigurationsdatencontainer (3) abgelegten Konfigurationsdaten in Abhängigkeit von den in der mindestens einen implementierungsunabhängigen Konfigurationsdatei (1) abgelegten Informationen;
Automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten; Verwenden von Konfigurationsregeln.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt:
Automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von den in dem Konfigurationsdatencon- tainer (3) abgespeicherten Konfigurationsdaten; die folgenden Schritte umfasst:
Automatisches Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei (5) in Abhängig- keit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten;
Automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von in der mindestens einen implemen- tierungsabhängigen Konfigurationsdatei abgelegten Informationen;
3. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Konfigurationsregeln beim automatischen Aufbau und/oder beim automatischen Aktualisieren der in einem Konfigurationsdatencontainer (3) abgelegten Konfigurationsdaten und/oder bei der automatischen Konfiguration des mindestens einen Moduls in Abhängigkeit von den in dem Konfigurations- datencontainer (3) abgespeicherten Konfigurationsdaten und/oder beim automatischen Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei (5) in Abhängigkeit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten verwendet werden.
4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Konfigurationsregeln in mindestens einer Konfigurationsregeldatei (Ib) abge- legt sind.
5. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass einem Konfigurationsparameter wenigstens eine Konfigurationsregel zugeordnet ist, wobei die Konfigurationsregel eine Berechtigung zum Bearbeiten des Konfigurationsparameters, eine formale Eigenschaft, eine existenzbestimmende Eigenschaft oder eine wertbestimmende Eigenschaft des Konfigurationsparameters beschreibt.
6. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass mindestens eine Abhängigkeitsinformation automatisch erzeugt wird, die eine Abhängigkeit von mindestens zwei in dem Konfigurationsdatencontainer vorliegenden Konfigurationsdaten beschreibt, und dass die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit der mindestens einen Abhängigkeitsinformation erzeugt wird.
7. Verfahren nach einem der vorstehenden Ansprüche, wobei das modulare System mehrere Module aufweist, dadurch gekennzeichnet, dass mehrere implementierungsunabhän- gige Konfigurationsdateien erstellt werden und jede der implementierungsunabhängigen Konfigurationsdateien mindestens einem Modul zugeordnet wird.
8. Verfahren nach einem der vorstehenden Ansprüche, da- durch gekennzeichnet, dass die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit von mindestens einer Eigenschaft einer Hardware, auf der eine Installation zumindest eines Teils des konfigurierten modularen Systems als Mikroprozessor- programm ermöglicht werden soll, erzeugt wird.
9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass automatisch eine Dokumentation erstellt wird und die Dokumentation die innerhalb der mindestens einen implementierungsunabhängigen Konfigurationsdatei und/oder der mindestens einen implementierungsabhängigen Konfigurationsdatei und/oder der Konfigurationsregeln und/oder der mindestens einen Konfigurationsregeldatei abgelegten Informationen beschreibt .
10. Verfahren nach einem der vorstehenden Ansprüche, da- durch gekennzeichnet, dass zum Erstellen und/oder Ändern der mindestens einen implementierungsunabhängigen Konfigurationsdatei ein Mikroprozessorprogramm verwendet wird, dass die Konfigurationsregeln berücksichtigt.
11. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die mindestens eine implementierungsunabhängige Konfigurationsdatei und/oder die mindestens eine Konfigurationsregeldatei in einem XML-basierten Format erstellt wird.
12. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in Abhängigkeit von den Konfigurationsdaten automatisch ermittelt wird, ob ein von dem modularen System umfasstes Modul von dem modu- laren System benötigt wird und eine Konfiguration dieses Moduls nur durchgeführt wird, falls das Modul von dem modularen System benötigt wird.
13. Verwendung eines Verfahrens nach einem der vorstehenden Ansprüche zur Konfiguration eines Mikroprozessorprogramms .
14. Softwaresystem zur Konfiguration eines mindestens ein Modul umfassenden Systems (modulares System) , dadurch gekennzeichnet, dass das Softwaresystem aufweist:
mindestens eine Konfigurationsregeldatei; mindestens eine implementierungsunabhängige Konfigurationsdatei; einen Konfigurationsdaten aufweisenden Konfigurationsdatencontainer und/oder Mittel zum Erstellen eines Konfigurationsdatencontainers in Abhängigkeit von in der mindestens einen implementierunsunabhängigen Konfigurationsdatei abgelegten Informationen; Mittel zum Ändern und/oder Auslesen von Konfigurationsdaten aus dem Konfigurationsdatencontainer; und - Mittel zum automatischen Konfigurieren des mindestens einen Moduls in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten; Softwaresystem nach Anspruch 13, wobei die Mittel zum automatischen Konfigurieren der mindestens einen Funk- tionseinheit in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten aufweisen:
Mittel zum automatischen Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Ab- hängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten; und
Mittel zum automatischen Konfigurieren des mindestens einen Moduls in Abhängigkeit von in der implementierungsabhängigen Konfigurationsdatei abgelegten Infor- mationen.
15. Softwaresystem nach Anspruch 13 oder -, dadurch gekennzeichnet, dass das Softwaresystem Mittel zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 12 aufweist.
16. Softwaresystem mit Programmcodemitteln, um unter Berücksichtungen von Konfigurationsregeln implementie- rungsunabhängige Konfigurationsdateien zu erstellen oder zu verändern.
17. Softwaresystemprodukt, dadurch gekennzeichnet, dass ein Softwaresystem nach einem der Ansprüche 13 bis 15 auf einem Speicherelement gespeichert ist.
18. Rechnereinheit, insbesondere Steuergerät, das einen Mikroprozessor aufweist, dadurch gekennzeichnet, dass die Rechnereinheit zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 12 programmiert ist.
19. Verwendung eines Verfahrens, eines Softwaresystems, eines Softwaresystemprodukts oder einer Rechnereinheit nach einem der vorstehenden Ansprüche im Bereich des Kraftfahrzeugbaus .
EP06764012A 2005-07-14 2006-06-30 Verfahren und softwaresystem zur konfiguration eines modularen systems Ceased EP1904923A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005032944A DE102005032944A1 (de) 2005-07-14 2005-07-14 Verfahren und Softwaresystem zur Konfiguration eines modularen Systems
PCT/EP2006/063765 WO2007006671A1 (de) 2005-07-14 2006-06-30 Verfahren und softwaresystem zur konfiguration eines modularen systems

Publications (1)

Publication Number Publication Date
EP1904923A1 true EP1904923A1 (de) 2008-04-02

Family

ID=36999907

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06764012A Ceased EP1904923A1 (de) 2005-07-14 2006-06-30 Verfahren und softwaresystem zur konfiguration eines modularen systems

Country Status (5)

Country Link
US (1) US20090106546A1 (de)
EP (1) EP1904923A1 (de)
CN (1) CN101223506A (de)
DE (1) DE102005032944A1 (de)
WO (1) WO2007006671A1 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007004423A1 (de) * 2007-01-23 2008-07-31 Carl Zeiss Industrielle Messtechnik Gmbh Steuerung eines Betriebes eines Koordinatenmessgerätes
US9009358B1 (en) 2008-09-23 2015-04-14 Western Digital Technologies, Inc. Configuring a data storage device with a parameter file interlocked with configuration code
US7984200B1 (en) 2008-09-23 2011-07-19 Western Digital Technologies, Inc. Configuring a data storage device with a configuration data record set in response to a configuration code
US8489841B1 (en) * 2009-12-10 2013-07-16 Western Digital Technologies, Inc. Manufacturing station dynamically configuring a data storage device with a validated configuration data record
FR2960668A1 (fr) * 2010-05-27 2011-12-02 Airbus Operations Sas Procede et dispositif de configuration incrementale de modules de type ima
DE102010026494A1 (de) * 2010-07-07 2012-01-12 Abb Ag Verfahren zur Konfigurierung einer Steuerungseinrichtung
DE102011052511A1 (de) * 2011-08-09 2013-02-14 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Verarbeitung von Daten in einem Beeinflussungsgerät
US20140330691A1 (en) * 2013-05-01 2014-11-06 Life Dreams, Inc. Devices, methods and systems related to automation that provides financial planning advice
US10185577B2 (en) 2014-12-08 2019-01-22 Oracle International Corporation Run-time adaption of external properties controlling operation of applications
US11954071B1 (en) * 2017-06-11 2024-04-09 Jennifer Shin File naming and management system
CN107636606B (zh) * 2017-08-02 2020-12-15 福建联迪商用设备有限公司 一种配置文件分级方法及终端
CN109597661B (zh) * 2018-10-26 2021-10-22 创新先进技术有限公司 一种业务功能配置方法及装置
CN111552508B (zh) * 2020-04-29 2023-03-14 杭州数梦工场科技有限公司 应用程序版本构建方法、装置、电子设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4562535A (en) * 1982-04-05 1985-12-31 Texas Instruments Incorporated Self-configuring digital processor system with global system
US4633392A (en) * 1982-04-05 1986-12-30 Texas Instruments Incorporated Self-configuring digital processor system with logical arbiter
US5872977A (en) * 1997-08-08 1999-02-16 International Business Machines Corporation Object-oriented method and apparatus for creating a makefile
US6636961B1 (en) * 1999-07-09 2003-10-21 International Business Machines Corporation System and method for configuring personal systems
DE10121790B4 (de) * 2000-06-03 2006-11-23 International Business Machines Corp. Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
US20030033588A1 (en) * 2001-01-29 2003-02-13 John Alexander System, method and article of manufacture for using a library map to create and maintain IP cores effectively
US6865733B2 (en) * 2001-06-21 2005-03-08 International Business Machines Corp. Standardized interface between Java virtual machine classes and a host operating environment
US6789254B2 (en) * 2001-06-21 2004-09-07 International Business Machines Corp. Java classes comprising an application program interface for platform integration derived from a common codebase
DE102004005730A1 (de) * 2004-02-05 2005-08-25 Robert Bosch Gmbh Verfahren zur Konfiguration eines Computerprogramms

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN101223506A (zh) 2008-07-16
WO2007006671A1 (de) 2007-01-18
DE102005032944A1 (de) 2007-01-18
US20090106546A1 (en) 2009-04-23

Similar Documents

Publication Publication Date Title
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
EP1904923A1 (de) Verfahren und softwaresystem zur konfiguration eines modularen systems
EP1401171B1 (de) Elektronische Vorrichtung für ein Bussystem
DE102018003142A1 (de) Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
EP2729855A1 (de) Verfahren und vorrichtung zur programmierung und konfigurierung einer speicherprogrammierbaren steuereinrichtung
WO2004077305A1 (de) System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten
EP2009525A1 (de) Testvorrichtung zum Testen wenigstens eines elektronischen Steuerungssystems und Verfahren dazu
EP2799983A1 (de) Flexible Aufteilung der I/O Kanäle einer Hardware Komponente
WO2015074871A1 (de) System zum rechnergestützten erstellen von regeln zur überwachung und/oder diagnose einer technischen anlage
DE102019008598A1 (de) Identifikation und Visualisierung von Assoziationen zwischen Code, der von einem Modell generiert ist, und Quellen, welche die Codegeneration beeinflussen
WO2009010338A1 (de) Verfahren zur rechnergestützten obfuskierung eines softwareprogramms und computerprogrammprodukt
DE102020119853B3 (de) Verfahren zum Steuern eines Automatisierungssystems mit Visualisierung von Programmobjekten eines Steuerprogramms des Automatisierungssystems und Automatisierungssystem
WO2021156483A1 (de) Verfahren und system zum validieren eines steuerungsprogramms
DE102010047954A1 (de) Formelle offline-Verifikation ausführbarer Modelle
EP3001318A1 (de) Bestimmung von Signalen für Readback aus FPGA
DE102017208143A1 (de) Verfahren zur rechnergestützten Benutzerassistenz bei der Erstellung eines Programms zur Analyse von Daten zumindest eines technischen Systems
EP1621945B1 (de) Konsistenzsicherung in einem Automatisierungssystem
EP2175331A1 (de) Steuerbares Gerät mit einem Steuerprogramm und Verfahren zum Steuern des Geräts
DE10300541A1 (de) Erzeugen einer ausführbaren Datei
DE102004020873A1 (de) System und Verfahren zum Bestimmen von anwendbaren Konfigurationsinformationen zur Verwendung bei einer Analyse eines computergestützten Entwurfs
EP0560342B1 (de) Verfahren zum Untersuchen des Ablaufs eines in einer Hardware-Beschreibungssprache geschriebenen Programms
DE202020105648U1 (de) Maschinelles Lernsystem zur Unterstützung der Ingenieurtätigkeit
WO2020099524A1 (de) Verfahren und systeme zur bereitstellung von leistungsdaten eines steuergerätes im fahrbetrieb
DE102010014720A1 (de) Verfahren zum Verifizieren eines aus einem Quellmodell generierten Zielprogramms
EP1983426A1 (de) Automatisierte Visualisierung einer Auswahl von Simulationsdaten

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

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080527

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20090228