Startseite > Automation > Safety und Multicore – ein schwieriges Verhältnis

Multicore-Prozessoren »safe« zu machen, ist nach wie vor mit Problemen verbunden

Safety und Multicore – ein schwieriges Verhältnis

12. November 2010, 13:05 Uhr | Andreas Knoll

Andreas Raabe, Fortiss: »Bei der verteilten Berechnung einer Funktion ist die Gefahr von Programmierfehlern deutlich erhöht, weil der Entwickler berücksichtigen muss, kein nicht-deterministisches Verhalten entstehen zu lassen.«

Multicore-Prozessoren ermöglichen es, in einem Baustein unterschiedliche Funktionen parallel ablaufen zu lassen, ein und dieselbe Funktion redundant ablaufen zu lassen oder eine Funktion verteilt zu berechnen. Je nach Baustein-interner Datenbus-/Datenkommunikations-Architektur resultieren daraus jedoch Safety- und Determinismus-Probleme.

▶ Diesen Artikel anhören

Worin sie bestehen und wie sie sich eventuell vermeiden lassen, darüber informiert Andreas Raabe, Leiter der Gruppe »Parallele Architekturen« der gemeinnützigen Fortiss GmbH.

Markt&Technik: Welche Safety-Probleme können sich bei der Verwendung von Multicore-Prozessoren in sicherheitsgerichteten Automatisierungs-Systemen ergeben?

Andreas Raabe: Grundsätzlich sind hier zwei Arten des Einsatzes zu unterscheiden: Integration verschiedener Funktionen auf einem Prozessor, aber verschiedenen Kernen (vor allem zur Kostenersparnis), und verteilte Berechnung einer Funktion zur Erhöhung der Rechenleistung oder zur Senkung des Energieverbrauchs. Vorhersagbarkeit im Hinblick auf Laufzeiten ist in beiden Szenarien wichtig. Besonders bei der verteilten Berechnung einer Funktion ist die Gefahr von Programmierfehlern deutlich erhöht, weil der Entwickler nun berücksichtigen muss, kein nicht-deterministisches Verhalten entstehen zu lassen. Hier ist vor allem das Vermeiden und Diagnostizieren von Race- Conditions sowie Dead- und Livelocks zu nennen. Bei der Integration von Funktionen ist vor allem auf Komponierbarkeit und Fehlereindämmung zu achten. Je nach Prozessortyp kann spezialisierte Hardware manche Probleme vermeiden. Darüber hinaus gilt, dass die Eignung eines Multicore- Prozessors stark von der Anwendung abhängt. Der eine Multicore- Prozessor kann beispielsweise für eine bestimmte sicherheitskritische Anwendung sehr gut geeignet, für andere dagegen ungeeignet sein. So eignen sich beispielsweise manche Plattformen besonders zum Aufbau einer Software-Pipeline, während andere bei erratischen Speicherzugriffen Stärken haben.

Welche Multicore-Architekturen können welche Safety-Probleme verursachen? Welche Rolle spielt dabei die bausteininterne Datenbus-Architektur?

Prinzipiell sind im Hinblick auf Vorhersagbarkeit und Determiniertheit alle geteilten Ressourcen problematisch, auf die anders als über einen rein zeitgesteuerten Bus zugegriffen wird. Die Vorhersage bzw. Beschränkbarkeit der Laufzeit ist hier ein Schlüsselkriterium für die Einsetzbarkeit in harten Echtzeitsystemen und damit praktisch in allen Safety-relevanten Bereichen. Besondere Schwierigkeiten entstehen bei der Beschränkung der Laufzeit bei Speicherzugriffen oder Zugriffen auf die Peripherie. Hier kann die Buskommunikation anderer (nebenläufiger/ konkurrierender) Tasks das Zeitverhalten praktisch unvorhersagbar machen. Dies gilt immer dann, wenn nicht ausschließlich Prozessorkerne zum Einsatz kommen, die eine exakte Laufzeitvorhersage erlauben. Letzteres ist jedoch ein signifikanter Nachteil im Hinblick auf die Rechenleistung.

Nicht-deterministisches Verhalten kann sowohl aus Nicht-Vorhersagbarkeit als auch aus der Verwendung geteilter Ressourcen mit einem inneren Zustand resultieren. Hierzu zählen insbesondere alle Formen geteilten Speichers.

Inwieweit ist es sinnvoll, in Multicore-Prozessoren redundante Prozesse ablaufen zu lassen?

Dies ist insofern sinnvoll, als dass sich so die Fehlerwahrscheinlichkeit reduzieren lässt. Ein Problem ist hier natürlich, dass eine Abhängigkeit der einzelnen Implementierungen wohl nicht vollständig zu vermeiden ist. Dies gilt für allgemeine Faktoren wie mögliche konzeptuelle Fehler (beispielsweise in einer Steuerlogik) oder Fehler in der Implementierung, aber auch für mehrkernspezifische Abhängigkeiten wie etwa Übertragungsfehler innerhalb des Chips.

Ein neu hinzukommendes Problem ist, dass die Laufzeit des Verfahrens nun der maximalen Laufzeit der redundanten Auslegungen entspricht, die auch in einem Mehrkernsystem nicht unbedingt identisch sein müssen. Im Gegenteil können zeitliche Unterschiede durch zeitliche Abhängigkeiten (Cache-Verdrängung, Buszugriffe) signifikant zunehmen oder sogar erst entstehen. Das identische Programm auf identischen Prozessorkernen auszuführen, erfordert daher einen deutlichen Implementierungs-Mehraufwand, nicht zuletzt weil der Entwickler hier die zeitliche Unabhängigkeit garantieren muss. Daher rechtfertigt das Kosten-Nutzen-Verhältnis eine solche Umsetzung selten.

Bei besonders hohen Safety-Anforderungen sollte stattdessen die zwar teurere, aber sicherste Lösung eingesetzt werden. Dies ist der Einsatz unterschiedlicher Entwicklungsteams, die ihre Implementierungen auf unterschiedliche (heterogene) Prozessorkerne abbilden. So lassen sich sowohl Hardware-Fehler als auch Fehler in der Implementierung nahezu vollständig erkennen.

Eine kostengünstigere Lösung ist die Verwendung von Lockstep-Architekturen. Hier wird die identische Implementierung auf zeitlich völlig voneinander separierten Prozessorkernen ausgeführt und miteinander verglichen. Sind die Ausgaben nicht identisch, so folgt im Falle einfach redundanter Auslegung (zwei Kerne) ein fail-silent-Verhalten. Sind drei oder mehr Kerne beteiligt, stimmen die Kerne über das richtige Ergebnis ab. Dies erfolgt rein Hardware-gestützt und ohne dass der Programmierer dies explizit vorsehen muss. Abfangen lassen sich so natürlich ausschließlich Fehler, die durch Hardware-Versagen hervorgerufen werden. Allerdings erfordert diese Art der redundanten Auslegung praktisch keinen zusätzlichen Entwicklungsaufwand; Zusatzkosten entstehen nur für die Hardware.

Ein Kompromiss ist die Verwendung von Watchdogs. Hier wird parallel zum eigentlichen Berechnungs-Task ein zweiter Task betrieben, der die Ausgabe des ersten einer Plausibilitätsprüfung unterzieht. So lassen sich Fehler erkennen und fehlerhafte Ausgaben unterdrücken. Weil der Plausibilisierungs-Algorithmus häufig eine wesentlich geringere Flexibilität aufweist, ist seine Implementierung wesentlich weniger fehleranfällig. Nachteil im Vergleich zu Lockstep- Lösungen ist, dass immer ein manueller Aufwand zur Implementierung der Plausibilisierungsfunktion erforderlich ist.