DE102005032944A1

DE102005032944A1 - Verfahren und Softwaresystem zur Konfiguration eines modularen Systems

Info

Publication number: DE102005032944A1
Application number: DE102005032944A
Authority: DE
Inventors: Bernhard Weichel; Frank Neukam
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2005-07-14
Filing date: 2005-07-14
Publication date: 2007-01-18
Also published as: EP1904923A1; WO2007006671A1; CN101223506A; US20090106546A1

Abstract

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

Description

Die Erfindung betrifft ein Verfahren sowie ein Softwaresystem zur Konfiguration eines mindestens ein Modul umfassenden Systems (modulares System).

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 modularen 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 breiten 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 zugrundeliegende 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 oder 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 Variablentypen.

Es ist bekannt, die in einem Mikroprozessorprogramm verwendeten Variablen und Funktionen in einer sogenannten Header-Datei zu deklarieren und eine Konfiguration des Mikroprozessorprogramms durchzuführen, indem einzelne Variablen oder Funktionsbezeichner in der Header-Datei verändert werden. Beispielsweise ist es möglich, einem in dem Mikroprozessorprogramm verwendeten und in der Header-Datei deklarierten Funktionsbezeichner in Abhängigkeit von einer bestimmten Konfiguration eine spezielle Funktion zuzuweisen.

Üblicherweise werden Mikroprozessorprogramme in einer sogenannten 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 Mikroprozessorprogramm 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 durchgefü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 Mikroprozessorprogramms 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 Mikroprozessorprogramm 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öglich. 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 Implementierung erreicht, indem zwischen einem Benutzer (Konfigurator) 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 Mikroprozessorprogramms 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 Aufgabe wird gelöst durch ein Verfahren gemäß dem Patentanspruch 1 und ein System gemäß dem Patentanspruch 14 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 Konfigurationsdateien 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 Konfigurationdatencontainer abgelegten Konfigurationsdaten wird automatisch das mindestens eine Modul konfiguriert.

Gemäß einer Ausführung des erfindungsgemäßen Verfahrens ist vorgesehen, dass mittels der in dem Konfigurationdatencontainer abgelegten Konfigurationsdaten automatisch mindestens 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ücksichtigt 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 durchgefü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 beispielsweise 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. Konfigurationsdaten, 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 Konfigurationsregeln 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 (interface) 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 (Konfigurator) und dem System eine abstrakte Beschreibung der auszufü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 ferner eine besonders hohe Flexibilität erreicht, die durch die Konfigurationsregeln überschaubar und beherrschbar bleibt.

Weiterhin bietet sich der Vorteil einer dezentralen Konfiguration. 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 arbeitsteiligen 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 Konfigurationsparameter 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 Konfigurationsregeldatei 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 weitere 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 verwendet 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 vorgesehen 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örigen 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ängige 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 Resourcenverwaltung verwendet werden. Die Abhängigkeitsinformationen werden zur Weiterleitung (Forwarding) von Konfigurationsinformationen 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 Subkomponenten verwendet werden. Es bietet sich daneben an, die Intention des Forwardings in Konfigurationsregeln abzulegen, 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 Konfigurationsregeln 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 beeinflussten 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 implementierungsabhä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 implementierungsunabhä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 sichergestellt, 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 implementierungsunabhä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 Funktionalitä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 sichergestellt werden. Eine nachträgliche Überarbeitung kann vermieden werden.

Vorzugsweise wird die mindestens eine implementierungsunabhä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 implementierungsunabhä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 besonders 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 derartige 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 Konfigurationsdatei;
– einen Konfigurationsdaten aufweisenden Konfigurationsdatencontainer und/oder Mittel zum Erstellen eines Konfigurationsdatencontainers in Abhängigkeit von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei abgelegten 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 Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten.

In einer bevorzugten Ausgestaltung weisen die Mittel zum automatischen Konfigurieren des mindestens einen Moduls in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten 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, insbesondere 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 einem 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 Softwaresystem geeignet ist.

Ein weiteres erfindungsgemäßes Softwaresystem bzw. Computerprogramm weist Programmcodemittel auf, um unter Berücksichtungen von Konfigurationsregeln implementierungsunabhängige Konfigurationsdateien zu erstellen oder zu verändern (Konfigurationsdateien-Editor).

Das Softwaresystem ist vorzugsweise auf einem Speicherelement (Speichermedium, Datenträger) abspeicherbar. Das Speicherelement 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
1 zeigt eine Ausführungsform eines Softwaresystems zur Durchführung des erfindungsgemäßen Verfahrens; und
2 ein schematisiertes Ablaufdiagramm einer Ausführungsform des erfindungsgemäßen Verfahrens.
In 1 ist ein Softwaresystem zur Durchführung des erfindungsgemäßen Verfahrens dargestellt. Das Softwaresystem weist mehrere implementierungsunabhängige Konfigurationsdateien 1 auf. Jeder Konfigurationsdatei 1 ist ein Dateiname zugeordnet. Die in 1 dargestellten implementierungsunabhängigen Konfigurationsdateien tragen beispielsweise die Dateinamen conf_1.xml, conf_2.xml, conf_3.xml bis conf_n.xml. Das Softwaresystem weist ebenfalls mehrere Konfigurationsregeldateien 1b auf. Jeder Konfigurationsregeldatei 1b ist ein Dateiname zugeordnet. Die in 1 dargestellten Konfigurationsregeldateien tragen beispielsweise die Dateinamen rule_1.xml, rule_2.xml, rule_3.xml bis rule_x.xml. Die Dateiendung xml weist darauf hin, dass die implementierungsunabhängigen Konfigurationsdateien 1 und die Konfigurationsregeldateien 1b in einem XML-basierten Format vorliegen. Eine in einem XML-basierten Format vorliegende 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 1b 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ängigen 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 Konfigurationsregeldateien 1b. 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 Fehlertexte 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 Konfigurationsregeldateien 1b innerhalb des Softwaresystems ist beispielhaft zu sehen. Die Konfigurationsregeldateien 1b 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 Programmiersprache 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 2 dargestellten Ablaufdiagramms beschrieben.
Das in 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 Konfigurationswerte 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 Mikroprozessorprogramms 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 1b (rule_1.xml bis rule_x.xml in 1) zur Verfügung. Herkömmlicherweise werden die Konfigurationsregeldateien 1b nicht bei jeder Durchführung des Verfahrens erstellt oder geändert. Die Konfigurationsregeldateien 1b beschreiben die formalen und inhaltlichen Eigenschaften der Konfigurationsparameter.
Die in dem Schritt 101 erstellten beziehungsweise geänderten implementierungsunabhängigen Konfigurationsdateien 1 und die Konfigurationsregeldateien 1b sind beispielsweise in einem XML-basierten Format erstellt. Ein derartiges Format ermöglicht es besonders gut, eine übersichtliche Strukturierung der implementierungsunabhängigen Konfigurationsdateien 1 und der Konfigurationsregeldateien 1b zu erreichen. Dies erhöht die Lesbarkeit der implementierungsunabhängigen Konfigurationsdateien 1 und der Konfigurationsregeldateien 1b 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 Konfigurationsdatei oder Konfigurationsregeldatei vorzusehen. Eine Strukturierung der in der implementierungsunabhängigen Konfigurationsdatei 1 abgelegten Informationen und der in der Konfigurationsregeldatei 1b abgelegten Konfigurationsregeln kann dabei durch geeignete XML-Strukturen erreicht werden. Besonders vorteilhaft jedoch ist es, mehrere implementierungsunabhängige Konfigurationsdateien und Konfigurationsregeldateien vorzusehen. Jede dieser implementierungsunabhängigen Konfigurationsdateien 1 und Konfigurationsregeldateien 1b kann beispielsweise einer oder mehreren Funktionseinheiten 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 1b eingelesen werden. Liegt den implementierungsunabhängigen Konfigurationsdateien 1 und/oder den Konfigurationsregeldateien 1b 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 implementierungsunabhängigen Konfigurationsdateien 1 und/oder der Konfigurationsregeldateien 1b 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 1b eine hierarchische Struktur auf, die sich vorteilhafterweise an der Struktur der Funktionseinheiten 8 selbst, deren Abhängigkeiten und/oder deren thematischer Nähe orientiert. Mittels 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 Beseitigung 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 implementierungsunabhä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 Konfigurationsdatencontainer 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 Konfigurationsdaten 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 implementierungsabhä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 implementierungsunabhä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ändern. Somit muss die richtige Auf rufreihenfolge (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 erkennen, 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 Konfigurationsdatencontainer 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_1.h, file_2.h, file_3.h in 1) sein. Ebenso können die erzeugten implementierungsabhängigen Konfigurationsdateien 5 auch Source-Code enthalten (file_2.c, file_k.c in 1). Typischerweise sind die von den Scripten 4 aus den abstrakten Konfigurationsdaten erzeugten konkreten Konfigurationsdaten durch Wertzuweisungen für Variablen 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 Mikroprozessorprogramm 7 beispielsweise in der Programmiersprache C++ codiert, so können die konkreten Konfigurationsdaten beispielsweise durch sogenannte #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 – übernehmen 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 1) abgelegt werden. Dazu kann ein Script 4 beispielsweise ein sogenanntes 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 implementierungsabhä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, file k.c in 1) unter Berücksichtigung der Header-Dateien (file_1.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 Konfigurationsdateien 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 ausfü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 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 implementierungsunabhä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 Mikroprozessorprogramm 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 Konfiguration 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 implementierungsabhä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 Erzeugung 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 Konfigurationsdaten sein, die keine Abhängigkeiten aufweisen und sich von den konkreten Konfigurationsdaten unterscheiden.

1: implementierungsunabhängige Konfigurationsdateien
1b: Konfigurationsregeldateien
2: Script
3: Konfigurationsdatencontainer
4: Konfigurationsscripte
5: implementierungsabhängige Konfigurationsdateien
6: Compiler
7: Mikroprozessorprogramm
8: Funktionseinheiten
100–107: Verfahrensschritte

Claims

Verfahren zur Konfiguration eines mindestens ein Modul umfassenden Systems (modulares System), insbesondere eines Mikroprozessorprogramms, gekennzeichnet durch folgende Schritte: – 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.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt: – Automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten; die folgenden Schritte umfasst: – Automatisches Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei (5) in Abhängigkeit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten; – Automatische Konfiguration des mindestens einen Moduls in Abhängigkeit von in der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen;
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 Konfigurationsdatencontainer (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.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Konfigurationsregeln in mindestens einer Konfigurationsregeldatei (1b) abgelegt sind.
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.
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.
Verfahren nach einem der vorstehenden Ansprüche, wobei das modulare System mehrere Module aufweist, dadurch gekennzeichnet, dass mehrere implementierungsunabhängige Konfigurationsdateien erstellt werden und jede der implementierungsunabhängigen Konfigurationsdateien mindestens einem Modul zugeordnet wird.
Verfahren nach einem der vorstehenden Ansprüche, dadurch 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 Mikroprozessorprogramm ermöglicht werden soll, erzeugt wird.
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.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zum Erstellen und/oder Ändern der mindestens einen implementierungsunabhängigen Konfigurationsdatei ein Mikroprozessorprogramm verwendet wird, dass die Konfigurationsregeln berücksichtigt.
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.
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 modularen System benötigt wird und eine Konfiguration dieses Moduls nur durchgeführt wird, falls das Modul von dem modularen System benötigt wird.
Verwendung eines Verfahrens nach einem der vorstehenden Ansprüche zur Konfiguration eines Mikroprozessorprogramms.
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 14, wobei die Mittel zum automatischen Konfigurieren der mindestens einen Funktionseinheit in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten aufweisen: – Mittel zum automatischen Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Abhä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 Informationen.
Softwaresystem nach Anspruch 14 oder 15, dadurch gekennzeichnet, dass das Softwaresystem Mittel zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 13 aufweist.
Softwaresystem mit Programmcodemitteln, um unter Berücksichtungen von Konfigurationsregeln implementierungsunabhängige Konfigurationsdateien zu erstellen oder zu verändern.
Softwaresystemprodukt, dadurch gekennzeichnet, dass ein Softwaresystem nach einem der Ansprüche 14 bis 17 auf einem Speicherelement gespeichert ist.
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 13 programmiert ist.
Verwendung eines Verfahrens, eines Softwaresystems, eines Softwaresystemprodukts oder einer Rechnereinheit nach einem der vorstehenden Ansprüche im Bereich des Kraftfahrzeugbaus.