einer Studienreihe<\/a> zur Nutzung von Open-Source-Software im Automobil ver\u00f6ffentlicht. Im Mittelpunkt der Befragung standen die technischen und organisatorischen Herausforderungen, vor denen Unternehmen beim Einsatz von Open-Source-Software in softwaredefinierten Fahrzeugen stehen. Die Studie wurde im Auftrag der noch jungen Software-Defined Vehicle (SDV) Working Group der Eclipse Foundation durchgef\u00fchrt. Befragt wurden 300 Entwickler und F\u00fchrungskr\u00e4fte von OEMs und Tier-1-Zulieferern.<\/p>\n\n\n\nDie Ergebnisse zeigen: der Open-Source-Ansatz ist auch im Auto gekommen, um zu bleiben. Das verdeutlicht das Beispiel BMW. Der Konzern ist strategisches Mitglied der SDV Working Group und seit zehn Jahren in verschiedenen Projekten der Eclipse Foundation involviert. Das Infotainment in den BMW- und MINI-Modellen beruht seit dem BMW Operating System 9 auf dem Android-Open-Source-Projekt. Das markenpr\u00e4gende Kundenerlebnis entwickelt der OEM dann in Eigenregie auf der Grundlage dieses Stacks. Diese Herangehensweise wird sich mit dem Operating System X, das in den Fahrzeugen der Neuen Klasse zum Einsatz kommen soll, weiter fortsetzen.\u00a0\u201eInsbesondere bei Basisfunktionen und der Entwicklungstool-Kette sehen wir aber noch mehr Potenzial f\u00fcr den Einsatz von Open Source\u201c<\/em>, sagt Christian Salzmann, Vice President Global Software-Platforms, -Strategy und -Factory bei BMW.<\/p>\n\n\n\n\u201eWir haben unsere Entwicklungsprozesse angepasst, sodass wir an jeder Stelle im Softwareentwicklungsprozess theoretisch in der Lage sind, Open-Source-Komponenten einzusetzen\u201c<\/em>, so Salzmann weiter. Eine vollst\u00e4ndige Angleichung von Open-Source- und Closed-Source-Entwicklungsprozessen sei jedoch schwer m\u00f6glich, da sich die vertraglichen Beziehungen mit den Partnern in Bezug auf Lizenz- und Verantwortungsmodelle stark unterscheiden.<\/p>\n\n\n\nOpen-Source auch im Sicherheitsbereich?<\/h2>\n\n\n\n Auch Elektrobit ist schon l\u00e4nger im Open-Source-Umfeld aktiv und ebenfalls Mitglied der SDV Working Group. \u201eEin gro\u00dfer Treiber f\u00fcr Open Source im Fahrzeug ist die sich aufl\u00f6sende Grenze zwischen Unternehmens-IT und Automotive-Software\u201c<\/em>, sagt Moritz Neukirchner, Senior Director Strategic Product Management beim Unternehmen. \u201eEs macht zum Beispiel keinen Sinn, f\u00fcr Fahrzeuge ein eigenes \u00d6kosystem dort aufzubauen, wo es dank Android bereits existiert.\u201c<\/em> Besonders bei europ\u00e4ischen und japanischen OEMs stellt Neukirchner ein gro\u00dfes Interesse an Open Source f\u00fcrs softwaredefinierte Fahrzeug fest.<\/p>\n\n\n\nInzwischen habe Open Source Einzug in s\u00e4mtliche Bereiche der automobilen Softwarearchitektur gehalten, selbst sicherheitskritische Prozesse seien abbildbar. \u201eZun\u00e4chst passt das ja eigentlich nicht zusammen, weil Open Source historisch nicht in diesem Umfeld entstanden ist\u201c<\/em>, sagt Neukirchner. Elektrobit hat inzwischen die erforderliche Qualifizierung f\u00fcr erste Open-Source-basierte Produkte mit Safety-Unterst\u00fctzung vorgenommen und auf den Markt gebracht. Daf\u00fcr brauche es in den Projekten letztlich immer ein Unternehmen, das zum Beispiel in die Haftung gehe. \u201eDeshalb halten wir auch Distributoren f\u00fcr Open-Source-Automotive-Software f\u00fcr so wichtig\u201c<\/em>, sagt Neukirchner. \u201eSo ein Ansatz ver\u00e4ndert nat\u00fcrlich auch f\u00fcr uns v\u00f6llig den Business Case.\u201c<\/p>\n\n\n\nChristian Salzmann sieht das \u00e4hnlich: \u201eErfolgsentscheidend ist auch ein tragf\u00e4higes Gesch\u00e4ftsmodell von Distributoren, die die Pflege, Qualifizierung und Verantwortung f\u00fcr das Open-Source-basierte Softwareprodukt \u00fcbernehmen, und sich somit in die Wertsch\u00f6pfungskette unserer Industrie einf\u00fcgen.\u201c<\/em> \u00dcberhaupt m\u00fcsse die Community die Prozesse f\u00fcr die Anwendung von Open-Source-Software gemeinsam weiterentwickeln, sodass die Integration in Fahrzeugprojekte noch einfacher erfolgen k\u00f6nne. Das betreffe vor allem die nicht funktionalen Aspekte der Softwareentwicklung, Dinge wie Dokumentation, Testing und Absicherung oder Releasemanagement.<\/p>\n\n\n\nWie lassen sich Konzepte umsetzen?<\/h2>\n\n\n\n Moritz Neukirchner sagt, dass eine Safety-Qualifizierung in einem Open-Source-Projekt \u201ederzeit noch selten m\u00f6glich ist\u201c<\/em>, was dazu f\u00fchre, dass Projekte immer wieder \u201eim Status einer Machbarkeitsstudie h\u00e4ngen bleiben\u201c<\/em>. Das liege daran, dass in den Open-Source-Projekten die Erstellung von Sicherheitsnachweisen nicht teil des regul\u00e4ren Entwicklungsprozesses sei. \u201eHier sollte die Community sich schon viel fr\u00fcher mit der sp\u00e4teren Qualifizierung und Pflege einer Software befassen.\u201c<\/em><\/p>\n\n\n\nIn dieser Hinsicht sieht Neukirchner in dem Projekt Eclipse S-Core<\/em> einen Leuchtturm, mit dem die Community genau solche Punkte adressieren m\u00f6chte. Im Projekt soll ein \u201eSafe Open Vehicle Core\u201c<\/em> zum nicht-differenzierenden Kern eines Software-Stacks werden, der auf hochleistungsf\u00e4higen Steuerger\u00e4ten eines softwaredefinierten Fahrzeugs laufen kann. Doch neben der blo\u00dfen Code-Implementierung befasst sich das Projekt anhand von Best Practices auch mit der Frage, wie sich Konzepte und Implementierungen von Prozessen umsetzen lassen. \u201eHier sind ganz klar Unternehmen gefordert, denn nur sie k\u00f6nnen die entsprechenden Vertragswerke aufsetzen\u201c<\/em>, sagt Neukirchner.<\/p>\n\n\n\nDie Verbreitung von Open Source f\u00fcr das softwaredefinierte Fahrzeug hat sich in den vergangenen Jahren beschleunigt. Gab es vor einem Jahrzehnt tats\u00e4chlich noch OEMs und Tier-1-Zulieferer, deren Entwicklungsteams sogar explizit nachweisen mussten, dass ihr Code keine Open-Source-Anteile enth\u00e4lt, tragen inzwischen immer mehr Unternehmen selbst zu Open-Source-Automotive-Projekten bei. Wie neu diese Entwicklung trotz allem noch ist, zeigt sich auch daran, dass Stakeholder noch immer glauben, betonen zu m\u00fcssen, dass \u201eOpen Source\u201c nicht mit \u201egratis\u201c gleichzusetzen ist. Es ist ein Irrglaube, dem in der Enterprise-IT wohl schon seit zwei Jahrzehnten niemand mehr anh\u00e4ngen d\u00fcrfte.<\/p>\n\n\n\n
Projekte sollen miteinander verkn\u00fcpft werden<\/h2>\n\n\n\n Die SDV Working Group gibt es nun seit rund drei Jahren. \u201eAnfangs waren da zwar viele Projekte, aber oft gab es dann niemanden, der den Code wirklich aufgriff\u201c<\/em>, sagt Ansgar Lindwedel, Director SDV Ecosystem Development bei der Eclipse Foundation. Das habe sich inzwischen gewandelt. Die sp\u00e4ter gestarteten Projekte wiesen viel mehr Mitglieder auf.<\/em> Denn, da ist sich Lindwedel sicher: \u201eEs geht im Fahrzeug nicht mehr ohne Open Source. Software f\u00fcr den Automobilbereich erfordert 20 Jahre lang Maintenance und wird, selbst wenn sie anfangs ein Alleinstellungsmerkmal hatte, irgendwann zum Commodity-Produkt. Wir werden daher wohl immer mehr eine Softwarekonsolidierung hin zu Open Source erleben.\u201c<\/em><\/p>\n\n\n\nGleichzeitig ist Open-Source-Software inzwischen hochprofessionell entwickelt \u2013 und vermeidet Parallelaufwand. Um den auch in den Community-Projekten m\u00f6glichst zu vermeiden, will Eclipse verst\u00e4rkt auf potenzielle Ankn\u00fcpfungspunkte zwischen Projekten hinweisen. \u201eAber letztlich trifft immer die Community und nicht Eclipse die Entscheidung, den einen oder den anderen Weg zu gehen\u201c<\/em>, stellt Lindwedel klar.<\/p>\n\n\n\nBei der Open-Source-Entwicklung gehe es zu 70 Prozent um Menschen, Unternehmenskultur und Vertrauen \u2013 und nur zu 30 Prozent um Technik. F\u00fcr eine Weiterentwicklung der Community w\u00fcnscht sich Lindwedel, dass Entwicklungsteams seitens ihres Arbeitgebers die Freiheiten bekommen, um sich in der Community zu engagieren. \u201eDamit meine ich nicht nur zeitliche Freir\u00e4ume, sondern klare Signale, dass ein Engagement seitens des Unternehmens gewollt ist. Entwickler sollten in der Community f\u00fcr das Unternehmen auch technische Entscheidungen treffen d\u00fcrfen.\u201c<\/em><\/p>\n\n\n\nUmgekehrt sollten auch die Entwicklungsteams bereit sein, diese Erm\u00e4chtigung tats\u00e4chlich anzunehmen, beispielsweise in Projekten den ersten Schritt zu tun und Code einzustellen, so Lindwedel. Immer wieder stelle er da \u2013 vor allem zu Beginn eines Projekts \u2013 eine \u201egewisse Sch\u00fcchternheit\u201c<\/em> fest, wohl gespeist von der Sorge, ob man gut genug ist. Hier r\u00e4t Lindwedel zu mehr Mut: \u201eDie Open-Source-Entwicklung ist ein Community-Prozess, ein iterativer gemeinsamer Prozess, eingestellter Code muss also anfangs nicht perfekt sein.\u201c<\/em> Vielmehr propagiere die Eclipse Foundation die Formel \u201ebetter done, than perfect\u201c.<\/p>","protected":false},"featured_media":5654,"template":"","meta":{"_acf_changed":false},"tags":[],"class_list":["post-5761","news","type-news","status-publish","has-post-thumbnail","hentry"],"acf":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t