Autoren: Thomas J\u00e4ger, Robert Bosch GmbH, Ingo Houben, Dr.-Ing. Ralf M\u00fcnzenberger, INCHRON GmbH<\/p>\n
Ein modellbasierter Ansatz, bei dem aus einer Single-Source-Quelle weitere Prozessschritte abgeleitet werden, bietet viele Vorteile. Das Systemmodell von AMALTHEA dient hierbei als Ausgangspunkt, um eine robuste dynamische System- und Software-Architektur zu entwerfen sowie Source-Code und Testf\u00e4lle zu erzeugen. In diesem Artikel wird ein Workflow vorgestellt, wie ausgehend von einem AMALTHEA-Systemmodell eine Architektur simuliert, analysiert und im Fehlerfall optimiert wird.<\/strong><\/p>\n Die Entwicklung von Fahrerassistenz-Systemen, seien es L\u00f6sungen auf einzelnen Steuerger\u00e4ten wie einer Kamera, oder Netzwerk-Verb\u00fcnde mehrerer Sensoren und Kontrollrechner, beginnt mit der Konzeption des Systemdesigns und wird in der daraus abgeleiteten Software-Architektur verfeinert. Die Herausforderungen liegen in der Beherrschung der zugrunde liegenden parallelen Hardware, wie Multicore-Rechnern, oder der Nebenl\u00e4ufigkeit von ganzen Steuerger\u00e4te-Netzen. Die verschiedenen logischen Pfade der Datenverarbeitung auf solchen Systemen verlaufen demzufolge parallel und weisen im Zuge der Informationsverdichtung Synchronisationspunkte, aber auch Verzweigungen auf. Rechenzeiten sind meist nicht konstant und Aufrufzyklen teilweise physikalisch an den Sensor oder den Aktuator gebunden, so dass es keine einheitliche Verarbeitungsfrequenz geben kann.<\/p>\n Die Parameter f\u00fcr die Entwicklung eines solchen Systems sind vielf\u00e4ltig und haben dar\u00fcber hinaus auch keine statische Verteilung \u00fcber der Zeit. Daher ist eine Unterst\u00fctzung durch geeignete Werkzeuge unumg\u00e4nglich, um die Komplexit\u00e4t und Variabilit\u00e4t w\u00e4hrend der System- und Softwareentwicklung zu beherrschen und zu verstehen. Grade die dynamischen Aspekte lassen sich \u00fcberhaupt erst durch eine geeignete Visualisierung untersuchen und mit Entwicklungsteam und dem Kunden kl\u00e4ren.<\/p>\n Die Anforderungen an das Werkzeug werden durch die vielf\u00e4ltigen Anwendungsf\u00e4lle bestimmt. Im Einzelnen sind es:<\/p>\n Um Inkonsistenzen in den Anwendungsf\u00e4llen zu verhindern, ist ein Single-Source-Ansatz w\u00fcnschenswert, wie es durch das AMALTHEA-Systemmodell m\u00f6glich ist. Vor allem f\u00fcr die Anforderungen (Requirements), die Generierung von Code sowie die Testf\u00e4lle wird eine durchg\u00e4ngige Nachweisbarkeit (Traceability) ben\u00f6tigt.<\/p>\n AMALTHEA [1] unterst\u00fctzt als offenes, standardisiertes Format zur System- und SW-Beschreibung die genannten Anwendungsf\u00e4lle (Abbildung 1,\u00a0PDF<\/a>). Es bringt ein Metamodell mit, dessen Instanzen in XML serialisiert werden k\u00f6nnen. Dar\u00fcber hinaus stellt es \u00fcber die Eclipse-Plattform eine m\u00e4chtige Entwicklungsumgebung bereit, um auf Instanzen der XML-Datenmodelle arbeiten zu k\u00f6nnen. Damit lassen sich \u00fcber Java- und Xtend-Programmierung beliebige Modell-Transformationen realisieren.<\/p>\n Am Beispiel einer vereinfachten Architektur eines Kamerasystems werden im Folgenden die einzelnen Aspekte dargestellt und praktisch erl\u00e4utert.<\/p>\n Die System-Architektur umfasst einen Imager-Chip zur Bilderfassung und einen integrierten Baustein mit mehreren Verarbeitungseinheiten. Diese sind spezialisierte Rechner f\u00fcr die Bildvorverarbeitung (Preprocessing, Feature-Berechnung sowie Klassifikation) und frei programmierbare Kerne. Jeder\u00a0osek-scheduler<\/em>\u00a0ist genau einer Verarbeitungseinheit zugewiesen, wie beispielsweise\u00a0Sch_Osek_2\u00a0<\/em>dem\u00a0Core_2<\/em>\u00a0auf dem Mikrocontroller\u00a0SOC<\/em>\u00a0(siehe Abbildung 2,\u00a0PDF<\/a>).<\/p>\n Auf die Recheneinheiten lassen sich jetzt die einzelnen logischen Verarbeitungsschritte zuordnen, wie in Abbildung 3 (siehe\u00a0PDF<\/a>) dargestellt. Der Scheduler\u00a0Sch_Osek_2<\/em>\u00a0ist hierbei mit der Task\u00a0task_2<\/em>\u00a0verkn\u00fcpft. Dieser Task wird periodisch getriggert durch einen 40ms Zeittrigger. Im Task wird das Runnable\u00a0runn_merge<\/em>\u00a0aufgerufen.<\/p>\n In der gleichen Art und Weise lassen sich ISR und weitere Tasks modellieren. Alle Tasks eines Schedulers konkurrieren um Rechenzeit auf der gleichen Verarbeitungseinheit, w\u00e4hrend die Tasks verschiedener Verarbeitungseinheiten parallel abgearbeitet werden k\u00f6nnen.<\/p>\n Dar\u00fcber hinaus ist es m\u00f6glich, die logischen Datenbeziehungen zwischen Runnables zu modellieren. In Abbildung 4 (siehe\u00a0PDF<\/a>) erh\u00e4lt das Runnable\u00a0runn_merge\u00a0<\/em>als Input Objekte vom Runnable\u00a0runn_algo\u00a0<\/em>und Klassifikationsergebnisse vom Runnable\u00a0runn_hwclass<\/em>\u00a0und liefert an die Funktionsberechnung eine fusionierte Szenenbeschreibung als Output f\u00fcr Runnable\u00a0runn_func<\/em>.<\/p>\n Ein \u00dcberblick \u00fcber die logischen Datenbeziehungen im modellierten System l\u00e4sst sich mithilfe des AMALTHEA-Frameworks als UML-Diagramm generieren (Abbildung 5, siehe\u00a0PDF<\/a>).<\/p>\n In der Regel sind f\u00fcr einen logischen Datenfluss (siehe Abbildung 5) zeitliche Anforderungen definiert, die in der Implementierung eingehalten werden m\u00fcssen. Typische Echtzeit-Anforderungen sind beispielsweise maximale und minimal Latenzzeiten, Datenverlust oder Datensynchronisation, wie in [3] beschrieben.<\/p>\n Eine reine statische Analyse des logischen Datenflusses durch ein Summieren der einzelnen Latenzzeiten der Bl\u00f6cke und Kanten ist nicht ausreichend, da weder Effekte durch Task-Scheduling oder Unterbrechungen von ISRs ber\u00fccksichtig werden, noch durch Inter-Core-Kommunikation oder im Allg. durch Kommunikation zwischen den Verarbeitungseinheiten. Hierf\u00fcr ist eine dynamische Betrachtung des Systemverhaltens basierend auf einem Timing-Modell notwendig.<\/p>\n In Abbildung 1 (siehe\u00a0PDF<\/a>) wurde als wichtige Anwendung von AMALTHEA die Simulation sowie die Visualisierung des dynamischen Systemverhaltens aufgezeigt. Das hierf\u00fcr ben\u00f6tigte Timing-Modell wird automatisiert aus dem AMALTHEA-Systemmodell generiert.<\/p>\n Das so erhaltene Timing-Modell wurde in die INCHRON Tool-Suite [2] geladen und mit dem Echtzeitsimulator chronSIM untersucht. Dieser Simulator zeigt das Echtzeitverhalten des untersuchten Systems aus verschiedenen Perspektiven. Neben Single-Core- und Multi-Core-Systemen k\u00f6nnen auch verteilte Systeme mit mehreren Prozessoren untersucht werden, die \u00fcber simulierte CAN- und FlexRay-Busse, per Ethernet oder \u00fcber andere Bussysteme kommunizieren.<\/p>\n Abbildung 6 (siehe\u00a0PDF<\/a>) zeigt den Datenfluss im untersuchten System. Dargestellt sind die Tasks auf den verschiedenen Recheneinheiten, die an den farbigen Balken links erkennbar sind. Jede Zeile zeigt den aktuellen Betriebssystemzustand eines Tasks. Die geschwungenen Verbindungen zeigen den logischen Datenfluss zwischen den Runnables, die in den Tasks ausgef\u00fchrt werden.<\/p>\n Aus Abbildung 6 (siehe\u00a0PDF<\/a>) ist ersichtlich, dass der zeitliche Verlauf des Datenflusses von der geradlinigen Darstellung in Abbildung 5 (siehe\u00a0PDF<\/a>) deutlich abweicht: Der \u00fcberlappende Verlauf entsteht dadurch, dass zu einem Zeitpunkt mehr als ein Satz von Bilddaten im System bearbeitet wird.<\/p>\n Im Timing-Modell sind die logischen Datenfl\u00fcssen als sogenannte Event-Chains modelliert. Diese werden im Modell wie Daten behandelt und zwischen den einzelnen Akteuren (Runnables, Tasks, aber auch Busnachrichten) weitergereicht.<\/p>\n Auf der Basis der Event-Chains k\u00f6nnen die Latenzen von Verarbeitungsketten analysiert werden (Abbildung 7, siehe\u00a0PDF<\/a>). Dazu definiert man eine Echtzeit-Anforderung vom ersten bis zum letzten Schritt der Event-Chain und stellt es als Histogramm dar. Im Beispiel ist zu erkennen, dass ein Gro\u00dfteil der Messwerte in einem abgegrenzten Bereich schwankt, w\u00e4hrend fast 18% deutlich k\u00fcrzer sind.<\/p>\n So l\u00e4sst sich schnell erkennen, wo das entworfene Design Fehler oder Engstellen aufweist (siehe Wirkkettendiagram in Abbildung 8,\u00a0PDF<\/a>) und etwa Verarbeitungsketten nicht bis zum Ende abgearbeitet werden, und wie sich solche Fehler dergestalt auswirken, das im Folgenden die Datenkonsistenz nicht mehr gew\u00e4hrleistet ist.<\/p>\n Nun liefern die Untersuchungen und Auswertungen Anhaltspunkte, warum es zu einer Verletzung oder einem Engpass gekommen ist. Dazu definiert der Anwender Echtzeit-Anforderungen, die automatisiert ausgewertet werden und dem Anwender die m\u00fchevolle manuelle Suche im Wirkkettendiagram ersparen. Abbildung 9 (siehe\u00a0PDF<\/a>) zeigt die \u00a0Datenfluss-Anforderung\u00a0Wirkketten-Abriss<\/em>. In 17,6% der F\u00e4lle l\u00e4uft der Datenfluss nicht bis zum Ende. Der Anteil der Fehler deckt sich mit der Verteilung der Latenzzeiten aus Abbildung 7 (siehe\u00a0PDF<\/a>).<\/p>\n Das Latenzhistogramm des Datenflusses aus Abbildung 7 (siehe\u00a0PDF<\/a>) hilft auch bei der Fehleranalyse weiter: Im Detail erkannt man, das die 17,6% abgerissenen Wirkketten einen H\u00e4ufungspunkt bilden, und die erfolgreichen Wirkketten gleichm\u00e4\u00dfig \u00fcber einen Bereich von 33 ms streuen.<\/p>\n Es werden also von den alle 33ms angelieferten Daten im Mittel nur ca. 82,4% verwertet. Berechnet man die mittlere Auswerteperiode als 33 \/ 0.824\u00a0 zu 40,05ms, so findet man die Abtastrate von 40ms des Runnables\u00a0runn_merge<\/em>\u00a0aus Abbildung 3 (siehe\u00a0PDF<\/a>), das mit einer 40ms Periode modelliert ist.<\/p>\n Damit ist der Grund der Datenabrisse identifiziert: Es handelt sich um eine Unterabtastung der Eingangssignale im „merge“-Schritt. Eine M\u00f6glichkeit, dem Datenabriss entgegenzuwirken, ist eine Anpassung der Abtastrate, indem z.B. der Zeittrigger f\u00fcr die Abtastung von 40ms auf 20ms gesetzt wird. Die automatisierte Auswertung der Datenfluss-Anforderung zeigt sofort den Effekt (siehe Abbildung 10,\u00a0PDF<\/a>): Alle Datenfl\u00fcsse laufen bis zum Ende, es treten keine Daten-Inkonsistenzen mehr auf.<\/p>\n Die dynamischen Auswirkungen der Design\u00e4nderungen werden in unterschiedlichen Diagrammen visualisiert und k\u00f6nnen somit verstanden werden. Abbildung 11 (siehe\u00a0PDF<\/a>) zeigt die Auswirkung auf die Wirkkettenverl\u00e4ufe. Datenabrisse treten jetzt nicht mehr auf.<\/p>\n Da die Ergebnisse der Simulations-Analysen und die Design\u00e4nderungen im zentralen AMALTHEA-Modell vorgenommen werden, wird eine konsistente Durchg\u00e4ngigkeit vom modifizierten Systemdesign, \u00fcber weitere Simulation und Visualisierungen, Kunden-Reports bis hin zum Steuerger\u00e4te-Code und Test gew\u00e4hrleistet.<\/p>\n In diesem Artikel ist ein Workflow beschrieben, um ausgehend vom AMALTHEA-Systemmodell als Single-Source-Quelle wichtige Prozessschritte durchzuf\u00fchren. Die Modellierung von logischen Datenfl\u00fcssen (Event-Chains) sowie die \u00dcberpr\u00fcfung der Echtzeit-Anforderungen sind hierbei zentrale Bausteine. Ein wesentlicher Vorteil dieses systematischen Vorgehens besteht darin, dass sich zeitliche Fehler bereits fr\u00fchzeitig w\u00e4hrend der Designphase aufdecken lassen, die ansonsten erst sp\u00e4t im Entwicklungsprozess durch Testen und Debuggen auf der Hardware gefunden werden. Durch die Simulation wurden zeitliche Fehler bis zu 12 Monate fr\u00fcher entdeckt, die Ursachen durch eine geeignete Visualisierung verstanden und effizient behoben.<\/p>\n [1]\u00a0AMALTHEA: An Open Platform Project for Embedded Multicore Systems<\/a><\/p>\n [2]\u00a0INCHRON Tool-Suite<\/a><\/p>\n [3]\u00a0\u00a0 T. Kramer, R. M\u00fcnzenberger: Modeling and real-time analysis of complex causal loops in driver assistance systems, 3. Autotest, FKFS, October 2010.<\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Architektur \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Architektur \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong><\/a>\u00a0f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nMotivation<\/h2>\n
\n
AMALTHEA<\/h2>\n
Anwendungsbeispiel<\/h2>\n
Modellierung von Tasks<\/h2>\n
Datenfluss und funktionales Verhalten<\/h2>\n
Analyseergebnisse<\/h2>\n
Zusammenfassung<\/h2>\n
Literaturverzeichnis<\/h2>\n
\nArchitektur – MicroConsult Trainings & Coachings<\/h2>\n
\nArchitektur\u00a0– Fachwissen<\/h2>\n