WO2006100078A1 - Vergleich von schnittstellen zwischen softwarekomponenten - Google Patents

Abstract

Die Erfindung betrifft ein Verfahren zur Überprüfung der Kompatibilität zwischen zwei Softwarekomponenten eines Steuergerätenetzwerks, wobei jeder Softwarekomponente wenigstens eine technische Schnittstellenbeschreibung zugeordnet ist, die einem bestimmten Beschreibungsstandard zugehört, und wobei jeder Beschreibungsstandard eine hierarchische Position in einer Vererbungshierarchie aller möglichen Beschreibungsstandards aufweist, wobei anhand der Vererbungshierarchie der in der Vererbungshierarchie nächstliegendste gemeinsame Beschreibungsstandard der zu vergleichenden Softwarekomponenten ermittelt wird und anhand des gemeinsamen Beschreibungsstandards der gemeinsame Anteil der jeweiligen Schnittstellenbeschreibungen ermittelt und miteinander verglichen wird.

Description

Vergleich von Schnittstellen zwischen Softwarekomponenten

Die Erfindung betrifft ein Verfahren zur Überprüfung der Kompatibilität zwischen zwei Softwarekomponenten, wobei jeder Softwarekomponente wenigstens eine technische Schnittstellenbeschreibung zugeordnet ist, die einem bestimmten Beschreibungsstandard zugehört.

Nahezu alle regelungstechnischen Systeme eines Automobils beinhalten heute Software. Die Software gilt als Wegbereiter für die meisten technischen Innovationen der vergangenen Jahre. Implementiert in einem Steuergerät, steuert und regelt Software heute unter anderem Motoren, Getriebe oder Sicherheits- und Komfortsysteme.

Mit zunehmender Anzahl an Anwendungsgebieten steigt die Anzahl regelungstechnisch realisierter Funktionen und damit auch die Komplexität. Die rasante Entwicklung stellt die Automobilhersteller heute vor große Herausforderungen um Qualität und die Entwicklungskosten von Software beiderseits auf moderatem Niveau zu halten. Der lange Lebenszyklus von automotiver Software (ca. 4 Jahre Entwicklung, ca. 8 Jahre Produktion und ca. 10 Jahre Reproduzierbarkeit mit Service) spielt dabei eine große Rolle. Während in den ersten vier Jahren enorme Entwicklungs- und Testkosten zu Buche schlagen, können in den Jahren wo das Auto produziert wird, hohe Kosten bei der Verwaltung von Varianten entstehen, dies vor allem bedingt durch unterschiedliche Softwarestände und Heterogenität bei der verwendeten Steuergerätehardware.

Um diese Probleme zu lösen, setzt die Automobilindustrie auf eine Standardisierung der Elektronikkomponenten. Zielsetzung ist es, über die Grenzen der einzelnen Fahrzeughersteller hinweg, offene Standards für Elektrik/Elektronik (E/E) Architekturen auf dem Automobilsektor zu schaffen. Zu den aktuellen softwaretechnischen Standards zählen AUTOSAR, MSR SW DTD oder EAST-EEA. Innerhalb der E/E Architekturen werden dabei verstärkt Softwarearchitekturen entworfen, deren wesentlicher Bestandteil Softwarekomponenten sind.

Die Softwarekomponenten repräsentieren Softwarebaussteine die speziell im Hinblick auf Wiederverwendung entworfen werden und ihre geschlossene Funktionalität durch ihre vertraglich spezifizierten Schnittstellen veröffentlichen.

Vertraglich spezifizierte Schnittstellen sind eindeutige Beschreibungen über das einerseits geforderte Verhalten als auch über das andererseits gebotene Verhalten von Softwarekomponenten. Vertraglich spezifizierte Schnittstellen reduzieren demnach die Verflechtung des Systems. Somit können Softwarekomponenten unabhängig voneinander entwickelt, gewartet, installiert und zusammengesetzt werden.

Die Standardisierung der vertraglich spezifizierten Schnittstellen über offene Standards gewährleistet darüber hinaus, dass Softwarekomponenten untereinander interoperabel sind, was ihre wichtigste Eigenschaft die Wiederverwendung vereinfacht. Eine Softwarekomponente die beispielsweise einen Teil einer Regelung eines Anti-Blockiersystems (ABS) umfasst, wird damit (OEM) Original Equipment Manufacturer -übergreifend nutzbar.

Auf Softwarekomponenten basierende E/E Architekturen ermöglichen aufgrund ihrer Wiederverwendbarkeit damit auch eine bessere Wartbarkeit und Aktualisierung der Systeme und unterstützen darüber hinaus durch die verbesserte Entkopplung der Steuergerätesoftware von der Hardware verstärkt den kommerziellen Einsatz von „Steuergeräten von der Stange".

Rein technisch betrachtet bestehen die vertraglich spezifizierten Schnittstellen der Softwarekomponenten zum einen aus der Veröffentlichung einer Sammlung von Operationen die von einer anderen Softwarekomponente als Dienst in Anspruch genommen werden können und zum anderen aus der vertraglichen Spezifikation der Schnittstelle selbst.

Eine sehr einfache Betrachtungsweise auf die vertraglich spezifizierten Schnittstellen ist, zwischen Dienstanbietern und Klienten zu unterscheiden. Dienstanbieter können beispielsweise Softwarekomponenten sein, die bestimmte Dienste implementieren und anbieten und Klienten können Softwarekomponenten sein, die bestimmte Dienste von Dienstanbietern in Anspruch nehmen. Dabei gibt die vertraglich spezifizierte Schnittstelle darüber Auskunft, welche Bedingungen erfüllt sein müssen, um ein erfolgreiches Zusammenspiel von Dienstanbietern und Klienten zu ermöglichen. Inhalte vertraglich spezifizierter Schnittstellen sind daher einerseits eine vertragliche Beschreibung dessen was der Klient vom Dienstanbieter an Diensten und Verhalten fordert (geforderte Schnittstelle) und gleichermaßen eine vertragliche Beschreibung dessen, was der Dienstanbieter unter bestimmten Vorraussetzungen an Diensten mit einem bestimmten Verhalten anbietet (gebotene Schnittstelle).

Die technische Beschreibung einer vertraglich spezifizierten Schnittstelle teilt sich in zwei Teile auf; einem funktionalen und einem nichtfunktionalen Teil. Zum funktionalen Anteil zählen beispielsweise Namen und Signaturen von Operationen und Datenelementen die zwischen zwei Softwarekomponenten ausgetauscht werden können. Zum nichtfunktionalen Teil zählt hauptsächlich das Verhalten der Softwarekomponente. Dazu zählen technischen Größen wie zum Beispiel das Antwortzeitverhalten in Millisekunden [ms] oder der Ressourcenverbrauch in Kilobyte [Kb], oder auch beispielsweise der genaue Ort bzw. die Angabe des Steuergerätes wo die Softwarekomponente zu Ausführung kommen soll.

Als Beispiel für die Beschreibung des nichtfunktionalen Anteils bzw. für das Verhalten einer Softwarekomponente diene eine Software komponente (Dienstanbieter) mit einer Funktionsbibliothek für die Berechnung von Einspritzmengen von Kraftstoffen, die von einer anderen Softwarekomponente (Klient), einer Steuerungs-Komponente der elektronischen Kraftstoffeinspritzung genutzt wird. Im Laufe der Zeit wird die Funktionsbibliothek so verbessert, dass die berechneten Einspritzmengen immer genauer wurden, jedoch zum Nachteil der Rechenzeit. Dies kann zur Folge haben, dass die Einspritzmenge nicht mehr in Real- Time an die Steuerungs-Komponente zurückgemeldet wird und die beiden Softwarekomponenten nicht mehr fehlerfrei zusammenwirken. Anhand dieses Beispiels ist ersichtlich, dass für die Beschreibung des nichtfunktionalen Anteils, die Festlegung des Antwortzeitverhaltens ein wichtiger „Vertragsbestandteil" ist.

Mit zunehmender Größe von Systemen zum Beispiel einem Steuergeräte-Netzwerk, wächst die Bedeutung einer Gesamtübersicht oder Architektursicht auf das System und damit einer Beschreibung aller im System befindlichen Softwarekomponenten und ihrer Interaktion untereinander, einschließlich den im System verfügbaren Recheneinheiten. Diese Beschreibung wird daher auch als Architekturbeschreibung bezeichnet. Für den Entwickler oder besser den Software-Architekt, der sich mit dem „Zusammenbau" von Softwarekomponenten und dem Verteilen von Softwarekomponenten auf verschiedene Recheneinheiten beschäftigt, stellt die Architekturbeschreibung eine wichtige Vorstufe für die spätere Implementierung dar, da die Architekturbeschreibung als eine Empfehlung für den Bauplan einer späteren Implementation gesehen werden kann. Durch die Möglichkeit Architekturen und Architekturbeschreibungen auch mit objektorientierten Ansätzen in Bezug zu bringen, besteht ferner die Möglichkeit, Vererbungsprinzipien z.B. aus der objektorientierten Sprachwelt in die abstraktere Architektursicht fortzuschreiben. Damit beschränkt sich die geforderte Wiederverwendung nicht nur auf Softwarekomponenten sondern auch auf die Wiederverwendung von Architekturen und Architekturbeschreibungen.

Anhand der Beschreibungen von Softwarekomponenten und Architekturen lassen sich Analysen betreiben, die die Softwarekomponenten bzw. die Architektur hinsichtlich ihrer Eigenschaften bewerten. Beispielsweise lassen sich aus den Beschreibungen der Softwarekomponenten Verträglichkeitsüberprüfungen für ein erfolgreiches Zusammenspiel von Softwarekomponenten durchführen oder die voraussichtlichen Antwortzeiten für Botschaften innerhalb des Systems abschätzen. Auf diese Weise kann der Entwickler schon zum Zeitpunkt des Architekturdesigns mögliche Engpässe bei der Erfüllung wichtiger Anforderungen aufdecken und frühzeitig, weit vor dem Zeitpunkt der Implementierung, Gegenmaßnahmen treffen. Bei dem Entwurf oder dem Design von Architekturen werden Entwickler heute von modellbasierten Architekturwerkzeugen unterstützt.

Dabei wird die Architektur eines Systems grafisch mit dem Architekturwerkzeug auf dem Bildschirm entworfen. In einem ersten Schritt komponiert der Entwickler eine Anzahl von Softwarekomponenten und Recheneinheiten zu einem System.

Die Schnittstellen der Softwarekomponenten werden dabei entsprechend miteinander verschaltet. Ferner erfolgt eine Verteilung der Softwarekomponenten auf die Recheneinheiten auf denen später die Softwarekomponenten zur Ausführung kommen sollen. Dieser Vorgang wird im allgemeinen auch als „Matching" bezeichnet.

Figur 1 zeigt zunächst der UML Schnittstellen-Notation sehr ähnlich zwei Softwarekomponenten die über Schnittstellen miteinander verbunden sind und auf dem Steuergerät A zur Ausführung gebracht werden. Figur 2 zeigt ein etwas komplexeres Beispiel mit mehreren Softwarekomponenten und mehreren Recheneinheiten (Steuergerät = Electronic Control Unit) nach erfolgtem „Matching".

Bei dem Verschalten von Softwarekomponenten kann der Entwickler Verträglichkeitsüberprüfungen vornehmen. Beispielsweise kann er überprüfen, ob die gebotene Schnittstelle einer Softwarekomponente die Eigenschaften der geforderten Schnittstelle erfüllt. Für die Verträglichkeitsüberprüfung ermittelt das Architekturwerkzeug anhand der vertraglich spezifizierten Schnittstellen beider Softwarekomponenten Unterschiede und teilt diese dem Entwickler mit.

Der Vergleich erfolgt konkret durch den Vergleich der Beschreibungen der vertraglich spezifizierten Schnittstellen. Ähnlich anderer automotiver Standards wie z.B. OSEK/VDX oder ASAM müssen auch die Beschreibungen der vertraglich spezifizierten Schnittstellen von Softwarekomponenten über eine formal einheitliche respektive technisch standardisierte Definition ihrer Inhalte, ihres strukturellen Aufbaus und ihres Formats verfügen. Ein Vergleich wäre sonst nicht so ohne weiteres möglich. Grundvoraussetzung für eine werkzeuggestützte Modellierung und einer Analyse oder einem ersten Test von Architekturen ist daher eine formale Beschreibung aller Bausteine einer Architektur, einschließlich der formalen Beschreibung der vertraglich spezifizierten Schnittstellen der Softwarekomponenten.

Das eigentlich technische Problem ist, dass es unterschiedliche Typen, Varianten oder Versionen eines Standards von technischen Softwarekomponentenbeschreibungen geben kann. Damit ist ein Vergleich ausschließlich auf Parameterebene (technische Größe und Einheit) nicht mehr so ohne weiteres möglich, da es andere Formate oder zusätzliche oder geänderte Kenngrößen in den Softwarekomponentenbeschreibungen geben kann.

Ein großer Nachteil besteht heute darin, dass derzeit für jeden Typ, Variante oder Version eines Standards einer technischen Beschreibung von Softwarekornponenten eine eigene Variante eines Architekturwerkzeugs für die Beschreibung von Softwarekomponenten vorausgesetzt wird. Architekturwerkzeuge können zwar mehrere Standards unterstützen, aber immer nur in einzelnen in sich abgeschlossenen Systemen. Ein Vergleich von Softwarekomponenten mit unterschiedlichen Standards in einer gemeinsamen Architektur war bisher nur schwer möglich. So ist es beispielsweise besonders schwierig und aufwändig eine Softwarekomponente vom Zulieferer A mit einer Softwarekomponente vom Zulieferer B zu verschalten, wenn die Beschreibungen der vertraglich spezifizierten Schnittstellen beider Softwarekomponenten unterschiedlichen Typen, Varianten oder Versionen von Beschreibungsstandards zugehören. Der Vergleich kann nur manuell mit hohem Aufwand erfolgen.

Die Aufgabe der vorliegenden Erfindung ist es, bei dem Verschalten von Softwarekomponenten die gebotenen und geforderten Schnittstellen überprüfen zu können, obwohl sie möglicherweise über unterschiedliche Typen, Varianten oder Versionen von Beschreibungsstandards verfügen, um im Entwicklungsprozess möglichst frühzeitig qualitative Aussagen zu der Verträglichkeit zwischen Softwarekomponenten zu bekommen.

Die Aufgabe wird dadurch gelöst, dass jeder Beschreibungsstandard eine hierarchische Position in einer Vererbungshierarchie aller möglichen Beschreibungsstandards aufweist, wobei anhand der Vererbungshierarchie der in der Vererbungshierarchie nächstliegendste gemeinsame Beschreibungsstandard der zu vergleichenden Softwarekomponenten ermittelt wird und anhand des gemeinsamen Beschreibungsstandards der gemeinsame Anteil der jeweiligen Schnittstellenbeschreibungen ermittelt und miteinander verglichen wird. So kann erfindungsgemäß mit einer Beschreibungsstandard-Vererbungshierarchie ein Verträglichkeitstest zwischen Softwarekomponenten durchgeführt werden.

Dabei wird zunächst jede Softwarekomponentenbeschreibung bzw. jede Schnittstellenbeschreibung einer Softwarekomponente einer Position in einer Vererbungshierarchie der Beschreibungsstandards zugeordnet. Anhand der Vererbungshierarchie wird der nächstliegendste gemeinsame Beschreibungsstandard zweier Schnittstellenbeschreibungen ermittelt.

So können bevorzugt die Schnittstellenbeschreibungen der zu vergleichenden Softwarekomponenten anhand der Festlegungen in dem nächstliegenden gemeinsamen Beschreibungsstandard verglichen werden. Auf diese Weise werden Verträglichkeiten aber auch Unverträglichkeiten zwischen den Schnittstellenbeschreibungen der Softwarekomponenten aufgedeckt.

Da dieser Verträglichkeitstest zu einem sehr frühen Zeitpunkt im Entwicklungsprozess eines Steuergerätes durchgeführt werden kann (unter Umständen noch bevor die Software implementiert wird), lassen sich im Falle von Unverträglichkeiten zusätzliche Kosten für nachträgliche Änderungen an der Implementation bzw. an bereits erstellter Software einsparen.

Zur Lösung dieser Aufgabe waren zunächst technische Überlegungen erforderlich. Diese beruhten darauf, dass technische Beschreibungen von Softwarekomponenten, also z.B. die technischen Schnittstellenbeschreibungen nur dann miteinander verglichen werden können, wenn beide technischen Beschreibungen zumindest zu einem Teil einem gemeinsamen Beschreibungsstandard angehören.

Für die weitere Präzisierung der Erläuterung der zur Rede stehenden Erfindung, soll ein Beispiel mit vier Softwarekomponenten angeführt werden. Figur 2 zeigt dieses Beispiel. Die Softwarekomponenten 1 bis 4 verfügen jeweils über Schnittstellen, über die sie mit anderen Softwarekomponenten kommunizieren.

Jeder der Schnittstellen wird ein Beschreibungsstandard zugeordnet. Im dargestellten Beispiel verfügt die Softwarekomponente 1 über die Schnittstellen 1.1 und 1.2 . Beide Schnittstellen verfügen über Schnittstellenbeschreibungen vom Beschreibungsstandard Typ C.

Schnittstellenbeschreibungen beinhalten konkrete Beschreibungen zu den Fähigkeiten und/oder Eigenschaften einer Schnittstelle. Beispielsweise die Fähigkeit Methoden zu beschreiben oder den Ressourcenverbrauch oder auch das Antwortzeitverhalten (Responsetime). Wie aus Figur 1 und Figur 2 ersichtlich, wird dabei zwischen gebotenen Schnittstellen und geforderten Schnittstellen unterschieden. Schnittstellenbeschreibungen beschreiben somit insbesondere technische Fähigkeiten und Eigenschaften.

Softwarekomponenten können beispielsweise für eine benötigte Berechnung eine bestimmte Antwortzeit in ihrer Schnittstellenbeschreibung fordern und andere Softwarekomponenten können in ihrer Schnittstellenbeschreibung diese Berechnung mit einem bestimmten Antwortzeitverhalten anbieten. Hieraus ergibt sich eine Art von Vertragsschließung zwischen den Softwarekomponenten bzw. zwischen den Schnittstellen, was in Figur 2 als Verbindung dargestellt wird. Die Überprüfung ob eine Softwarekomponente in ein Gesamtsystem mit ihren gebotenen Schnittstellen und geforderten Schnittstellen passt oder nicht (Prüfung der Verträglichkeit) ist Aufgabe dieser Erfindung und soll an diesem Beispiel erläutert werden.

Um die Verträglichkeiten zwischen Softwarekomponenten festzustellen ist es notwendig, ihre Schnittstellenbeschreibungen miteinander zu vergleichen. Der Vergleich muss jedoch bestimmten Regeln und einer bestimmten Vorgehensweise unterworfen werden, damit Vergleiche möglich werden. Ein Vergleich ist z.B. möglich wenn: 1. Format und syntaktische Beschreibung der zu vergleichenden Inhalte gleich sind und damit die Lesbarkeit und Interpretierbarkeit von Schnittstellenbeschreibungen ermöglicht wird

2. bekannt ist, welche Fähigkeiten in einem bestimmten Beschreibungsstandard enthalten sind, damit geforderte Fähigkeiten auf ihre Rechtmäßigkeit hin überprüft werden können

3. bekannt ist, welchem Beschreibungsstandard die zu vergleichenden Schnittstellenbeschreibungen angehören.

Vorteilhaft am erfindungsgemäßen Verfahren ist es, dass auch Schnittstellenbeschreibungen unterschiedlicher Beschreibungsstandards miteinander verglichen werden können.

Die Erfindung geht davon aus, dass mit der Existenz von verschiedenen Versionen von Beschreibungsstandards und gebildeten Varianten die Beschreibungsstandards einen Ursprung in einem bestimmten, insbesondere übergeordneten Beschreibungsstandard haben. Die Möglichkeit der Verfolgung der Entwicklung von Beschreibungsstandards ist daher von elementarer Bedeutung. Insbesondere dann, wenn zwei unterschiedliche Beschreibungsstandards miteinander verglichen werden sollen.

Die Idee ist, alle in einem Gesamtsystem vorkommenden Beschreibungsstandards in eine Vererbungshierarchie einzuordnen. Damit ist es möglich, jeden Beschreibungsstandard bis zu seinem Ursprung zurückzuverfolgen und beim Vergleich zweier Schnittstellenbeschreibungen den nächsten gemeinsamen verwandten Standard zu ermitteln.

Mit dieser Methode ist es möglich, den gemeinsamen Anteil zweier Schnittstellenbeschreibungen zu ermitteln und zu vergleichen. Sind bei einer Schnittstellenpaarung alle geforderten und gebotenen Fähigkeiten in diesem gemeinsamen Anteil zu finden und werden alle geforderten Fähigkeiten erfüllt, ist der Verträglichkeitstest positiv. Dieses Beispiel zeigt exemplarisch, dass mit dieser Methode auch Softwarekomponenten auf Verträglichkeit geprüft werden können, obwohl unterschiedliche Beschreibungsstandards im Spiel sind. Dies setzt voraus, dass neue Softwarekomponenten dessen Schnittstellen über bisher unbekannte Beschreibungsstandards verfügen, eine Beschreibung zu der bestehenden Vererbungshierarchie mitbringen müssen, sodass eine Einordnung und ein Update der Vererbungshierarchie ermöglicht werden kann.

Die Vergleiche von Schnittstellenbeschreibungen können z.B. durch Schnittstellenmanager erfolgen. Der Schnittstellenmanager ist ein Programm, das zur Laufzeit des Architekturwerkzeugs geladen werden kann und den Vergleich von Schnittstellenbeschreibungen durchführt. Ein möglicher Zeitpunkt des Ladens wäre, wenn ein Architekturwerkzeug anhand der angegebenen Schnittstellenbeschreibungen und anhand der Vererbungshierarchie den richtigen Schnittstellenmanager für einen anstehenden Verträglichkeitstest ermittelt hat. Der Schnittstellenmanager vergleicht anschließend die geforderten Fähigkeiten mit den gebotenen Fähigkeiten anhand der vorliegenden Schnittstellenbeschreibungen. Werden die Forderungen erfüllt, dann ist der Vergleich erfolgreich und die Verträglichkeit zwischen den Schnittstellen ist gegeben. Der Vergleich erfolgt gemäß der Vererbungshierarchie für den gemeinsamen Anteil der Schnittstellenbeschreibungen. Gibt es neben einem gemeinsamen Anteil auch jeweils individuelle Anteile in den Schnittstellenbeschreibungen, so können diese vom zuständigen Schnittstellenmanager zunächst nicht miteinander verglichen werden. Insofern geht mit dem Vergleich der gemeinsamen Anteile auch ein Informationsverlust hinsichtlich der individuellen Anteile einher. Der Anwender kann bevorzugt auf individuelle Anteile aufmerksam gemacht werden, sodass er manuell einen Vergleich individueller Anteile vornehmen kann.

Aus der Figur 3 ist ersichtlich, dass der Beschreibungsstandard Typ C vom Beschreibungsstandard Typ A. abstammt. Würde im vorliegendem Beispiel eine Schnittstellenbeschreibung vom Beschreibungsstandard Typ B mit der Schnittstellenbeschreibung vom Beschreibungsstandard Typ C verglichen, wäre der nächste gemeinsame Verwandte der Typ A . Der Schnittstellenmanager SM_A wäre dann das Programm, dass den Vergleich zwischen den Schnittstellenbeschreibungen Typ B und C vornimmt.

Bei der Paarung Typ E und Typ B wäre es der Schnittstellenmanager SM_B und bei der Paarung Typ F und Typ G wäre es der Schnittstellenmanager SM_C.

Sonderfälle entstehen, wenn ein Vergleich der Beschreibungsstandards nicht über die Vererbungshierarchie des Vererbungsbaums erfolgen kann oder erfolgen soll. Beispielsweise wenn die Anforderung besteht, zwei Beschreibungsstandards miteinander zu verglichen und sich dabei ein Beschreibungsstandard außerhalb der Hierarchie befindet oder beispielsweise beide Beschreibungsstandards sich innerhalb der Hierarchie befinden aber direkt und ohne Informationsverlust miteinander verglichen werden sollen.

Dieser Sachverhalt wird beispielsweise an der Paarung C-CX deutlich wie in Figur 3 und Figur 5 beispielhaft dargestellt. Für diese Sonderfälle gibt es gibt es mehrere Möglichkeiten einen Vergleich durchzuführen.

Die erste Möglichkeit besteht in der Transformation des Beschreibungsstandards von einem in den anderen Standard. Im vorliegenden Beispiel würde der Transformator die Schnittstellenbeschreibung CX in die Schnittstellenbeschreibung C transformieren. Dabei würde der Transformator wie aus Figur 5 beispielhaft ersichtlich die Samplerate von [μs] in [ms] umwandeln. Nach der Transformation würde der Schnittstellenmanager „SM_C" den Vergleich von C und CX vornehmen. Die zweite Möglichkeit besteht in der Verwendung eines speziellen Schnittstellenmanagers. Dieser vergleicht C und CX miteinander ohne vorherige Transformation und wird aufgrund seiner Spezialisierung die Samplerate nur temporär für den Vergleich umrechnen.

Spezielle Schnittstellenmanager oder Transformatoren können auch erforderlich sein, wenn Schnittstellenbeschreibungen innerhalb der Vererbungshierarchie ohne Informationsverlust verglichen werden sollen. Beispielsweise der Vergleich von Typ B mit Typ F. In diesem Fall würde ursprünglich der Schnittstellenmanager SM_A den Vergleich vornehmen. Aus der Vererbungshierarchie ist ersichtlich, dass nur der gemeinsame Anteil aus Typ A miteinander verglichen werden kann. Der Informationsverlust wäre also entsprechend groß. Mit einem speziellen Transformator oder einem speziellen Schnittstellenmanager für die Paarung Typ B mit Typ F könnte der Informationsverlust vermieden werden. Daher macht die Verwendung von speziellen Transformatoren oder speziellen Schnittstellenmanagern nicht nur für Paarungen Sinn wo ein Teil des Paares außerhalb der Vererbungshierarchie angeordnet ist, sondern auch für Paarungen die innerhalb der Vererbungshierarchie angeordnet sind.

In der Praxis könnte es dann so sein, dass Hersteller von Softwarekomponenten zu ihrer Softwarekomponente einen Transformator oder einen speziellen Schnittstellenmanager für bestimmte Vererbungshierarchien mitliefern. Dies würde die Wiederverwendbarkeit von Softwarekomponenten nochmals deutlich verbessern.

Figur 4 zeigt, welchen gemeinsamen Schnittstellenmanager das Architekturwerkzeug anhand der Vererbungshierarchie gemäß der Figur 3 ermitteln würde, wenn das Beispiel aus Figur 2 zugrunde gelegt wird.

Als eine weitere Ausführungsform kann auch vorgesehen werden, dass keine dedizierten Schnittstellenmanager zum Vergleich gegeben sind. Im Falle zunehmender Standardisierung könnte es sein, dass der Vergleich nur noch von einem Schnittstellenmanager durchgeführt wird, da auf höchster Ebene Inhalte, Struktur, das formelle Aussehen und das Format in dem die Schnittstellenbeschreibungen vorliegen einheitlich standardisiert sind. In diesem Fall könnte ein einzelner Schnittstellenmanager alle in der Vererbungshierarchie befindlichen Schnittstellenbeschreibungen miteinander vergleichen. Das Vorhandensein von unterschiedlichen Varianten eines Beschreibungsstandards und das Vorhandensein der Vererbungshierarchie bleibt davon jedoch unberührt.

Ein wichtiges Merkmal der vorliegenden Erfindung ist, dass die Beschreibungsstandards den allgemein bekannten Eigenschaften von Vererbung unterworfen werden. Daraus folgt, dass mit der zugrunde gelegten Vererbungshierarchie ein Nachfahre-Beschreibungsstandard immer über einen gemeinsamen Anteil mit seinem in der Vererbungshierarchie nächst höheren Vorfahre-Beschreibungsstandard verfügt. Unterschiede zwischen Vorfahre und Nachfahre bestehen immer aus dem Hinzufügen weiterer Fähigkeiten Schnittstellen zu beschreiben.

Es ist nicht zulässig, dass beispielsweise im gemeinsamen Anteil zweier Beschreibungsstandards eine Eigenschaft oder Fähigkeit, z.B. der Ressourcenverbrauch unterschiedlich beschrieben wird. In diesem Fall wäre eine Transformation von einem Standard in den anderen Standard notwendig oder ein spezieller Schnittstellenmanager (Siehe Typ CX in Figur 3, Figur 4 und Figur 5). Ist dies nicht möglich sind die jeweiligen Softwarekomponenten nicht kompatibel und ein Vergleich verläuft negativ.

Unterschiede können in der Vererbungshierarchie folglich nur aus dem Hinzufügen von weiteren Fähigkeiten bestehen. Figur 5 verdeutlicht beispielhaft diesen Sachverhalt. An dieser Stelle sei erwähnt, dass die angeführten Fähigkeiten in Figur 5 nur als Beispiel dienen um den Zusammenhang der Vererbung und die Erweiterung von Fähigkeiten zu verdeutlichen. Tatsächlich würde ein Großteil der jetzt dort verteilt aufgeführten Fähigkeiten in einem einzigen Beschreibungsstandard vereint sein. Eine vollständige Aufführung würde den Rahmen einer übersichtlichen Veranschaulichung jedoch sprengen.

Mit den vorliegenden Informationen aus Fig. 2 bis Fig. 5 ist ein Architekturwerkzeug in der Lage, einen Vergleich zwischen zwei konkret vorliegenden Schnittstellenbeschreibungen durchzuführen. Figur 6 zeigt ein Beispiel einer konkreten Schnittstellenbeschreibung für die Schnittstelle 1.1.

Aus der Figur 6 wird erkenntlich, dass die Schnittstelle 1.1 dem Typ C entspricht. Beispielhaft wurde auch die Syntax des Schnittstellenstandards Typ C festgelegt. Es wird angenommen, dass in der Schnittstelle 1.1 alle in Typ C aufgeführten Fähigkeiten verwendet bzw. geboten werden. Diese sind sowohl die gemeinsamen Fähigkeiten mit dem übergeordneten Standard A (Fähigkeit 1) als auch die neu hinzugefügten Fähigkeiten (Fähigkeit 2) bzgl. weiterer Tasks im Standard C. So bietet die Schnittstelle 1.1 die Methoden Op1 (), Op2() und Op3(), sowie die Tasks Task10 und Task20. In der untersten Tabelle wird für dieses Beispiel fiktiv das Verhalten bestimmt indem beispielsweise RESPONSTIME oder SAMPLERATE mit konkreten Werten versehen werden.

Analog zur Schnittstelle 1.1 und Figur 6 können für alle anderen im Beispiel gemäß Figur 2 vorkommenden Schnittstellen ebenfalls Werte angenommen werden. Aus Figur 7 bis Figur 13 wird deutlich, dass mehr Fähigkeiten in einem Schnittstellenstandard definiert sein können, als später in einer konkreten Schnittstellenbeschreibung enthalten sind.

Nachfolgende Figuren zeigen beispielhaft die Berechnungsergebnisse der ermittelten Schnittstellenmanager. Dabei werden die Verbindungen gemäß Figur 2 zugrunde gelegt sowie die Vererbungshierarchie aus Figur 3.

Die Figur 7 zeigt als ein Beispiel, dass alle geforderten Fähigkeiten der Verbindung 1 erfüllt sind, z.T. besser als gefordert. Der Vergleich verläuft somit positiv.

Das Beispiel nach Figur 8 zeigt einen negativen Vergleich bei der Verbindung 2, da die geforderten Ressourcen nicht geboten werden. Die jeweiligen Komponenten sind nicht kompatibel.

Figur 9 zeigt beim Vergleich der Schnittstellenbeschreibungen der Verbindung 3, dass der Beschreibungsstandard C den nächstliegenden gemeinsamen Standard bildet. Schnittstelle 3.2 bietet diesen Standard C, jedoch fordert Schnittstelle 2.2 mehr als Standard C, nämlich Standard G. Dieser Standard G umfasst alle Fähigkeiten des Standards C fordert jedoch noch weitere Fähigkeiten, nämlich die Zuordnung von Prioritäten einerseits 1 andererseits 4 zu den Tasks 3 und 4. Da diese Prioritäten nicht im Standard C geboten werden kann es sein, dass die Softwarekomponenten nicht kompatibel sind.

Gemäß Figur 10 sind bei der Verbindung 4 wieder alle geforderten Fähigkeiten durch die gebotenen gegeben. Die Softwarekomponenten sind kompatibel. In Figur 11 ist ersichtlich, dass die Signale Sig1 und Sig2 jeweils gefordert und geboten werden, jedoch fordert die Schnittstelle 2.3 vom Typ E eine Signalabhängigkeit, die nicht geboten wird. Auch hier kann deswegen eine Inkompatibilität vorliegen. Figur 12 zeigt ein Beispiel, bei dem zunächst eine Inkompatibilität im geforderten und gebotenen Zeitverhalten vorliegt, da die zugehörigen Beschreibungsstandards in diesem Punkt nicht übereinstimmen. Das Fehlen der Übereinstimmung ist jedoch nur durch die jeweilige Einheit der relevanten Größe bedingt. Die Schnittstelle 4.3 fordert ein Zeitverhalten in Mikrosekundenbereich, die Schnittstelle 3.2 bietet ein Zeitverhalten im Millisekundenbereich. Ein spezieller Schnittstellenmanager kann nun in der Lage sein während der Vergleiches festzustellen, dass es sich lediglich um eine formale Inkompatibilität handelt und zur Laufzeit die geforderte Einheit transformieren, so dass sie der gebotenen entspricht. Sodann ist feststellbar, dass die gebotenen Größe besser ist als die geforderte. Die Komponenten sind somit kompatibel.

Gemäß Figur 13 wird die Problematik der formalen Inkompatibilität aufgrund unterschiedlicher Einheitenangaben beim Zeitverhalten derart gelöst, dass mit einem Transformator die geforderte Schnittstelle vom Standard CX transformiert wird in eine Schnittstelle vom Standard C. Sodann ergibt sich wieder die Kompatibilität.

Die Erfindung wurde anhand eines Prototypen getestet. Mit der Modellierungssprache UML (Unified Modeling Language), einer Sprache zur Beschreibung von Softwaresystemen, lassen sich die bisher in den Figuren 2 und 3 dargestellten Informationen formal beschreiben. Die Möglichkeit UML Diagramme nach XMI bzw. XML Dateien zu exportieren, kann ein Architekturwerkzeug nutzen, um die Informationen z.B. aus Figur 2 sowie Figur 3 oder alternativ Figur 4 datentechnisch zu verarbeiten. Für den Prototyp war es daher notwendig die Figuren 3 bis 6 teilweise in UML Diagramme umzuwandeln. Figur 14 zeigt beispielweise das zugehörige UML Diagramm zur Softwarekomponente 1.

Figur 15 zeigt das UML Klassendiagramm zur Softwarekomponente 2.

Figur 16 zeigt das UML Klassendiagramm zur Softwarekomponente 3.

Figur 17 zeigt das UML Klassendiagramm zur Softwarekomponente 4.

Figur 18 zeigt das UML Klassendiagramm zur Vererbungshierarchie gemäß Figur 3. Der Übersichtlichkeit halber wurde in Figur 18 der Sonderfall für den Standard Typ CX nicht eingezeichnet.

Ein Architekturwerkzeug wäre nach dem Einlesen der UML Diagramme beziehungsweise nach dem Einlesen der exportierten XML Files in der Lage, die im Gesamtsystem verfügbaren Softwarekomponenten und ihre gebotenen sowie geforderten Schnittstellen anzuzeigen. Ein Softwarearchitekt kann jetzt Verbindungen gemäß Figur 1 herstellen. Das Architekturwerkzeug kann anhand der Vererbungshierarchie gemäß Figur 18 für eine Verbindung den zugehörigen Schnittstellenmanager ermitteln und eine Berechnung durchführen.

Figur 19 zeigt ein Beispiel wie der Prototyp „Softwarekomponentenevaluator" als Teil eines Architekturwerkzeugs die Softwarekomponenten darstellen könnte.

In einem nächsten Schritt können die für die Verbindung in Frage kommenden Schnittstellen ausgewählt werden, was beispielhaft für Verbindung 1 in Figur 20 dargestellt wird. Mit Betätigung der Schaltfläche „Berechne Ergebnis" wird vom Softwarekomponentenevaluator der richtige Schnittstellenmanager aus der Vererbungshierarchie ermittelt und (zur Laufzeit) gestartet. Der Schnittstellenmanager führt anschließend die Berechnung durch. Figur 20 zeigt hierfür beispielhaft die Berechnung. Die Berechnung gleicht der Berechnung in Figur 7.

Damit unterschiedliche Beschreibungsstandards in einem Architekturwerkzeug in einem Gesamtsystem verwendet werden können, müssen Vererbungshierarchie, Beschreibungsstandards und Schnittstellenmanager sowie die Softwarekomponentenbeschreibungen dem Architekturwerkzeug explizit vorliegen. Figur 21 verdeutlicht diesen Sachverhalt noch einmal.

Ein Architekturwerkzeug, mittels dem z.B. auch grafisch ein Zusammenstellen von Softwarekomponenten erfolgen kann greift zu auf eine explizit vorliegende spezielle Vererbungshierarchie, die Softwarekomponenten- bzw. Schnittstellenbeschreibungen, die einzelnen Beschreibungsstandards mit Schnittstellenmanagern und ggf. Transformatoren bzw. spezielle Schnittstellenmanager. So kann direkt bei der Softwarekomponentenmodellierung die Kompatibilität geprüft werden, unabhängig davon ob die Softwarekomponente bereits als ausführbares Programm vorliegt oder nicht.

Im derzeitigen Stand der Technik gibt es noch keine Vergleiche zwischen den unterschiedlichen Arten der Beschreibungen von Softwarekomponenten. Bisher geht man davon aus, dass alle Softwarekomponenten in einem System einheitlich standardisierte Schnittstellen haben. Der wesentliche Vorteil besteht darin, mit der erfindungsgemäßen Methode schon zur Zeit der Softwarekomponentenmodeliierung unterschiedliche Standards in einem Architekturwerkzeug zu verarbeiten bzw. die Unterschiede bekannt zu machen. Hersteller von Architekturwerkzeugen sind dann nicht gezwungen, für jeden am Markt befindlichen Standard ein eigenes Werkzeug entwickeln. In einer weiteren Ausführungsform kann die zur Rede stehende Erfindung auch auf den Vergleich von ganzen Architekturbeschreibungen übertragen werden. Damit könnte das erfindungsgemäße Verfahren auch qualitative Aussagen zu verschiedenen Architekturen ermöglichen, obwohl sie unterschiedlichen Beschreibungsstandards angehören.

Claims

Patentansprüche:

1. Verfahren zur Überprüfung der Kompatibilität zwischen zwei Softwarekomponenten eines Steuergerätenetzwerks, wobei jeder Softwarekomponente wenigstens eine technische Schnittstellenbeschreibung zugeordnet ist, die einem bestimmten Beschreibungsstandard zugehört, dadurch gekennzeichnet, dass jeder Beschreibungsstandard eine hierarchische Position in einer Vererbungshierarchie aller möglichen Beschreibungsstandards aufweist, wobei anhand der Vererbungshierarchie der in der Vererbungshierarchie nächstliegendste gemeinsame Beschreibungsstandard der zu vergleichenden Softwarekomponenten ermittelt wird und anhand des gemeinsamen Beschreibungsstandards der gemeinsame Anteil der jeweiligen Schnittstellenbeschreibungen ermittelt und miteinander verglichen wird.

2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Schnittstellenbeschreibungen der zu vergleichenden Softwarekomponenten des Steuergerätenetzwerkes anhand der Festlegungen in dem nächstliegenden gemeinsamen Beschreibungsstandard verglichen werden.

3. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Vererbungshierarchie aller Beschreibungsstandards dadurch gebildet wird, dass jeder Beschreibungsstandard bis auf der in der Vererbungshierarchie höchste zumindest zu einem Teil einen hierarchisch höherliegenden Beschreibungsstandard umfasst und hierzu Ergänzungen aufweist.

4. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass in einer Schnittstellenbeschreibung einer Softwarekomponente des Steuergerätenetzwerkes die von der Softwarekomponente gebotenen und/oder geforderten technischen Eigenschaften beschrieben sind.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass bei einem Vergleich geprüft wird, ob die geforderten Fähigkeiten einer Schnittstelle von den gebotenen Fähigkeiten einer anderen Schnittstelle erfüllt werden.

6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass bislang nicht in der Vererbungshierarchie eingeordnete Beschreibungsstandards einer Schnittstellenbeschreibung zur Einordnung und Erweiterung der Vererbungshierarchie derart geändert werden, dass sie einen mit der bestehenden Vererbungshierarchie gemeinsamen Anteil aufweisen.

7. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass jedem Beschreibungsstandard der Vererbungshierarchie ein Schnittstellenmanager zugeordnet ist, der für den Vergleich zweier Schnittstellenbeschreibungen eingesetzt wird, insbesondere wobei für den Vergleich derjenige Schnittstellenmanager des nächstliegenden gemeinsamen Beschreibungsstandards zweier Schnittstellenbeschreibungen ausgewählt wird.

8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass Softwarekomponenten des Steuergerätenetzwerks mittels eines insbesondere grafischen Architekturwerkzeuges zusammengesetzt werden, wobei während der Laufzeit des Architekturwerkzeugs der für einen Vergleich benötigte Schnittstellenmanager anhand der Vererbungshierarchie ermittelt und ausgeführt wird.

9. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass ein Beschreibungsstandard einer Schnittstellenbeschreibung, der keinen Anteil aufweist, der einem Beschreibungsstandard der Vererbungshierarchie entspricht mittels eines Transformators transformiert wird in einen Beschreibungsstandard, der einen Anteil aufweist, der einem Beschreibungsstandard der Vererbungshierarchie entspricht.

10. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Schnittstellenbeschreibung mit einem ersten Beschreibungsstandard, der keinen Anteil aufweist, der einem Beschreibungsstandard der Vererbungshierarchie entspricht mittels eines speziellen Schnittstellenmanagers verglichen wird mit einer anderen Schnittstellenbeschreibung, wobei der Schnittstellenmanager temporär den ersten Beschreibungsstandard transformiert so dass beide Beschreibungsstandards der zu vergleichenden Schnittstellenbeschreibungen zumindest während des Vergleichs einen gemeinsamen nächstliegenden Beschreibungsstandard aufweisen.