DE19955002C2 - Modellierungsverfahren für Informationsmodelle zur konsistenten Repräsentation und/oder Speicherung von Systemelementen hierarchischer Systemstrukturen - Google Patents

Description

1. GEBIET DER ERFINDUNG

Die Erfindung betrifft ein Modellierungsverfahren für Informa­ tionsmodelle für die computergestützte Verarbeitung von System­ elementen. Insbesondere betrifft die Erfindung Modellie­ rungsverfahren hierarchisch darstellbarer Systemstrukturen so­ wie deren Anwendungsmöglichkeiten.

1.2. NACHTEILE DES STANDES DER TECHNIK

In der DE 195 38 240 A1 wird ein Verfahren und eine Vorrichtung zur Speicherung von Daten in einer Datenbasis offenbart, in dem die Objekte, die Beziehung zwischen den Objekten, die Merkmale der Objekte, die Merkmale der Beziehungen zwischen den Objek­ ten, die Verbindung zwischen den Objekten und deren Merkmalen sowie die Verbindung zwischen den Beziehungen und deren Merkma­ len in separaten Speicherbereichen abgelegt werden, um eine be­ liebige, auch nachträgliche Erweiterbarkeit der Datenbasis zu ermöglichen. Jedoch ist für die Systemelemente in dieser Daten­ struktur keine hierarchische Abbildungsmöglichkeit vorgesehen.

In der US 5,933,831 wird ein Verfahren und eine Vorrichtung zur Generierung und Visualisierung von Entity-Relationship-(ER)- Diagrammen aus der Introspektion einer relationalen Datenbank offenbart. Dieses Verfahren hat den Vorteil, dass Änderungen an der relationalen Datenbank in dem ER-Diagramm in Echt-Zeit an­ gezeigt werden können. Zudem ermöglicht dieses Verfahren, ein ER-Diagramm ausschnittsweise zu betrachten, was die Handhabung sehr vereinfacht. Ein besonderes Verfahren zum Aufbau der Da­ tenbasis für das entsprechende ER-Modell wird in der Erfindung aber nicht offenbart.

In der US 5,487,135 wird ein Verfahren und eine Vorrichtung zur Generierung von Regeln für regelbasierte Systeme, die auf ER- Diagrammen bzw. ER-Theorien aufbauen, offenbart. Diese neuen Regeln werden kompiliert und stehen dann als Programm-Modul für das regelbasierte System zur Verfügung, was die Erstellung von Software-Modulen für diese Systeme sehr vereinfacht. Auf die Problematik der Erstellung und Pflege des ER-Systems sowie des­ sen Abbildung in einer Datenbasis wird in dieser Schrift nicht eingegangen.

Ein Modell, gemäß dem Wortlaut dieser Beschreibung, ist eine Abstraktion von bestimmen Ausschnitten der Wirklichkeit. Da Ab­ straktionen im wesentlichen Vereinfachungen sind, beschreibt ein Modell somit eine vereinfachte Form eines für eine bestimm­ te Aufgabe relevanten Aspektes der Realität. In diesem Sinne soll das Modell stellvertretend sein für die Wirklichkeit.

Der Terminus "Informationsmodell" oder auch Datenbankmodell wird häufig bei der Entwicklung von Modellen für Anwendungspro­ gramme gebraucht, wobei diese Anwendungsprogramme bestimmte Vorgänge aus dem relevanten Bereich der Wirklichkeit nachvoll­ ziehen.

Der relevante Bereich der Wirklichkeit wird auch "System" ge­ nannt. Ein System besteht aus mehreren Systemelementen, die im folgenden auch Designelemente genannt werden. Je nach Komplexität des betrachteten Systems kann ein solches System unter Umständen sehr viele Designelemente besitzen. Diese Designelemente können in bestimmten Relationen zueinander stehen. Diese Relationen spiegeln den durch die Semantik des Systems gegebenen Zusammenhang zwischen den einzelnen Elementen wieder. Das Charakteristische eines Informationsmodells besteht darin, sämtliche Relationen zwischen den einzelnen Systemelementen zu erfassen, soweit sie für die Arbeitsabläufe oder die physikalischen Vorgänge in dem betrachteten System relevant sind und deren logische Abhängigkeiten untereinander genau zu erfassen. Nur auf diese Weise ist es möglich, zu einem späteren Zeitpunkt das Informationsmodell zur logischen Grundlage einer Datenbankanwendung oder eines Anwendungsprogrammes werden zu lassen und dann bestimmte Abläufe vorzugeben, die über 'Ursache-Wirkung'-Mechanismen das System dynamisch verändern. Eine solche Veränderung des Systems vollzieht sich durch Hinzufügen, durch Entfernen und durch Verändern des Wertes oder des Zustandes bestimmter Systemelemente.

Problematisch wird die logisch-korrekte und redundanzfreie Entwicklung eines Informationsmodells dann, wenn das System aus sehr vielen Systemelementen besteht. Hier besteht immer die Gefahr, daß der oder die Menschen, die das System entwickeln, bestimmte Zusammenhänge zwischen Systemelementen übersehen, wodurch das Modell die Wirklichkeit nur noch fehlerhaft wiederspiegelt. Sollen durch das Modell bestimmte Geschäftsabläufe erfaßt werden, besteht dann die Gefahr, daß durch solche Fehler bestimmte Lücken im Informationsfluß entstehen, deren Vorhandensein dann in der Praxis nicht hinnehmbar ist. Weiter besteht die Möglichkeit, daß durch eine unsaubere Strukturierung Inkonsistenzen im Modell sowie ungewollte Redundanzen auftreten, die bei der Anwendung des Informationsmodells in einem Anwendungsprogramm für weitere Fehler sorgen.

Die vorliegende Erfindung stellt sich daher die Aufgabe, ein Verfahren zur Entwicklung von Informationsmodellen zu schaffen, die weniger fehleranfällig sind, und bei denen die Wahrscheinlichkeit auch bei großen, komplexen Systemen mit einer großen Anzahl von Systemelementen hoch ist, die Abhängigkeiten zwischen den Systemelementen logisch korrekt und vollständig zu erfassen.

2. ZUSAMMENFASSUNG UND VORTEILE DER ERFINDUNG

Diese Aufgabe wird durch das Modellierungsverfahren gemäß Patentanspruch 1 gelöst.

Das erfinderische Verfahren ist in seinem Wesen äußerst generell. Das gemäß der Erfindung vorgeschlagene Verfahren läßt sich für Modellierungen beliebiger Systeme anwenden. Beispielhaft nur seien genannt physikalische Systeme, betriebswirtschaftliche Systeme, betriebliche Systeme, Hardwaresysteme oder Softwaresysteme, oder Mischungen aus vorgenannten Systemen.

Das erfinderische Verfahren wird im wesentlichen durch den Gedanken bestimmt, die in dem System vorhandenen Systemelemente oder Designelemente nicht sämtlich als logisch auf einer Ebene liegend zu betrachten. Vielmehr wird in die Vielzahl der Systemelemente eine hierarchische Struktur eingebracht, was seinerseits auf der Erkenntnis beruht, daß die Systemelemente oft so anordnungsfähig sind, daß auf einer jeweils höheren, logisch abstrakteren Ebene des Informationsmodells solche Systemelemente angeordnet werden, die eine logische Abstraktion von einem oder mehreren Systemelementen darstellen, die auf einer nächsttieferen Ebene im Informationsmodell liegen. Mit anderen Worten, Systemelemente auf einer niedrigeren Ebene sind abgeleitet von einem bestimmten Systemelement auf einer höheren Ebene, was mittels entsprechender Relationen 'Systemelement A ist abgeleitet von Systemelement B auf der darüberliegenden Ebene' ausgedrückt wird. Diese stufenweise oder ebenenweise strukturierte Darstellung von Systemelementen trägt dem dringenden Bedürfnis Rechnung, daß die Semantik eines Systems vom Entwickler des Informationsmodells leichter verstanden wird, da die Systemelemente in ihrer natürlichen Ordnung angeordnet sind, und bestimmte Werte oder Attribute von Systemelementen jeweils spezifisch auf der für sie semantisch richtigen Ebene zu finden sind. Besonders bevorzugt sind gemäß der vorliegenden Erfindung Informationsmodelle mit mehr als zwei Ebenen, insbesondere mit vier oder fünf Ebenen.

Unter konsistenter Repräsentation und/oder Speicherung von Systemelementen hierarchisch darstellbarer Systemstrukturen wird verstanden, die Systemelemente insbesondere sehr komplexer Systemstrukturen aus semantischer Sicht logisch korrekt, in vorteilhafter Weise redundanzarm oder redundanzfrei darstellen zu können.

Des Weiteren wird vorgeschlagen, Systemelemente, die auf einer gemeinsamen Ebene liegen, logisch miteinander zu verknüpfen. Solche Verknüpfungsrelationen werden unter anderem bestimmt durch die Eigenschaften der Systemelemente für das System, durch die inhaltliche Funktion und die semantische Bedeutung der Systemelemente. Die Relationen sind spezifisch für jedes System; in der Praxis häufig vorkommend sind z. B. die folgenden: 'Systemelement A ist kompatibel mit Systemelement B'; 'A ist inkompatibel mit B'; 'A ist Teil von B'; 'A ist verbunden mit B'; 'A ist mit B assoziiert', etc.

Das vorliegende, erfinderische Verfahren kann in vorteilhafter Weise mit dem sogenannten Entity-Relationship-Modell kombiniert werden. Auf diese Form der Modellierung wird weiter unten noch genauer Bezug genommen.

Des weiteren können mit dem vorliegenden Verfahren hierarchische Systemstrukturen beliebiger Strukturtiefe modelliert werden.

Weiter besteht die Möglichkeit zu einer strukturgleichen Umsetzung eines erfinderisch hergestellten Informationsmodells in ein relationales Datenbank-Management-System RDBMS.

Weiter besteht die Möglichkeit, eine beliebige, transformierte Umsetzung eines erfinderisch hergestellten Informationsmodells in ein beliebiges Speicherungssystem für das Informationsmodell zu schaffen.

Das Informationsmodell läßt sich in vorteilhafter Weise auch für industrielle Steuerungssysteme oder für Steuerungssysteme in Kraftfahrzeugen oder beliebigen, anderen Fahrzeugen aller Art einsetzen. Die oben erwähnten Designelemente können dann beispielsweise Frames, die auch als Rahmen bezeichnet werden, und Prozesse sein, auf die weiter unten näher eingegangen wird.

Insbesondere ist das erfinderische Konzept geeignet, Client-Server-Architekturen bei solchen Steuerungen abzubilden. Das erfinderische Verfahren eignet sich beispielsweise für Client-Server-Anwendungen in verteilten, integrierten Systemen unter Berücksichtigung starker Ressourcen-Einschränkung hinsichtlich CPU- und Memory-Ressourcen.

Die Grundkonzepte der vorliegenden Erfindung ermöglichen gerade in solchen Umgebungen einen ganzheitlichen Systementwurf, der leicht erweiterbar und leicht wiederverwendbar ist im Gegensatz zu dem steuergeräteorientierten Anwendungsentwurf vom Stand der Technik.

Das erfinderische Modellierungsverfahren kann ein Informationsmodell erzeugen, das als Anwendungsdatenmodell im Kontext und als Ausprägung abstrakterer Metamodelle aufgefaßt werden kann. Nur beispielhaft sei hier die dritte Ebene des IRDS-Standards genannt.

3. ZEICHNUNGEN

Ein Ausführungsbeispiel der Erfindung ist in den Zeichnungen dargestellt und wird in der nachfolgenden Beschreibung näher erläutert.

Es zeigen:

Fig. 1 ein schematisch dargestelltes Strukturdiagramm, das den groben Aufbau eines Informationsmodells gemäß der vorliegenden Erfindung, enthaltend 5 verschiedene Ebenen, darstellt,

Fig. 2A, B ein Auszug aus einer Tabelle für ein Untermodell einer Ebene aus Fig. 1, die gemäß dem erfinderischen Verfahren erzeugt wurde,

Fig. 3A, B ein Auszug aus einer Tabelle für ein Untermodell einer Ebene aus Fig. 1, die ebenfalls gemäß dem erfinderischen Verfahren erzeugt wurde.

4. GENAUE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Mit allgemeinem Bezug zu den Zeichnungen und besonderem Bezug zu Fig. 1 wird das erfindungsgemäße Modellierungsverfahren anhand eines spezifischen Beispieles und einer spezifisch gewählten Modellierungsform - der Entity-Relationship-Methode - erläutert, bei dem eine große Anzahl von Steuerungsfunktionen zum Einsatz in einem Kfz modelliert werden. Dies geschieht in zwei Stufen zum Zwecke der leichteren Verständlichkeit.

In Abschnitt 4.1 wird mit Bezug zu der Fig. 1 zunächst in das Thema des Ausführungsbeispiels eingeführt, und dann werden mit Bezug zu den Fig. 2 und 3 Auszüge aus Tabellen einer Ebene aus Fig. 1 erläutert, die konkrete Elemente des Informationsmodells auszugsweise darstellen.

In Abschnitt 4.2 wird dann das in 4.1 beschriebene Ausführungsbeispiel des erfinderischen Verfahrens vertieft dargestellt und dessen Vorzüge hinsichtlich leichter Erweiterbareit und Flexibilität für den mehrfachen Einsatz bei den verschiedensten Steuerungssystemen dargestellt.

4.1

Grundsätzlich werden sogenannte Entitätstypen über bestimmte Relationstypen miteinander verknüpft. Die Inhalte oder Ausprägungen eines Entitätstyps sind dessen Entitäten. Diese werden als eindeutig bestimmtes Modellierungsobjekt auch als Instanzen eines Entitätstyps bezeichnet. Entitätstypen sind dann Objekte höherer, abstrakterer Art, nämlich im allgemeinen Mengen von Instanzen. Für weitere Details zum Entity-Relationship-Ansatz wird auf die weiterführende Literatur verwiesen.

Das durch das erfindungsgemäße Verfahren bestimmte Vorgehen zur Erstellung eines Informationsmodelles definiert eine Mehrzahl von Modellierungsebenen unterschiedlicher Abstraktheit. Gemäß dem vorliegenden, bevorzugten Ausführungsbeispiel werden für das Modellierungsverfahren der vorliegenden Erfindung fünf Ebenen definiert, die jeweils eine ähnliche, innere Struktur besitzen, die ihrerseits jeweils durch bestimmte Entitätstypen besetzt sind. Damit gliedert sich das Modell hierarchisch in fünf Ebenen mit fast gleichbleibender Struktur auf. Dabei findet sich für jeden Entitätstyp A auf Ebene n = 2 . . 5 ein Enttitätstyp B als abstraktere Entsprechung von A auf Ebene n-1.

Zwischen A und B besteht dabei immer der Relationstyp 'ist abgeleitet von'. Daraus folgt, daß in diesem Beispiel ein Entitätstyp A sämtliche Eigenschaften all seiner Entsprechungen auf einer oder mehreren höheren Ebenen oder abstrakteren Ebenen erbt.

Die Notwendigkeit für ein vier- oder fünf-stufiges Modell speziell in diesem Hardware/Software-gemischten Steuerungssystem ergibt sich aus dem Anspruch, einen hierarchischen Systementwurf redundanzfrei zu beschreiben.

Inhalt und Aufgabe der fünf Ebenen wird im folgenden kurz umrissen.

Die höchste Ebene 10 wird als 'Typenebene' bezeichnet und legt die grundsätzlichen Komponenten eines Systementwurfs fest.

Die Entitätstypen der Typenebene und die jeweiligen dort angesiedelten Entitäten definieren alle SW- und HW- Designelemente, die für das Steuerungssystem relevant sind. Beispielswiese ist jedes in einem das erfinderische Verfahren wenigstens teilweise umsetzenden System-Design-Tool verwendbare Designelement durch eine entsprechende Entität auf der Typenebene repräsentiert, welches es zu einem gültigen Designelement des Systems macht.

Auf der zweithöchsten Ebene 12 - der Klassenebene - werden Klassen von Designelementen verankert, die Teile ihrer Eigenschaften von einer entsprechenden Entität auf der Typenebene erben. Die Entitäten der Klassenebene repräsentieren Klassen von System-Komponenten, die, sobald sie erstmalig definiert sind, während des Systementwurfs beliebig referenziert werden können, um weitere, abgeleitete Anwendungen zu entwerfen.

Auf der darunterliegenden 'Strukturebene' 14 wird einmalig die Struktur derjenigen Entwurfsobjekte abgelegt, die hierarchisch - d. h. unter Verwendung anderer und/oder gleichartiger Objekte - beschrieben werden. Werden Entwurfsobjekte in einem größeren Zusammenhang verwendet, wird dieser Gebrauch ausschließlich in Form von Verweisen auf die in der Strukturebene abgelegten Informationen beschrieben. Die Strukturebene bietet ein gewisses Maß an Transparenz bzgl. des Aufbaus von Designelement-Klassen, da sie ausschließlich definiert, welche Komponenten eine gegebene Klasse aufbauen, ohne dabei explizit die innere Struktur dieser Komponenten aufzulösen.

Um sowohl die innere Struktur des gerade betrachteten Systemelements als auch dessen gegebenenfalls mehrfache Verwendung innerhalb der nächsthöheren Designebene dokumentieren zu können, wird für Entitätstypen, die Systemelemente verwalten, die sowohl eine innere Struktur besitzen als auch andererseits Teil grösserer Strukturen sind, eine selbstbezügliche 'ist abgeleitet von'-Relation definiert.

Die Verweise auf die Strukturebene werden in der darunterliegenden 'Referenzenebene' 16 dokumentiert. Wenn während des Anwendungsentwurfs Referenzentitäten von Entitäten der Klassenebene abgeleitet werden, werden diese auf der Referenzebene verankert. Im selben Moment wird die Klasse ihrer Struktur nach bis zu atomaren Designelementen aufgelöst. Die hierfür notwendigen Informationen werden von der Strukturebene abgeleitet. Anschliessend werden Referenzen für alle die Klassenstruktur repräsentierenden Designelemente auf Referenzebene angesiedelt. Somit ist nach diesem Vorgang die komplette Struktur einer Designelementklasse auf der Referenzebene repliziert. Dies ist beispielsweise notwendig, um eine referenzspezifische Zuordnung von Datenwerten zu Datenelementen zu ermöglichen.

Prinzipiell kann die Auflösung der Struktur zu atomaren Designelmenten bei Bedarf auch schrittweise und zu einem späteren Zeitpunkt erfolgen, wenn dies beispielsweise aus Gründen vertretbarer Systemantwortzeiten in einem interaktiven Designwerkzeug angezeigt ist.

Es wäre möglich, die Klassenstruktur eines Designelementes auf der Referenzebene zu definieren, indem die Klassenstruktur dort als erste Referenz dieser Klasse verankert wird. Dies impliziert, daß die Strukturebene zur redundanzfreien Speicherung der Designinformationen nicht absolut notwendig ist.

Alle realen Entwurfsobjekte 20, 22, 24 stellen Instanzen aus der Referenzenebene 18 dar, die in dieser eigenständigen 'Instanzenebene' festgehalten werden.

Die Objekte der Instanzenebene sind als 'Blaupausen' für die Instanzen der realen Welt zu verstehen, die beispielsweise in jedem produzierten Kraftfahrzeug vorkommen. Letztere würden auf Ebene 4 im IRDS-Modell liegen, sind aber nicht Gegenstand des vorgeschlagenen Verfahrens, sondern stellen nur die Zielobjekte dessen in der realen Welt dar.

Mit Bezug zur inneren Struktur der Fig. 1 stellt diese ein sogenanntes Entity-Relationship-Diagramm dar und zeigt einen Ausschnitt eines gemäß des Verfahrens der vorliegenden Erfindung modellierten Informationsmodells zur Repräsentation und insbesondere zur Speicherung hierarchischer Designinformationen.

Im dargestellten Ausführungsbeispiel wird der vorliegende Gegenstand der Erfindung auf eine spezielle, hierarchische Softwaredesignmethode angewandt. In dieser Softwaredesignmethode stehen u. a. sogenannte Rahmen oder Frames, Prozesse, Verbindungen und Schnittstellen für den Systementwurf zur Verfügung. Diese Begriffe werden im folgenden kurz erklärt, soweit sie für das Verständnis der vorliegenden, erfinderischen Konzepte wichtig sind.

Frame

Ein Frame hat Schnittstellen nach außen und beinhaltet Prozesse, Verbindungen und ggf. weitere Frames für einen hierarchischen Systementwurf.

Prozess

Ein Prozess hat gleichartige Schnittstellen wie ein Frame und wird mit weiteren Prozessen oder den äusseren Schnittstellen eines der Frames, in dem er angesiedelt ist, über Verbindungen verbunden.

Auf Typenebene können beispielsweise folgende Designinformationen verwaltet werden:
Innerhalb des Entitätstyps Frame_Type gibt es folgenden Typ von Frames:
Frames für hierarchisches Design.

Innerhalb des Entitätstyps Process_Type gibt es folgende Typen von Prozessen:
Client/Server-Prozesse für eventorientierte Kommunikation,
PeerToPeer-Prozesse für PeerToPeer-Kommunikation,
Sonstige.

Innerhalb des Entitätstyps Connection_Type gibt es folgende Typen von Verbindungen:
Client/Server-Verbindungen,
PeerToPeer-Verbindungen,
Sonstige.

Innerhalb des Entitätstyps Interface_Type gibt es folgende Typen von Schnittstellen:
Client/Server-Schnittstellen,
PeerToPeer-Schnittstellen.

Auf Klassenebene können beispielsweise folgende Designinformation verwaltet werden:
Bezogen auf eine Frame-Klasse X wird verwaltet, welche Prozessklassen und Verbindungsklassen diese Frame-Klasse beinhalten kann und welche Schnittstellenklassen die Schnittstelle des Frames bilden können.

Auf Strukturebene können beispielsweise folgende Designinformation verwaltet werden:
Bezogen auf die Struktur der Frame-Klasse X wird verwaltet, welche Prozesse/Frames, abgeleitet von entsprechenden Prozess-/Frameklassen, diese Frame-Klasse beinhaltet, und wie diese mittels Verbindungen verbunden sind. Dies dokumentiert die innere Struktur der Frame-Klasse X. Ein Frame kann also weitere Frames beinhalten.

Auf Referenzebene können beispielsweise folgende Designinformation verwaltet werden:
Wird ein Frame der Frame-Klasse X in einem anderen Frame Y verwendet, so müssen zahlreiche der auf Strukturebene definierten Eigenschaften der Frame-Klasse X dupliziert werden, um sie den lokalen Anforderungen im Frame Y anzupassen. Die komplette Speicherung dieser referenzspezifischen Informationen geschieht auf der Referenzebene.

Auf Instanzebene können beispielsweise folgende Designinformation verwaltet werden:
Wenn ein erfinderischer Client/Server-Architektur(CSA)-Frame als Basis für die Instanziierung ausgewählt wird und damit zum Erstellen von Instanzen von all dessen, was dieser Frame beinhaltet, so werden die sich hierfür ergebenden Informationen auf Instanzebene gespeichert.

Wird schließlich eine Referenz der Frame-Klasse X real gemacht, d. h. instanziiert, so werden alle instanzrelevanten Informationen auf der Instanzebene gespeichert.

Desweiteren werden die meisten während des Implementierungsdesigns relevanten Informationen (Abbildung von erfinderischen CSA-Prozessen auf Betriebssystemtasks, CAN-IDs, timeout retransmit-Tabelleneinträge, Taskprioritäten) auf der Instanzebene verwaltet.

Auf den vier höheren Ebenen 16, 14, 12, 10 gibt es gemäß der vorliegenden Erfindung Entitätstypen, die lediglich der hierarchischen Systembeschreibung dienen. Diese haben keine Entsprechung im physikalischen System, weshalb ihnen keine Entitätstypen auf der Instanzenebene zugeordnet sind. Dies gilt im Ausführungsbeispiel für das Designelement Frame.

Im Gegensatz dazu würden in einem nicht-hierarchischen Entwurf vom Stand der Technik die konkreten Objekte des Entwurfs auf der Instanzenebene unmittelbar durch Instanziierung aus der Klassenebene abgeleitet.

Als Besonderheit dieses speziellen, hardware- und software­ bezogenen Informationsmodelles des Ausführungsbeispiels werden im folgenden gewisse Untermodelle beschrieben, die die Einordnung der Designobjekte in ihren semantischen Zusammenhang noch leichter machen.

Das beispielhaft skizzierte Informationsmodell teilt sich auf allen 5 Ebenen stets in zwei Teile auf, nämlich in das Software- und das Hardware-Untermodell.

Das Hardware-Untermodell beschreibt die für den Systementwurf relevanten 'Hardware'-Objekte oder - Komponenten wie CPUs, Steuergeräte, Sensoren, Aktuatoren und Kommunikationsmedien in dem betrachteten Steuerungssystem. Außerdem finden sich darin die Standard-Betriebs-Software und die Middleware, die für den Betrieb der genannten Komponenten erforderlich sind.

Dagegen dokumentiert das Software-Untermodell die Elemente der Anwendungs-Software, wie beispielsweise Frames oder Rahmen, Prozesse und Protokolle.

Beide Untermodelle können weitgehend unabhängig voneinander betrachtet werden. Zwischen ihnen bestehen nur wenige Querverbindungen, die die Abbildung der Software auf die Hardware beschreiben.

Sowohl das Software- als auch das Hardware-Untermodell sind wiederum auf allen 5 Ebenen in weitere Teilmodelle gegliedert. Beispiele für diese Untermodelle sind das sog. 'Implementation Submodel' oder das sogenannte 'Physical Design Submodel'.

Das gesamte Informationsmodell der vorliegenden Erfindung enthält grafische Darstellungen, so wie sie aus der Entity/Relationship-Methode bekannt sind, und enthält Tabellen, die die Elemente der grafischen Notation beschreiben.

Für das Erzeugen des Software- und des Hardware- Untermodelles und die Beschreibung des Inhalts der zugehörigen Typenebene ist in bevorzugter Weise jeweils eine Tabelle vorgesehen, die die Entitäten beschreibt. Auszüge solcher Tabellen sind für die Typenebene in Fig. 2 für das Hardware-Untermodell und in Fig. 3 für das Software- Untermodell abgebildet. Die Tabellen listen die Entitätstypen (EntityType-Spalte) auf, sammeln die zugehörigen Entitäten (Entity-Spalte) auf der jeweiligen Ebene und liefern eine Beschreibung der jeweiligen Entität hinsichtlich deren Systemfunktion. Die Beschreibung kann letztlich dazu verwendet werden, die relevanten Attributtypen des jeweiligen Entitätstyps zu identifizieren.

Beide Tabellen gehen von den Entitätstypen aus, die auf der Typenebene bestehen. Um das Verständnis zu erleichtern, können die jeweiligen Erläuterungen in diesen Tabellen Informationen, die sich auch auf weitere Ebenen des Modells beziehen, gleich mitenthalten. Es ist aber auch möglich und in verschiedenen Anwendungsszenarien sinnvoll, jede Ebene in dieser Form zu dokumentieren. In letzter Konsequenz stellt eine gefüllte, auf dem Informationsmodell basierende Datenbank die vollständige Definition und Dokumentation der Designelemente und der daraus gebildeten Systeme dar.

Wie aus Fig. 2A ersichtlich ist, gibt es z. B. einen Entitätstyp 'ACTUATOR_T', der drei verschiedene Ausprägungen in dem Steuerungssystem besitzt, und daher drei Entitäten auf Typenebene, nämlich einen analogen, einen binären und einen komplexen Aktuator enthält. Wenn ein Entitätstyp nur eine einzige Ausprägung besitzt, dann gibt es in der Tabelle auch nur eine einzige Entität, s. den Entitätstyp 'DOMAIN'.

In Fig. 2B folgen weitere Beispiele, die weitere Hardware- Entitätstypen sowie deren Entitäten zeigt. Aus Praktikabilitätsgründen ist in dem Hardwaremodell auch Software aufgeführt; jedoch handelt es sich dabei entweder um (Betriebs-) Systemsoftware oder um Software zum direkten Ansteuern einer zugehörigen Hardware.

In Fig. 3A und 3B sind analog zu oben Beispiele aus dem Software-Untermodell aufgelistet. Die Beispiele bedürfen keiner weiteren semantischen Erläuterung. Rekursive Strukturen sollten in den Tabellen nicht gebildet werden, da dies das Modell inkonsistent machen würde, unter anderem, weil die Rekursionsgrenzen nicht notwendigerweise Teil dieses Tabellenschemas sind.

Das oben beschriebene Ausführungsbeispiel kann prinzipiell direkt in eine relationale Datenbankimplementierung übersetzt werden.

4.2

Das nachfolgend geschilderte Ausführungsbeispiel zeigt exemplarisch einen Ausschnitt eines hierarchischen Systemdesigns und dokumentiert, wie die notwendigen Designinformationen innerhalb eines gemäss der vorliegenden Erfindung modellierten Informationsmodells verwaltet werden. Desweiteren werden die Vorteile des erfinderischen Verfahrens gegenüber dem Stand der Technik hinsichtlich der leichten Erweiterbarkeit der Informationsmodelle für andere Anwendungen klar, wie etwa Steuerungssysteme für Schiffe, Schienenfahrzeuge, oder etwa für mehrere Produktfamilien von Pkws, etwa Luxusautos, Mittelklasseautos und Kleinwagen.

Dem exemplarischen Systemdesign liegen folgende Annahmen zugrunde:
Es werden Prozessklassen zur Ansteuerung von Lampen modelliert.

Bezogen auf diese Prozessklassen gibt es eine spezifische Ausprägung für die Ansteuerung von Xenon-Lampen.

Xenon-Lampen mögen zum Zweck der Offenbarung der vorliegenden Erfindung eine andere Ansteuerung als konventionelle Glühbirnen verlangen.

Die jeweilige Ausprägung der Prozessklassen als Prozessreferenzen sei durch einen entsprechenden Attributtyp GERÄTETYP an semantisch korrekter Stelle auf der Referenzebene zu kennzeichnen, der ggf. mit dem Attribut XENON_LAMP versehen wird.

Es werden Frames für die Lampen des Abblendlichts definiert, und die Instanzebene wird exemplarisch für zwei konkrete Baureihen 8000 und 9000 der Modellplattform LUXURY_CAR dargestellt.

Für die Modellplattform LUXURY_CAR kommen für das Abblendlicht generell Xenon-Lampen zum Einsatz.

Dem Wesen seiner Allgemeinheit entsprechend kann das erfinderische Verfahren zur Herstellung von Informationsmodellen nun leicht erweiterbare Anwendungen erstellen, die dann je nach Einsatzzweck auf einer der 5 vorgenannten Ebenen neue Entitätstypen oder neue Entitäten definiert haben, die möglicherweise auch neue Relationen zu Entitätstypen innerhalb der gleichen Ebene oder zu der tiefer- bzw. Höher gelegenen Ebene aufweisen. Die Änderungen auf einer höheren Ebene setzen sich dann baumartig in die tieferen Ebenen fort. Je geringfügiger Änderungen im Anwendungssystem ausfallen, desto tiefer liegen die Ankerpunkte für Änderungen in dem Informationsmodell und umgekehrt. Daher kann die Systementwicklung für die beiden Baureihen 8000 und 9000 der Modellplattform LUXURY_CAR weitgehend für die Entwicklung der Modellplattform MIDSIZE_CAR oder für Kleinwagen verwendet werden; die Änderungen wären hier weitgehend erst in der Referenzebene zu treffen.

Frames haben in diesem Beispiel auf Instanzebene keine Relevanz mehr, da sie lediglich für den hierarchischen Systementwurf benötigt werden.

Die Baureihen 8000 und 9000 (Attributtyp BAUREIHE) haben jeweils ein spezifisches Steuergerätenetzwerk, was, bezogen auf die Instanzen der Prozesse in den Steuergeräten, bedeutet, dass sie auf andere Nachrichten auf dem Feldbussystem (z. B. CAN-Feldbus) hören und andere Nachrichten versenden. Die jeweiligen Kennzeichner dieser Nachrichten werden in den Attributtypen IN_MSG_ID und OUT_MSG_ID an semantisch korrekter Stelle auf der Instanzebene verwaltet.

Die oben erwähnten, anderen Modellplattformen hätten dann ebenso spezifische Netzwerke und unterschiedliche ausgebildete Instanzenebenen.

Auf Typenebene werden folgende Designinformationen verwaltet:
Innerhalb des Entitätstyps Frame_Type gäbe es nur eine Entität und somit einen Typ von Frames für den hierarchischen Systementwurf.
Attributtypen des Entitätstyps Frame_Type: NAME
STANDARD_FRAME.
Innerhalb des Entitätstyps Process_Type gäbe es drei Entitäten und somit drei Typen von Prozessen:
Attributtypen des Entitätstyps Process_Type: NAME:

• 1. CLIENT_SERVER_PROCESS,
• 2. FIRMWARE_PROCESS,
• 3. PEER_TO_PEER_PROCESS.

Die, bezogen auf den Entitätstyp Frame_Class selbstbezügliche "ist Teil von"-Relation enthält folgende Tabelleneinträge:
STANDARD_FRAME "ist Teil von" STANDARD_FRAME.

Diese Relation ist im vorliegenden Ausführungsbeispiel für den hierarchischen Systementwurf notwendig und bedeutet, dass ein Frame einen anderen beinhalten darf.

Für die Relation Process_Type "ist Teil von" Frame_Type gäbe es folgende Tabelleneinträge, die ausdrücken, welche Prozesstypen ein Frametyp enthalten darf:

CLIENT_SERVER_PROCESS "ist Teil von" STANDARD_FRAME,
FIRMWARE_PROCESS "ist Teil von" STANDARD_FRAME.

Auf Klassenebene werden folgende Designinformationen verwaltet, wobei weitere Prozess- und Frameklassen als Erweiterungen für andere Fahrzeuge, wie etwa Schiffe, Schienenfahrzeuge, also jeweils Gegenstände, die verteilte, integrierte Systeme aufweisen, hinzukämen, bzw. bereits vorhandene ersetzen würden.

Innerhalb des Entitätstyps Frame_Class gäbe es folgende Klassen von Frames:
Attributtypen des Entitätstyps Frame_Class: NAME

• 1. LAMP_CONTROL_FRAME_CLASS,
• 2. CAR_FRAME_CLASS.

Innerhalb des Entitätstyps Process_Class gäbe es folgende Klassen von Prozessen:
Attributtypen des Entitätstyps Process_Class: NAME:

• 1. LAMP_CONTROL_PROCESS_CLASS,
• 2. LAMP_DRIVER_PROCESS_CLASS.

Die, bezogen auf den Entitätstyp Frame_Class selbstbezügliche "ist Teil von"-Relation enthält folgende Tabelleneinträge:

LAMP_CONTROL_FRAME_CLASS "ist Teil von" CAR_FRAME_CLASS.

Für die Relation Process_Class "ist Teil von" Frame_Class gäbe es folgende Tabelleneinträge, die ausdrücken, welche Prozessklassen eine gegebene Frameklasse enthält.

LAMP_CONTROL_PROCESS_CLASS "ist Teil von" LAMP_CONTROL_FRAME_CLASS und
LAMP_DRIVER_PROCESS_CLASS "ist Teil von" LAMP_CONTROL_FRAME_CLASS.

Auf Strukturebene werden folgende Designinformationen verwaltet:
Innerhalb des Entitätstyps Frame_Struc seien zwei mögliche Strukturen der Frameklasse LAMP_CONTROL_FRAME und eine Struktur der Frameklasse CAR_FRAME_CLASS definiert.

Attributtypen des Entitätstyps Frame_Struc: NAME:

• 1. SINGLE_LAMP_CONTROL_FRAME_ANCHOR,
• 2. DOUBLE_LAMP_CONTROL_FRAME_ANCHOR,
• 3. CAR_FRAME_ANCHOR.

Für die Beschreibung der internen Struktur von CAR_FRAME_ANCHOR:

• 1. DOUBLE_LAMP_CONTROL_FRAME_STRUC_1.

Für die Beschreibung der inneren Struktur der ersten beiden Framestrukturen werden innerhalb des Entitätstyps Process_Struc folgende Einträge benötigt:
Attributtypen des Entitätstyps Process_Struc: NAME zur Verankerung der internen Struktur von LAMP_CONTROL_PROCESS_ANCHOR und LAMP_DRIVER_PROCESS_ANCHOR:

• 1. LAMP_CONTROL_PROCESS_ANCHOR,
• 2. LAMP_DRIVER_PROCESS_ANCHOR,

für die Beschreibung der internen Struktur von SINGLE_LAMP_CONTROL_FRAME_ANCHOR und
DOUBLE_LAMP_CONTROL_FRAME_ANCHOR:

• 1. LAMP_CONTROL_PROCESS_STRUC_1,
• 2. LAMP_CONTROL_PROCESS_STRUC_2,
• 3. LAMP_CONTROL_PROCESS_STRUC_3,
• 4. LAMP_DRIVER_PROCESS_STRUC_1,
• 5. LAMP_DRIVER_PROCESS_STRUC_2,
• 6. LAMP_DRIVER_PROCESS_STRUC_3.

Entsprechende Änderungen wären auf der Strukturebene durchzuführen, die dann auf den Änderungen der darüberliegenden Klassenebene aufsetzen würden und ein eigenes, neues Innenleben auf der Strukturebene aufweisen können. Beispielsweise gäbe es einen TRIPLE_LAMP_CONTROL_FRAME_ANCHOR für die Fahrscheinwerfer eines ICE-Triebkopfes, da dieser 3 Scheinwerfer für die Sicht nach vorne aufweist und ein Kfz nur 2. Entsprechend gäbe es dann statt vier wie oben sechs Prozesse.

Für die Relation Process_Struc "ist Teil von" Frame_Struc gäbe es folgende Tabelleneinträge, die ausdrücken, welche Prozesse eine gegebene Framestruktur enthält:

LAMP_CONTROL_PROCESS_STRUC_1 "ist Teil von" SINGLE_LAMP_CONTROL_FRAME_ANCHOR,
LAMP_DRIVER_PROCESS_STRUC_1 "ist Teil von" SINGLE_LAMP_CONTROL_FRAME_ANCHOR,
LAMP_CONTROL_PROCESS_STRUC_2 "ist Teil von" DOUBLE_LAMP_CONTROL_FRAME_ANCHOR,
LAMP_CONTROL_PROCESS_STRUC_3 "ist Teil von" DOUBLE_LAMP_CONTROL_FRAME_ANCHOR,
LAMP_DRIVER_PROCESS_STRUC_2 "ist Teil von" DOUBLE_LAMP_CONTROL_FRAME_ANCHOR,
LAMP_DRIVER_PROCESS_STRUC_3 "ist Teil von" DOUBLE_LAMP_CONTROL_FRAME_ANCHOR.

Die, bezogen auf den Entitätstyp Frame_Struc selbstbezügliche "ist abgeleitet von"-Relation enthält folgende Tabelleneinträge:

DOUBLE_LAMP_CONTROL_FRAME_STRUC_1 "ist Teil von" DOUBLE_LAMP_CONTROL_FRAME_ANCHOR.

Die, bezogen auf den Entitätstyp Frame_Struc selbstbezügliche "ist Teil von"-Relation enthält folgende Tabelleneinträge:

DOUBLE_LAMP_CONTROL_FRAME_STRUC_1 "ist Teil von" CAR_FRAME_ANCHOR.

Die, bezogen auf den Entitätstyp Process_Struc selbstbezügliche "ist abgeleitet von"-Relation enthält folgende Tabelleneinträge:

LAMP_CONTROL_PROCESS_STRUC_1 "ist abgeleitet von" LAMP_CONTROL_PROCESS_ANCHOR,
LAMP_CONTROL_PROCESS_STRUC_2 "ist abgeleitet von" LAMP_CONTROL_PROCESS_ANCHOR,
LAMP_CONTROL_PROCESS_STRUC_3 "ist abgeleitet von" LAMP_CONTROL_PROCESS_ANCHOR,
LAMP_DRIVER_PROCESS_STRUC_1 "ist abgeleitet von" LAMP_DRIVER_PROCESS_ANCHOR,
LAMP_DRIVER_PROCESS_STRUC_2 "ist abgeleitet von" LAMP_DRIVER_PROCESS_ANCHOR,
LAMP_DRIVER_PROCESS_STRUC_3 "ist abgeleitet von" LAMP_DRIVER_PROCESS_ANCHOR.

Auf Referenzebene werden folgende Designinformationen verwaltet:
Für den Entitätstyp Frame_Ref gäbe es zwei Referenzen auf bereits definierte Framestrukturen:
Attributtypen des Entitätstyps Frame_Ref: NAME:

• 1. LUXURY_CAR_FRAME_REF_1,
• 2. LOW_BEAM_CONTROL_FRAME_REF_1.

Für den Entitätstyp Process_Ref gäbe es folgende Referenzen auf bereits definierten Prozessstrukturen, bzw. in Fortsetzung des Aspekts der leichten Erweiterbarkeit oder Flexibilität für andere Einsatzbereiche gäbe es neue Entitäten als Referenzen auf dieser Ebene.

Attributtypen des Entitätstyps Process_Ref: NAME, GERÄTETYP:

• 1. LAMP_CONTROL_PROCESS_REF_1, XENON_LAMP,
• 2. LAMP_CONTROL_PROCESS_REF_2, XENON_LAMP,
• 3. LAMP_DRIVER_PROCESS_REF_1, XENON_LAMP,
• 4. LAMP_DRIVER_PROCESS_REF_2, XENON_LAMP.

Für die Relation Process_Ref "ist Teil von" Frame_Ref gäbe es folgende Tabelleneinträge, die ausdrücken, welche Prozessreferenzen eine gegebene Framereferenz enthalten:

LAMP_CONTROL_PROCESS_REF_1 "ist Teil von" LOW_BEAM_CONTROL_FRAME_REF_1,
LAMP_CONTROL_PROCESS_REF_2 "ist Teil von" LOW_BEAM_CONTROL_FRAME_REF_1,
LAMP_DRIVER_PROCESS_REF_1 "ist Teil von" LOW_BEAM_CONTROL_FRAME_REF_1,
LAMP_DRIVER_PROCESS_REF_2 "ist Teil von" LOW_BEAM_CONTROL_FRAME_REF_1.

Die, bezogen auf den Entitätstyp Frame_Ref selbstbezügliche "ist Teil von"-Relation enthält folgende Tabelleneinträge:

LOW_BEAM_CONTROL_FRAME_REF_1 "ist Teil von" LUXURY_CAR_FRAME_REF_1.

Für Modifikationen des Informationsmodells für andere Modellplattformen oder Baureihen wie etwa MIDSIZE_CAR würden sich auch auf Referenzebene entsprechend zu den weiter oben vorgenommenen Änderungen andere Entitäten ergeben. Für technisch andersartige Systeme als Kfz, also etwa Flugzeuge, sind auch neue Entitätstypen denkbar.

Auf Instanzebene werden folgende Designinformationen verwaltet:
Für den Entitätstyp Process_Inst gäbe es folgende Instanzen, die zur Ansteuerung des Abblendlichts in den beiden Baureihen 8000 und 9000 unter Berücksichtigung unterschiedlicher Steuergerätenetzwerktopologie, insbesondere unterschiedliche Eingangs- und Ausgangsnachrichten, bezogen auf den CAN-Bus, benötigt werden.

Wären beispielsweise für die auf Referenzebene angedeutete Framereferenz MIDSIZE_CAR auch schon konkrete Baureihen definiert, wüden sich für diese Baureihen konkrete Einträge in der folgenden Tabelle ergeben, die die spezifischen Steuergeräte und Netzwerkstrukturen in dieser Baureihe reflektieren. CAN-Identifier und Nachrichten würden dann eben in entsprechender Weise spezifisch dokumentiert.

Attributtypen des Entitätstyps Process_Inst: NAME, BAUREIHE, IN_MSG_ID, OUT_MSG_ID:

• 1. LAMP_CONTROL_PROCESS_INST_1, 8000, 93, 46,
• 2. LAMP_CONTROL_PROCESS_INST_2, 8000, 103, 47,
• 3. LAMP_DRIVER_PROCESS_INST_1, 8000, 46, NULL,
• 4. LAMP_DRIVER_PROCESS_INST_2, 8000, 47 NULL,
• 5. LAMP_CONTROL_PROCESS_INST_3, 9000, 12, 77,
• 6. LAMP_CONTROL_PROCESS_INST_4, 9000, 15, 96,
• 7. LAMP_DRIVER_PROCESS_INST_3, 9000, 77, NULL,
• 8. LAMP_DRIVER_PROCESS_INST_4, 9000, 96, NULL.

Als Relationen zwischen Typen- und Klassenebene werden folgende Informationen verwaltet:
Zwischen Entitätstyp Frame_Class auf Klassenebene und Entitätstyp Frame_Type auf Typenebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

LAMP_CONTROL_FRAME_CLASS "ist abgeleitet von" STANDARD_FRAME,
CAR_FRAME_CLASS "ist abgeleitet von" STANDARD_FRAME.

Zwischen Entitätstyp Process_Class auf Klassenebene und Entitätstype Process_Type auf Typenebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

LAMP_CONTROL_PROCESS_CLASS "ist abgeleitet von" CLIENT_SERVER_PROCESS,
LAMP_DRIVER_PROCESS_CLASS "ist abgeleitet von" FIRMWARE_PROCESS.

Als Relationen zwischen Struktur- und Klassenebene werden folgende Informationen verwaltet:
Zwischen Entitätstyp Frame_Struc auf Strukturebene und Entitätstyp Frame_Class auf Klassenebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

SINGLE_LAMP_CONTROL_FRAME_ANCHOR "ist abgeleitet von" LAMP_CONTROL_FRAME_CLASS,
DOUBLE_LAMP_CONTROL_FRAME_ANCHOR "ist abgeleitet von" LAMP_CONTROL_FRAME_CLASS,
CAR_FRAME_ANCHOR "abgeleitet von" CAR_FRAME_CLASS.

Zwischen Entitätstyp Process_Struc auf Strukturebene und Entitätstype Process_Class auf Klassenebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

LAMP_CONTROL_PROCESS_ANCHOR "ist abgeleitet von" LAMP_CONTROL_PROCESS_CLASS,
LAMP_DRIVER_PROCESS_ANCHOR "ist abgeleitet von" LAMP_DRIVER_PROCESS_CLASS.

Als Relationen zwischen Referenz- und Strukturebene werden folgende Informationen verwaltet:
Zwischen Entitätstyp Frame_Ref auf Referenzebene und Entitätstyp Frame_Struc auf Strukturebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

LOW_BEAM_CONTROL_FRAME_REF_1 "ist abgeleitet von" DOUBLE_LAMP_CONTROL_FRAME_STRUC_1,
LUXURY_CAR_FRAME_REF_1 "abgeleitet von" CAR_FRAME_ANCHOR.

Zwischen Entitätstyp Process_Ref auf Referenzebene und Entitätstype Process_Struc auf Stukturebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

LAMP_CONTROL_PROCESS_REF_1 "ist abgeleitet von" LAMP_CONTROL_PROCESS_STRUC_2,
LAMP_CONTROL_PROCESS_REF_2 "ist abgeleitet von" LAMP_CONTROL_PROCESS_STRUC_3,
LAMP_DRIVER_PROCESS_REF_1 "ist abgeleitet von" LAMP_DRIVER_PROCESS_STRUC_2,
LAMP_DRIVER_PROCESS_REF_2 "ist abgeleitet von" LAMP_DRIVER_PROCESS_STRUC_3.

Als Relationen zwischen Instanz- und Referenzebene werden folgende Informationen verwaltet:
Zwischen Entitätstyp Process_Inst auf Instanzebene und Entitätstype Process_Ref auf Referenzebene existieren für die "ist abgeleitet von"-Relation folgende Tabelleneinträge:

LAMP_CONTROL_PROCESS_INST_1 "ist abgeleitet von" LAMP_CONTROL_PROCESS_REF_1,
LAMP_CONTROL_PROCESS_INST_2 "ist abgeleitet von" LAMP_CONTROL_PROCESS_REF_2,
LAMP_DRIVER_PROCESS_INST_1 "ist abgeleitet von" LAMP_DRIVER_PROCESS_REF_1,
LAMP_DRIVER_PROCESS_INST_2 "ist abgeleitet von" LAMP_DRIVER_PROCESS_REF_2,
LAMP_CONTROL_PROCESS_INST_3 "ist abgeleitet von" LAMP_CONTROL_PROCESS_REF_1,
LAMP_CONTROL_PROCESS_INST_4 "ist abgeleitet von" LAMP_CONTROL_PROCESS_REF_2,
LAMP_DRIVER_PROCESS_INST_3 "ist abgeleitet von" LAMP_DRIVER_PROCESS_REF_1,
LAMP_DRIVER_PROCESS_INST_4 "ist abgeleitet von" LAMP_DRIVER_PROCESS_REF_2.

Das oben beschriebene Ausführungsbeispiel kann gemäß der vorliegenden Erfindung prinzipiell direkt in eine relationale Datenbankimplementierung übersetzt werden.

Obwohl die vorliegende Erfindung anhand eines bevorzugten Ausführungsbeispiels vorstehend beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Weise modifizierbar.

Weiter kann der Gegenstand der vorliegenden Erfindung in Hardware, Software oder einer Kombination aus beiden realisiert werden. Eine beliebige Art von Computersystem oder Computergeräten ist dafür geeignet, das erfindungsgemäße Verfahren ganz oder in Teilen durchzuführen. Eine typische Hardware-Software-Kombination wäre ein normaler Computer mit einem Computerprogramm, das, wenn es geladen und ausgeführt wird, den Computer derart steuert, daß er das erfindungsgemäße Verfahren ganz oder in Teilen ausführt.

Die vorliegende Erfindung kann auch in ein Computerprogramm- Erzeugnis eingebettet sein, das sämtliche Merkmale enthält, die eine Implementierung der hierin beschriebenen Verfahren ermöglichen, und die, wenn sie in ein Computersystem geladen wird, dazu imstande ist, diese Verfahren auszuführen.

Computerprogrammeinrichtungen oder Computerprogramme bedeuten im vorliegenden Kontext beliebige Ausdrücke in einer beliebigen Sprache oder Notation oder einem beliebigen Code eines Satzes von Anweisungen, die ein System mit einer Informationsverarbeitungsmöglichkeit dazu veranlassen sollen, von den folgenden Funktionen:

• a) Umsetzung in eine andere Sprache oder Notation oder einen anderen Code,
• b) Reproduktion in eine unterschiedliche, materielle Form

eine bestimmte entweder direkt oder nacheinander oder beide durchzuführen.

Insbesondere kann die Anzahl der Modellierungsebenen variiert, eine andere als die Entity-Relationship-Methode verwendet und das erfinderische Verfahren ganz oder in Teilen in Tools umgesetzt werden, die das Verfahren ganz oder in Teilen computergestützt durchführen.

Claims (10)

1. Modellierungsverfahren für Informationsmodelle zur konsistenten Repräsentation und/oder Speicherung von Systemelementen hierarchisch darstellbarer Systemstrukturen, enthaltend den Schritt:
Relationen zwischen Systemelementen zu identifizieren, wobei das Verfahren gekennzeichnet ist durch den Schritt:
die Systemelemente in einer hierarchischen Struktur, bestehend aus wenigstens zwei Ebenen, zu ordnen, wobei die jeweils höhere Ebene Systemelemente trägt, die eine Abstraktion der auf einer bezüglich der höheren Ebene niedrigeren Ebene enthaltenen Systemelemente darstellen, und wobei Attribute von Systemelementen auf einer jeweils semantisch geeigneten Ebene angeordnet sind.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zwischen Systemelementen verschiedener Ebenen die Beziehung "ist abgeleitet von" definiert wird.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Relationen gemäß dem Entity-Relationship-Modell gebildet werden.

4. Verfahren nach dem vorstehenden Anspruch, dadurch gekennzeichnet, dass die Systemelemente in einer Struktur geordnet sind, die eine übergeordnete Typenebene, eine darunterliegende Klassenebene, eine darunterliegende Strukturebene, eine darunterliegende Referenzebene und eine darunterliegende Instanzebene enthält.

5. Verfahren nach dem vorstehenden Anspruch, dadurch gekennzeichnet, dass es den Schritt enthält:
anwendungsgetriebene Relationen zwischen den Elementen einer Ebene und/oder den Elementen wenigstens einer benachbarten Ebene zu bilden.

6. Verfahren nach dem vorstehenden Anspruch, dadurch gekennzeichnet, dass es den Schritt enthält:
einem Systemelement auf einer niedrigeren Ebene Eigenschaften eines Systemelementes auf einer höheren Ebene zu vererben.

7. Verfahren nach dem vorstehenden Anspruch, dadurch gekennzeichnet, dass die Systemelemente von wenigstens zwei Ebenen auf einer Ebene repräsentiert und/oder zusammengefasst werden.

8. Verwendung des Verfahrens nach einem der Ansprüche 1 bis 6 zur Entwicklung eines computergestützten Datenbanksystems.

9. Verwendung nach Anspruch 8 für ein computerbasiertes Steuerungssystem.

10. Verwendung nach Anspruch 9, bei der das computerbasierte Steuerungssystem zur Steuerung von Komponenten eines Kraftfahrzeugs, einer industriellen Steuerungsanlage oder einer sonstigen, verteilten Steuerungsanlage ausgebildet ist.