Automobil-Software
Dieser Artikel soll den anfänglichen Nebel im Kopf beim Verständnis des AUTOSAR-Konzepts lichten und die Fähigkeiten und Mängel des allgegenwärtigen AUTOSAR weiter erörtern. Die Entwicklung eingebetteter Software in der Automobilindustrie unterscheidet sich stark von typischen Softwareentwicklungsszenarien in Bereichen wie Webentwicklung, Programmierung von Windows-basierten Anwendungen usw. Einer meiner ehemaligen Kollegen, Viktor Shepik, hat die Situation bei der Entwicklung von Automobil-Software in einem seiner Blogbeiträge treffend beschrieben. Wie Viktor in dem Beitrag zu Recht erwähnt, ist ein Softwareentwickler schockiert, wenn er in die Entwicklung von Automobil-Software einsteigt, und meiner Meinung nach ist das noch untertrieben.
Technische Begriffe sind domänenspezifische Begriffe, Compiler werden optimiert und überarbeitet, die Programmierregeln sind streng. Darüber hinaus sind erfahrene Ingenieure weder bereit noch haben sie die Geduld oder Zeit, ihr umfangreiches Wissen mit einem Anfänger in der Automobilbranche zu teilen. Die in den Büchern vorhandenen Informationen haben meist nichts mit den praktischen Aufgaben des Alltags zu tun.
Was ist AUTOSAR?
Zunächst einmal handelt es sich um ein Konsortium, das gleiche oder ähnliche Funktionen unter einer offenen und standardisierten mehrschichtigen Softwarearchitektur für Kfz-Steuergeräte standardisieren soll. Das Konsortium wurde 2003 von Automobilriesen wie BMW, Daimler, VW, Ford, GM, Toyota, PSA, Continental und Bosch gegründet. Automobilhersteller, Zulieferer, Software- und Tool-Entwickler arbeiten unter einem Dach zusammen.
Warum wird AUTOSAR benötigt?
Die immer komplexer werdende E/E-Technologie (Elektrik/Elektronik) von Fahrzeugsystemen war einer der Hauptgründe für die Entwicklung des Standards. Ein modernes Auto kann mehr als 100 elektronische Steuergeräte haben, und jedes davon enthält Tausende von Funktionen, die bei einem Wechsel der Hardware (Prozessortyp) oft von Grund auf neu geschrieben werden müssen. Für die Automobilriesen war es dringend notwendig, zusammenzuarbeiten, um die Anwendungssoftware von der Hardware unabhängig zu machen. Um dies zu erreichen, werden grundlegende Funktionen in AUTOSAR als branchenweite Standardkernlösung implementiert und die Software modular und wiederverwendbar gestaltet. Was sind die Ziele?
Das Motto ist einfach:
Bei Standards kooperieren, bei der Umsetzung konkurrieren
- Mit AUTOSAR ist es möglich, die Software unabhängig von der ECU zu entwickeln, und diese Software kann in verschiedene Systeme oder ECUs übertragen oder verwendet werden. Andererseits kann die Basissoftware in verschiedenen ECUs und Bereichen verwendet werden. Sie kann an verschiedene Fahrzeuge, Plattformen oder Hardware angepasst werden
- und entspricht allen internationalen Standards für die Automobilindustrie wie ISO 15767, ISO 14229, ISO 27145 und modernsten Technologien wie Steer-by-wire und autonomen Fahrzeugen.
Automobil-Steuergeräte weisen folgende Merkmale auf:
- Starke Interaktion mit der Hardware (d. h. Sensoren und Aktoren)
- Verbindung mit Fahrzeugbuskommunikationssystemen
- Enthalten einen Mikrocontroller mit typischerweise 16 oder 32 Bits
- Echtzeitsystem
- Interner/externer Flash-Speicher
AUTOSAR-Architektur
AUTOSAR unterteilt Embedded-Software in 5 Schichten. Auf den ersten Blick sehen wir ein OSI-ähnliches, aber charakteristisches Schichtenmodell, das die hierarchische Struktur der AUTOSAR-Software in einem Top-Down-Ansatz beschreibt. Zu diesem Zweck unterteilt sich AUTOSAR in Basissoftware, Laufzeitumgebung und Anwendungsschicht. In jeder Schicht werden bestimmte Softwaremodule abstrahiert und diese Schichten kommunizieren über Schnittstellen. Die Basissoftware besteht aus drei Schichten: Mikrocontroller-Abstraktionsschicht, ECU-Abstraktionsschicht und Serviceschicht. Jede Schicht enthält vordefinierte Softwaremodule und Dienste, die die Anwendungssoftware unabhängig von der ECU machen.
MCAL: Microcontroller Abstraction Layer
MCAL ist die unterste Softwareschicht der Basissoftware. Als mikrocontrollerspezifische Schicht kapselt MCAL Hardware-spezifische Treiber wie AD-Wandler, PWM, Flexray Controller, MCU, Watchdog, um direkten Zugriff auf *µC und spezifische Funktionen zu haben. Seine Aufgabe ist es, höhere Softwareschichten unabhängig von µC zu machen.
*µC: Mikrokontroller
ECAL: ECU Abstraction Layer
ECAL bietet Schnittstellen, um unabhängig vom µC auf alle Funktionen eines Steuergeräts zugreifen zu können. Seine Aufgabe besteht darin, höhere Softwareschichten unabhängig vom Steuergerät zu machen.
Services Layer
Der Services Layer stellt standardisierte Dienste bereit, die für Anwendungssoftware und Basissoftware relevant sind, wie z. B. Betriebssystem, Fahrzeugnetzwerkkommunikation, Speicherdienste (NvRAM-Verwaltung), Diagnosedienste (*UDS, Fehlerspeicher) usw. Seine Aufgabe besteht darin, höhere Softwareschichten unabhängig von ECU und µC zu machen.
*UDS: Unified Diagnostic Services
RTE: Runtime Environment
RTE ist das Herz der AUTOSAR-Architektur.
- RTE funktioniert wie ein Callcenter. Es handelt sich um eine konfigurierbare Schnittstelle (Middleware) zwischen Applikationssoftware und Basissoftware.
Applikationsschicht
Die Applikationssoftware eines Steuergeräts oder Fahrzeugs kann mithilfe des AUTOSAR-Schichtenmodells als System miteinander verbundener Softwarekomponenten entwickelt werden.
Fazit
Mit Hilfe des AUTOSAR-Schichtenmodells kann eine Applikationssoftware eines Steuergeräts oder eines Fahrzeugs unabhängig von der Hardware entwickelt und auf andere Projekte von einem Steuergerät auf ein anderes übertragen werden. Darüber hinaus werden grundlegende Funktionen wie Fahrzeugkommunikation und Fehlererkennung, die für Automobilhersteller unverzichtbare Voraussetzungen sind, als Teil der Basissoftware entwickelt, während Hersteller und Zulieferer diese Basissoftware mit AUTOSAR-Tools, die in der Regel von Tool-Anbietern entwickelt werden, so konfigurieren, dass sie ihren individuellen Anforderungen am besten entspricht. (Konfiguration)