Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
10 2021 Elektronik 47 Embedded Technology 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 Peerto-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 DesktopComputern 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 Bder 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 moving ones test set every bit of memory to 0 for each bit of memory { verify that all bits are 0 set the bit under test to 1 verify that it is 1 verify that all other bits are 0 set the bit under test to 0 } 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 Quelle Walls 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