Typische Fehlerquellen vermeiden Selbsttest in eingebetteten Systemen

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Siemens EDA

Wenn der verfügbare Speicher nicht vollständig ausgeschöpft ist, lohnt es sich beim Design eines eingebetteten Systems, die Implementierung einiger Selbsttestfunktionen in Betracht zu ziehen.

Moderne Elektronik ist zwar in der Regel erstaunlich zuverlässig, doch gleichwohl sind Ausfälle immer möglich. In einem eingebetteten System gibt es im Wesentlichen vier Bereiche, in denen Fehler auftreten können:

• CPU

• Peripherie

• Speicher

• Software

Fehler in der CPU

Fällt eine CPU aus, handelt es sich in der Regel um einen Komplettausfall des Systems. Dies bietet keine Möglichkeit zum Selbsttest. Ein partieller Ausfall einer CPU ist sehr unwahrscheinlich.

Bei einem Multicore-System empfiehlt es sich, einen der Kerne die Überwachung der Systemintegrität zu nutzen.

Fehler in der Peripherie

Peripheriegeräte können auf verschiedene Weise ausfallen, doch viele Ausfallarten sind sehr geräte-/anwendungsspezifisch. Wenn ein Gerät nicht auf seiner Adresse reagiert, kann der Fehler abgefangen werden – dafür ist es unbedingt erforderlich, einen Trap-Handler einzubeziehen, um diesen Fehler zu verarbeiten.

Andernfalls enthalten Kommunikationsgeräte in der Regel einen „Loopback“-Modus, der das Testen der Übertragung und des Empfangs und damit verbundener Unterbrechungen ermöglicht.

Fehler im Speicher

Speicherausfall ist immer möglich. Dieser Fehler kann vorübergehend sein – ein einzelnes Bit kann beispielsweise von einem vorbeiströmenden kosmischen Strahl umgekehrt werden. Ein solcher Fehler kann in der Regel nicht erkannt werden und dann einen Software-Crash verursachen.

Daher ist es von entscheidender Bedeutung, die Wiederherstellung im Fall eines solchen Crashes zu berücksichtigen. Ein harter Fehler kann eine fehlende Adressantwort sein oder Bits blieben bei 0 oder 1 stehen. Ein Trap-Handler ist für Ersteres notwendig, Letzteres erfordert jedoch einige spezifische Tests. Umfassende Speichertests können nur beim Gerätestart durchgeführt werden.

Ein Moving Ones-Test ist wirksam. Während das Gerät in Betrieb ist, können Tests mit Mustern an einzelnen Bytes/Wörtern durchgeführt werden, die bestimmte Fehlerarten erkennen lassen.

Fehler in der Software

Der komplexeste Teil moderner Geräte ist Software. Obwohl die Software eigentlich nicht verschleißt, kann ihre Komplexität zu Fehlern führen, die bei der Entwicklung nur schwer zu erkennen sind. Gute, defensive Codiertechniken können helfen, einige Probleme vorherzusehen. Generell gibt es zwei Arten von Softwarefehlern: Datenkorruption und Code-Looping.

Datenkorruption kann durch einen Missbrauch des Pointers verursacht werden, der schwer zu erkennen oder zu verhindern ist, aber auch als Folge eines Überlaufs einer Datenstruktur, wie eines Arrays oder des Stacks. Das Einfügen von „Schutzwörtern“ kann bei der Erkennung von Überlauf helfen, bevor Schäden verursacht werden.

Code-Looping kann durch sorgfältiges Design – Vorsichtsmaßnahmen wie Timeouts beim Warten auf Geräte – oder eine Art Watchdog-Einrichtung (in Hardware oder Software) angegangen werden, die nicht reagierenden Code fängt.

Funktionale Sicherheit: Zertifizierte Mikrokontroller-Selbsttest-Software

Simulation von Fehlersituationen: Fault Injection einfach automatisieren

Der Autor

* Colin Walls verfügt über fast 40 Jahre Erfahrung in der Elektronikindustrie, hauptsächlich im Bereich Embedded Software. Er ist Embedded-Software-Technologist bei Mentor, a Siemens business, mit Sitz in Großbritannien. Walls hält regelmäßig Vorträge auf Konferenzen und Seminaren. Zudem ist er Autor zahlreicher Fachartikel sowie zweier Bücher über Embedded Software und betreibt ein Blog auf https://blogs.sw.siemens.com/embedded-software/.

(ID:47162020)