Das von der OSGi-Alliance erarbeitete komponentenbasierte, serviceorientierte Entwicklungsframework gleichen Namens ist für die Automotive-Industrie insbesondere durch die Möglichkeit, Komponenten dynamisch zu laden zu aktualisieren sehr interessant. Mit dem Ziel der Plattformunabhängigkeit wurde Java als Basis von OSGi ausgewählt. Daraus ergibt sich, dass die Komponenten innerhalb des Frameworks in der gleichen Java Virtual Machine laufen. Dies hat zur Folge, dass die einzelnen Komponenten nicht ausreichend gegen Störungen durch andere Komponenten abgeschirmt sind, die sich zum Beispiel aus übermäßiger Nutzung von Systemressourcen ergeben können.
Die Betriebssysteme QNX und Sun Solaris 10 bieten Mechanismen, die es erlauben, einzelnen Prozessen genau definierte Systemressourcen zuzuweisen. Es ließen sich also negative Effekte durch übermäßigen Ressourcenverbrauch einzelner Komponenten vermeiden. Beide Betriebssysteme bieten jedoch keine Unterstützung serviceorientierter, komponentenbasierter Entwicklungsansätze.
Wünschenswert wäre also ein System, das die Vorteile beider Ansätze vereint. Dazu sind zunächst Middleware-Ansätze wie CORBA oder DCOM in Hinblick auf möglicherweise verwendbare Konzepte zu betrachten. Weiterhin soll das zu erstellende System in verschiedenen Programmiersprachen (insbesondere C++) entwickelte Komponenten unterstützen. Ein zentraler Aspekt der Middleware ist die Steuerung der Softwarekomponenten. Hier ist vor allem zu untersuchen, wie das Dienstemanagement, die Prioritätensteuerung, die HMI-Integration und das unabhängige Reset einzelner Komponenten ermöglicht werden kann. Nach der Voruntersuchung ist ein entsprechendes System auf der Basis von Sun Solaris/Intel zu implementieren und zu evaluieren.
Die Containertechnologie von Sun Solaris 10 bietet eine ideale Grundlage, eine klar abgegrenzte Umgebung für Komponenten zu bieten. Um eine wirkungsvolle Abgrenzung zu erhalten, muss jede Komponente in ihrem eigene Container ablaufen, in der ihr bestimmte Systemressourcen zugewiesen und garantiert werden können. Da die Kommunikation von Prozessen in verschiedenen Containern lediglich über ein IP-basiertes Netzwerk möglich ist, müssen hierzu entsprechende Mechanismen geschaffen werden. Hier kann möglicherweise SOAP zur Anwendung kommen, wodurch diese Aufgabe auf relativ unkomplizierte Weise bewältigt werden kann. Weiterhin muss ein Mechanismus zur Verwaltung der Komponenten zur Verfügung stehen, sowie ein Mechanismus zur Überwachung der Komponenten. Innerhalb der Container müssen diejenigen Prozesse geregelt gestartet und gestoppt werden können, die die Komponenten ausmachen. Eine Übersicht über eine mögliche Architektur stellt die folgende Abbildung dar.
Stand: 26.06.2007