Autoren: Karsten Schmidt, Audi Electronics Venture GmbH, Kai Richter, Symtavision GmbH<\/p>\n
Neue Technologien wie Multicore und Ethernet bieten ein Vielfaches der bisher bekannten Rechen- und Kommunikationskapazit\u00e4ten. Die verf\u00fcgbaren Ressourcen in den Steuerger\u00e4ten und im Netzwerk m\u00fcssen auch auf die Vielzahl der zu integrierenden Teilfunktionen und deren Software aufgeteilt werden. Einen wichtigen Beitrag zur effizienten Umsetzung liefert eine gute Timing-Architektur.<\/strong><\/p>\n Neue Technologien wie Multicore und Ethernet bieten ein Vielfaches der bisher ge\u00adkannten Rechen- und Kommunikationskapazit\u00e4ten. Sie legen damit den Grundstein f\u00fcr die Umsetzung der kundenerfahrbaren Megatrends in nahezu allen Bereichen: Fahrer\u00adassistenz, Elektrifizierung, Connectivity, autonomes Fahren. Die neue Herausforderung dabei: Die verf\u00fcgbaren Ressourcen in den Steuerger\u00e4ten und im Netzwerk m\u00fcssen auch auf die Vielzahl der zu integrierenden Teilfunktionen und deren Software aufgeteilt werden. Einen wichtigen Beitrag zur effizienten Umsetzung liefert eine gute Timing-Architektur. Jedoch ist das Finden einer guten Timing-Architektur herausfordernd, und h\u00e4ufig\u00a0 mangelt es den Beteiligten an Erfahrung im Umgang mit Echtzeitanforderungen, da diese Aufgabe noch nicht in der Breite etabliert ist.<\/p>\n Im vorliegenden Betrag zeigen wir „Best Practices“ f\u00fcr die L\u00f6sung wiederkehrender Entwurfsprobleme im Bereich Timing und erfolgreiche und erprobte Muster f\u00fcr das Finden guter Timing-Architekturen, also „Timing-Architektur-Pattern“. Zudem grenzen wir diese explizit von „Nicht-Pattern“ bzw. „Worst Practices“ oder „Not-so-good Practices“ ab, die heute in der Praxis (leider) beobachtet werden k\u00f6nnen. Damit wollen wir Anregungen geben, wie und mit welchen konkreten Schritten das Thema Timing k\u00fcnftig besser gehandhabt werden k\u00f6nnte.<\/p>\n F\u00fcr die Realisierung von Fahrzeugfunktionalit\u00e4ten spielt Software eine zunehmend wichtigere Rolle. W\u00e4hrend sie in fr\u00fchen Systemen lediglich in ausgew\u00e4hlten Komponenten zu finden war, ist sie mittlerweile f\u00fcr fast jede Fahrzeugfunktionalit\u00e4t relevant, wodurch neben der Hardware eine eigene Struktur der Software entsteht. Die Softwareelemente des Fahrzeugs werden innerhalb von Steuerger\u00e4ten (ECUs) und anderen eingebetteten Komponenten ausgef\u00fchrt. Traditionell ist neben den nicht-funktionalen Anforderungen dabei der sparsame Umgang mit knappen Betriebsmitteln (Speicher, CPU-Zyklen, Kommunikationsslots) ein wesentlicher Aspekt. Jeder noch so kleine Anstieg im Ressourcenverbrauch wirkt sich als Multiplikator direkt auf die Bauteilkosten aus. Mit den steigenden Anforderungen an Funktionalit\u00e4ten und neue Wertsch\u00f6pfungsketten w\u00e4chst die Menge von Software mittlerweile so stark, dass Timing-Probleme h\u00e4ufig zu beobachten sind.<\/p>\n Die Entwickler stellen sich den Herausforderungen und haben bereits eine Vielzahl unter\u00adschiedlicher Strategien zur Beherrschung von Timing-Problemen entwickelt. Jedoch tauchen durch die Komplexit\u00e4t des gesamten Entwicklungsprozesses immer wieder typische Probleme auf.<\/p>\n Verst\u00e4ndnisl\u00fccke<\/strong><\/p>\n Bedingt durch die Aufgabenteilung in Systementwicklung, Funktionsentwicklung und der eigentlichen Softwareentwicklung ist h\u00e4ufig ein Kommunikationsproblem zwischen den unterschiedlichen Stakeholdern im Entwicklungsprozess zu beobachten. Jeder beherrscht sein Teilgebiet exzellent, jedoch gehen bei der Kommunikation durchaus relevante Informationen verloren. Erschwert wird dies durch den notwendigen Know-How-Schutz bei der Zusammenarbeit unterschiedlicher Firmen. In [4, 5] ist dieser Fakt ausf\u00fchrlich beschrieben. Verst\u00e4rkt wird dieser Effekt durch die Integration unterschiedlicher Softwareanteile in ein Steuerger\u00e4t.<\/p>\n Werkzeugl\u00fccke<\/strong><\/p>\n Sehr eng verwandt mit der Verst\u00e4ndnisl\u00fccke ist die Werkzeugl\u00fccke. Jeder Stakeholder benutzt das f\u00fcr seine Zwecke passende Werkzeug, um effizient seine Probleme zu l\u00f6sen. Der Austausch zwischen den einzelnen Parteien ist h\u00e4ufig durch h\u00e4ndische Aktivit\u00e4ten gekennzeichnet.<\/p>\n Gesamtsystemverst\u00e4ndnis<\/strong><\/p>\n Bedingt durch die Zusammenarbeit \u00fcber Firmengrenzen hinweg und der Integration von Software unterschiedlichster Parteien ist es f\u00fcr den eigentlichen Integrator schwer, bei Problemen mit einem Gesamtsystemverst\u00e4ndnis an die Fehlersuche zu gehen.<\/p>\n Grundlegende und wiederkehrende Erfahrungen aus unterschiedlichsten Projekten manifestieren sich in Pattern, die entsprechend angwendet, gro\u00dfen Nutzen spenden. Trotzdem setzt die Anwendung von Patterns bzw. der Vermeidung von Anti-Pattern eine gewisse Erfahrung voraus, da nicht jedes Pattern zwingend immer erfolgreich anwendbar ist.<\/p>\n Vermessung des Systems<\/strong><\/p>\n Ein Pattern, welches unserer Erfahrung nach immer anwendbar ist, ist die Entwicklung von Messmethoden f\u00fcr Timing-Fragen im zu entwickelnden System, da nur Dinge, die quantitativ vorliegen, auch optimiert werden k\u00f6nnen [1, 2].<\/p>\n Das grundlegende Vorgehen beim Tracing ist die Aufnahme von Zeitstempeln. In aktuellen Systemen erfolgt das typisch auf zwei Ebenen:<\/p>\n Dabei geht es grunds\u00e4tzlich um den ausf\u00fchrbaren Code, der ja auf CPU l\u00e4uft und somit getraced werden kann. Dabei existieren zwei grundlegende Methoden:<\/p>\n Hierbei ist zu beachten, dass prinzipiell jede Messung das System verf\u00e4lschen kann. Aus diesem Grund ist es notwendig, die Messtechnik m\u00f6glichst non-intrusive auszulegen. Zuk\u00fcnftig werden deshalb CPU-Hersteller erweiterte on-chip Trace-M\u00f6glichkeiten etablieren m\u00fcssen (z.B. in einer Art Timing-Unit f\u00fcr Programmspeicherzugriffe), um das non-intrusive Tracing aus den Laboren in die Fahrzeuge zu bringen.<\/p>\n Systemmodellierung<\/strong><\/p>\n Habe ein Modell deines Systems in der richtigen Granularit\u00e4t! Eine wichtige Grundlage daf\u00fcr ist ein systematisches Erfassen der Anforderungen. Hier empfiehlt sich folgende Vorgehensweise:<\/p>\n Vergleiche System und Messung<\/strong><\/p>\n Dieses Pattern benutzt und kombiniert die beiden vorhergehenden Patterns. Wichtig ist, dass pr\u00fcfbare Anforderungen existieren, und Timing-Anforderungen mit gr\u00f6\u00dferer Komplexit\u00e4t auf einfache und pr\u00fcfbare Timing-Anforderungen zur\u00fcckgef\u00fchrt werden k\u00f6nnen.<\/p>\n Nutzung eienr Timing-Simulation zur Prognose<\/strong><\/p>\n Simulationen, insbesondere im Bereich Scheduling, welches die origin\u00e4re Timing-Ebene darstellt, k\u00f6nnen zur Vorabsch\u00e4tzung verschiedener Fragestellung verwendet werden. Dazu z\u00e4hlen insbesondere Fragestellungen des Typs „Was w\u00e4re wenn \u2026?“, wie z.B.<\/p>\n Interessant bei diesem Pattern ist, das bei systematischer Modell-Erfassung dieser Schritt leicht umsetzbar ist.<\/p>\n Problemverst\u00e4ndnis<\/strong><\/p>\n Verstehe das Problem und stelle die richtigen Frage in der richtigen Granularit\u00e4t. Hierzu sind die involvierten Stakeholder im Projekt durch passende Weiterbildungen zu schulen. Bei den Schulungen ist speziell darauf hinzuweisen, dass es unterschiedliche Sichten auf das Timing gibt (funktionale Sicht, Software, Architektur und Schedule-Sicht) mit teilweise unterschiedlicher Terminologie [3].<\/p>\n Weiterhin ist es zwingend notwendig, Timing-Experten im Unternehmen zu etablieren, die in komplizierten Projekten die Rolle eines „Dolmetschers“ zwischen den real unterschiedlichen Sichten wahrnehmen.<\/p>\n Schulungen<\/strong><\/p>\n Ein wichtiger Pattern-Baustein stellen entsprechende Schulungen da. Sie vermitteln das notwendige Wissen, die notwendigen F\u00e4higkeiten sowie das Handwerkzeug um die genannten erfolgreichen Pattern anzuwenden. Timing-Schulungen sollten folgende Fragen behandeln:<\/p>\n Keep it simple<\/strong><\/p>\n Das ist ein h\u00e4ufig untersch\u00e4tztes Pattern. Als Daumenregel gilt: „Alles, was man nicht wirklich schnell erkl\u00e4ren kann, ist nicht einfach.“ In unserem Kontext bedeutet „wirklich“, dass sichergestellt ist, dass eine Erkl\u00e4rung auch vollst\u00e4ndig verstanden wird, also was es ist und was es nicht ist. Den Autoren ist klar, dass die Fahrzeugsysteme komplex sind. Trotzdem muss beachtet werden, dass Komplexit\u00e4t ein Problem insgesamt ist, und dass es sich auch lohnt, einfachere Systeme zu bauen.<\/p>\n Wichtig ist auch, dass was m\u00f6glicherweise f\u00fcr einen Stakeholder eine einfache L\u00f6sung darstellt, f\u00fcr andere Stakeholder zu extrem komplizierten L\u00f6sungen f\u00fchrt.<\/p>\n Workflow und Tools<\/strong><\/p>\n Ein sinnvoller Workflow ist unabdingbar. Um die Timing-Eigenschaften zu erf\u00fcllen, sollte jeder Workflow mindestens die folgenden Schritte in der passenden Granularit\u00e4t umfassen<\/p>\n Die folgende Abbildung (siehe\u00a0PDF<\/a>) zeigt diese Schritte exemplarisch an einem beispielhaften Produkt-Entstehungs-Prozess unter Beachtung der Timing-Eigenschaften.<\/p>\n Auch wenn es zun\u00e4chst widersinnig erscheint, Anti-Pattern zu dokumentieren, haben sie doch einen gro\u00dfen Nutzen.<\/p>\n Noch mehr Prozess<\/strong><\/p>\n Prozesse sind nicht grunds\u00e4tzlich schlecht. Aber Prozesse brauchen Inhalte und unterliegen Randbedingungen, die sich unterscheiden k\u00f6nnen in:<\/p>\n Prozesse um des Prozesses willen sind akademische \u00dcbungen, aber niemals echte L\u00f6sungen. Nach Meinung der Autoren m\u00fcssen die einzelnen existierenden Prozessschritte optimiert werden, durch gezielten Einsatz von neuen und aktuell verf\u00fcgbaren Technologien. Man erh\u00e4lt dadurch akzeptierte Standardbausteine mit konkretem Nutzen, die je nach Projekt entsprechend kombiniert werden k\u00f6nnen. Zu strikte Prozessvorgaben schr\u00e4nken ein, wodurch die Akzeptanz sinken wird. Auf der anderen Seite bieten zu generische Prozessbeschreibungen keinen Mehrwert.<\/p>\n Zus\u00e4tzlich m\u00fcssen die Prozessbausteine mit entsprechenden Schulungsma\u00dfnahmen unterst\u00fctzt werden, damit die Anwender die Prozessschritte an die konkrete Situation anpassen k\u00f6nnen.<\/p>\n Monster-Tools<\/strong><\/p>\n Der wichtigste Aspekt dieses Pattern ist es zu verstehen, dass Tools keine Magie vollbringen k\u00f6nnen. Wenn das Problem verstanden ist, dann k\u00f6nnen Tools, die im wesentlichen Maschinen sind, die Dinge automatisieren, sehr gewinnbringend angwendet werden. Weiterhin gilt zu beachten: Tools haben dem Prozess zu folgen, nicht umgedreht, dass ein Tool einen bestimmten Workflos bestimmt.<\/p>\n Die Komplexit\u00e4t im Entwicklungsprozess hochintegrierter Steuerger\u00e4te erfordert eine Ber\u00fccksichtigung von querschneidenden Entwurfspaketen, wobei wir uns im vorliegenden Beitrag auf Echtzeitf\u00e4higkeit und Ressourcenverbrauch fokussiert haben.<\/p>\n Es ist wichtig zu verstehen, dass dies keine leichte Aufgabe, sondern vielmehr ein Paradigmenwechsel ist. Kein einzelnes Werkzeug und kein einzelnes Austauschformat vermag die Prozessl\u00fccke zwischen Systementwicklung, Funktionsentwicklung und Softwareentwicklung zu schlie\u00dfen. Auf der Basis eigener, gelebter Erfahrung haben wir elementare, aufeinander aufbauende Muster vorgestellt:<\/p>\n Einfache Standardl\u00f6sungen existieren zum jetzigen Zeitpunkt nur f\u00fcr wenige Spezialf\u00e4lle, die von Experten erkannt und genutzt werden k\u00f6nnen. Diese m\u00fcssen wir konsequent ausbauen, indem wir die genannten Ma\u00dfnahmen ergreifen. Systematisch verfolgt, werden dadurch die Prozessl\u00fccken sukzessive minimiert.<\/p>\n [1]\u00a0\u00a0 K. Schmidt, J. Harnisch, D. Marx, A. Mayer, „Timing Analysis and Tracing Concepts for ECU Development“, SAE Technical Paper 2014-01-0190, 2014, doi:10.4271\/2014-01-0190.<\/p>\n [2]\u00a0\u00a0 M. Jersak, K. Richter. H. Sarnowski, P. Gliwa, „The Right Timing Analysis Tools Increase Safety and Productivity“, ATZ Elektronik, 01\/2009<\/p>\n [3]\u00a0\u00a0 A. Hamann, D. Ziegenbein, S. Lampke, S. Schliecker, „Resource-Aware Control – Model-Based Co-Engineering of Control Algorithms and Real-Time Systems“, SAE World Congress, April 2015, Detroit, USA<\/p>\n [4]\u00a0\u00a0 K. Schmidt, D. Marx, K. Richter, K. Reif, A. Schulze, T. Fl\u00e4mig, „On Timing Requirements and a Critical Gap between Function Development and ECU Integration“, SAE World Congress, April 2015, Detroit, USA<\/p>\n [5]\u00a0\u00a0 K. Reif, K. Schmidt, F. Gesele, S. Reichelt, M. Saeger, N. Seidler, „Networked control systems in motor vehicles“ in\u00a0 ATZelektronik worldwide, 04\/2008 Pages 18-23, Springer Fachmedien Wiesbaden GmbH (2008)<\/p>\n Beitrag als PDF-Datei herunterladen<\/strong><\/a><\/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 Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/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>\nEinleitung<\/h2>\n
Situation der Automobilindustrie<\/h2>\n
Pattern<\/h2>\n
\n
\n
\n
\n
\n
\n
Anti-Pattern<\/h2>\n
\n
Zusammenfassung<\/h2>\n
\n
Literaturverzeichnis<\/h2>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
\nEchtzeit – Fachwissen<\/h2>\n