Softwareentwicklung mit AUTOSAR: Grundlagen, Engineering, Management in der Praxis
|
| Preis: | EUR 44,00 Kostenlose Lieferung Details |
Verfügbarkeit: Gewöhnlich versandfertig in 24 Stunden
Versand und Verkauf durch Amazon.de
88 neu oder gebraucht verfügbar EUR 29,80
Durchschnittliche Kundenbewertung:(5 Kundenrezensionen)
Produktinformation
- Amazon-Verkaufsrang: #71669 in Bücher
- Veröffentlicht am: 2009-06-08
- Einband: Gebundene Ausgabe
- 292 Seiten
Kundenrezensionen
Hilfreichste Kundenrezensionen
3 von 3 Kunden fanden die folgende Rezension hilfreich.
Gute Einführung und Motivation für AUTOSAR, tiefer gehts aber leider nicht..
Von Stefan V.
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.
6 von 7 Kunden fanden die folgende Rezension hilfreich.
Endlich ein Standardwerk zu AUTOSAR
Von Uwe Hartmann
Jeder der nicht von Anfang an dabei war und sich, wie ich selbst, als "Späteinsteiger" mit dem Thema AUTOSAR beschäftigen muss, kennt die Schwierigkeiten, sich einen Überblick über diesen mit jedem Release komplexer werdenden Standard zu verschaffen. Dabei hilft dieses Buch, indem es Themen beleuchtet wie
- Hintergründe, Entstehungsgeschichte und Ziele von AUTOSAR
- Wie ist AUTOSAR im Umfeld Softwarearchitektur einzuordnen?
- Worin liegen die Vor- und Nachteile dieses Standardisierungsansatzes gegenüber anderen Herangehensweisen.
- Grundlegende Begriffe, Methodik, Kommunikationsmechanismen, Module usw.
- Die AUTOSAR-Spezifikation umfasst Tausende von Seiten, wo fange ich an zu lesen?
- Was kostet ein Umstieg, welche Risiken bestehen, was kann ich gewinnen?
Einsteiger, die AUTOSAR-Tools entwickeln bzw. anwenden, oder die eigene embedded automotive Software konzipieren, schreiben oder integrieren sollen, bekommen mit diesem Buch einen hervorragenden Einstieg in die Materie geboten, der sich ansonsten nur über längere Zeit durch Herumfragen bei erfahrenen Kollegen (soweit vorhanden) und das Sammeln und Sortieren von Puzzlestücken gewinnen lässt.
Der zweite Leserkreis, der wesentlich von diesem Werk profitieren kann, sind Projektleiter und Manager bei OEMs und Zulieferern, die mit der Entscheidung für oder gegen AUTOSAR konfrontiert sind, oder die eine Einführung oder Migration bestehender Systeme vorbereiten und begleiten sollen.
Da AUTOSAR zunehmend auch ein Thema an den Hochschulen wird, kann das Buch sicherlich auch für Lehrkräfte und Studenten hilfreich sein.
Besonders positiv ist mir bei der Lektüre aufgefallen, dass durchaus auch die Nachteile von AUTOSAR nicht verschwiegen werden. Bisher fehlt jede Alternative zu diesem gelungenen Buch, das insbesondere Einsteigern und Entscheidern viel Zeit und Nerven sparen kann.
1 von 1 Kunden fanden die folgende Rezension hilfreich.
Gut zu lesen
Von Triple-s Gmbh
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)"



