Wenn ich eine Anwendung programmiere, die auf der einen Seite
ununterbrochen laufen könnte, auf der anderen Seite aber bei Bitfehlern
in Registern / SRAM durchaus unkontrollierbaren Mist bauen könnte, ist
es dann empfehlenswert, gegen zufälliges Bitkippen Vorkehrungen zu
treffen? Oder kommt das praktisch auch bei jahrelanger Laufzeit nicht
vor?
Zum Beispiel:
1
ldi r16, 20; für schnelles Setzen im Interrupt
2
3
main:
4
;...
5
rjmp main
6
7
interrupt:
8
;...
9
sts Atimeout, r16 ;spart einen Zyklus für das Setzen der Konstante
10
;...
11
reti
Hier könnte ein Bitkippen in r16 für eine falsches Timeout sorgen.
Wäre dann eine Variante, die das Register regelmäßig auffrischt,
sicherer?
1
ldi r16, 20; für schnelles Setzen im Interrupt
2
3
main:
4
;...
5
ldi r16, 20; Register auffrischen
6
rjmp main
7
8
interrupt:
9
;...
10
sts Atimeout, r16 ;spart einen Zyklus für das Setzen der Konstante
11
;...
12
reti
Ist sowas sinnvoll oder kann man davon ausgehen, daß einmal geschriebene
Register ihren Wert behalten?
Brownout, ordentliche Spannungsversorgung und Watchdog seien mal als
vorhanden anzusehen.
Die Register werden (zumindest beim M32) im SRAM gespeichert. Sollten
also unter den gegebenen Umständen unbegrenzt halten. Du hast keine
Tesla-Spule oder dicke Motoren daneben stehen?
Viele aktuelle µCs haben ein automatisches Hardware Parity-Checking für
das SRAM integriert. Wenn da ein Bit kippen sollte, gibt das beim
nächsten Zugriff einen Fault und du kannst in eine
Fehlerbehandlungsroutine springen.
Eine Frage der Anwendung, resp der Umgebung. Hier unten passiert das
eigentlich nicht. Im Flugzeug auf 10km hoehe schon eher. Auf der ISS
schon.
Deswegen muss man fuer fuer Spaceanwendungen spezielle chips verwenden.
Aber eben, hier unten geschieht das nicht. Sonst wuerd nichts laufen.
Die EMV muss man natuerlich im Griff haben.
A. K. schrieb:> Viele Mikrocontroller?
Z.B. die Tricore Aurix-Familie.
Wird aber nur deswegen gemacht weil die Ausbeute ohne automatische
Fehlerkorrektur bei den Strukturbreiten sonst zu gering wäre.
Im Datenblatt wird das dann als "Sicherheitsfeature" verkauft.
Zur Ursprungsfrage:
Timm T. schrieb:> ist> es dann empfehlenswert, gegen zufälliges Bitkippen Vorkehrungen zu> treffen? Oder kommt das praktisch auch bei jahrelanger Laufzeit nicht> vor?
Das hängt davon ab wie gut Dein Hardwaredesign (z.B. gegenüber EMV) ist.
Wenn es wirklich sicherheitsrelevant ist solltest Du Maßnahmen
ergreifen.
Z.B. alle variablen als true und Komplement ablegen und in jedem
Durchlauf gegeneinander prüfen. Auch ein zyklischer Speichertest wäre
dann eine sinnvolle Maßnahme.
Allerdings mußt du dir dann auch Gedanken machen was deine Endstufen tun
wenn z.B. der Spannungsregler "durchlegiert" und mit der ungefilterten
Rohspannung (24 V) den Prozessor grillt. (Der brown out hilft in dem
Fall nicht).
Oft reicht ja schon eine einfache Maßnahme (z.B. mechanische
Übertemperatursicherung) um den GAU zu verhindern.
Gruß Anja
Siebzehn F. schrieb:> Eine Frage der Anwendung, resp der Umgebung. Hier unten passiert das> eigentlich nicht. Im Flugzeug auf 10km hoehe schon eher. Auf der ISS> schon.>> Deswegen muss man fuer fuer Spaceanwendungen spezielle chips verwenden.> Aber eben, hier unten geschieht das nicht. Sonst wuerd nichts laufen.
Er hat "jahrelange Laufzeit" geschrieben.
Da schlägt die Statistik gnadenlos zu - und natürlich passiert das dann
auch hier unten mit nicht unbedingt vernachlässigbarer
Wahrscheinlichkeit. Zumindest für alles
sicherheits-/überlebens-/massentöt-relevantes sollte man das nicht
einfach ignorieren.
Anja schrieb:> Allerdings mußt du dir dann auch Gedanken machen was deine Endstufen tun> wenn z.B. der Spannungsregler "durchlegiert"
Ich sag mal: Keine Medizinprodukte, keine AKW, keine Raumstation.
Legiert der Spannungsregler durch, geht es kaputt und ich bekomme es
mit.
Haut ein Blitz die Elektronik weg, geht es kaputt und ich bekomme es
mit.
Ändert sich ein Wert in einem Register oder SRAM, läuft der AVR weiter,
regelt falsch oder liefert falsche Werte, und ich bekomme es unter
Umständen über Monate weg nicht mit.
Darum geht es mir.
Es sind ATmega / ATtiny AVR unter normalen Bedingungen. Kein Automotive,
keine gemeinen Umgebungsbedingungen, eventuell Metallgehäuse.
Register können nicht in dem Sinne kippen. Was passieren könnte
(unwahrscheinlich) ist irgend eine Störung auf einer Leitung, welche die
Leitung zum "kippen" bringt. Das kann in der Alu genau so passieren wie
in den SRAM-Registern. Deshalb sind Register nicht gefährdeter für eine
Fehlfunktion als irgend ein anderer Teil des uCs.
Sollte eine solche Fehlfunktion auftreten, so kann ein einzelnes
Register verfälscht werden, es kann aber gerade so gut die Steuerlogik
(Program counter, Stack pointer, usw.) betroffen sein, so dass der uC
Amok läuft.
Aus diesem Grund sind Überprüfungen von einzelnen Registern nicht
sinnvoll. Wenn du gegen Störungen gesichert sein willst, dann musst du
die gesamte Funktion des uCs überwachen, z.B. mit Watchdog und weiteren
Ideen.
Timm T. schrieb:> Ändert sich ein Wert in einem Register oder SRAM, läuft der AVR weiter,> regelt falsch oder liefert falsche Werte, und ich bekomme es unter> Umständen über Monate weg nicht mit.
Ein einzelnes Bauteil kann sich nicht vollständig selbst überwachen,
denn dazu muss es zu einem gewissen Grad korrekt funktionieren, was im
abzufangenden Fehlerfall gerade nicht gegeben ist. Damit ist die Theorie
für dein Problem abgehandelt, fertig.
Die Wahrscheinlichkeit, dass du in den Self-Check-Code Fehler einbaust,
ist vermutlich höher als die eines Bitkippers, und optimierende Compiler
kannst du gleich vergessen. Außerdem kann dir ein Bitkipper im uC egal
sein, solange die Ausgaben (Reaktionen) des Systems stimmen. Um dich
dagegen abzusichern, hilft am einfachsten Redundanz: 3 Systeme, wenn
mind. 2 gleicher Meinung sind ist alles prima.
Oder du verabschiedest dich von der Unendlichkeit und planst einfach
einen regelmäßigen (monatlich, jährlich) Reset ein, der vermutlich
ohnehin auftritt (Stromausfall, Verschleiß/Reparatur des restlichen
Systems, ...).
S. R. schrieb:> Außerdem kann dir ein Bitkipper im uC egal> sein, solange die Ausgaben (Reaktionen) des Systems stimmen.
Deswegen die obigen Beispiele.
Flash dürfte gegen Einflüße deutlich resistenter sein als SRAM.
Stackfehler oder Pointerfehler führen zu Programmfehler, WDR, Überlauf
und damit zu Neustart. Damit habe ich wieder definierte Zustände.
SRAM Fehler führen nicht zu Neustart und bleiben eventuell längere Zeit
im Speicher.
Vergiss den Schmarrn. Du kannst dich darauf verlassen, dass sich der
Zustand deines Prozessors nicht einfach zufällig ändert. Ohne dies
Annahme ist Programmieren unmöglich. Punkt.
Natürlich gibt es abgefahrene Anwendungen, wo das nicht mehr immer
zutrifft, aber das sind Spezialbereiche, die dann auch spezielle
Hardware erfordern.
> Flash dürfte gegen Einflüße deutlich resistenter sein als SRAM.
Soll ich mal lachen? Ich finde es immer wieder erstaunlich, dass Flashs
überhaupt Daten ne relevante Zeit halten können. Bei den TLCs zählen
sie schon, wieviel Elektronen pro Tag maximal abfließen dürfen, damit
sie 10 Jahre hinbekommen (war glaub ich 2 Stück).
Timm T. schrieb:> Ändert sich ein Wert in einem Register oder SRAM, läuft der AVR weiter,> regelt falsch oder liefert falsche Werte, und ich bekomme es unter> Umständen über Monate weg nicht mit.
Um das mitzubekommen reicht dann eine einfache Checksumme über die
kritischen Parameter die zyklisch geprüft wird.
-> du bekommst dann Änderungen mit.
asdfasd schrieb:> Du kannst dich darauf verlassen, dass sich der> Zustand deines Prozessors nicht einfach zufällig ändert. Ohne dies> Annahme ist Programmieren unmöglich.
Bei genügend großen Stückzahlen kannst du noch nicht einmal garantieren
daß alle Prozessoren bei einer Multiplikation das gleiche Ergebnis
liefern weil ein Maskenfehler bei der Produktion bei einem einzelnen
Chip durchgerutscht ist.
Elektrostatische Entladungen ESD haben genügend Energie um einzelne Bits
kippen zu lassen.
Und auch die Brown-Out Funktionen des Prozessors haben sicherlich Lücken
so daß zwar Register bei Netzstörungen verändert werden können aber kein
ordentlicher Reset ausgelöst wird.
Gruß Anja
> Bei genügend großen Stückzahlen kannst du noch nicht einmal garantieren> [...] Maskenfehler [...] ESD [...] Netzstörungen [...]
Ja, und ein Flugzeug könnte auch auf den Prozessor fallen. Natürlich
kann das alles und noch viel mehr passieren, aber das sind keine Sachen,
die man beim Programmieren berücksichtig! Wenn die Hardware nicht mehr
deterministisch arbeitet, hat die Software keine Chance mehr.
asdfasd schrieb:> Wenn die Hardware nicht mehr> deterministisch arbeitet, hat die Software keine Chance mehr.
Die Software kann doch aber einige Einfallstore durch die Programmierung
schließen: Sie kann Werte einmalig beim Start aus dem Flash oder Eeprom
holen, oder sie kann diese Werte regelmäßig holen.
Gibt es denn praktische Erfahrungen mit Bitfehlern bei längerem
Dauerbetrieb von AVR Controllern (oder anderen)? Ich weiß, sowas ist
schwer nachzuvollziehen, und beim nächsten Reset ist es eh wieder weg.
Hallo,
an einem einzelnen Punkt anzusetzen wie in dem Fall Register r16 hilft
nicht wirklich weiter. Es kann was passieren, allerdings sehr selten,
aber dann an beliebiger Stelle, es ist sehr unwahrscheinlich dass gerade
das Register r16 getroffen wird. Wenn man also sich dagegen absichern
wollte wären viel viel umfangreichere Massnahmen notwendig, was man nur
bei hochsicheren Anwendungen versucht.
Daten, die für unbestimmte Zeit gespeichert werden, z.B. bei mir
Parametersätze im batteriegestützten RAM, sichere ich i.d.R. per
Prüfsumme gegen Veränderung. Allerdings bringt das nur was, wenn man
auch einen Plan B hat, d.h. was ist zu tun wenn ein Fehler vorliegt:
z.B. eine 2. Kopie verwenden oder auf Notbetrieb mit Standardparametern
gehen. Und der Fehler muss unbedingt irgendwie gemeldet werden,
spätestens beim nächsten Kundendienst sofern vorgesehen, oder durch eine
Fehler-LED.
Du kannst natürlich r16 immer wieder setzen, nicht unbedingt in der ISR,
sondern in der main-Schleife, aber eine Hochsicherheitsanwendung wird
dadurch nicht daraus. Du kannst auch r16 und andere kritische Werte auf
Plausibilität überwachen, aber das führt schnell in eine endlose
Rekursion - wer überwacht die Überwachung?
Georg
Nach der Weihnachtsfeier ein Bit gekippt?
Dann hat es zuviel am Glühwein genippt!
Auf der Straße lag ein betrunkenes Byte
das war völlig dicht und 8 Bittes breit
Entfernt hat es dann der Herr Straßenfeger,
völlig korrekt und äußerst integer
MfG Paul
> Ändert sich ein Wert in einem Register oder SRAM, läuft der AVR weiter,> regelt falsch oder liefert falsche Werte, und ich bekomme es unter> Umständen über Monate weg nicht mit.
Sowas kannst selbstverstaendlich passieren. Gegen solche Probleme hofft
man mit SIL vorzugehen:
https://en.wikipedia.org/wiki/Safety_integrity_level
Dadurch wird aber sowohl die Hardware, wie auch die Software sehr
aufwendig.
Das ist nicht gerade das was man in seiner Kaffemaschine einbauen wird.
Aber der Fuellstandschalter am Oeltanker hat sowas. (und kostet dann
soviel wie 10 Kaffemaschinen. :-)
Olaf
Olaf schrieb:> https://en.wikipedia.org/wiki/Safety_integrity_level>> Dadurch wird aber sowohl die Hardware, wie auch die Software sehr> aufwendig.
Der Text da oben in Wikipedia ist zu 3/4 von mir in der deutschen
Ausgabe
https://de.wikipedia.org/wiki/IEC_61508
allerdings nur die Grundlagen. Die neue Ausgabe der 61508 spricht von
sog. Soft-Errors die berücksichtigt werden müssen bei Designs. Teil 6,
Software. Eine jahrelange Laufzeit in einer Low-Demand Anwendung die
auch noch SIL 2-3 erreichen soll ist eine große Herausforderung, die in
der Praxis mit 2 CPU's gemacht wird und externem Watchddog sowie der
ganzen Palette an Speichertest und Decodertests, sowie gegenseitiger
Überwachung. Ohne einen Proof Test wird es nicht gehen, der immer wieder
zwischendurch gemacht werden muss.
Gruss,
Christian
Timm T. schrieb:> Die Software kann doch aber einige Einfallstore durch die Programmierung> schließen: Sie kann Werte einmalig beim Start aus dem Flash oder Eeprom> holen, oder sie kann diese Werte regelmäßig holen.
Das dürfte statistisch kaum relevant sein. Wenn der Inhalt futsch ist
und das Programm spinnt, dann liegt das Kind schon im Brunnen. Sich
dagegen abzusichern erfordert eine Kontrolle innerhalb der
Arbeitsprozesse, etwa die erwähnte Parität. Und ggf. ein gründlicher
Selbsttest beim nachfolgenden Neustart.
Praxisrelevanter scheint mir eine Prüfsumme über das Flash und deren
Kontrolle mindestens beim Start. Denn dass der Inhalt vom Flash mal
verschütt gehen kann, das gehört zum Lebensrisiko mit solcher Technik
arbeitender Systeme. Ebenso bei Konfigurationsdaten im EEPROM, wobei das
da auch bei jedem einzelnen Zugriff praktikabel sein kann.
A. K. schrieb:> Viele Mikrocontroller?
z.B. STM32F0, STM32F3, STM32L4
Aber das HW-Checksumming betrifft dort nur das SRAM, nicht die Register
von der Peripherie. Es könnte also sich auch z.B. das Interrupt-Flag
eines Timers zurücksetzen und dann wird Dein Interrupt nie aufgerufen.
Wirklich absichern wirst Du nicht alle Fälle können, denn wenn eines der
zentralen Register des Cores (z.B. Stackpointer) sich verändert, hast Du
keine Kontrolle mehr drüber was Dein Programm gerade macht. Da läuft es
dann auf die schon angesprochene Lösung mit den 3 µCs raus deren
Ausgaben verglichen werden.
Da Timm ja explizit von Timeouts sprach, wäre eine Überwachung der Takte
auch noch etwas an das ich denken würde. Kaputte Quarze hatte ich
nämlich schon so einige. Also vielleicht 2 Oszillatoren laufen lassen
(µC-Takt und Uhrenquarz) und gegeneinander prüfen. Das ist nicht
besonders aufwendig.
Timm T. schrieb:> Die Software kann doch aber einige Einfallstore durch die Programmierung> schließen: Sie kann Werte einmalig beim Start aus dem Flash oder Eeprom> holen, oder sie kann diese Werte regelmäßig holen.
In vollintegrierten Microcontrollern mit integriertem Flash hat man
i.d.R. nicht die Ressourcen, um das Flash komplett ins RAM zu kopieren.
Oder dank Harvard überhaupt nicht die Möglichkeit.
Anders sieht es bei höhergradigen Systemen mit externem RAM fürs
Programm aus. Dann ist das RAM aber meist DRAM und die Idee von Parität
oder ECC im RAM sowieso nicht ganz abwegig. Und das Flash ist dann oft
NAND-Flash mit eigenem ECC.
asdfasd schrieb:> Ja, und ein Flugzeug könnte auch auf den Prozessor fallen. Natürlich> kann das alles und noch viel mehr passieren, aber das sind keine Sachen,> die man beim Programmieren berücksichtig!
In welcher Spielzeugwelt lebst Du denn?
Früher (TM) als man noch richtige Zündschlösser im Auto hatte, konnte
man den Motor noch mit dem Zündschloß ausschalten wenn der Gaszug sich
verklemmt hatte.
Das geht heutzutage nicht mehr wenn man ein Keyless-Go system mit Start
Stopp betrachtet.
In einem modernen Motorsteuergerät sind etwa 100kB Objectcode die sich
nur mit dem unwahrscheinlichen Fall von < 1 ppm/Jahr beschäftigen daß
irgend ein Teil der Prozessorinternen Hardware spinnt.
(Verkabelungsfehler sind wesentlich häufiger und werden getrennt
abgehandelt).
Gerd E. schrieb:> Also vielleicht 2 Oszillatoren laufen lassen> (µC-Takt und Uhrenquarz) und gegeneinander prüfen. Das ist nicht> besonders aufwendig.
Auch das wird gemacht wobei meistens unterschiedliche Prinzipien zum
Einsatz kommmen. Z.B. Quarz für Prozessor, Resonator oder R/C-Oszillator
für den Challenge Response Window-Watchdog.
Gruß Anja
Ich habe in den 90ern mal an der Entwicklung eines Telemetriemoduls
eines (geostationären) Satelliten mitgearbeitet.
Das Ding hatte (soweit ich mich erinnere) 7 Z80 CPUs mit jeweils eigenem
SRAM, von denen immer mindestens zwei dasselbe getan haben, während eine
dritte auf die beiden anderen "aufgepaßt" hat. Bei Diskrepanzen wurde
das Dreigestirn neu gestartet, solange haben drei andere übernommen.
Wie oft der Mechanismus im Flug tatsächlich ansprach, kann ich leider
nicht sagen, wohl aber daß die Programmierung ein ziemlicher Krampf war.
Timm T. schrieb:> Stackfehler oder Pointerfehler führen zu Programmfehler, WDR, Überlauf> und damit zu Neustart. Damit habe ich wieder definierte Zustände.
Sehr optimistisch.
Wenn dir dein Prozessor den Brutschrank 3 Tage auf 320 Grad aufheizt,
anstatt auf 32, dann kriegt das kein Mensch mit.
Die von dir genannten Probleme können zu einem so schwerwiegenden
Fehler führen. Aber sie müssen es nicht. Gerade auf einem AVR ist es dem
Prozessor piepschnurzegal, von wo er sich werte holt (Pointerfehler).
Der liest einfach vom Bus und gut ists. Und nicht jeder Schreibzugriff
"in den Wald" führt auch zu einem Programmabsturz. Ganz im Gegenteil,
die wenigsten tun das. Meistens wird dann einfach nur mit falschen
Werten weiter gerechnet.
Ja man kann fehlertolerante Systeme in dem Sinne bauen, die auch gegen
solchen Unbill gefeit sind. Aber der Aufwand ist extrem hoch, damit das
vernünftig wird. Und alles andere als vernünftig willst du nicht, denn
dann ist der Aufwand immer noch extrem hoch, du hast aber nichts davon.
Für ein Gewächshaus ist das alles Overkill. Sieh lieber zu, dass du
möglichst alle Programmfehler aus dem Programm rauskriegst. Das bringt
viel mehr als sich gegen den unwahrscheinlichen Fall zu wappnen.
Markus F. schrieb:> Das Ding hatte (soweit ich mich erinnere) 7 Z80 CPUs mit jeweils eigenem> SRAM, von denen immer mindestens zwei dasselbe getan haben, während eine> dritte auf die beiden anderen "aufgepaßt" hat. Bei Diskrepanzen wurde> das Dreigestirn neu gestartet, solange haben drei andere übernommen.
Das war wohl die Billiglösung. Wenn man es wirklich ernst meint, dann
verwendet man verschiedene Prozessoren in verschiedener Schaltung, die
von verschiedenen Teams entwickelt werden. ;-)
... und bevor man fertig ist, ist das Projekt aufgrund Zeit- oder
Geldmangels verschieden.
Anja schrieb:> In einem modernen Motorsteuergerät sind etwa 100kB Objectcode die sich> nur mit dem unwahrscheinlichen Fall von < 1 ppm/Jahr beschäftigen daß> irgend ein Teil der Prozessorinternen Hardware spinnt.
Außer bei Toyota/Denso. Da gibt es dann zwar auch ein paar Zeilen zu,
aber die machen nix :-)
Karl H. schrieb:> Sieh lieber zu, dass du> möglichst alle Programmfehler aus dem Programm rauskriegst.
Löblich, aber ....
> Das bringt> viel mehr als sich gegen den unwahrscheinlichen Fall zu wappnen.
Doch, genau der Zustand will erkannt werden.
> Kippen Bits in Registern zufällig?
Eher nicht, ist aber nicht 100% ausgeschlossen.
Um Strategien gegen den "Schlimmsten Fall" zu entwickeln, müsste man
wohl die konkrete Anlage/Aufgabe kennen.
A. K. schrieb:> Das war wohl die Billiglösung. Wenn man es wirklich ernst meint, dann> verwendet man verschiedene Prozessoren in verschiedener Schaltung, die> von verschiedenen Teams entwickelt werden. ;-)
Mit dieser Art von Redundanz versucht man sich vor Programm- und
Designfehlern zu schützen (und die haben wir damals einfach nicht
gemacht). So gesehen ist das die Billiglösung, wenn man sich's nicht
leisten kann, es einfach richtig zu machen ;).
Die Z80-Redundanz war zum Schutz vor Bitkippern durch harte Strahlung.
Strahlung ist nichtdeterministisch. Die Wahrscheinlichkeit, daß es einem
in zwei unterschiedlichen Prozessoren und unterschiedlichen Schaltungen
die logisch gleichen Bits umhaut ist darum genau gleich groß wie in zwei
identischen.
Ulrich F. schrieb:> Karl H. schrieb:>> Sieh lieber zu, dass du>> möglichst alle Programmfehler aus dem Programm rauskriegst.> Löblich, aber ....>>>> Das bringt>> viel mehr als sich gegen den unwahrscheinlichen Fall zu wappnen.> Doch, genau der Zustand will erkannt werden.
Darf ich sagen, was ich denke?
Ich denke, wir haben es wieder mal mit jemanden zu tun, der
Programmfehler auf 'zufällig beim letzten Sonnensturm gekippte Bits'
schieben will. Alles schon dagewesen.
Das man in sicherheitskritischen Systemen und/oder in der Raumfahrt mit
ganz anderen Redundanzen operieren muss, als in der 08/15
Gewächshaussteuerung, ist klar und auch logisch. Überhaupt dann, wenn
ein Fehler fatal wäre oder man nicht mehr so einfach an den Computer
herankommt. Das sind aber die Ausnahmen. Die überwältigende Mehrheit
aller Computer (und nein, das sind nicht PC - das sind kleine µC wie sie
in fast jeder Kaffeemaschine oder Waschmaschine verbaut sind) benötigt
das alles nicht und geht von der Annahme aus, dass der Speicher seinen
Wert behält, komme was da wolle - und wenn nicht, dann ist die Hardware
ganz einfach schlecht designed.
Wer derartige Sicherheitsanforderungen erfüllen muss, der ist allerdings
so weit und so gut, dass er sicher nicht in mikrocontroller.de
nachfragen muss.
Vielleicht interessiert dich ja:
https://www.altera.com/en_US/pdfs/literature/wp/wp-01179-ecc-embedded.pdf
kurz Zusammenfassung: Ein einzelnes Bit wird wahrscheinlich in deiner
Lebzeit nie kippen. Wenn man aber zig milliarden Bits hat (4GB -> 32
milliarden Bits), kommt man plötzlich in den Bereich von Monaten, bis
mal eins kippt. Und spätestens wenn der normale PC > 128GB RAM hat,
sollte ECC auch für Privatanwender interessant werden um Abstürze
vorzubeugen.
Karl H. schrieb:> Darf ich sagen, was ich denke?
Meinen Segen hast du! ;-)
Karl H. schrieb:> Kaffeemaschine
Da reicht es sicherlich, im Fehlerfall, mit irgendwelchen
Sicherheitseinrichtungen die Stromversorgung abzutrennen.
Temperaturschalter, Feuchtesensor, Fi usw. um das inhumieren einer
Kantinenbelegschaft zu vermeiden.
Egal ob die Störung durch Sonnenflecken oder einen Programmierfehler
ausgelöst wird.
Karl H. schrieb:> Wer derartige Sicherheitsanforderungen erfüllen muss, der ist allerdings> so weit und so gut, dass er sicher nicht in mikrocontroller.de> nachfragen muss.
TÜV, und vergleichbare Organisationen, haben schon gewisse Vorstellungen
davon wie Sicherheitsmaßnahmen auszusehen haben. Ob die immer
ausreichend sind, steht auf einem anderen Blatt. Aber als
Mindestanforderung sollte/muss man sie akzeptieren.
Karl H. schrieb:> und geht von der Annahme aus, dass der Speicher seinen> Wert behält, komme was da wolle - und wenn nicht,
Dann verhindert die Thermosicherung daß die Bude abfackelt.
Alle anderen Fehlfunktionen haben begrenzte Auswirkung.
(nach 2 Litern Wasser ist der Tank leer).
Gruß Anja
Karl H. schrieb:> als in der 08/15> Gewächshaussteuerung
In sowas im Kleinen - eine Bakterien-Wachstumskammer - habe ich in der
Zuleitung der elektrischen Heizung einen Bimetallschalter für 65 Grad
eingebaut. So kann der Prozessor spinnen wie er will, das Gerät kann
sich nicht durch Schmelzen des Gehäuses selber vernichten. Kosten waren
etwa 1 Euro, der Konstruktionsaufwand war auch deutlich geringer als bei
3fach redundanten Prozessoren.
Georg
Anja schrieb:> Früher (TM) als man noch richtige Zündschlösser im Auto hatte, konnte> man den Motor noch mit dem Zündschloß ausschalten wenn der Gaszug sich> verklemmt hatte.> Das geht heutzutage nicht mehr wenn man ein Keyless-Go system mit Start> Stopp betrachtet.
Dochdoch: Du mußt die Schlüsselkarte ziehen und aus dem Fenster werfen.
Dann hält das Auto an. Wenn der Schlüssel Dein Handy ist - dann mußt Du
halt Prioritäten setzen. ;-)
Karl H. schrieb:> Darf ich sagen, was ich denke?
Die Gedanken sind frei, mach mal.
> Ich denke, wir haben es wieder mal mit jemanden zu tun, der> Programmfehler auf 'zufällig beim letzten Sonnensturm gekippte Bits'> schieben will. Alles schon dagewesen.
Es ist eine rein hypothetische Frage, die mir beim Programmieren eines
TWI-Slaves aufgefallen ist. Dort soll ein Timeout ein dauerhaftes
Blockieren des Busses durch den Slave aus welchen Gründen auch immer
verhindern. Hier ist das nicht kritisch, ein verändertes Timeout würde
einfach nur den Bus solange blockieren, bis der Zähler übergelaufen ist.
Mir ist zum Beispiel aufgefallen, daß der C-Compiler häufig ein Register
als 0x00 definiert und dieses für Operationen mit 0x00 verwendet. Nun
kann er das einmal am Programmstart machen und nie wieder anfassen. Oder
er kann es regelmäßig beim Aufruf einer Subroutine machen (was der
gängige Fall zu sein scheint).
Anderes und etwas anders geartetes Beispiel: Bei meinem Einstieg in C
hab ich mich kurz mit Arduino beschäftigt (aber schnell gemerkt, daß das
zu unflexibel für mein Projekt ist). Da gibt es eine Funktion, die die
abgelaufenen Millisekunden zurückgibt. Und ein Programmbeispiel, wie man
diese nutzt.
Bei scharfen Betrachten des Beispiels wird schnell klar, daß das
innerhalb weniger Tage, wenn der Zähler überläuft, nicht mehr
funktioniert. Das scheint aber keinen zu interessieren, zumindest wird
das in den Tuts nirgends erwähnt.
Timm T. schrieb:> Bei scharfen Betrachten des Beispiels wird schnell klar, daß das> innerhalb weniger Tage, wenn der Zähler überläuft, nicht mehr> funktioniert.
49,7 (?) Tage!
Das ist wohl bekannt, in der Arduino Gemeinde!
Spielt aber keine Rolle, solange die zu bearbeitenden Zeiträume kleiner
sind.
Hat auch nix mit "versehentlichen" Togglern zu tun.
> Das scheint aber keinen zu interessieren, zumindest wird> das in den Tuts nirgends erwähnt.
Wenn das nicht erwähnt wird, dann wird die "richtige"
Überlaufabhandlung eingesetzt, oder das Tut ist Mist.
Gibt es beides.
Timm T. schrieb:> Wenn der Schlüssel Dein Handy ist - dann mußt Du> halt Prioritäten setzen. ;-)
Du meinst, dass es günstiger sein könnte, seinen alten Kleinwagen an den
Baum zu setzen als das frische iPhone zu riskieren? Wird ne schwere
Entscheidung in der kurzen Zeit. ;-)
Bei Windows (vor NT) war es auch egal. Diese Systeme bleiben nach knapp
50 Tagen (2^32 ms) schlicht stehen, interessierte niemanden. Wenn dich
das stört, ist das einfach die falsche Technologie.
Wenn ein Gerät deinen I2C-Bus dauerhaft blockiert, weil es abgestürzt
ist, dann ist das ein Bug in deinem Code. Andere Geräte am Bus können da
nichts gegen tun.
Andererseits - und das wurde auch schon geschrieben - sind Bitkipper
eine statistische Sache. Wenn du eine 4TB-Festplatte ein paarmal
vollschreibst, hast du mit an Sicherheit grenzender Wahrscheinlichkeit
ein falsches Bit (nach der Fehlerkorrektur) auf der Platte stehen. Das
fällt dann auf, wenn das Dateisystem mit Checksummen anfängt. Bei Flash
ist das noch schlimmer, aber da wird deswegen härtere Fehlerkorrektur
gefahren.
Warum kümmert es niemanden? Weil es im Normalfall keine Rolle spielt.
Die Wahrscheinlichkeit, dass auf der Platte ein ungenutztes Bit kippt
oder dass in irgendeinem Bild oder Video ein paar Pixel kaputtgehen, ist
gering. Die Wahrscheinlichkeit, dass es dir in einem relevanten Binary
einen Pointer zerschießt, ist noch viel geringer.
S. R. schrieb:> Wenn du eine 4TB-Festplatte ein paarmal> vollschreibst, hast du mit an Sicherheit grenzender Wahrscheinlichkeit> ein falsches Bit (nach der Fehlerkorrektur) auf der Platte stehen.
Zumindest streng nach Vorschrift, also gemäss zugesagter Fehlerrate. Die
Praxis sieht glücklicherweise besser aus, wie reale SATA Speichersysteme
zeigen. Ausserdem bin ich mir nicht sicher, wie diese Statistik zu lesen
ist. Also ob es wirklich um 1 Bit geht, oder um den ganzen Sektor und
das dann auf 1 Bit runtergerechnet wird.
> Das fällt dann auf, wenn das Dateisystem mit Checksummen anfängt.
... und deren routinemässiger Verifizierung. Oder beim regelmässigen
Scrubbing von RAID-6/DP Systemen. Und genau da ist es mir noch nicht
gross aufgefallen.
Ich tippe ja darauf, dass Serverplatten sowohl bessere Hardware als auch
bessere Firmware benutzen. In großen RAID-Arrays wird man eher keine
Consumerware verbauen. Von der Hardware bereits korrigierte Fehler sieht
man im SMART aber öfter.
Google (oder wer anders?) hatte auch mal Statistiken zu Bitkippern in
(Consumer-?)DRAM, und das sah auch eher traurig aus. Aber dank Flash und
SD-Karten in Telefonen und Raspberrys wissen wir ja, wie man auf einem
vollkommen wackeligen Fundament ein stabiles Haus baut...
S. R. schrieb:> Ich tippe ja darauf, dass Serverplatten sowohl bessere Hardware als auch> bessere Firmware benutzen.
SAS Disks sind bei der zugesicherten Fehlerrate 2 Grössenordnungen
besser. Aber die meine ich hier nicht.
In meiner persönlichen jüngeren Statistik sind neben einem grösseren
SATA System, dem ich eine Vorselektion beim Diskhersteller zutraue, auch
2 ein paar Jahre alte RAID 6 Arrays aus jeweils einem Dutzend
stinknormaler Hitachi SATAs drin, wie sie sich Privatleute in den PC
stecken. Keine speziellen RAID Editionen, keine spezielle Firmware und
ganz gewöhnliche Megaraid-Controller.
Fehler beim Scrubbing hat es gegeben. Aber sehr selten.
> In großen RAID-Arrays wird man eher keine> Consumerware verbauen.
Kommt drauf an von wem du es kaufst und wieviel zu zahlst. Bei
EMC/NetApp/... kann das, was da drin steckt, schon customized und
vorselektiert sein. Vielleicht auch auf 520 statt 512 Bytes formatiert.
Günstige Noname Storage-Systeme oder grössere Qnap/...Thecus Kisten
basieren aber auf normalen Standarddisks.
Mein privates btrfs Serverlein hat trotz regelmässiger Bemühungen noch
nie einen Fehler in den Checksums gefunden.
A. K. schrieb:> Kommt drauf an von wem du es kaufst und wieviel zu zahlst. Bei> EMC/NetApp/... kann das, was da drin steckt, schon customized und> vorselektiert sein. Vielleicht auch auf 520 statt 512 Bytes formatiert.> Günstige Noname Storage-Systeme oder grössere Qnap/...Thecus Kisten> basieren aber auf normalen Standarddisks.
Da stecken ganz normale Platten drin - kannst Du auch bei eBay
bestellen. Die unterschiedlichen zugesicherten MTBFs zwischen Server-
(oder Speichersystem-) Platten (SAS) und SATA spielen auch keine Rolle
mehr.
IBM hat in einem seiner größten (und teuersten) Speichersystem ganz
normale "Popel-SATA"-Platten drin (wenn's sein muß, 1PB/Rack).
Markus F. schrieb:> Da stecken ganz normale Platten drin - kannst Du auch bei eBay> bestellen.
In einem älteren IBM Speichersystem der Oberklasse steckten Disks, die
mit 520 Bytes formatiert und mindestens in der ID customized waren.
Umformatieren auf 512 ging aber. Ist aber schon gut ein Jahrzehnt her,
kann sein dass man davon abgekommen ist.
Dass du Disks für EMC oder NetApp bei eBay kaufen kannst heisst nur,
dass es Leute gibt, die alte solche Systeme in Einzelteilen
verscherbeln. Und ist sehr praktisch, wenn man ein Altsystem hat, das
wegzuschmeissen zu schade ist.
> Die unterschiedlichen zugesicherten MTBFs zwischen Server-> (oder Speichersystem-) Platten (SAS) und SATA spielen auch keine Rolle> mehr.
Nix MTBF. Im Datasheet gibts mitunter eine Angabe der Fehlerrate,
angegeben in 1 Bit aus 10 hoch soundsoviel. Und da gibts 3 Klassen.
Normale 3,5er SATAs, 3,5er Nearline SAS mit SATA Kapazität und 2,5er
SAS. Bei dieser Fehlerrate sind die jeweils um Faktor 10 auseinander.
A. K. schrieb:> Nix MTBF. Im Datasheet gibts mitunter eine Angabe der Fehlerrate,> angegeben in 1 Bit aus 10 hoch soundsoviel. Und da gibts 3 Klassen.> Normale 3,5er SATAs, 3,5er Nearline SAS mit SATA Kapazität und 2,5er> SAS. Bei dieser Fehlerrate sind die jeweils um Faktor 10 auseinander.
Das mag ja sein, daß das so im Datenblatt steht. Obwohl ich das bei ganz
aktuellen Platten fast bezweifeln möchte (hab' grad' keins parat):
im realen RZ-Betrieb gehen SATA-Platten durchaus nicht (mehr) öfter
kaputt als SAS-Platten. Das war zu Beginn, als die ersten Hersteller
sich getraut haben, große SATA-Systeme im Petabyte-Bereich anzubieten,
durchaus noch anders.
Markus F. schrieb:> im realen RZ-Betrieb gehen SATA-Platten durchaus nicht (mehr) öfter> kaputt als SAS-Platten.
Korrekt. Allerdings ging es hier um defekte Daten, nicht um defekte
Disks. Wobei mir auch da keine hohe Fehlerrate auffiel, wie ich oben
auch schrieb.
Aus dem Bauch raus würde ich sagen, dass die SAS öfter ausfallen als die
SATA. Haben aber auch etwas mehr Arbeit.
A. K. schrieb:> In einem älteren IBM Speichersystem der Oberklasse steckten Disks, die> mit 520 Bytes formatiert und mindestens in der ID customized waren.
Ist bei NetApp auch so. Eigene Hersteller-ID, und 520 Bytes/Sektor für
eine Checksum.
Thread beobachten
Seitenaufteilung abschalten