Ganzheitliches Konzept
Interferenzen und Timing meistern
Um den für Hard-Realtime-Anwendungen erforderlichen Determinismus auf heterogenen Multicore-Prozessoren zu erzielen, können Entwickler Analysetechniken einsetzen, z. B. zum Messen von Timing-Werten und Interferenzen. Die Leitlinien von CAST-32A [1] und A(M)C 20-193 [2] geben eine Anleitung.
Multicore-Prozessoren (MCP) bieten eine Abhilfe gegen die bei Singlecore-Rechnern bestehenden Beschränkungen. Sie können ein größeres Arbeitsaufkommen bewältigen und vermeiden die aus der Taktrate und der Wärmeentwicklung resultierenden physikalischen Restriktionen. In Hard-Realtime-Anwendungen mit ihren strikten Echtzeitanforderungen bringen solche Systeme jedoch Herausforderungen für die Entwicklungsteams mit sich, was die Einhaltung der Timing-Vorgaben und den Umgang mit gegenseitigen Beeinflussungen zwischen heterogenen Kernen angeht.
Hard-Realtime-Anwendungen verlangen nach deterministischen Verarbeitungszeiten. Im Durchschnitt wird die Zeit, die die Verarbeitung einer bestimmten Task-Zusammenstellung in Anspruch nimmt, auf einem Multicore-Prozessor stets kürzer sein als auf einem Singlecore-Prozessor, allerdings unterliegt sie auch einer größeren Schwankungsbreite. Diese große Variabilität macht es schwieriger, die Einhaltung der Timing-Anforderungen bestimmter Tasks zu garantieren, und bringt erhebliche Probleme für Anwendungen mit sich, in denen nicht die Durchschnittswerte zählen, sondern es auf jede einzelne Verarbeitungszeit ankommt.
Das Certification Authorities Software Team (CAST) trägt diesen Herausforderungen mit einem Positionspapier für Avionikhersteller Rechnung [1]. Darin ist eine Reihe von Zielsetzungen aufgeführt, die im Rahmen des Softwareentwicklungsprozesses erfüllt werden müssen, um zu gewährleisten, dass das jeweilige System verstanden wurde – besonders im Hinblick auf das Timing-Verhalten. Diese Zielsetzungen stellen keine bindenden Anforderungen dar, die von den Entwicklern zwingend umgesetzt werden müssen, sondern dienen eher als Leitlinien und als Unterstützung für Aktivitäten in Richtung allgemein akzeptierter Standards wie DO-178C.
In Europa hat inzwischen das Dokument AMC 20-193 das Positionspapier CAST-32A bereits verdrängt, und es wird erwartet, dass es mit AC 20-193 in den USA bald ebenso sein wird. Die als A(M)C 20-193 bekannten Nachfolgedokumente stellen in weiten Teilen eine Kopie von CAST-32A dar.
Jobangebote+ passend zum Thema
Best-Case- versus Worst-Case-Verarbeitungszeit
Hard-Realtime-Anwendungen, ob im Avionikbereich oder auf anderen Gebieten, müssen zur Gewährleistung von Funktion und Sicherheit strikt vorgegebene Timing-Vorgaben einhalten.
In Soft-Realtime-Anwendungen mit weniger strikten Echtzeitanforderungen ist die Lage etwas entspannter, und das Überschreiten einer Deadline hat hier weniger gravierende Konsequenzen. In der Tabelle sind anhand zweier praktischer Beispiele die wichtigsten Unterschiede zwischen beiden Arten von Echtzeitsystemen zusammengefasst.
Die kürzeste Verarbeitungszeit für eine bestimmte CPU-Task wird als »Best-Case Execution Time« (BCET) bezeichnet, die längste dagegen als »Worst-Case Execution Time« (WCET). In Bild 1 ist an exemplarischen Timing-Messungen grafisch dargestellt, wie diese Werte ermittelt werden.
Bei Singlecore-Systemen lässt sich garantieren, dass die Obergrenzen der Verarbeitungszeit stets eingehalten werden, solange zusätzliche CPU-Kapazität bereitgestellt und hinreichend gepflegt wird. Bei Multicore-Systemen dagegen sind die Herausforderungen größer, denn es gibt keine effektive Methode zum Berechnen einer garantierten Timing-Abfolge, die die parallele Verarbeitung mehrerer Prozesse auf mehreren heterogenen Kernen berücksichtigt. Verschärft wird die Lage durch die Auswirkungen von Hardware-Interferenzen auf Tasks, denn diese können sich von einem Kern zum anderen ändern und die Vorhersagbarkeit und Messung des Task-Timings vereiteln.
Verdeutlichen lässt sich dies an der gemeinsam genutzten hierarchischen Speicherarchitektur in Bild 2. Kollidierende Speicherzugriffe lassen im Beispiel für verschiedene Kerne unterschiedliche Interferenzkanäle entstehen, als deren Folge die Task-Verarbeitungszeit stark differiert. Hierdurch wiederum ist es in diesem System schwierig, einen vorhersagbaren Hard-Realtime-Determinismus zu garantieren.
Anders als in Singlecore-Systemen gibt es in Multicore-Konfigurationen keine Approximationsmethoden, um auf statistischem Weg sinnvolle Näherungswerte für die WCETs und BCETs zu generieren. Stattdessen muss auf Prüf- und Messergebnisse zurückgegriffen werden, die möglichst viel Verlässlichkeit bieten.
CAST-32A und A(M)C 20-193 als Leitlinien
CAST-32A und A(M)C 20-193 ergänzen die in der Norm DO-178C formulierten Prozesse für Multicore-Prozessoren durch zehn Zielsetzungen für die Softwareplanung bis hin zur Verifikation. Zu diesen Zielsetzungen – die Bezeichnungen der spezifischen Zielsetzungen sind jeweils in Klammern gesetzt – gehören unter anderem:
➔ MCP-Konfigurationseinstellungen werden festgelegt und dokumentiert, da sich diese Optionen auf vielfältige Weise auf das Verhalten und die Sicherheit des Systems auswirken können. Besonders wichtig ist es, diese Einstellungen über den gesamten Projektlebenszyklus hinweg zu verfolgen, denn aufgrund der Eigenheiten interaktiver Entwicklungs- und Testaktivitäten ist es wahrscheinlich, dass sich die Konfigurationen ändern. (MCP_Resource_Usage_1)
➔ Durch die Identifikation von MCP-Interferenzkanälen und die Verifikation von Abhilfestrategien wird die Wahrscheinlichkeit reduziert, dass zur Laufzeit Probleme auftreten. (MCP_Resource_Usage_3)
➔ MCP-Tasks haben genügend Zeit zum Beenden der Verarbeitung und es werden ausreichend Ressourcen bereitgestellt, sofern diese in der finalen Konfiguration verfügbar sind. (MCP_Software_1 und MCP_Resource_Usage_4)
➔ Die Daten- und Kontrollkopplung zwischen den Softwarekomponenten wurde während der Testphase ausprobiert, um den Nachweis zu erbringen, dass ausschließlich solche Folgen eintreten, die im Entwurf vorgesehen sind. Dies ist wichtig, da Kopplungsmängel mit großer Wahrscheinlichkeit Auswirkungen auf das Timing haben, da Zugriffe auf Daten zu verschiedenen Zeiten durch verschiedene Threads auf verschiedenen Kernen erfolgen. (MCP_Software_2)
Was das Resourcing betrifft, erkennen sowohl CAST-32A als auch A(M)C 20-193 den Nutzen einer zeitlichen und räumlichen Partitionierung an, sodass Entwickler die Möglichkeit haben, die Verifikation der Applikation und die Bestimmung der WCET separat vorzunehmen, sofern sie verifiziert haben, dass die MCP-Plattform eine robuste Ressourcen- und Timing-Partitionierung bietet. Aus den Dokumenten ist zu entnehmen, dass eine robuste Partitionierung mit großer Wahrscheinlichkeit zu einer erleichterten Eindämmung von Interferenzen beiträgt.
Weder CAST-32A noch A(M)C 20-193 schreiben indes die Methoden zum Erreichen dieser Ziele vor, sondern überlassen die Auswahl den Entwicklungsteams. Obwohl also die besagten Dokumente lediglich beratenden Charakter haben, sollten sich die Entwickler der Tatsache bewusst sein, dass Abschnitt 6.3.4 der Norm DO-178C explizit die Notwendigkeit einer WCET-Analyse ausdrückt:
„6.3.4f: Genauigkeit und Konsistenz: Ziel ist es, die Korrektheit und Konsistenz des Quellcodes festzustellen, einschließlich, der Stack-Nutzung, der Speichernutzung, […] der Worst-Case-Verarbeitungszeiten, des Exception Handlings […]“
- Interferenzen und Timing meistern
- Analyse der Verarbeitungszeit in Echtzeitsystemen
Lesen Sie mehr zum Thema
