Wie Mathworks die Entwicklung systematisieren will

Udo Gohier: Grundsätzlich geht es Mathworks sehr gut, denn die voranschreitende Digitalisierung hilft unseren Kunden dabei, unsere Produkte verstärkt einzusetzen. In den letzten 15 Jahren ist ja der Anteil von Elektronik im Fahrzeug immer weiter vorangeschritten, und ich glaube, es ist fair zu sagen, dass wir daran einen sehr großen Anteil hatten: Je mehr im Fahrzeug auch die Software in den Vordergrund rückt, desto mehr setzen sich unsere Kunden mit unseren Produkten auseinander. In einem Satz: Es geht uns in Automotive sehr gut.

Was heißt das in Zahlen?

Udo Gohier: Mathworks hat heute mehr als 6000 Mitarbeiter weltweit und Umsätze von rund 1,25 Milliarden US-Dollar. Die Automobilindustrie ist ein sehr wichtiger und einflussreicher Markt für uns in vielen Ländern. In Europa und speziell hier in Deutschland sind wir stark engagiert.

Udo Gohier: Schon in den späteren 90er Jahren haben die ersten Matlab- und Simulink-Produkte dazu beigetragen, dass mathematische Berechnungen auf ECUs korrekt entworfen und implementiert wurden, aber mittlerweile hat sich die Komplexität natürlich vervielfacht. In dieser rasanten Steigerung der Komplexität haben wir unsere Chance gesehen und unsere Produkte entsprechend ausgerichtet. Außerdem sind wir sehr früh in einen intensiven Dialog mit den Kunden gegangen. In den 90ern haben wir auf Initiative von Unternehmen wie Daimler, Toyota, Bosch oder Ford Workshops gehalten, in denen es um den Übergang von der reinen Hardware hin zu einem Embedded-Hardware/Software-System ging.

Aus diesen frühen Workshops wurde dann das sogenannte Mathworks Automotive Advisory Board, MAAB, das bis heute fortgeführt wird. So können wir intensiven Kontakt zur Basis bei den Kunden halten, um wirklich festzustellen, an was die Ingenieure arbeiten und was die großen Problemstellungen sind. Das Feedback, das wir dort einsammeln, fließt dann in die Weiterentwicklung und Optimierung unserer Produkte ein – nicht nur in Funktionalität, sondern auch hinsichtlich Kompatibilität, Inter-operabilität, Geschwindigkeit, Realtime- oder Faster-than-Realtime-Simulationen, wie wir sie heute quasi in jedem Produkt zur Verfügung stellen.

Später haben wir dann das Format des Advisory Boards auf weitere Industrien übertragen, und der Austausch mit Kunden aus der Luft- und Raumfahrt, der Halbleiterindustrie und des Maschinenbaus bis hin zu Finanzunternehmen mit ihren Big-Data-Herausforderungen hat zu wichtigen Produkterweiterungen auch für Automobilingenieure geführt.

Mit dem MAAB haben wir uns auch bei der Einführung von Programmier- und Entwicklungsstandards nach vorne bewegt, dort zugehört, aber auch versucht, Einfluss zu nehmen. Es wurde nämlich sehr früh klar, dass wir uns sehr schwertun würden, wenn jeder seinen eigenen Daimler-, Ford-, Toyota-, Volkswagen-Standard etc. ausbaut. In der Folge hätten wir unzählige Modellierungs-Guidelines oder Code-Standards unterstützen müssen, und die Effizienz unserer Entwicklungsplattform und damit auch die Effizienz der Produktentwicklung beim Kunden hätte sich deutlich reduziert. Zu diesem Zeitpunkt entstand die Idee, dass für die Software-Entwicklung eher ein Modellieren und ein Standardisieren notwendig ist, ein Systematisieren der kompletten Entwicklungs-Workflows.

Und das waren damals quasi auch die Ursprünge der modellbasierten Entwicklung, wo wir versucht haben, den Ingenieuren passende Modelle quasi als Programmierhilfe zur Verfügung zu stellen, an denen sie sich orientieren können und mit denen sie ihre Ideen ausprobieren und testen können. Durch den zunehmend konsequenten Einsatz von Modellen und Simulationen wurde dann ermöglicht, die Komplexität von ganzen Systemen in den Griff zu bekommen.

Wir sind ja schon seit Jahren eng mit dem akademischen Bereich verzahnt, und das hat uns auch im Automotive-Bereich sehr geholfen. Weil die Studierenden schon während ihres Studiums unsere Software nutzen, kommen angehende Ingenieure, Wissenschaftler und Informatiker gut vorbereitet in ihre ersten kommerziellen Projekte. Mit unserem Ansatz für die akademische Lizenzierung unterstützen wir auch die akademischen Anwender, so dass sie unsere Tools in Lehre, Forschung und Projekten einsetzen können – inklusive Support durch uns.

Udo Gohier: Das weite Spektrum unserer Produkte ist wohl am besten erklärt mit unserem Firmenmotto „Accelerating the pace of engineering and science” – die Beschleunigung des Fortschritts in allen Technologie- und Forschungsfeldern, die wir durch die Systematisierung der Entwicklung ermöglichen. Unsere Produkt-Plattform basiert auf Matlab, unserer Umgebung für technische Berechnungen, die Entwicklung von Algorithmen, Datenanalysen und -visualisierungen, und Simulink als Blockdiagramm-basierte Entwicklungsumgebung für Simulationen und modellbasierte Produkt Entwicklung.

Welche technischen Herausforderungen sehen Sie denn derzeit?

Udo Gohier: Bei der Entwicklung des Software-defined Vehicle gibt es vielfältige technische Herausforderungen. Die Umstellung auf einen vollelektrischen Antriebsstrang erfordert neue Ansätze für die Regelung und fahrzeugweite Energiestrategien. Gleichzeitig müssen die Batterietechnologie und das Batteriemanagement beherrschbar sein.

Dann gibt es die Herausforderung der Kommunikation, sowohl innerhalb des Fahrzeugs als auch von Fahrzeug zu Fahrzeug und zur Fahrzeuginfrastruktur, und dies in Echtzeit. Hier steht nicht nur die Technik für die Kommunikation selbst im Blickpunkt; es müssen Funktionen entworfen werden, die auf Grundlage der Kommunikation das Fahrerlebnis wirklich verbessern und zuverlässig sind.

Für das autonome Fahren muss ein koordinierter Satz von ADAS-Funktionen bereitgestellt und ins Fahrzeug integriert werden. Für die Weiterentwicklung muss man darauf achten, dass die Funktionen ausbaufähig sind in Richtung vollständiger Autonomie. Hinzu kommen die Herausforderungen rund um Cybersecurity. Sie sind zentral für alle Anwendungen und müssen daher im gesamten Entwicklungsprozess verankert sein. Um durchgängige Security zu erreichen und sich den dynamischen Bedrohungsszenarien zu stellen, muss die Funktionalität sehr schnell anpassbar sein. Dabei darf die Safety des gesamten Systems nicht beeinträchtigt werden.

Darüber hinaus betreffen diese Herausforderungen die Integration der einzelnen technischen Ansätze in einen einheitlichen Entwicklungsprozess und die dazu erforderliche Abstimmung von Prozessen und Methoden aller beteiligten Teams.

Udo Gohier: Die Herausforderungen der Automobilindustrie sind ja exponentiell nach oben geschnellt. Elektrifizierung ist das eine, Connectivity ist das andere. Es geht auch darum, diese Gigabyte von Daten sinnvoll zu nutzen und damit einen Mehrwert zu generieren. Neben klassischen Methoden zur Daten-Auswertung und -Reduktion kommen hier mehr und mehr auch KI-Methoden wie Machine Learning und Deep Learning zum Einsatz. Und hierfür bieten wir verschiedene Lösungswege, die nicht bei Interpretation der Daten halt machen, sondern mit denen sich KI-Modelle in ein Gesamtsystem integrieren lassen. Der Weg zum autonomen Fahren stellt fundamental andere Anforderungen an die Daten und die E/E-Architekturen als das noch vor fünf bis zehn Jahren der Fall war.

Cybersecurity ist ein weiterer, extrem wichtiger Bereich, denn es gibt keine Safety ohne Security. Bei Funktionen und Lösungen für Functional Safety sind wir in den letzten Jahren sehr nach vorne geschritten, und einige dieser Lösungsansätze können wir in den Cybersecurity-Bereich übertragen. Ein gutes Beispiel ist die Buffer-Overflow-Problematik, an der wir im Safety-Bereich seit Jahren arbeiten; jetzt sorgt diese Problematik im Security-Bereich für Schlagzeilen. Wir haben unter anderem mit unseren Polyspace-Produkten die entsprechenden Werkzeuge für mehr Sicherheit entwickelt – getrieben von Safety-Themen. Die ISO 26262 unterstützen wir schon seit 2010 mit einem Referenz-Workflow und arbeiten auch in Working Groups für Standardisierungen mit, z. B. der Working Group für ISO 21434 zum Cybersecurity-Standard.

Wie unterstützen Sie das Testen in der virtuellen Welt?

Udo Gohier: Simulationen ermöglichen wir seit über 30 Jahren – und dies in unterschiedlichen Ausprägungen bezogen auf Realitätstreue und in verschiedenen Konzepten und Intensitäten von Simulation. Früher standen jedoch häufig einzelne Komponenten, Fahrzeuge oder ein Einzelsystem und dessen Funktionalität im Zentrum.

Im Rahmen des autonomen Fahrens ist der Kontext noch einmal erheblich größer. Es gehört dann eben auch dazu, die Welt, in der das Fahrzeug fährt, virtuell abzubilden. Hierzu gehören Fußgänger, Störfälle etc. in verschiedenen Szenen und Szenarien. Damit gehen wir weit über eine singuläre Funktionsprüfung hinaus, denn das gesamte autonome Fahrzeug und alle abhängigen Subsysteme müssen vor diesem Hintergrund simuliert werden, zusammen mit Verkehrsteilnehmern.

Diese konsequente Verlagerung in den Simulationsbereich wird heutzutage mit dem Begriff des Shift-Left beschrieben. Dies besagt nichts anderes, als dass die Gesamtabsicherung schon in die Simulation vorgezogen werden kann. Mit Simulationen lassen sich die Anforderungen überprüfen und Integrationsprobleme entdecken, und sie helfen zu verstehen, wie sich ein System in unerwarteten Situationen verhält. Solche virtuellen Tests lassen sich automatisiert in großem Maßstab mit Matlab und Simulink durchführen, wozu High-Performance-Computing und Cloud-Ressourcen genutzt und riesige Datenmengen als Simulationsinputs verwendet werden.

Udo Gohier: Die Herausforderung liegt in der rapiden ansteigenden Anzahl von parallel arbeitenden und interagierenden Systemen, die zusammen mindestens genauso gut oder besser agieren müssen wie ein Mensch. Damit einher geht zum einen eine Explosion des Entwicklungsaufwands. Dem kann nur begegnet werden mit einem Dreiklang aus einem modellbasierten Design-Ansatz und umfassender und hochpräziser Simulation, getragen durch Industrie-Standards. Zum anderen verursacht die immer höher werdende Komplexität ein zunehmendes Risk of Failure. Dieses Risiko kann nur durch frühzeitiges Validieren und Verifizieren minimiert werden, wobei das Testen und die Verifikation direkt schon im Entwicklungsprozess verankert sein muss.

Verschiedene Ansätze zur Softwareentwicklung, wie modellbasiert und agil, müssen zusammengeführt und automatisiert werden, um schneller zu Resultaten zu kommen als jemals zuvor. Für Mathworks sind das die Grundlagen eines aktuellen systematischen Entwicklungsprozesses. Daraus folgt für den Kunden eine messbar bessere Softwarequalität in kürzerer Zeit.

Udo Gohier: Eins der heißesten Themen ist die Migration des Entwicklungsprozesses in die Engineering Cloud. Das bedeutet, dass nicht nur Daten in der Cloud liegen, sondern auch Berechnungen und Simulationen in der Cloud durchgeführt werden und dass die Continuous Integration idealerweise bereits mit Anbindung an die Cloud erfolgt. Warum ist das so? Die Anforderungen an den Grad der Automatisierung steigen stetig, komplexe Systeme und kürzere Innovationszyklen erfordern agile Entwicklungsmethoden. Die stetig ansteigende Menge an Daten aus Entwicklung und Designdokumenten, Simulation, Prozessen und Betrieb muss nutzbar gemacht werden, damit sie als Feedback-Mechanismus für kontinuierliche Verbesserungen von Produkt und Service einfließen können.

Alles zielt darauf ab, das Software-defined Vehicle als sicheres und bezahlbares und nachhaltiges Produkt entstehen zu lassen. Diese Technologie muss sich ferner hoch automatisiert anpassen, weiterentwickeln, simulieren und testen lassen. Ein Aspekt davon ist auch die Implementierung auf Hardware, seien es Embedded Microcontroller, FPGAs, DSPs oder weitere Varianten. Denn Ingenieure sollen die Wahl haben und sich nicht bereits vor der Algorithmen-Entwicklung schon für eine Hardware entscheiden zu müssen.

Kosten gemessen in Zeit spielen in diesem Zusammenhang selbstverständlich eine entscheidende Rolle. Daher sind wir besonders erfreut über Aussagen von unseren Kunden, dass sie durch die Nutzung unserer Tools – im Vergleich zur nicht-modellbasierten Entwicklung – 20 Prozent bis 40 Prozent Zeit einsparen.

Udo Gohier: Die Herausforderungen sind mannigfaltig. Lassen Sie mich folgende Bereiche ansprechen: Software- und Hardwareentwicklung müssen entkoppelt werden, da sie unterschiedlichen Zyklen folgen. Das heißt aber nicht, dass es nicht einen intensiven Austausch geben muss.

Der zweite Punkt betrifft die Kooperation von Menschen in unterschiedlichen Aufgabenfeldern. Systems Engineering und Software Engineering müssen lernen, einander zu verstehen und zusammen zu arbeiten. Sogenannte Domain Skills, also ein bereichsübergreifendes Wissen, müssen entstehen, und der vorhandene Erfahrungsschatz muss durch Up- und Re-Skilling erhalten bleiben. Durch einen direkten Austausch und die Zusammenarbeit von Entwicklern aus unterschiedlichen Bereichen entstehen dann neue Synergien.

Als drittes kommen die angewandten Methoden ins Spiel. Das bekannte und gelernte V-Modell sollte mit agilen Methoden der Software-Entwicklung und dem DevOps-Ansatz für kontinuierliche Modifikationen verheiratet werden. Natürlich nur bis zu einem sinnvollen Maß. Wir prägen innerhalb von Mathworks den Begriff des Automotive-Grade DevOps. Das stellt sicher, dass neben einer agilen Arbeitsweise auch die Absicherung den nötigen Stellenwert in der Entwicklung erhält.

Und viertens müssen Standards in den Blick genommen werden: Um die Effizienz innerhalb der Industrie zu adressieren, um legislative Regularien für Functional Safety oder Themen der Cybersecurity folgen zu können oder auch um kompatibel zu Autosar-Vorgaben zu sein. Diese Standards müssen möglichst umfassend von der Tool-Chain unterstützt werden.

Udo Gohier: Ein verstärkt auftretendes Problem ist der Wildwuchs von nicht interoperablen Entwicklungswerkzeugen, der über die Jahre entstanden ist. Wir sehen dort teilweise 200 oder 300 isolierte Werkzeuge im Einsatz einer Entwicklungsreihe. Das blockiert einen durchgängigen, managebaren und automatisierbaren Workflow. Interoperabilität ist nicht gewährleistet und erfordert häufig ein manuelles Nacharbeiten. Dadurch leidet die Qualität der Software bis hin zur Dysfunktion, und von Effizienz kann keine Rede mehr sein. Diese Risiken muss man durch eine konsequente Durchgängigkeit der Tool-Ketten in den Griff bekommen.

Welche Bedeutung hat der Automobil-Elektronik-Kongress für Sie?

Udo Gohier:  Dort kommen die Transformatoren der Automobilindustrie und die Entscheider zusammen, um sich über die neuesten Entwicklungen auszutauschen. Meine Erfahrung ist, dass dort die bedeutenden und dringlichen Themen adressiert und diskutiert werden.   