Echtzeit Bewältigung von Timing- und Interferenzproblemen bei Multicore-Prozessoren

Anbieter zum Thema

LDRA Inc

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Embedded-Software-Entwickler stehen vor ganz besonderen Herausforderungen, wenn es um Timing- und Interferenzprobleme auf heterogenen Multicore-Systemen geht. Solche Plattformen bieten einerseits mehr Verarbeitungskapazität und Performance als Setups mit Single-Core-Prozessoren (SCPs), aber andererseits kann es aufgrund ihrer Komplexität extrem schwierig sein, strikte Timing-Vorgaben einzuhalten.

Hard-Real-Time-Anwendungen verlangen nach deterministischen Verarbeitungszeiten. Im Durchschnitt wird die Zeit, die die Verarbeitung einer bestimmten Task-Zusammenstellung in Anspruch nimmt, auf einer Multicore-Plattform stets kürzer sein als bei einem Single-Core-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.

Zur Bewältigung dieser Herausforderungen haben Embedded-Software-Entwickler die Möglichkeit, Dokumente wie CAST-32A, AMC 20-193 und AC 20-193 als Leitlinien zu nutzen. Im Dokument CAST-32A skizziert das Certification Authorities Software Team (CAST) wichtige Aspekte für das Timing von Multi-Core-Prozessoren (MCPs) und legt Zielsetzungen für den Softwareentwicklungs-Lebenszyklus (Software Development Life Cycle, SDLC) fest, um das Verhalten eines Multicore-Systems besser verstehen zu können. Diese Zielsetzungen stellen keine bindenden Anforderungen dar, sondern leiten und unterstützen die Entwickler lediglich bei der Einhaltung allgemein akzeptierter Standards wie DO-178C.

In Europa hat 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 gemeinsam als A(M)C 20-193 bekannten Nachfolgedokumente stellen in weiten Teilen eine Kopie der in CAST-32A umrissenen Prinzipien dar.

Um die Anleitung durch CAST-32A und die Nachfolgedokumente anzuwenden, können Entwickler auf verschiedene Techniken zur Messung des Timings und der Interferenzen auf MCP-basierten Systemen zurückgreifen.

Es kommt auf die Worst-Case-Verarbeitungszeiten an

In Hard-Real-Time-Systemen ist es zur Sicherstellung der Vorhersagbarkeit und des Determinismus essenziell, strikte Timing-Vorgaben einzuhalten. Schließlich laufen auf solchen Systemen missions- und sicherheitskritische Anwendungen wie etwa Fahrassistenzsysteme (Advanced Driver-Assistance Systems, ADAS) oder Autopiloten von Luftfahrzeugen. Im Gegensatz zu Soft-Real-Time-Anwendungen, in denen das Überschreiten einer Deadline weniger gravierende Konsequenzen hat, ist das Verstehen der „Worst-Case Execution Time“ (WCET) bei Hard-Real-Time-Tasks von entscheidender Bedeutung, da das Überschreiten von Deadlines hier katastrophale Folgen haben kann.

Die Entwickler müssen für jede CPU-Task neben der WCET auch die „Best-Case Execution Time“ (BCET) im Blick haben. Der BCET -Wert gibt die kürzeste, der WCET-Wert dagegen die längste mögliche Verarbeitungszeit an. Bild 1 verdeutlicht anhand exemplarischer Zeitmessungen, wie diese Werte ermittelt werden.

Besonders entscheidend ist das Messen der WCET, da dieser Wert eine Obergrenze für die Verarbeitungszeit einer Task darstellt, sodass sichergestellt werden kann, dass kritische Tasks innerhalb der vorgegebenen Zeit ausgeführt werden.

Bei Single-Core-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. Noch komplexer wird die Lage, wenn in Applikationen bestimmte Hardwareressourcen von mehreren Prozessorkernen genutzt werden. Der Konkurrenzbetrieb bei der Verwendung solcher „Hardware Shared Resources” (HSR) ist kaum vorhersagbar, sodass ein Messen des Task-Timings hier nicht möglich ist.

Bei der Entwicklung von Hard-Real-Time-Systemen auf MCPs darf man sich, anders als bei Single-Core-Systemen, nicht auf statische Approximationsmethoden verlassen, um belastbare Näherungswerte für die BCETs und WCETs zu bekommen. Stattdessen bedarf es iterativer Tests und Messungen, um möglichst großes Vertrauen in das Verstehen der Timing-Eigenschaften der Tasks zu gewinnen.

CAST-32A und A(M)C 20-193 verstehen

Um besser verstehen zu können, welche Leitlinien den Entwicklern überhaupt zur Verfügung stehen, bietet Bild 2 eine Übersicht über die Zusammenhänge zwischen verschiedenen Dokumenten aus der Zivilluftfahrt.

CAST-32A und A(M)C 20-193 nehmen in hohem Maße die Entwickler in die Pflicht, Nachweise zu erbringen, dass die zugewiesenen Ressourcen eines Systems für die Einhaltung der WCETs ausreichen. Das Erbringen dieses Nachweises wiederum erfordert Anpassungen an den Entwicklungsprozessen und Tools mit dem Ziel, auf iterative und kontrollierte Weise die Verarbeitungszeiten zu ermitteln und zu analysieren, damit die Entwickler den Code während des gesamten Lebenszyklus optimieren können.

Weder CAST-32A noch A(M)C 20-193 schreiben indes die genauen Methoden zum Erreichen der Ziele vor, sondern überlassen es vielmehr den Entwicklern, sich für diejenigen Implementierungsweisen zu entscheiden, die am besten für ihre Projekte geeignet sind.

Leitlinien für Entwickler

CAST-32A und A(M)C 20-193 geben die Timing- und Interferenz-Zielsetzungen bei MCPs für die Softwareplanung bis hin zur Verifikation vor:

• Dokumentation der MCP-Konfigurationseinstellungen über den gesamten Projektlebenszyklus hinweg, denn aufgrund des Wesens der Softwareentwicklung und der Tests ist es wahrscheinlich, dass sich die Konfigurationen ändern. (MCP_Resource_Usage_1)

• Identifikation von MCP-Interferenzkanälen und Ausarbeitung entsprechender Abhilfestrategien, um die Wahrscheinlichkeit von Problemen zur Laufzeit zu verringern. (MCP_Resource_Usage_3)

• Sicherstellung, dass den MCP-Tasks genügend Zeit zum Beenden der Verarbeitung bleibt und dass in der finalen Konfiguration ausreichend Ressourcen bereitgestellt werden. (MCP_Resource_Usage_4)

• Gebrauch der Daten- und Kontrollkopplung zwischen den Softwarekomponenten während der Testphase, um nachzuweisen, dass nur solche Folgen eintreten, die designseitig vorgesehen sind. (MCP_Software_2)

Sowohl CAST-32A als auch A(M)C 20-193 beziehen die zeitliche und räumliche Partitionierung ein, sodass Entwickler die Möglichkeit haben, die Bestimmung der WCET und das Verifizieren der Applikation separat vorzunehmen, sofern sie festgestellt haben, dass die MCP-Plattform eine robuste Ressourcen- und Timing-Partitionierung bietet. Die Anwendung dieser Partitionierungsmethoden hilft den Entwicklern bei der Eindämmung von Interferenzproblemen, jedoch lassen sich nicht alle HSRs auf diese Weise partitionieren. DO-178C und ähnliche Standards verlangen aber in jedem Fall Nachweise für ein hinreichendes Resourcing.

Hier trifft sich die Branche

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress bietet eine Vielzahl an Keynotes, Vorträgen und Seminaren. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der fünf Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI und Machine Learning bis hin zu Safety, Security und Ethik in der Technikschöpfung.

Jetzt mehr erfahren und anmelden!

Analyse der Verarbeitungszeiten auf MCP-Plattformen

Die nachfolgend beschriebenen Methoden eignen sich dafür, die Anforderungen der WCET-Analyse zu erfüllen und den Leitlinien von CAST-32A und A(M)C 20-193 gerecht zu werden.

Halstead-Metrik und statische Analyse

Die als Maß für die Komplexität verwendete Halstead-Metrik kann Entwicklern als eine Art Frühwarnsystem dienen und Aussagen über die Komplexität und den Ressourcenbedarf bestimmter Codesegmente liefern. Mithilfe der statischen Analyse können Entwickler Halstead-Daten zusammen mit tatsächlichen Messwerten aus dem Zielsystem nutzen, was einen effizienteren Weg zur Sicherstellung einer hinreichenden Ressourcenplanung für die Applikation ebnet.

Die besagten Metriken, aber auch andere Daten beleuchten die mit dem Timing zusammenhängenden Aspekte des Codes, wie etwa die Modulgröße, die Kontrollfluss-Strukturen und den Datenfluss. Durch die Identifikation von Abschnitten mit größerem Umfang, höherer Komplexität und verwickelteren Datenfluss-Mustern wird den Entwicklern geholfen, ihre Arbeitsaufgaben zu priorisieren und solche Codesegmente, die besonders viel Verarbeitungszeit beanspruchen, genauer abzustimmen. Werden diese ressourcenintensiven Bereiche in einer frühen Phase des Lebenszyklus optimiert, verringert sich der Arbeitsaufwand ebenso wie das Risiko von Timing-Überschreitungen.

Empirische Verarbeitungszeit-Analyse

Durch Messen, Analysieren und Verfolgen der Verarbeitungszeiten einzelner Tasks wird die Eindämmung von Problemen in Modulen erleichtert, die die Timing-Vorgaben nicht einhalten. Die dynamische Analyse ist für diesen Prozess von essenzieller Bedeutung, denn sie automatisiert das Messen und Dokumentieren des Task-Timings, sodass die Entwickler entsprechend entlastet werden.

Um die Genauigkeit zu gewährleisten, sollten sie dabei drei entscheidende Überlegungen anstellen:

1. Die Analyse hat in der Umgebung stattzufinden, in der die Applikation letztendlich laufen soll. So lassen sich Auswirkungen etwaiger Konfigurationsunterschiede zwischen Entwicklungs- und Produktionsumgebung ausschließen (z. B. Compileroptionen, Linkeroptionen und Hardwarefeatures).

2. Die Analyse muss wiederholt eine hinreichende Anzahl Tests ausführen, um umgebungs- und anwendungsbezogene Variationen zwischen den Durchläufen zu berücksichtigen.

3. Eine Automatisierung ist äußerst empfehlenswert, um zu gewährleisten, dass ausreichend viele Tests in einem vertretbaren Zeitraum ausgeführt werden und um Auswirkungen manueller Aktionen, die im Vergleich damit langsamer sind, auszuschließen.

Ein Beispiel dafür ist die LDRA Tool Suite, die einen „Wrapper“-Test-Harness zum Ausführen von Modulen im Zielsystem nutzt und die Timing-Messungen dadurch automatisiert. Entwickler können bestimmte zu testende Komponenten definieren – sei es eine einzelne Funktion, ein aus mehreren Komponenten bestehendes Subsystem oder das gesamte System. Überdies können sie angeben, welche Art von CPU-Stresstests durchgeführt werden sollen, um das Vertrauen in die Ergebnisse zu stärken (ein Beispiel ist der quelloffene Workload-Generator Stress-ng).

Analyse der Kontroll- und Datenkopplung in der Applikation

Die Kontroll- und Datenkopplungs-Analyse spielt eine entscheidende Rolle, um Abhängigkeiten zwischen den Tasks einer Applikation aufzudecken. Mithilfe der Kontrollkopplungs-Analyse lässt sich nämlich untersuchen, wie sich die Verarbeitungs- und Datenabhängigkeiten zwischen Tasks gegenseitig beeinflussen. Die Standards schreiben diese Analysen nicht nur vor, um die Ausführung aller Kopplungen sicherzustellen, sondern auch wegen ihrer Fähigkeit zur Aufdeckung potenzieller Probleme.

Die LDRA Tool Suite bietet robuste Unterstützung für Kontroll- und Datenkopplungs-Analysen. Wie in Bild 4 dargestellt, helfen diese Analysen den Entwicklern beim Identifizieren kritischer Codeabschnitte, die optimiert oder umstrukturiert werden müssen, um die Vorhersagbarkeit des Timings und die Ressourcennutzung der Applikation zu verbessern.

Zusammenfassung

Wenn sie die Leitlinien von CAST-32A und A(M)C 20-193 und die hier präsentierten Analysemethoden verstanden haben, sind Embedded-Software-Entwickler besser dafür gerüstet, die Komplexitäten von HSR-Interferenzen in den Griff zu bekommen und sich den Programmierproblemen zuzuwenden, die darauf Einfluss haben. All dies ist von essenzieller Bedeutung, um die effiziente und deterministische Verarbeitung kritischer Aufgaben auf Multicore-Plattformen sicherzustellen.  (mbf)

* Mark Pitchford verfügt über mehr als 30 Jahre Erfahrung in der Softwareentwicklung für technische Anwendungen. Er hat an vielen bedeutenden Industrie- und Handelsprojekten in den Bereichen Entwicklung und Management gearbeitet, sowohl in Großbritannien als auch international. Seit 2001 arbeitet Pitchford mit Entwicklungsteams zusammen, die eine konforme Softwareentwicklung in sicherheitskritischen Umgebungen anstreben, mit Standards wie DO-178, IEC 61508, ISO 26262, IIRA und RAMI 4.0. Er studierte an der Nottingham Trent University mit dem Abschluss Bachelor of Science und wurde vor über 30 Jahren Chartered Engineer. Pitchford arbeitet jetzt als technischer Spezialist bei LDRA Software Technology.

(ID:49734492)