Schwerpunkte

Selbsttests für embedded-Systeme

Software checkt Hardware und sich selbst

09. Juli 2021, 15:50 Uhr   |  Von Colin Walls

Software checkt Hardware und sich selbst
© AdresiaStock | Shutterstock

Fehler und Ausfälle lassen sich nie vollkommen ausschließen. Deshalb gilt es, ein Embedded-System so auszulegen, dass es Fehler selbst erkennen und – im Idealfall – auch selbst korrigieren kann. Mit den folgenden Tipps lassen sich Selbsttests ohne Aufwand implementieren.

Die meisten Ingenieure sind bestrebt, einen guten Job zu machen. Sie wollen das Beste schaffen, ganz gleich was sie tun. Obwohl dies eine gute Einstellung ist, bedeutet es, dass sie blind für die Möglichkeit eines Fehlers sein können. Elektronische Systeme sind komplex und ein Fehler ist immer möglich.

Diese Tatsache zu akzeptieren ist entscheidend, um bessere Systeme zu bauen. Die Hauptaufgaben bestehen darin, die Wahrscheinlichkeit von Problemen zu reduzieren, mit einem drohenden oder tatsächlichen Ausfall umzugehen und die Wiederherstellung nach einem Ausfall zu definieren.

Es gibt grob gesagt vier Teile eines eingebetteten Systems, die ausfallen können:

  • CPU
  • Peripheriegeräte
  • Speicher
  • Software

In jedem Fall gibt es Möglichkeiten für selbsttestenden Code, der in die Anwendung integriert werden kann. Einige solcher Tests können beim Start durchgeführt werden; andere Tests können im Hintergrund während des Betriebs eines Geräts durchgeführt werden.

CPU-Ausfall

Der Ausfall eines Prozessors ist recht ungewöhnlich, und da in diesem Fall kein Code ausgeführt werden könnte, gäbe es auch keine Möglichkeit der Wiederherstellung. Elektronische Geräte fallen meist beim Einschalten aus, sodass sich ein solcher Ausfall normalerweise durch ein »totes« Gerät bemerkbar macht. Der Teilausfall einer CPU ist in der Tat sehr unwahrscheinlich, sodass sich Integritätstests wahrscheinlich nicht lohnen. In einem Multicore-Prozessorsystem gibt es die Möglichkeit, dass ein Kern »Master« ist und die Integrität der anderen überprüft, oder die Peer-to-Peer-Kommunikation zwischen den Kernen könnte demselben Zweck dienen.

Ausfall von Peripherie

Wenn ein Peripheriegerät komplett ausfällt, antwortet es nicht auf seine Adresse. Das bedeutet, dass der Versuch, auf die Peripherie zuzugreifen, zu einem Trap führt. Es ist eine gute Praxis, Trap-Handler einzubauen, um eine solche Möglichkeit zu berücksichtigen.

Andere Fehlermodi sind sehr geräteabhängig, sodass es schwierig ist, verallgemeinerte Ratschläge zu geben. Viele Kommunikationsgeräte verfügen über eine Art »Rückkopplungs«-Modus, bei dem alle gesendeten Daten sofort zurückgegeben werden. Dies ermöglicht sehr einfache Tests der Sende-/Empfangsfunktion.

Speicherausfall

Obwohl Speicherchips sehr zuverlässig sind, befindet sich in den meisten Systemen so viel Speicher, dass die Möglichkeit eines Ausfalls in Betracht gezogen werden muss. Es gibt im Wesentlichen zwei Arten von Speicherausfällen: transiente und schwere Ausfälle.

Ein transienter Speicherausfall ist typischerweise das Umkippen eines einzelnen Bits. Dabei handelt es sich in der Regel um ein zufälliges Ereignis, das durch kosmische Strahlung, Hintergrundstrahlung oder thermische Effekte verursacht wird. Da der Fehler flüchtig ist, wird die Wertänderung nicht bemerkt, wenn das Datenbit zu diesem Zeitpunkt nicht in Gebrauch war. Wenn der Speicher in Gebrauch ist, ist die Auswirkung des Flips unvorhersehbar und könnte alles sein, von einem Fehler in einer Berechnung aufgrund schlechter Daten bis hin zu einem harten Systemabsturz.
Es ist durchaus möglich, dass solche flüchtigen Speicherausfälle ein häufiger Grund für zufällige Abstürze von Desktop-Computern sind. Es gibt nichts, was aus der Perspektive des Selbsttests getan werden kann, um diese Art von Fehlern zu berücksichtigen. In einem kritischen System, wie z.B. der Avionik, kann eine zusätzliche Abschirmung wirksam sein.

Ein schwerer Speicherfehler liegt vor, wenn ein Problem auftritt und bestehen bleibt. Ein solcher Fehler tritt höchstwahrscheinlich beim Einschalten auf, daher ist ein umfassender Selbsttest beim Hochfahren sinnvoll.Es gibt drei Arten von schweren Speicherfehlern:

  • Speicher antwortet nicht
  • Festgefahrene Bits – Bits, die dauerhaft auf 0 oder 1 bleiben
  • Übersprechen – das Schreiben in ein Bit beeinflusst ein oder mehrere andere Bits

Beim ersten Start eines Geräts, bevor irgendetwas Nützliches in den RAM geladen wurde, ist ein idealer Zeitpunkt, um einen umfassenden Speichertest durchzuführen.

Ein »Moving Ones«-Test – oder »Moving Zeroes« nach demselben Prinzip – prüft, ob jedes Bit des Speichers nicht verklemmt ist und ob es kein Übersprechen gibt (Listing 1).

 Mit dem »Moving Ones«-Test lässt sich jedes Bit im Speicher prüfen, ob ein Bit »klemmt« und ob es ein Übersprechen auf andere Bits gibt. Ist der Speicheraufbau bekannt, kann der Test optimiert werden, um schneller abzulaufen
© Walls

Listing 1. Mit dem »Moving Ones«-Test lässt sich jedes Bit im Speicher prüfen, ob ein Bit »klemmt« und ob es ein Übersprechen auf andere Bits gibt. Ist der Speicheraufbau bekannt, kann der Test optimiert werden, um schneller abzulaufen.

Unter der Voraussetzung, dass ein Trap-Handler integriert wurde, wird auch nicht reagierender Speicher erkannt.

Diese Art von Test kann zeitaufwendig sein, aber da ein Übersprechen zwischen Speicher-ICs weniger wahrscheinlich ist, kann der Test optimiert werden, wenn der Speicheraufbau bekannt ist. Außerdem muss der Code für diesen Test aus dem ROM (Flash-Speicher) ausgeführt werden und alle Daten müssen in Maschinenregistern gehalten werden.

Dieser Test erlaubt eine wortweise Prüfung des Speichers im norma­len Betrieb, die im Hintergrund läuft, und mit Bitmustern den Speicher auf festsitzende Bits und wortinternes Übersprechen überprüft
© Walls

Listing 2. Dieser Test erlaubt eine wortweise Prüfung des Speichers im norma­len Betrieb, die im Hintergrund läuft, und mit Bitmustern den Speicher auf festsitzende Bits und wortinternes Übersprechen überprüft.

Sobald der Anwendungscode geladen ist und ausgeführt wird, ist ein umfassender Speichertest nicht mehr möglich. Eine wortweise Prüfung kann jedoch möglich sein, wobei etwas »Hintergrund«-CPU-Zeit verwendet wird. Diese Art des Testens verwendet eine Reihe von Bitmustern, um den Speicher auf festsitzende Bits und wortinternes Übersprechen zu überprüfen (Listing 2).

Seite 1 von 2

1. Software checkt Hardware und sich selbst
2. Softwarefehler

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

Siemens AG Erlangen