Autoren: Dr. Jochen H\u00e4rdtlein, Kramer Simon, Peter H\u00e4fele, Dr. Dirk Ziegenbein, Robert Bosch GmbH<\/p>\n
Die L\u00f6sung der Fehlerf\u00e4lle, die durch nebenl\u00e4ufige bzw. parallele SW-Ausf\u00fchrung entstehen, mit traditionellen Mitteln – wie etwa Locks – f\u00fchrt zu gro\u00dfem System-Overhead und schr\u00e4nkt die Verteilbarkeit bzw. die effektive Nutzung der parallelen Rechenleistung massiv ein. Mit dem konstruktiven Ansatz der Logical Execution Time wird die Kommunikation von den Berechnungen entkoppelt und systemweit zeitlich strukturiert. Im vorliegenden Beitrag werden die typischen Fehlerf\u00e4lle nebenl\u00e4ufiger Echtzeit-SW analysiert und konstruktive Mechanismen zu deren Vermeidung zusammengefasst [6]. Ebenso wird ein Ausblick auf toolgest\u00fctzte korrekte Softwareverteilung gegeben.<\/strong><\/p>\n Die n\u00f6tige Leistungssteigerung f\u00fcr die eingebetteten Steuerger\u00e4te in Fahrzeugen kann nicht mehr wie in den vergangenen Jahrzehnten allein \u00fcber eine steigende Taktfrequenz in Single-Core-Rechnern bereitgestellt werden. Neben der Entwicklung hin zu Mikrocontrollern mit Multi- bzw. Many-Core-Architekturen kommen auch Multi-\u00b5C-L\u00f6sungen oder Dom\u00e4nenrechner mit Mikroprozessoren zum Einsatz. Diese Rechnerarchitekturen bestehen aus einer Vielzahl von teils heterogenen Rechnerkernen, d.h. unterschiedlicher Rechenleistung bzw. Berechnungsf\u00e4higkeiten. Zus\u00e4tzlich ist die zugeh\u00f6rige Speicherarchitektur vermehrt durch NUMA (Non-uniform Memory Access) gekennzeichnet, d.h. Zugriffsgeschwindigkeiten und Bandbreiten zwischen Rechnern und Speichern variieren. Die Anforderungen an die SW-Architektur f\u00fcr aktuelle und zuk\u00fcnftige eingebettete Systeme wird massiv von der steigenden Parallelit\u00e4t und der zunehmenden Heterogenit\u00e4t der parallelen Systeme bestimmt (siehe Abbildung 1,\u00a0PDF<\/a>).<\/p>\n Eingebettete Systeme \u2013 wie etwa Motorsteuerungssysteme f\u00fcr Verbrennungsmotoren \u2013 sind Systeme mit einer Mischung aus Event- und zeitgesteuerten Berechnungen, die ein hohes Ma\u00df an Echtzeitanforderungen haben, um die Korrektheit der implementierten Regelungen sicherzustellen. Dar\u00fcber hinaus werden die L\u00f6sungen aufgrund der Komplexit\u00e4t verteilt entwickelt, an unterschiedlichen Standorten sowie in verschiedenen Unternehmen (OEM, TIER1, TIER2). In diesem Setup ist es notwendig zu verstehen, dass die Absicherung der Systeme mit der steigenden heterogenen Parallelit\u00e4t zunehmen aufw\u00e4ndig und komplex wird. Im ersten Schritt m\u00f6chten wir daher die m\u00f6glichen Fehlerf\u00e4lle der Software aus Nebenl\u00e4ufigkeits- und Echtzeitsicht verstehen, um im Nachgang L\u00f6sungen f\u00fcr deren Vermeidung ableiten zu k\u00f6nnen ([1], [5]).<\/p>\n Die eingebetteten Softwaresysteme bestehen aus mehreren hundert Funktionen, die mit spezifischer Frequenz aufgerufen werden. Das Betriebssystem hat die Aufgabe, die Berechnungen entsprechend ihrer Aktivierungsrate zu aktivieren und ggf. laufende Berechnungen mit niederer Priorit\u00e4t zu unterbrechen (rate-monotonic scheduling). Jede korrekte Bearbeitung einer Funktion basiert auf Abh\u00e4ngigkeiten zu Funktionen \u2013 genannt Ordnung \u2013 welche vorher bzw. nachher gerechnet werden (z.B. muss ein Sensorwert aufbereitet werden, bevor er weiterverarbeitet wird). Bei Berechnungen auf einem Rechnerkern ist dies f\u00fcr Funktionen mit gleicher Aktivierungsrate einfach sicherzustellen (durch eine fixe Reihenfolge innerhalb der Task). Jedoch ist bereits die Reihenfolge zwischen unterschiedlichen Zeitscheiben nur teilweise mittels Priorit\u00e4ten regelbar oder kostspielig mittels Synchronisationspunkten realisierbar. Sind die Berechnungen \u00fcber mehrere Rechenkerne verteilt, l\u00e4sst sich die Reihenfolge nur noch \u00fcber Synchronisationspunkte (etwa auch ein globales Scheduling) realisieren, was aber den Nutzen der parallelen Rechenleistung deutlich reduziert. Zus\u00e4tzlich zeigt sich, dass die impliziten Annahmen der Legacy-Software in Single-Core-Systemen h\u00e4ufig nicht l\u00fcckenlos transparent sind. Dies birgt die Gefahr, dass bei einer einfachen Verteilung der Software die notwendigen Berechnungsreihenfolgen evtl. (sporadisch) nicht eingehalten werden (siehe Abbildung 2,\u00a0PDF<\/a>).<\/p>\n Die wohl bekanntesten Fehlerquellen bei Synchronisationen sind sicherlich Deadlocks. Verklemmungen k\u00f6nnen auftreten, wenn etwa Locks sukzessive gesetzt werden und die Reihenfolge nicht systemweit einheitlich ist. M\u00f6gliche L\u00f6sungen sind etwa die Nutzung einer Ressource f\u00fcr alle zu sch\u00fctzenden Anteile oder die Sicherstellung der konformen systemweiten Locking-Reihenfolge. Erstere L\u00f6sung kann zu gro\u00dfen System-Overhead f\u00fchren, da Beeinflussungen von Berechnungen entstehen, die inhaltlich unabh\u00e4ngig sind. Das vollst\u00e4ndige Betrachten der systemweiten Locking-Reihenfolge ist im Allgemeinen extrem schwierig sicherzustellen (siehe Abbildung 3,\u00a0PDF<\/a>).<\/p>\n Dateninkonsistenzen sind die meistgenannten Fehlerquellen in nebenl\u00e4ufigen Systemen. Diese k\u00f6nnen entstehen, wenn gleichzeitig auf Daten gearbeitet bzw. Funktionen mehrfach aufgerufen werden. Zur Vermeidung dieser \u00dcberlappungsfehler werden h\u00e4ufig auch Synchronisationen eingesetzt, die wiederum Overhead erzeugen. Zus\u00e4tzlich sind Zustandswechsel in Software zu beachten, da besonders Realisierungen aus der Single-Core-Umgebung h\u00e4ufig schwer beherrschbare Zeiteffekte in parallelen Systemen haben (siehe Abbildung 4,\u00a0PDF<\/a>).<\/p>\n Die letzte Kategorie behandelt die Verletzung von Echtzeitanforderungen, etwa dem Verpassen von Deadlines, was dazu f\u00fchrt, dass Ergebnisse anderen Funktionen zu sp\u00e4t bereitgestellt werden. Je nach Schwere der Auswirkung kann dies entweder irrelevant sein oder auch zur v\u00f6lligen Fehlfunktion des eingebetteten Systems f\u00fchren (siehe Abbildung 5,\u00a0PDF<\/a>).<\/p>\n Die aufgef\u00fchrten Fehler werden typischerweise mittels Synchronisationsmechanismen wie Spinlocks vermieden. Bei steigender Auslastung des Systems steigt auch der Overhead durch das Sperren bzw. Abfragen der Locks signifikant.<\/p>\n Eine strukturelle L\u00f6sung, den Aufwand zur Sicherstellung einer konsistenten Kommunikation in parallelen Echtzeitsystemen zu senken, wurde von Henzinger et al. mit der Logical Execution Time eingef\u00fchrt und in deren Giotto Framework umgesetzt ([2], [3], [4]). Mittels der Logical Execution Time werden die Kommunikationen von den Berechnungen entkoppelt und systemweit koordiniert. Dadurch reduzieren sich die individuellen Synchronisationen auf ein Minimum. Diese Kommunikationsart wird Timed Communication genannt (siehe Abbildung 6,\u00a0PDF<\/a>).<\/p>\n Im Vergleich zur traditionellen Implementierungen, in denen Zeitscheiben die Daten direkt mit dem globalen Speicher austauschen, findet bei Timed Communication der Datenaustausch direkt zwischen zwei Zeitscheiben statt. Zus\u00e4tzlich wird nur dann kommuniziert, wenn auch neue Daten verf\u00fcgbar sind. Durch die zeitliche Entkopplung der Kommunikation von der Berechnung wird f\u00fcr zeitgesteuerte Tasks sichergestellt, dass diese immer Daten mit gleichem Alter als Input erhalten, wenn die Berechnungen inklusive der Kommunikation innerhalb der Periode beendet werden.<\/p>\n Mittels Timed Communication k\u00f6nnen Ordnungsfehler zwischen Zeitscheiben vermieden und Synchronisations- bzw. \u00dcberlappungsfehler (f\u00fcr Daten) verhindert werden. Zus\u00e4tzlich strukturiert Timed Communication die deterministische, lockfreie Kommunikation und erlaubt das taskspezifische Erkennen von Echtzeitfehlern.<\/p>\n Dar\u00fcber hinaus ist es m\u00f6glich, auf der Basis einer deterministischen Kommunikation mit den zeitlichen Anforderungen der Kommunikation zwischen Funktionen eine toolgest\u00fctzte Verteilung zu erreichen, welche die zugrundeliegenden Zeitanforderungen per Konstruktion sicherstellt bzw. \u00fcberpr\u00fcft. Daf\u00fcr sind f\u00fcr alle Funktionen, die zeitkritischen Schnittstellen und deren Zeitanforderungen zu erfassen. Zus\u00e4tzlich ist das Ausweisen der zeitkritischen Wirkketten mit deren Deadlines zu erfassen. Ebenso wird eine abstrahierte Beschreibung der zugrundeliegenden Hardware ben\u00f6tigt. All diese Daten sind jedoch typischerweise nur mittels Expertenwissen zu ermitteln. Diese Daten k\u00f6nnen bereits heute in dem \u00f6ffentlich verf\u00fcgbaren Amalthea-Format verwaltet werden (siehe Abbildung 7,\u00a0PDF<\/a>) [7].<\/p>\n Aus dem aktuell genutzten pr\u00e4emptiven rate-monotonic Scheduling in automotive Single-Core-Systemen resultiert bereits ein nebenl\u00e4ufiges Echtzeitsystem, in dem die pr\u00e4sentierten Fehlerzust\u00e4nde bereits auftreten k\u00f6nnen. Die Wahrscheinlichkeit der Fehler erh\u00f6ht sich jedoch signifikant durch die Verteilung der Software auf parallele Recheneinheiten. Die Vermeidung der Fehler durch zus\u00e4tzliche Synchronisationen f\u00fchrt zu zus\u00e4tzlichem Overhead, der den Nutzen der zus\u00e4tzlichen parallelen Rechenleistung zum Teil zunichtemacht und dar\u00fcber hinaus schwierig abzusichern ist. Zus\u00e4tzlich ist die Freiheit von Echtzeitfehlern weiterhin schwierig zu validieren. Das Timed Communiction Framework kann nun als Grundlage genutzt werden, um die Zeitanforderungen der Funktionen und der Wirkketten systemweit beim Systemsetup zu sicherzustellen und dadurch den massiv steigenden und komplexeren Absicherungsaufwand in parallelen Systemen massiv zu reduzieren.<\/p>\n [1] Clarke S.J. and McDermid JA.\u00a0Software fault trees and weakest preconditions: a comparison<\/em><\/p>\n and analysis.\u00a0<\/em>Software Engineering Journal. 8(4):225-236, 1993.<\/p>\n [2] Henzinger TA, Horowitz B, Kirsch CM (2001a) Embedded control systems development with Giotto. In: Proceedings of the ACM SIGPLAN workshop on languages, compilers, and tools for embedded systems (LCTES). ACM<\/p>\n [3] Henzinger TA, Horowitz B, Kirsch CM (2001b) Giotto: A time-triggered language for embedded programming. In: Proceedings of the international workshop on embedded software (EMSOFT), vol 2211 of LNCS, Springer, pp 166\u2013184<\/p>\n [4] Henzinger TA, Horowitz B, Kirsch CM (2003a) Giotto: A time-triggered language for embedded programming. Proc IEEE 91(1):84\u201399<\/p>\n [5] Thane, Henrik.\u00a0Monitoring, testing and debugging of distributed real-time systems<\/em>. Diss. Ph. D. Thesis, MRTC Report 00\/15, 2000.<\/p>\n [6] H\u00e4rdtlein, Jochen,\u00a0Verteilte Software in Echtzeitsytemen<\/em>. HANSER automotive 03-04\/2017<\/p>\n [7]\u00a0www.amalthea-project.org<\/a>, An Open Platform Project for Embedded Multicore Systems, \u00d6ffentlich gef\u00f6rdertes ITEA Projekt<\/p>\n Beitrag als PDF-Datei downloaden<\/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\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nNebenl\u00e4ufigkeits- und Echtzeitfelder<\/h2>\n
Timed Communication<\/h2>\n
Quellen<\/h2>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
\nEchtzeit – Fachwissen<\/h2>\n