Embedded-Systeme auf RISC-V-Basis
Schnellere Zertifizierung durch Continuous Verification
Für die Entwicklung sicherer und zuverlässiger Embedded-Systeme auf Basis von Prozessoren mit RISC-V-Architektur gibt es inzwischen ein Spektrum von Entwicklungs- und Verifikations-Tools, das den gesamten Lebenszyklus abdeckt. Besonders wichtig sind dabei Methodiken wie Continuous Verification.
Die RISC-V-Architektur wurde mit dem Ziel der Integration von Safety, Security und Zuverlässigkeit konzipiert, damit Entwickler etwaige Risiken schon in einer früheren Phase des Design-Lebenszyklus erkennen und beseitigen können. Hierfür wurden im Einzelnen mehrere besondere Eigenschaften hinzugefügt (siehe unten), die einen kontrollierten Zugriff auf Speicher und eine Verbesserung des Determinismus ermöglichen, indem viele der für traditionelle Mehrkern-Prozessoren typischen Timing-Restriktionen eliminiert werden. Multicore-Prozessoren auf Basis der RISC-V-Technologie können diese neuen architekturspezifischen Fähigkeiten und Ergänzungen ebenso nutzen wie unterstützende Software-Verifikations-Tools, um die Entwicklung sowie den Test und die Zertifizierung von kritischen Systemen wie etwa Automotive- und Aerospace-Anwendungen, industriellen Steuerungen und vielen weiteren Applikationen zu beschleunigen.
Heutige Embedded-Systeme sind dank leistungsfähigerer Prozessoren zunehmend Software-definiert, was mehr Flexibilität, Funktionalität und Individualisierung ermöglicht und das Innovationstempo erhöht. Die wachsende Komplexität der Software führt allerdings dazu, dass die Wahrscheinlichkeit potenzieller Schwachstellen zunimmt, die Auswirkungen auf die Sicherheit und Zuverlässigkeit haben können. Bei Systemen auf Basis von Multicore-Prozessoren ist dies von besonderer Brisanz.
Jobangebote+ passend zum Thema
Zusätzlich verkompliziert wird das Design durch die vom Markt verlangte gesteigerte Schlagzahl bei der Entwicklung. Die Systeme müssen beispielsweise in kürzeren Zeitabständen aktualisiert werden – nicht nur, um durch Einführung neuer Merkmale und Funktionen wettbewerbsfähig zu bleiben, sondern auch, um der wachsenden Herausforderung gerecht zu werden, die Sicherheit komplexer und vernetzter Systeme zu wahren. Um die gewünschte Funktionalität schneller umsetzen und zugleich die Safety- und Security-Vorgaben erfüllen zu können, sind Entwicklungskonzepte wie DevSecOps, die mit Methodiken wie Continuous Integration und Continuous Deployment (CI/CD) arbeiten, von essenzieller Bedeutung (Bild 1).
Nicht zuletzt müssen kritische Systeme eine breite Palette von Normen erfüllen, um sicherzustellen, dass sie den strikten Regelwerken von Staat, EU und Industrie in Sachen Functional Safety, Security und Zuverlässigkeit gerecht werden. Abhängig davon, wie kritisch die Software im jeweiligen System ist, geben diese Normen unterschiedliche Grade an Konformität (Compliance) vor. Die Standards CAST-32A, AMC 20-193 und AC 20-193 etwa skizzieren wichtige Überlegungen für das Design mit Multicore-Prozessoren. Dazu gehören beispielsweise unverbindliche SDLC-Zielsetzungen (Software Development Life Cycle), die die Entwickler bei der Einhaltung von Industriestandards wie DO-178C anleiten und unterstützen können.
Worst-Case Execution Time
Die »Worst-Case Execution Time« (WCET), also die im ungünstigsten Fall zu erwartende maximale Verarbeitungszeit, ist ein wichtiges und schwierig zu quantifizierendes Merkmal von Multicore-Systemen. Die in den verschiedenen Kernen eines Prozessors laufenden Tasks nutzen bestimmte Ressourcen gemeinsam, sodass es auf Anwendungsebene zu Konflikten um die Ressourcen kommen kann. Diese Konflikte wiederum haben Verzögerungen bei der Verarbeitung zur Folge, die auf der Anwendungsebene völlig unsichtbar sind, aber zu Schwankungen der Verarbeitungszeit führen. Weil diese Verzögerungen in einer bestimmten Situation nicht unbedingt zum Tragen kommen, kann die im Einzelfall eintretende Verarbeitungszeit des jeweiligen Programmcodes stark streuen. Bild 2 visualisiert die Spanne möglicher Verarbeitungszeiten eines Task einschließlich der WCET.
Angesichts der Schwankungen, die sich bei Konflikten zwischen den Kernen vom einen Durchlauf zum anderen ergeben, gestaltet sich das Berechnen der maximal möglichen (d.h. der tatsächlichen) WCET äußerst schwierig. Die Konflikte hängen nämlich davon ab, welche weiteren Tasks zur Laufzeit in den jeweils anderen Kernen laufen. Häufig ist es deshalb schlicht unmöglich, die Auswirkungen aller möglichen Konflikte zwischen den Kernen zu verifizieren. Die Umstände, die zur wirklichen WCET führen, treten also möglicherweise so selten auf, dass sie sich im Labor niemals beobachten lassen. Hieraus darf jedoch nicht geschlossen werden, dass sie auch im Feld niemals vorkommen. Sie stellen somit ein potenzielles Ausfallrisiko dar, das bei seinem Eintreten unter Umständen zu Verletzten und Toten führen kann.
Genau dies soll durch Functional-Safety-Normen verhindert werden. Das Ziel der WCET-Analyse ist es, die WCET anhand der beobachteten Verarbeitungszeiten abzuschätzen. Um zu garantieren, dass sämtliche Echtzeit-Timingvorgaben eingehalten werden, kalkulieren die Entwickler einen zusätzlichen Sicherheitspuffer ein und setzen die Timing-Obergrenze so an, dass die tatsächliche WCET sicher in einen akzeptablen Bereich fällt.
Einer der Vorteile der RISC-V-Architektur ist die Möglichkeit der direkten Zuordnung zwischen Cache und RAM. Dies ermöglicht eine festgelegte Zykluszahl für Speicherzugriffe, sodass für jegliche Programme oder Daten, die in diesem Speicher abgelegt werden, ein deterministischeres Zugriffsmuster zum Tragen kommt. Verfügbar ist dieses Feature auf RISC-V-basierten Architekturen wie den PolarFire- und PIC64-Familien von Microchip Technology. Weil gemeinsam genutzte Cache- und Speicherstrukturen zu den wichtigsten Konfliktursachen zählen, kann das Adressieren der Schwankungen, die bei der Zugriffszeit eines bestimmten Kerns auf den Hauptspeicher-Cache auftreten, entscheidend dazu beitragen, den Determinismus zu verbessern und die WCET zu verkürzen.
Analysieren der WCET
Es gibt mehrere Konzepte für eine effektive Analyse der WCET, um mit Systemen auf der Basis von Multicore-Prozessoren die CAST-32A- und A(M)C-20-193-Richtlinien zu erfüllen. Nachfolgend werden drei häufig verwendete Methoden beschrieben.
Statische Codeanalyse: Die traditionelle Methode zur Betrachtung der Prozessor-Schwankungsbreite bestand darin, den Code statisch und auf der Befehlsebene zu untersuchen. Mit Kennwerten wie den Halstead-Metrics können Entwickler die Komplexität eingrenzen und messen, zu wie vielen Befehlen eine bestimmte Routine kompiliert werden wird. Weil es inzwischen jedoch Prozessoren mit hochgradigem Pipelining und wechselnden Befehlsverarbeitungszeiten gibt, reichen diese Kenndaten nicht mehr aus, um die Verarbeitungszeit einer Routine und die Schwankungsbreite vorherzusagen.
Empirische Analyse der Verarbeitungszeiten: Bei diesem Verfahren werden die individuellen Verarbeitungszeiten durch dynamische Analyse gemessen, analysiert und verfolgt. Um die Genauigkeit zu gewährleisten, muss die Analyse im tatsächlichen Verarbeitungsumfeld der Applikation (oder in einer Art digitalem Zwilling dieses Umfelds) erfolgen. Hierdurch werden Faktoren wie Compiler- und Linker-Optionen sowie unterschiedliche Umsetzungen von Hardware-Features eliminiert. Überdies muss die Analyse hinreichend viele wiederholte Tests umfassen, damit umgebungs- und anwendungsbedingte Schwankungen zwischen den Durchläufen berücksichtigt werden. Automatisierte Tools vereinfachen die dynamische Analyse, indem sie den Testprozess straffen, die Wahrscheinlichkeit menschlicher Fehler reduzieren und präzise, konsistente Ergebnisse gewährleisten.
Kontroll- und Datenkopplungs-Analyse: Die Datenkopplungs-Analyse identifiziert Datenabhängigkeiten, die Kontrollkopplungs-Analyse dagegen Taskabhängigkeiten innerhalb einer Applikation. Viele Standards verlangen die Anwendung sämtlicher Kopplungen zur Aufdeckung potenzieller Probleme, die durch Interaktionen von Kontroll- und Datenabhängigkeiten hervorgerufen werden könnten (Bild 3). Dabei kann die Daten- und Kontrollkopplung impliziter und expliziter Natur sein: wenn mehrere Prozessoren für Cache- und Speicherzugriffe denselben Datenbus nutzen, resultiert hieraus eine implizite Daten- und Kontrollkopplung. Indem sie die Dispatch-Tabelle untersucht und herausarbeitet, welche Teile der Applikation gemeinsam bzw. getrennt verarbeitet werden, kann die Daten- und Kontrollkopplungs-Analyse jene Abschnitte isolieren, die sich gegenseitig ins Gehege kommen könnten.
RISC-V-Zertifizierung
Mehrere Merkmale der RISC-V-Architektur vereinfachen und verbessern das Testen und Zertifizieren kritischer Embedded-Systeme:
Individualisierung sicherheitskritischer Anforderungen: Die hinter RISC-V stehende modulare Designphilosophie gibt Halbleiteranbietern und Systemarchitekten die Möglichkeit, kundenspezifische Features auf der Hardwareebene zu implementieren. Dies hilft bei der Adressierung bestimmter Sicherheitsanforderungen für Mission-spezifische Applikationszertifizierungs-Standards, indem individuelle Fehlererkennungs- und Korrekturfunktionen sowie Überwachungs- und Diagnosefähigkeiten auf Hardwareebene ebenso unterstützt werden wie latenzarme, deterministische Verarbeitungs-Features zur Reduzierung der WCET und zur Einhaltung der Echtzeit-Anforderungen. Die Fähigkeit zur Implementierung kundenspezifischer Befehle und Hardwarefeatures erlaubt zudem eine Optimierung für spezifische Sicherheitsanforderungen ohne Abstriche an der allgemeinen System-Performance.
Speichermanagement: Die von RISC-V gebotene Möglichkeit zur Zuweisung von Level-2-Cachespeicher als RAM verleiht Entwicklern mehr Kontrolle über die Systemlatenz als traditionelle Architekturen. Eine erhöhte Eindämmung von Cache-Konflikten aber unterstützt ein besser vorhersagbares Verarbeitungs-Timing und vereinfacht das Management der WCET, indem für ein deterministischeres Multicore-Verhalten gesorgt wird. Das Cache-to-RAM-Mapping ist die Basis einer umfassenden Lösung für Multicore-bedingte Probleme in kritischen Embedded-Systemen beispielsweise im Avionik-Bereich.
Performance-Aspekte: RISC-V bietet mehrere Vorteile besonders für sicherheitskritische Anwendungen, zum Beispiel deterministische Verarbeitungspfade für Echtzeit-Anwendungen, kundenspezifische Befehle für die Sicherheitsüberwachung, effiziente Kontextwechsel für Systeme unterschiedlicher Kritikalität sowie konfigurierbare Speicherschutz-Einheiten, um die Verfälschung von Stack- und Dateninhalten zu minimieren.
Architekturbezogene Unabhängigkeit: Das offene Konzept von RISC-V bietet mehrere Vorteile für die Eindämmung von Lieferketten-Risiken. So verringert die Möglichkeit der Zusammenarbeit mit mehreren Halbleiteranbietern das Single-Point-of-Failure-Risiko in der Lieferkette. Relevant ist dies hauptsächlich für Anwendungen mit langen Lebenszyklen, die möglicherweise über Jahrzehnte hinweg gewartet und unterstützt werden müssen.
Unterschiedliche Redundanz: Sicherheitskritische Systeme, die eine Zertifizierung gemäß Design Assurance Level A (DAL-A) unter DO-178C erfordern, werden oft redundant ausgelegt, um vor Mehrfach-Primärausfällen geschützt zu sein. Die offene Architektur von RISC-V bietet Vorteile bei der Implementierung unterschiedlicher Redundanzstrategien. Dazu gehören die Implementierung unterschiedlicher Prozessorkonfigurationen in ein und demselben System, die Verwendung vielfältiger Redundanzschemata mit Lösungen verschiedener Anbieter sowie die Nutzung verschiedener Architekturen in Systemen mit unterschiedlicher Kritikalität und wechselnden Sicherheitsanforderungen.
Anschub seitens der Industrie: Eine wachsende Zahl Safety-zertifizierter RISC-V-IP-Kerne gibt Designern fertig zertifizierte Komponenten in die Hand, die strikten Sicherheitsanforderungen genügen. Microchip Technology, SiFive, CAST und weitere Anbieter haben spezialisierte RISC-V-Implementierungen mit integrierten Safety-Features, Ausfallerkennungs-Mechanismen und Redundanzfähigkeiten herausgegeben. Anbieter wie Frontgrade Gaisler gehen noch weiter und bieten strahlungsfeste Mikroprozessoren und IP-Cores für Systeme zum Einsatz im Weltraum an.
Ausgereifter Bestand an Entwicklungstools: Inzwischen sind die Entwicklungswerkzeuge und Verifikationsumgebungen für RISC-V so weit ausgereift, dass der gesamte Lebenszyklus abgedeckt wird. Zum Beispiel unterstützt das Target License Package (TLP) von LDRA für RISC-V-Architekturen die Entwicklung und das On-Target-Testing mit Multicore-Codeabdeckungs-Analyse, WCET-Messung für die AMC-20-193-Compliance, Anforderungs-Rückverfolgbarkeit sowie Integration mit wichtigen RISC-V-Entwicklungsplattformen. Mit diesem TLP ist die RISC-V-Architektur für Safety und Security gerüstet. Außerdem ist LDRA hochgradig in RISC-V-Umgebungen integriert und unterstützt das dynamische Testen mit Hardware und kommerziellen bzw. quelloffenen Simulationsumgebungen einschließlich der Simulation auf Halbleiterebene. Diese Umgebungen unterstützen das umfassende, hardwaregenaue Testen und Verifizieren zum Entwickeln und Testen der Software, während die Hardware noch entwickelt wird.
Kontinuierliche Verifikation
Anstatt mit allen Tests zu warten, bis die Software fertig entwickelt ist, lassen sich etwaige Probleme in früheren Phasen aufdecken, solange ihre Behebung noch einfacher und kostengünstiger möglich ist. Zum Beispiel können Entwickler Timingfehler und Unzulänglichkeiten in der Daten- und Kontrollkopplung schon während der Applikationsentwicklung detektieren. Entscheidend für das Entwickeln sicherer, geschützter und zuverlässiger Software ist ein robuster Entwicklungsprozess, der die Verifikation in jede Designphase einbindet – bekannt unter der Bezeichnung Continuous Verification. Zum Beispiel lassen sich Halstead Complexity Metrics während des gesamten Designlebenszyklus der Software nutzen. Die gleichen Tools, die den Entwicklern bei der Umstrukturierung des anfänglichen Codes helfen, um das Risiko von Multicore-bedingten Timing-Problemen zu verringern, lassen sich auch zur Aufdeckung von Code nutzen, der mit der Zeit übermäßig komplex geworden ist.
Continuous Verification hat gemeinsam mit Continuous Integration und Continuous Deployment das Ziel, den Verifikationsprozess parallel zu den Entwicklungs- und Ablieferungsprozessen zu beschleunigen. Durch Einbindung der kontinuierlichen Verifikation in die Designtool-Kette und die Entwicklungsumgebung wird die Verifikation zu einem transparenten Bestandteil des Design-Flows. Wenn die Verifikation dann automatisiert wird – mit dem Ausführen von Tests und Metriken, dem Konsolidieren der Ergebnisse über das gesamte Entwicklungsteam hinweg und dem Erstellen der nötigen Berichte –, wird die Compliance deutlich vereinfacht und für mehr Genauigkeit und Konsistenz gesorgt.
Die Software von RISC-V-basierten Multicore-Embedded-Systemen wird immer komplexer, weil neue Fähigkeiten hinzugefügt und die Zertifizierungsstandards weiterentwickelt werden. Durch das Einbeziehen von Test- und Verifikationselementen in jede Designphase können Entwickler vom Continuous-Verification-Konzept profitieren, was zu einer schnelleren Softwareentwicklung, einer beschleunigten Auslieferung und vereinfachter Compliance führt, während zugleich für das nötige Maß an Safety, Security und Zuverlässigkeit gesorgt ist.
Der Autor:
Jay Thomas ist Director Field Development bei LDRA.
Lesen Sie mehr zum Thema
