Softwareentwicklung mit AUTOSAR: Grundlagen, Engineering, Management in der Praxis [Gebundene Ausgabe]

Die beiden Autoren geben auf knapp 50 Seiten eine gute Motivation für den Einsatz von AUTOSAR, in dem sie den Ist-Zustand von Softwarearchitektur und Entwicklungsprozessen aktueller embedded Systeme im automotive Bereich beschreiben. Die folgenden 100 Seiten vermitteln recht anschaulich die technische Grundlagen und Grundgedanken zu AUTOSAR.
Die letzten 100 Seiten beschäftigen sich mit den zu erwartetenden Vor- bzw. Nachteilen beim Einsatz von AUTOSAR. Dieser Teil scheint mir eher wenig gelungen, da hier dem Leser die Übersicht in der Vielzahl halbherzig angerissener Themen die Übersicht verloren geht. D.h. man vermisst immer wieder die Abgrenzung zw. AUTOSAR spezifischen Problemen und denen vom "konventionellen" Softwareengineering.

Im folgenden eine Auflistung konkreter Kritikpunkte:

Seite 117ff. Inhaltlich teilweise etwas dünn: "Die ECU Abstraktionsschicht abstrahiert von der ECU... "

Auf Seite 99ff. werden die verschiedenen Kommunikationsarten erläutert. Es existieren auch gute, knappe Beispiele für C-Implementierungen von Ports/Interfaces. Schön wären hier noch Beispiele für die entsprechende xml -Notation.

Seite 130: Was ist AUTOSAR OS (In einem Buch über AUTOSAR sollten doch zumindest 3 Seiten nur über AUTOSAR OS möglich sein. Wie erfolgt Speicherschutz und Dealineüberwachung?)

Seite 158:
Beispiel für Resourcenmehrverbrauch durch Autosar (Beispielprojekte)
Woher stammen die Mindestanforderungen 32Bit und 256kb ROM? Wie sieht sieht der Mehrverbrauch bzgl. ICC1, ICC2 bzw. ICC3 aus? Nur Beispiele aus der Praxis können hier als Argumentationshilfe für Projektleiter, Architekten etc. dienen.

S. 159 Hier geben uns die Autoren eine kleine Werbeeinlage für Effizienz von C++ Code. Der Zusammenhang ist jedoch unklar: Wird C++ von Autosar propagiert?

S.165 Variantenmanagement
Etwas unstrukturiert (ja, meine Rezension ist das auch :-) ).
Erst am Ende des Kapitels wird der Bezug zu AUTOSAR wieder hergestellt.

S.178 AUTOSAR TOOLS: Hier fehlt eine Übersicht der verfügbaren Tools und Erfahrungen mit diesen.

S.180 Modellierung und Integration: Hier erfolgt ein Abriß über die Unzulänglichkeit verfügbarer Beschreibungssprachen für dynamischen Verhalten. Der Sinn des Abschnitts in Bezug auf "Kritik an Autosar" wird nicht ganz ersichtlich. Kann man es besser lösen?

S. 182 Die Absatztitel "Von der Integrationsnot in die Konfigurationsnot" ist sehr wichtig und gut gewählt leider aber etwas zu kurz und didaktisch mäßig aufgebaut. Konfigurationen sind teilweise für den Anwender eines Autosar-Konfigurators nur durchzuführen, wenn dieser die Implementierung dahinter kennt. Die Trennung vom Konfigurierer und Implementierer ist in der Praxis äußerst schwer. Hat AUTOSAR.org sich hier Ziele/Lösungen parat?

S.183 "Dokumentation einer Konfiguration" ebenfalls äußerst wichtiger Kritikpunkt ist die Nachverfolgbarkeit und Vergleichbarkeit von Konfigurationen auf XML Basis. Sehr schön, dass dieser Punkt erwähnt wird. Dieser Nachteil kann aber fast garnicht groß genug gedruckt werden. Erwähnenswert evtl. auch Anwendung herkömmlicher Teststrategien (Unit-Tests) auf Konfigurationen bzw. generierten Code. Durch die mir bekannten Tools kann derart unterschiedlicher Code durch verschiedene Konfigurationen erzeugt werden, dass man sich nicht mehr auf exemplarische Test von exemplarischen Konfigurationen verlassen kann.
Dagegen lassen sich (im Hinblick auf Dokumentation und Tracability) Links zu Requirements häufig einfacher einem Konfigurationspunkt zuordnen als einer Codezeile.
Auch hier: Wie sieht AUTOSAR.org das Problem?

S.185 Sensorfusion: Meiner Ansicht nach unsinniges Beispiel. Niemand kommt auf die Idee Rohdaten von Kameras und Radarsensoren über den Fahrzeugbus zu verteilen oder auch nur über einen Kommunikationsstack laufen zu lassen. Die entsprechende Objekterkennung wird natürlich im gleichen Steuergerät vorgenommen und die Positions-, Geschw.- und Beschleunigungsdaten der erkannten Objekte über den Bus zu den verschiedenen Assistenzsystemen verteilt.

S. 186 Im Abschnitt "Dynamik zur Laufzeit" bleibt unklar, was eigentlich der Kritikpunkt ist. Bzw. trägt in der Kürze nur zur Verwirrung bei. Für Infotainment und sicherheitskritische Applikationen gelten einfach ganz verschiedene Massstäbe. AUTOSAR will hier aktuell nur für die zuletzt genannten einen Standard bieten. Dynamik zur Laufzeit wird es in diesem Bereich auch in ferner Zukunft nicht geben.

S.187 Abschnitt "Timing und Multitasking". Das ist teilweise richtig für die Applikationen oberhalb der RTE. Ein guter Konfigurator sollte jedoch keine Synchronisationsprobleme, Race-Conditions oder Deadlocks im generierten Code erzeugen.

S. 197 Die Beziehung zwischen Usability und Reusability sollte mit einer Quellenangabe belegt sein.

S. 197 Bezug zur AUTOSAR im Abschnitt "Schutz des geistigen Eigentums" unklar.

S. 206 Auch ohne AUTOSAR kann eine Auslieferung als .h und .obj erfolgen und tut es häufig auch. Allerdings zwingen die OEMs den Zulieferer häufig zur Veröffentlichung des Quellcodes.

S.209 Hier wird kurz mal ein schwerwiegendes Problem aus der Praxis genannt. Warum ist das Netzwerkmanagement inkompatibel zu "konventionellen ECUs"? Ist das konventionelle Konzept nicht abwärtskompatibel erweiterbar gewesen? Warum? Wie behandelt AUTOSAR.org das Problem?

S.209 Ein Protokoll, das oberhalb von z.B. CAN-TP liegt als Complex-Device Driver implementieren? Warum?

S.219 Abschnitt zur Werkzeugauswahl. Grober Abriss zu Auswahlkriterien, die auch ohne AUTOSAR selbstverständlich sein sollten.

Fazit: Es erfolgt eine gute und leicht verständliche Einleitung über die Motivation für AUTOSAR und dessen technischen Grundlagen in den ersten 150 Seiten. In letzten Teil verliert man sich in vielen Details und Andeutungen. Weniger und dabei präzisere Punkte mit Quellenangaben oder konkreten Praxiserfahrungen wären wünschenswert.
Schön wäre ein Erfahrungsbericht bei der Entwicklung eines Serienprojekts mit festgestellten Hürden oder auch positiven Erfahrungen und ein Vergleich zur klassischen Implementierung (Ja, diese gibt es zumindest schon einigermaßen seriennah).
Hat nicht das Zeug zum Standardwerk, aber für einen Einstieg in das Thema dennoch bedingt empfehlenswert.

Das Buch vermittelt einen guten Einstieg in die Thematik, wenn man es genauer wissen will kommt man aber an einem detaillierten Blick in die AUTOSAR-Spezifikation nicht vorbei.
Manchmal wuerde ich mir etwas ausfuehrlichere Beschreibung und noch etwas mehr Hintergrundinformationen wuenschen. Insbesondere beim Zusammenspiel der verschiedenen Layer der Architektur (Applikation/Basis-Software und RTE-Generierung).
Die Beispiele sind nicht immer gleich vollstaendig dargestellt, was zu Verwirrung fuehren kann. Hier sollte das Buch erweitert werden und der gesamte AUTOSAR-Arbeitsablauf am Beispiel Schritt fuer Schritt ausfuehrlicher illustriert werden.
Eine Neuauflage des Buches waere fuer mich daher wuenschenswert, auch da inzwischen der AUTOSAR-Standard an einigen Stellen erweitert wurde, die im Buch bisher nicht beruecksichtigt sind.

Wer sich erstmalig mit AUTOSAR beschäftigen will oder muss für den ist dieses Buch die ideale Ergänzung um den Einstieg in den Standard (www.autosar.org) zu finden. Mit dem Buch bekommt man für wenig Geld ein Grundwissen zu AUTOSAR auf dem Silbertablett serviert, das man sich aus dem Standard mühsam erarbeiten müsste. Viele Grafiken, gut gewählte Beispiele und ein flüssiger Schreibstil sorgen für entspanntes Lesen. Auf der anderen Seite wird umfassend auf alle möglichen Aspekte der Softwareentwicklung im Bereich Automotive eingegangen, wobei sich die Autoren auch nicht scheuen dabei die oft real bestehenden Missstände anzuprangern. Allein der Titel ist irreführend, da er beim Profi Erwartungen weckt, die das Buch nicht einhalten kann. Besser wäre gewesen: "Softwareentwicklung mit AUTOSAR (Band I Grundlagen)"