Stabilität und Zuverlässigkeit Hard- und Softwareaspekte für optimierte Embedded Systeme - Teil 2

Autor / Redakteur: Kei Thomsen * / Sebastian Gerstl

Im ersten Teil dieses Beitrags befassten wir uns mit einem Vergleich unterschiedlicher CPU-Plattformen und zeigten, wie gute bzw. schlechte Programmierung deren Performance beeinflussen kann. Im zweiten Teil beleuchten wir näher, welche Auswirkungen die Wahl der Speicherarchitektur auf die Leistung und Zuverlässigkeit eines Embedded Systems hat.

Firmen zum Thema

Typischer Speicherriegel mit Error Correction Code: Industrielle Steuerungen sollen in erster Linie stabil funktionieren, da sind Speicherfehler durch Bitkipper nicht akzeptabel. Dennoch vertrauen viele auf Hauptspeicher ohne Fehlererkennung und Korrektur - bei immer geringeren Ladungsmengen in den Speicherbausteinen. Ein großer Fehler!
Typischer Speicherriegel mit Error Correction Code: Industrielle Steuerungen sollen in erster Linie stabil funktionieren, da sind Speicherfehler durch Bitkipper nicht akzeptabel. Dennoch vertrauen viele auf Hauptspeicher ohne Fehlererkennung und Korrektur - bei immer geringeren Ladungsmengen in den Speicherbausteinen. Ein großer Fehler!
(Bild: MicroSys)

Moderne Halbleiterstrukturen werden immer kleiner und ermöglichen dabei immer mehr Speicherplatz. Das gilt für RAMs (DDR3/4) ebenso wie für NAND Flashes. Betrachten wir hinsichtlich der Systemsicherheit zunächst die RAMs.

Die aktuelle Größe der Chip-Struktur eines DDR4 RAMs beträgt 20 nm und wird mit einer Spannung von 1,2V betrieben, um die zu bewegende Ladung (< 20.000 Elektronen) gering zu halten. Das ist notwendig, um den Stromverbrauch zu reduzieren und die Geschwindigkeit zu erhöhen. Damit besteht aber die Gefahr von Soft-Error-Störungen durch Höhen- und radioaktiver Strahlung, sowie durch energiereiche Strahlung von Elektromotoren und statischen Feldern. Diese Effekte bezeichnen wir als Single Event Upsets – SEU. Häufig sind auch die RAM Timings nicht genau berechnet und eingestellt. Da das Timing Temperaturabhängig ist, kann es bei hohen oder niedrigen Temperaturen zu Bit-Fehlern kommen kann. Ohne geeignete Gegenmaßnahmen kann das, hinsichtlich eines sicheren Systembetriebs recht gefährlich werden! Hier ist für sicherheitskritische Anwendung eine geeignete Maßnahme der Einsatz von ECC-Speicher (Error Correction Code).

Eine kleine Hilfe, sich die Größenordnung von 20nm vorzustellen: Nehmen sie an, sie haben ein Zimmer mit 5Meter Länge und weisen dieser Länge 1 mm zu. Legen sie nun ein Haar auf den Boden, dann entspricht die Haarbreite (etwa 0,1mm) den 20nm.

Erhöhung der Zuverlässigkeit für CPU Plattformen und Speicher durch ECC

Um Speicherfehler zu erkennen und zu korrigieren, kommt in den meisten Fällen ein Hardware-ECC zum Einsatz. Dazu wird das 64 Bit breite RAM um 8 Bit auf 72 Bit erweitert (bei 32 Bit + 7 Bit). Damit lässt sich ein 1-Bit-Fehler direkt korrigieren und ein 2-Bit-Fehler erkennen, was natürlich vom Memory Controller unterstützt werden muss. Jedoch haben heute bei weitem nicht alle Prozessoren einen solchen ECC-fähigen Memory Controller auf dem Chip (System On Chip – SoC). Fast alle PowerPC Prozessoren besitzen hingegen einen ECC-fähigen Controller. Für ARM-CPUs ist das jedoch die Ausnahme und bei X86-CPUs sind es meist nur die größeren Server Chipsets und nur selten die Embedded SoCs, die mit dieser Funktion ausgestattet sind.

Wenn der SoC nun ECC unterstützt und auch die entsprechende Anzahl von RAM-Bausteinen vorhanden sind (das sind typischerweise 5 oder 9 RAMs auf dem Board), dann sollte dieses Feature natürlich auch genutzt werden. Hierbei stellt sich auch gleich die Frage, wieviel zusätzliche Verarbeitungszeit das kosten kann. Aus unseren Erfahrungen mit PowerPC Boards und ARM Xilinx ZYNQ Systemen, sind das weniger als 5% Verlust der Memory Performance, was durchaus akzeptabel für den Zugewinn an Systemsicherheit sein sollte. Weiterhin ist es ist sinnvoll, ECC-Interrupt von dem Betriebssystem zu unterstützen, um die Fehler überhaupt auf Systemebene sichtbar zu machen. Der Memory Controller kann bei einem ECC-korrigierbaren Einzel-Bit-Fehler ein Interrupt auslösen. In der Interrupt-Behandlung wird nun die Speicherzelle ausgelesen und neu geschrieben, denn die gelesenen Daten sind ja (noch) korrekt. Bei einem Multi-Bit-Error geht das jedoch nicht mehr und es muss speziell entschieden werden, wie damit umgegangen werden soll, z.B.: sicherer Zustand, Fehlermeldung, Reboot, … Solch ein Vorgehen lässt sich auch sehr schön testen, da jeder ECC-fähige Controller auch die Möglichkeit einer Error Injection besitzt, um Fehler zu simulieren.

Weshalb sind nun ECC-Speicher so wichtig für die Systemzuverlässigkeit? Ein Single- Bit-Fehler wird im Speicher, wodurch auch immer, verursacht. Mit ECC-Speicher wird eine Meldung ausgegeben und die Daten werden korrigiert zurückgeschrieben, alles gut! Ohne ECC-Speicher sind im besten Fall die Daten nur ein wenig falsch, im schlimmsten Fall ist das im Betriebssystem-Code passiert und ein Sprung geht nicht +100 Byte nach vorne, sondern -100 rückwärts.

NAND (SLC, MLC, TLC) Flashes und deren Sicherung gegen Datenverlust

Richtig gruselig wird es jedoch bei den NAND-Flash-Speichern, die heute in allen gängigen Speicherkarten wie USB-Stick, CF, SD, µSD oder SSDs enthalten sind, vorallem wenn sie in zuverlässigen embedded Systemen zum Einsatz kommen sollen. Normalerweise würde man annehmen: 1 Speicherzelle = 1 Bit. Das stimmt grade mal bei den SLC-Flash-Bausteinen. SLC = Single Level Cells, MLC = Multi Level Cells, TLC = Three Level Cells. Besonders kritisch sind die MLC- und TLC-Technologien. Bei MLC (Schwarze Magie) werden pro Zelle 2 Bit gespeichert, also der Ladungsfüllstand 0, 0.33, 0.66 und 1 in der Zelle. Bei TLC (Alien Technologie) sind es sogar 3 Bit. Die Zelle wird also mit 8 unterschiedlichen Zuständen geladen (kurz beschreiben mit welchen). Man kann sich vorstellen, was innerhalb der Chips für ein Aufwand getrieben werden muss, um diese minimalen Ladungsunterschiede noch voneinander unterscheiden zu können. Bereits das Laden der Zellen entspricht einer Komplexität, als wollte man aus 20m Entfernung in ein Glas exakt 80ml Wasser eingießen.

Um die Daten korrekt zu halten wird der ECC in den OutOfBand (OOB) Daten gespeichert, was ein zusätzlicher Datenbereich zu den eigentlichen Daten ist (16Byte OOB / 512Byte Nutzdaten). Bei SLC werden typischerweise 3 Byte pro 512 Byte für den ECC genutzt, bei MLC und TLC wird fast der gesamte 16 Byte Bereich hierzu verwendet (auch Sinn). Die meisten NAND-Flash-Controller auf den SoCs benutzen die 3 Byte, um eine 1 Bit Error Correction per Hardware zu erzeugen. Werden mehr ECC-Bits benötigt, dann muss das in der Treiber-Software des Betriebssystems (von was) gelöst werden. Da die Zellen nur eine gewisse Anzahl an Schreib-Lösch-Zyklen vertragen (SLC ~100.000, MLC ~10.000, TLC ~ 3 - 5.000), müssen die Daten mit dem Wear-Leveling-Verfahren (kurze Erklärung) gleichmäßig auf die NAND Blöcke verteilt werden. Diese Arbeit wird bei SD, µSD, CF, USB-Stick und SSDs in dem eingebauten Flash-Controller geleistet. Bei eingelöteten NAND-Flashes organisiert das ein entsprechendes Filesystem wie UBIFS, JFFS2 oder YAFFS2.

Bereits vor einigen Jahren haben die NAND-Flashes eine Speicherdichte pro mm² erreicht, bei denen nach einigen Monaten einzelne Bits von selbst kippen (Zustandsänderung von 0 auf 1 oder umgekehrt) und das sogar in Sektoren die täglich nur 1-2-mal beim Booten gelesen werden oder gar nicht mit Strom versorgt werden (Gerät im Lager). Nach intensivem Nachfragen bei den Herstellern bekommt man irgendwann mal die Auskunft, dass das im Erwartungsbereich liegt. Und das für den Einsatz im industriellen Umfeld! In Datenblättern ist so etwas nirgends zu finden. In unserer täglichen Entwicklungspraxis ist uns das dadurch aufgefallen, dass ein NAND-Flash nach 12 Monaten plötzlich ein gespeichertes Linux nicht mehr lesen konnte, da in einem 512 Byte Sektor 2 Bits umgekippt waren, die dann nicht mehr mit dem 1-Bit-ECC korrigiert werden konnten. Abhilfe kann hier schaffen, regelmäßig (alle 1-2 Monate) einmal das gesamte NAND-Flash zu lesen und dabei den Fehler-Status vom NAND-Flash-Controller zu überprüfen. Meldet der Controller, dass er ein Bit korrigiert hat, kann man diesen Sektor einfach überschreiben und neu überprüfen. Wenn man diese Information vom Controller nicht bekommen kann, dann hilft nur ein regelmäßiges Scrubbing, bei dem die Sektoren gelesen und wieder überschrieben werden. Das sollten die externen Flash-Speicher-Medien idealerweise selbstständig machen. Nur, wie macht das z.B. eine SD-Karte, die als Backup bereits seit 3 Jahren im Schrank liegt?

Eine befreundete Firma hat in diesem Zusammenhang herausgefunden, dass z.B.: neuere SanDisk CF Karten (>= 2GB) scheinbar aus Geschwindigkeitsgründen das Wear-Leveling nicht mehr über den gesamten Bereich, sondern nur über den für den FAT32 benötigten Bereich durchführt, wie er typischerweise in SD-Cards für Kameras benutzt wird. Somit sind andere Filesysteme wie EXT2/3/4, OS-9, QNX u.a.(?), die nicht in dem Wear-Leveling Bereich der CF Karte angelegt sind, tödlich für den sicheren Betrieb, denn sie verweigern nach ein paar tausend Zugriffen die Funktion. In unseren Marktuntersuchungen fanden sich nur wenige CF-Karten als industrietauglich, die mit SLC-Technologie und Wear-Leveling über den gesamten Bereich arbeiten. Vom Gebrauch von MLC- oder TLC-Technologien wird für den industriellen Einsatz deshalb ganz abgeraten. Wie das aktuell bei SD-Karten aussieht… keine Idee!

Jetzt fragen Sie sich sicherlich, wie verhält es sich das nun im Zusammenhang mit den zunehmend verbreiteten SSD-Festplatten?

Ja, SSD-Platten basieren auf NAND-Flashes. Auch hier gibt es SLC-, MLC- und TLC-Festplatten. Je lauter die Werbung schrillt: „bahnbrechende 3D-NAND-Technik“, desto vorsichtiger sollte man sein sie für einen sicheren Systembetrieb in Betracht zu ziehen, denn damit wird meist MLC oder TLC beworben, bei der die Flash-Chips übereinandergelegt sind (3D). Günstig sind diese Produkte sicherlich, aber wie steht es um deren langfristige Zuverlässigkeit? SSDs mit SLC-Technologie muss man speziell suchen, für ihren industriellen Einsatzzweck auswählen und dann sind sie jedoch auch keine „Billigheimer“ mehr.

Ich habe bei den Recherchen zum diesem Artikel im Verein Embedded4You e.V. (Zusammenschluss von mehr als 30 embedded Lösungsanbietern) nachgefragt, ob jemand besondere Erfahrungen mit SSD-Technik gemacht hat. Und prompt kam zurück, „wir haben in 10 Rechnern seit 1 ½ Jahren SSD-Platten im Entwicklungseinsatz und innerhalb von 2 Wochen sind 3 SSD-Platten so ausgefallen, dass gar nichts mehr ging! Sie ließen sich überhaupt nicht mehr lesen. Zum Glück hatten wir bei 2 davon ein Backup der nicht älter als 1 Woche war.“. Ein anderer: „SSD... für Entwicklungsrechner ja, für industriellen Einsatz: niemals“.

In Bezug auf die Zuverlässigkeit von SSD-Festplatten möchte ich noch auf den Petabyte Club hinweisen, bei dem versucht wird 1 Petabyte Daten zyklisch auf 250GByte SSD-Platten zu speichern (1 Petabyte = 1024 TByte). Hierbei konnten 3 SSD-Platten von insgesamt 6 nur knapp über 700 TByte beschrieben werden, bevor sie komplett ausfielen. Ausführliche Informationen über diese Untersuchungen sind unter diesem Link zu finden.

In der Industrie ist auf ECC und SLC-NAND zu achten

Durch die zunehmend kleiner werdenden Strukturen und die eingesetzten Alien- Technologien werden Sicherungsmaßnahmen durch den SoC, das Betriebssystem und den Filesystemen immer wichtiger. Bei industriellem Einsatz unter extremen Bedingungen, wie Temperatur und Störfeldern, sollte immer versucht werden ECC- Speicher zu nutzen, da sonst die Folgen desaströs sein können. Der minimale Verlust an Performance wird durch massive Verbesserung der Stabilität und Systemzuverlässigkeit mehr als wettgemacht. Da ECC schon lange Standard bei PowerPC Prozessoren ist, sind diese Prozessoren zumindest in unserem Haus weiterhin die erste Wahl für Applikationen mit besonderen Anforderungen im industriellen Umfeld. Die meisten ARM-Prozessoren hingegen sind für Commercial Use gebaut und haben nur selten einen ECC-fähigen Speicher-Controller. Bei den NAND-Flashes sind im industriellen Einsatz eigentlich nur Flashes mit SLC-Technologie guten Gewissens zu empfehlen. Alles andere wäre an der falschen Stelle gespart. Wie zu Anfang beschrieben, ist Performance durch nichts zu ersetzen als durch noch mehr Performance. Sie resultiert aber nicht alleine aus der zugrundeliegenden Hardware, sondern kann auch das Ergebnis von gut geschriebenen Programmen sein.

* Dipl.Ing. Kei Thomsen ist Entwickler, Support und Trainer für das Betriebssystem OS-9 bei MicroSys.

(ID:44521237)