Interview mit Wolfgang Leimbach, IBM Rational, über das Internet der Dinge im Design-Engineering-Bereich

JAXenter: Herr Leimbach, gibt es das Internet der Dinge schon?

Wolfgang Leimbach: Als Begriff schon, aber je nach Domäne existieren andere Erwartungshaltungen, und in unserer tendiere ich zu einem Nein, was den allgemeinen Stand der Realisierung betrifft.

JAXenter: Was müsste für eine Realisierung passieren?

Leimbach: Man müsste sich zunächst auf einen Standard einigen, über den man die „Dinge“ erreichen will. Die Frage ist auch, von welchen „Dingen“ wir überhaupt sprechen. Wenn man den Begriff auf unsere Design-Engineering-Welt bezieht, könnte man darunter zum Beispiel Designartefakte verstehen. Das kann eine Anforderung sein, und es kann ein Testfall sein, mit dem am Ende des Tages geprüft wird, ob das, was entwickelt wurde, den Anforderungen entspricht. Wenn das die „Dinge“ sind und sie über Internettechnologie erreicht werden sollen, dann sind wir bei IBM Rational auf einem guten Weg zu dem Internet der Dinge. Das Internet hat sich bewährt als sehr skalierende Technologie. Wie Sie wissen, wurde Eclipse auch von IBM gestartet und in die Open-Source-Community gegeben. Genauso haben wir eine Technologie, bzw. ein Protokoll für das Internet der Dinge im Engineering-Bereich entwickelt. Es nennt sich OSLC, Open Services for Lifecycle Collaboration. Wir beobachten, dass es in unserer Industrie allmählich immer mehr Zuspruch bei denen findet, die mitwirken wollen, um ein Internet der Dinge in dieser Domäne zu realisieren. Es hat das Potenzial, sich als offener Standard zu etablieren.

JAXenter: Bei Eclipse ja durch das Projekt Lyo, das ein SDK für die OSLC-Spezifikation zur Verfügung stellt. Für .NET gibt es OSLC4Net. Muss man also in ganz großen Zusammenhängen denken, wenn man Toolintegration und ALM in der Embedded-Entwicklung ermöglichen möchte?

Leimbach: Wir sehen drei Phasen: Durch Phase eins sind wir schon durch. Hier wurden bestimmte Disziplinen im Engineering-Bereich – bezogen auf Embedded-Software oder mechatronische Systeme – automatisiert. Zum Beispiel das Anforderungsmanagement. IBM Rational DOORs ist ein bewährtes Tool, das in vielen Industrien zum Quasi-Standard geworden ist. Auch in den entwicklungsprozesstechnisch nachgeschalteten Bereichen Architektur, Design, Implementierung und Test – also in allen einzelnen Disziplinen des Produktentstehungsprozesses wird kräftig automatisiert. IBM Rational bietet hier eine Palette von Tools an, wie z. B. Focal Point, System Architect, Rhapsody, Quality Manager und Team Concert.

Phase zwei ist das Verbinden dieser einzelnen Disziplinen zu einer integrierten Entwicklungsumgebung. Das findet jetzt gerade statt und wird unter dem Begriff ALM (Application Lifecycle Management) heiß gehandelt, hauptsächlich im Embedded-Software-Bereich. Fast jeder möchte hier schnell Verbesserungen erzielen. Nach der Automatisierung der Einzeldisziplinen geht es also jetzt darum, die Teildisziplinen zu verbinden, um so genannte „Traceability“ zu ermöglichen oder auch Impact-Analysen zu machen. Wenn im Test ein Fehler auftritt, möchte ich automatisch wissen, welche Anforderung überhaupt betroffen ist.

In der dritten Stufe – und hier würde ich sagen: das ist dann das, was wir als Internet der Dinge bezeichnen können – integrieren wir über Domänen hinaus. Dann möchte ich nicht nur wissen, was in meinem Elektroniksystem geschieht, in meinem Softwaresystem oder in meinem Mechaniksystem, sondern was insgesamt los ist. Ich will dann alle Artefakte managen können. Wenn vom Marketing die Anfrage kommt: „Ich möchte ein neues Feature in meinem Tempomat haben, um zum Beispiel bei zweimaligem, nicht mehr bei einmaligem Tippen einer Taste eine Beschleunigung zu erzielen“, möchte ich doch gerne wissen, was davon potenziell betroffen ist: welche mechanische Komponente, welcher Softwareteil und welche elektronische Komponente. Dazu brauche ich natürlich eine Klammer um alles. Und das würde ich als „Internet der Dinge“ im Design-Engineering-Bereich bezeichnen.

Nach der Automatisierung der Einzeldisziplinen geht es jetzt darum, die Teildisziplinen zu verbinden, um so genannte „Traceability“ zu ermöglichen.

JAXenter: Ist „Internet der Dinge“ also der richtige Begriff hierfür, wenn man „Dinge“ spezifiziert, wie Sie es gerade getan haben?

Leimbach: Ich denke, der Begriff ist schon sinnvoll. Wir benutzen natürlich nicht nur das Internet, sondern eine erweiterte auf dem Internet basierende Technologie.

JAXenter: Was wäre der erste Schritt hin zu dieser letzten Phase, zu einer umfassenden Vernetzung? Protokollstandards? Hardware?

Leimbach: Hardware ist nicht relevant. Es war in unserer Domäne wichtig, ein Protokoll zu finden, auf das man sich nun einigt. Mit OSLC haben wir diese Voraussetzung geschaffen. Die gilt es nun anbieterübergreifend zum Nutzen der Anwender umzusetzen.

JAXenter: Gibt es hier Vorbilder oder existierende Technologien, an die man sich halten kann – MQTT wird ja gerade als möglicher Standard gehandelt [1]? Oder muss man von verschiedenen Protokollschichten ausgehen?

Leimbach: MQTT ist ein gutes Beispiel aus einer anderen Domäne – ebenfalls von IBM initiiert. Es geht dabei um die Verbindung von Sensoren und Steuergeräten für die Telemetrie. Es handelt sich hier nicht um eine andere Protokollschicht, sondern eine ganz andere Aufgabenstellung.

JAXenter: Die OSLC sind ein Ökosystem von vielen im Embedded-Bereich. Strategische Allianzen, Partnerschaften scheinen darin immer wichtiger zu werden. Schließlich will niemand mehr alles aus einer Hand anbieten.

Leimbach: Absolut. Wir sind dabei, ein Ökosystem mit den Partnern zu etablieren, die für unsere Domäne Sinn machen. Unsere Kunden sagen uns letztendlich, mit wem wir Partnerschaften eingehen müssen. Der Markt treibt uns an. Und weil wir nicht in jeder Disziplin etwas anbieten, müssen wir mit Partnern zusammenarbeiten. Wir haben gerade eine Partnerschaft mit einem Unternehmen im Testautomatisierungsbereich, National Instruments, begonnen, mit dem wir kooperieren, um für unsere Kunden eine integrierte Lösung zu schaffen.

JAXenter: Die Gefahr eines Vendor-Lock-ins besteht bei solchen Kollaborationen also weniger. Aber zwischen den Partnern kommt es zu neuen Abhängigkeiten. Kann es da nicht so etwas wie einen „Partner-Lock-in“ geben?

Leimbach: Nun ja, das ist wie im Leben (lacht). Wenn ich eine bestimmte Lösung anbiete, die ich mit einem Partner zusammen realisiere, dann mache ich mich natürlich abhängig. Die Art und Weise der technischen Realisierung von Integrationslösungen ist jedoch relevant. Mit einer sehr spezifischen One-to-one-Verbindung ist die Abhängigkeit natürlich sehr groß. Wählt man einen Standard wie OSLC, dann wird zumindest die technische Abhängigkeit geringer. Unsere Kunden sind im Übrigen auch daran interessiert, dass Integrationen über Standards realisiert werden, weil das für sie zukunftssicherer ist und es den Wettbewerb belebt. Wir propagieren auf jeden Fall Offenheit – getreu der IBM-Kultur.

JAXenter: Wie versuchen Sie, Unternehmen den Beitritt zu den OSLC schmackhaft zu machen?

Leimbach: Ganz wie im Fall Eclipse, muss man am Anfang investieren. Aber irgendwann kommt der Punkt, an dem das Thema zum Selbstläufer wird. Bei OSLC haben wir diesen Punkt jetzt erreicht. Vielleicht sollten wir noch mehr Öffentlichkeitsarbeit machen, wobei aber hier schon viel getan wurde. Wir haben natürlich große Kunden, wie Siemens und einige andere, die inzwischen offen für OSLC werben.

JAXenter: Wie muss man sich die OSLC intern vorstellen, wie wird interagiert? Sind das ganz offene Prozesse?

Leimbach: Ja, ganz offen – es gibt keine Geheimnisse.

JAXenter: Was bedeuten diese komplexen neuen Ökosysteme für den Kunden?

Leimbach: Die Kunden sind das Wichtigste, und die möchten er es ja so haben, um den nächsten Schritt in der Evolution immer komplexerer Systeme gehen zu können. Der Kunde will vernetzte Entwicklungsumgebungen, damit er schneller wird, bessere Qualität entwickelt, weniger Risiken hat etc. Gute Frage, wie diese neue Komplexität von ihm beherrschbar gemacht werden kann. Ich denke, durch einen Standard bessert sich die Situation für den Endanwender, weil er dadurch die Chance hat zu handeln: Wenn es mit einem [Anbieter] nicht funktioniert, ist dieser leichter ersetzbar. Wir sprachen über Abhängigkeit – in der Vergangenheit ohne Standards waren Anwender den Toolanbietern weitaus mehr ausgeliefert.

In der Vergangenheit ohne Standards waren Anwender den Toolanbietern weitaus mehr ausgeliefert.

JAXenter: Er muss sich offensichtlich auch besser informieren.

Leimbach: Wie Anwender diese Komplexität handhaben, ist eine berechtigte Frage. Früher waren 10 000 Zeilen Softwarecode in komplexen Embedded-Systemen normal, heute sind es bereits bis zu 10 Millionen Zeilen Code in einem Automobil. Wir können [die Kunden] nur nach bestem Wissen und Gewissen beraten. Es gibt Methoden, Prozesse, Standards, mit denen man diese gewaltige Komplexitätsexplosion beherrschbar machen kann. Aber letztendlich können wir nur beraten. Die Kunden müssen entscheiden.

EM: Was haben die OSLC im Bereich Sicherheitsstandards zu bieten? Gibt es hier so etwas wie Guidelines?

Leimbach: Da schließt sich der Kreis. Denn um höchstmögliche Sicherheit zu erzielen, bedarf es größtmöglicher Nachvollziehbarkeit – und die ist durch die Verbindung der Disziplinen gegeben: Anforderungen zu Modellelementen, zum Code, zu Testcases. Das muss durchgehend verbunden sein, damit man zu jeder Zeit in der Lage ist, etwas nachzuvollziehen. Wenn irgendwo im Lifecycle ein Fehler passiert, möchte ich schnellstens wissen, an welcher Stelle ich eingreifen muss, um diesen Fehler zu eliminieren bzw. herauszufinden, warum er überhaupt aufgetreten ist. Mittels OSLC schaffen wir die notwendige Kollaboration zwischen den Entwicklungsabschnitten. Darüber hinaus unterstützen wir unsere Kunden durch Profile, die man entsprechenden Tools hinterlegen kann und die wir auf Wunsch bereitstellen. ISO 26262 ist z. B. ein neuer Safety-Standard in der Automobilindustrie, für den wir den Anwendern ein Profil liefern, damit sie einen schnellen und konformen Einstieg in diese Thematik finden.

JAXenter: Was ist für Sie die größte Herausforderung, der sich der Embedded-Bereich in den nächsten Jahren zu stellen hat?

Leimbach: Das, womit wir [das Interview] begonnen haben, nämlich das Internet der Dinge zu realisieren. Transparenz in mechatronischen Systemen. Die haben wir heute noch nicht. Heute gibt es Silos. Nehmen wir den Automobilbereich: Es gibt eine Abteilung, welche die Motormechanik entwickelt, eine, die sich damit auseinandersetzt, wie die elektronische Steuerung für diesen Motor aussieht, meistens zusammen mit Zulieferern. Und dort gibt es eine eigene Abteilung, die nichts anderes tut, als die Software zu entwickeln, die in dieser Steuerung läuft. Jede Disziplin arbeitet mit ihren spezifischen Tools, die ihre spezifischen Daten halten, welche nicht integriert sind – und das bei zunehmender Komplexität, weil der Motor mit seiner Steuerung ja nur ein Subsystem ist und mit anderen zusammenspielen muss. Natürlich kann man sich darauf verlassen, dass es immer noch funktioniert. Gerade bei uns in Deutschland werden gute Autos gebaut, die erfolgreich exportiert werden – die Zahlen sprechen für sich. Aber ich kann Ihnen sagen, dass der Entwicklungsaufwand enorm ist, und bei unseren Arbeitskosten ist das geschäftskritisch. Wir stehen mit diesen Firmen ständig in Verbindung, weil es unsere Kunden sind und hören unisono, dass eine der größten Herausforderungen, diese Aufwände zu begrenzen, in der Integration der Entwicklungsdisziplinen und deren Daten liegt. Und damit sind wir wieder beim Internet der Dinge: Ich möchte jederzeit Zugriff auf alles haben. Vor allem natürlich auch auf die Struktur von Softwaresystemen, weil diese mit immer größeren und geografisch verteilten Teams entwickelt werden. Der Softwareanteil in mechatronischen Produkten wird weiter rasant ansteigen …

Die bevorzugte Programmiersprache im klassischen Embedded-Bereich ist nach wie vor C.

JAXenter: …und damit auch die Vielfalt der Programmiersprachen?

Leimbach: Ja. Die bevorzugte Programmiersprache im klassischen Embedded-Bereich ist nach wie vor C. Die Komponenten, die einmal in C entwickelt wurden, möchte man möglichst nicht mehr anfassen. Die wurden klassisch entwickelt – böse Zungen sprechen von Spaghetticode. Wir haben in den letzten zehn Jahren zumindest einigen Kunden geholfen, die Software modellbasiert zu entwickeln. Das hilft schon einmal, die Komplexität innerhalb des Softwaresystems zu beherrschen. Aber es kamen auch Kunden zu uns, die das umgekehrt machen wollten: Die wollten aus existierendem C-Code Modelle generieren, weil die Entwickler nicht mehr greifbar waren und sie den Code nicht verstanden, weil zu komplex und ohne gute Architektur. Als ich vor etwas mehr als zehn Jahren von Elektronikentwicklung zu Softwareentwicklung gewechselt bin, war einer der großen Telekommunikationsausrüster einer meiner ersten Kunden. Ich erinnere mich noch, dass wir gebeten wurden, Modelle aus Code zu bauen. Wirklich sinnvoll ist es nicht, weil aus schlechtem Code kein gutes Modell entstehen kann. Man sollte also gleich modellbasiert beginnen.

Das ist also auch eine große Herausforderung momentan: Dass dieser ganze existierende Embedded-Code…

JAXenter: …alter C-Code ist?

Leimbach: Nicht unbedingt, dass es C-Code ist, sondern die Art und Weise, wie er entwickelt wurde. Jeder möchte wiederverwenden, und das ist auch gut. Nur: Vielfach ist Code nicht leicht wiederzuverwenden, weil er gar nicht für diesen Zweck geschrieben wurde. Bei modellbasierter Entwicklung wäre die Lage von Haus aus günstiger, aber das ist sehr oft leider anders.

Wir sehen natürlich auch eine Tendenz weg von C. Ganz typisch für die Embedded-Welt ist auch, Sie hatten es erwähnt, dass alle Sprachen verwendet werden. In mechatronischen Systemen sind die Oberflächen beispielsweise oft in Java oder C# implementiert. Die Sensoren- und Aktuatorensoftware ist häufig weiterhin noch in C kodiert, manchmal sogar noch in Assembler, und ansonsten hat sich C++ inzwischen auf breiter Front etabliert. Unsere Lösungen sind weitestgehend unabhängig von der Sprache und der Zielplattform. Wir müssen alles unterstützen, weil unsere Kunden alles haben.

JAXenter: Wie sehen Sie die Zukunft von Java Embedded?

Leimbach: Embedded Java ist nichts Neues. Das wurde hier auf der Messe vor mehr als zehn Jahren angekündigt. Es gab damals schon kleine spezialisierte Firmen, die daran geglaubt und behauptet haben, Embedded Java würde der Renner werden.

JAXenter: Java wurde ja auch ursprünglich für eingebettete Systeme entwickelt.

Leimbach: Interessanterweise gab es unsere Modellierungsumgebung Rhapsody, die auf der UML basiert, ganz am Anfang für Java, weil wir dachten, Java würde im Embedded-Bereich das Ding werden.

JAXenter: War das auch um 2000 herum?

Leimbach: Ja. Und dann stellte man sehr schnell fest, dass es dafür keinen Markt gab. Also haben wir dann auf C++-Codegenerierung gesetzt und mussten feststellen: C++ in Embedded entwickelt sich leider auch nur langsam. Schließlich haben wir Rhapsody in C gebracht, und das wurde ein Renner. Danach kam auch noch ADA und damit hatten wir dann alle in der Embedded-Welt gängigen Sprachen. C# unterstützen wir inzwischen auch, und für alle Fälle gibt es einen regelbasierten Codegenerator, mit dem Anwender sich spezifische Codegenerierung selbst konfigurieren können. Wenn man heute wieder über Java Embedded redet, kann ich nur sagen: Alles schon mal dagewesen – aber gerne wieder.

JAXenter: Das hat man über JavaFX aber auch gesagt, und dann hat es richtig an Fahrt aufgenommen, gerade auch durch den möglichen Embedded-Einsatz.

Leimbach: Wir haben aus unserer Erfahrung gelernt und sind diesbezüglich ganz und gar kundengetrieben.

JAXenter: Vielen Dank!

Das Gespräch führte Diana Kupfer am Rande der embedded world Nürnberg 2013.