T-Systems-Claim-Logo
Suchen
Auto-Silhouette mit bunter Licht-Aura

Embedded Software Entwicklung auf AUTOSAR

Wie kommen neue Services ins Auto? Ein Showcase am Beispiel Licht und Sicht.

08. März 2021Markus Lorenz

Auf zum Software-definierten Auto

Ein Auto mit Augenaufschlag? Wir zeigen anhand eines Showcases, wie moderne Autoservices im Software-definierten Fahrzeug entstehen. Kenntnisse von E/E-Architekturen und AUTOSAR sind für die Entwicklung von In-Car-Software essenziell. Am Schluss steht ein Auto mit Persönlichkeit. Blicken Sie mit uns unter die Motorhaube.

Auf dem Weg zur In-Car Software 

Über die Bedeutung neuer E/E-Architekturen für das Software-definierte Auto hatte ich bereits vor einiger Zeit geschrieben. Ohne moderne Architekturen wird der Weg zum digitalen Auto steinig, das Management der In-Car-Software für neue Services aufwändig.

Hier möchte ich mich dem Thema In-Car-Software von einer anderen Seite nähern: von der praktischen. E/E-Architekturen – das klingt großartig. Aber es sagt noch wenig aus, welche Komponenten konkret notwendig sind, um In-Car-Software zu entwickeln und zu betreiben. Und vor allem: Welche Fähigkeiten braucht man dazu? 

Lightshow via In-Car-Software 

Wir haben anhand eines Showcases durchgespielt, wie sich zwei typische Einsatzszenarien für moderne Autoservices mithilfe der Außenbeleuchtung (Einstieg und Ausstieg) realisieren lassen. – Und wir wollten dabei die Möglichkeiten ausnutzen, die uns moderne Hardware wie Matrix-LEDs bieten. Also kein einfaches Ein- und Ausschalten der Fahrzeugbeleuchtung, sondern eine kleine Lightshow, bei der eine vordefinierte Choreografie abläuft. In unserem Fall beginnt die Animation am Heck, umläuft das Auto mehrmals und schließt mit einem betörenden Augenaufschlag an den Frontscheinwerfern ab. Neben dem emotionalen Unterhaltungseffekt hat die Lösung auch praktische Bedeutung: Der Fahrer findet in der dunklen Jahreszeit den Weg vom und ins Auto besser. 

Doch mit den beiden Szenarien waren die Möglichkeiten noch nicht ausgereizt. Wir wussten, dass wir auch Zugriff auf Sensordaten haben, die Personen in der Nähe des Autos erfassen. Daher entschlossen wir uns, noch eine Diebstahlsicherung einzubauen. 

Wir haben von der Realsituation aus gedacht und zunächst eine Hardware/Software-Architektur auf Basis gebräuchlicher Komponenten konzipiert, die uns als Leitlinie für einen kompletten Showcase diente. Einen Showcase, der über die reine Entwicklung hinaus geht. Wir wollten ein Auto mit unserer Embedded Software an Bord. 

Ein Blick in die E/E-Architektur 

IM-Embedded-Software-1

Moderne E/E-Architekturen sehen eine (oder mehrere) übergeordnete Steuereinheit(en) vor, um serviceorientierte Architekturen zu realisieren. Diese zentralen Steuereinheiten sind nichts anderes als leistungsfähige Rechner. Auf diesen Rechnern ist die jeweils notwendige Steuerungssoftware für das Auto in Bibliotheken gespeichert. Diese Bibliotheken betreuen einzelne Funktionen im Auto und greifen auf die jeweils zuständigen Microcontroller (MCUs) zu. Mit AUTOSAR, der Automotive Open System Architecture, existiert bereits seit geraumer Zeit eine solche Standard-Bibliothek für funktionale Software. 

Whitepaper

Lernen Sie, worauf es bei der Software-Entwicklung und darüber hinaus ankommt. Das software-definierte Auto – Die Entwicklung der In-Car Software.

AUTOSAR trifft Microcontroller

Nasser Asphalt und Lichtstreifen von vorbeifahrenden Autos.

In unserem Fall ist vor allem der Microcontroller MCU PSoC 5LP für die Außenbeleuchtung relevant, u.a. die Scheinwerfer. . Er kümmert sich darum, dass unsere LEDs punktgenau ein- oder ausgeschaltet werden, und verwaltet „zufällig“ auch noch den Proximity Sensor, der erfasst, ob eine Person in der Nähe des Autos ist. Mit einer passenden Bibliothek, sprich einer In-Car-Software, können wir festlegen, wann und wie der Controller das Licht ein- und ausschaltet. Wenn AUTOSAR Classic keine solche Bibliothek vorhält, können Entwickler diese einfach hinzufügen. Genau das haben wir getan.

Wir nutzten dazu eine Entwicklungssoftware namens AUTOSAR Builder. Nachdem die genauen Spezifikationen für die Szenario-spezifischen Animationen festgelegt waren (z.B. Leuchtdauer, Leucht-Reihenfolge der LEDs, Ansteuerung der Matrix-LEDs zur Gestensimulation), programmierten wir die neuen Funktionen ganz klassisch in C bzw. C++. Der AUTOSAR Builder kompilierte den Code, so dass er konform mit der AUTOSAR-Bibliothek an Bord des Fahrzeugs ist. Der Entwicklungsteil des Systems war damit abgeschlossen. Beim nächsten Software-Update unseres Autos konnte diese Software der Bord-Bibliothek hinzugefügt werden. Der einfachste Weg dazu wäre ein Over the Air Update. Wir kopierten aber unsere Bibliothek via Laptop direkt auf den MCU. 

Wir sind für Sie da!

Sie suchen nach einem Partner für Ihre In-Car-Software-Projekte? Sprechen Sie uns an.

Auf zum Prototyp

IM-Embedded-Software-3

Im nächsten Schritt suchten wir ein Auto, mit dem wir unsere Entwicklung ausprobieren konnten. Unsere Wahl fiel auf einen Audi Q2. Keinen ganz echten, sondern einen Nachbau im Maßstab 1:8, stolze 22 x 52 cm groß. Aber wir rüsteten es mit der notwendigen Technik aus: zunächst die Fahrzeugbeleuchtung in Form von einzeln adressierbaren LEDs (Addressable 5V RGB LED Stripes für das Heck und 11x7 Matrix Breakout LEDs für die Front). Diese LEDs sind weit verbreitet; sie finden sich in ähnlicher Form heute in vielen modernen Fahrzeugen.

Die LEDs wurden an den MCU PSoC 5LP angelötet, der die Ansteuerung übernimmt. In der Realität wird PSoC allerdings nicht direkt angesprochen. Es gibt noch eine Art Concierge, der sich um die Verbindung zur Außenwelt sowie die Verarbeitung der Ein- und Ausgangssignale kümmert, der MCU ESP32. Nachdem wir ihn hinzugefügt hatten, war für unseren Showcase das E/E-Setup komplett.

ESP32 fungiert als Gateway ins Auto. Er kann über Kabel oder Wifi angesprochen werden. Zugleich hat er einen integrierten Webserver. Und dieser wiederum lässt sich über einen Standardbrowser oder via CANoe (eine Test- und Entwicklungssoftware) ansprechen. Das reichte uns im Labor, um die Funktionen auszulösen. Et voilá – alles funktioniert: Licht wird Service via Software. 

In der echten Welt ist die Steuerung der Beleuchtung abhängig von einer Vielzahl von Eingangssignalen, wie zum Beispiel dem Status der Türen („Tür vorne links auf/zu“), dem Klemmenstatus („Zündung ein/aus“) oder der Ver-/Entriegelung des Fahrzeugs. In der Regel löst der Fahrer die Animation aber mit einem Druck auf den Autoschlüssel aus – und die ganze Welt der On-Board-Hardware und -Software bleibt „unter der Motorhaube“.

Know-how für In-Car-Software-Projekte

Entwickler für In-Car-Software brauchen nicht nur Expertise in der Softwareentwicklung, sondern müssen auch vertraut sein mit modernen E/E-Architekturen. Insbesondere benötigen sie Know-how in AUTOSAR. Zudem ist entscheidend, Sicherheitsaspekte zu berücksichtigen. 
Tatsächlich gibt es noch zumindest zwei weitere Parameter, die für den Erfolg eines professionellen In-Car-Software-Projektes relevant sind: Das Entwicklungsteam muss über die reine Steuerungssoftware in der AUTOSAR-Bibliothek hinausdenken. Eventuell ist zusätzlicher Code für die Kooperation zwischen AUTOSAR und Hardware notwendig. Und der Code muss natürlich in verschiedenen Szenarien getestet werden. 
Dieser Showcase zeigt Ihnen, wie In-Car-Software entwickelt wird und was dabei zu beachten ist. Falls Sie entsprechende Projekte planen, sprechen Sie uns an und lassen Sie uns gemeinsam den Weg zum „software-defined Car“ gehen. Es muss nicht immer ein Augenaufschlag für das Auto sein.

Zum Autor
Markus Lorenz

Markus Lorenz

Senior Business Development Manager im Sales Automotive & Manufacturing, T-Systems International GmbH

Profil und alle Artikel ansehen
Besuchen Sie t-systems.com außerhalb von Germany? Besuchen Sie die lokale Website für weiterführende Informationen und Angebote für Ihr Land.