Hallo, ich habe eine Frage bezüglich den AVR 8 Bitern. Sollte man in der Mainschleife gegebenenfalls Backups von wichtigen Registern anlegen um so Störungen festzustellen? Stellt euch vor Ihr habt ein Programm geschrieben das die Main dauern abarbeitet. Nun kommt eine Störung (Spannungsspitze, Blitzschlag, keine Ahnung) Und es verändert sich ein Registerzustand. Kann sowas passieren? Das Programm würde eventuell nicht mitbekommen das ein Register falsche Werte angenommen hat. Ich seh das gerad kritisch. Für Vorschläge, Erfahrungen und Denkanstöße bin ich dankbar.
Skittler Bruce schrieb: > Das Programm würde eventuell nicht mitbekommen das ein Register falsche > Werte angenommen hat. Ich seh das gerad kritisch. Wer sagt dir denn, dass dein Blitzschlag nicht den Wert vom Backup-Register verändert hat, und dein Hauptregister eigentlich richtig wäre? Was machst du dann? Machst du 2 Kopien und einen Mehrheitsentscheid? Oder 5 Kopien? Oder 15? Wer sagt dir, dass der Blitzschlag nicht das Flash so verändert hat, dass die Überprüfroutine fehlerhaft ist? Irgendwann besteht dein Programm dann nur noch aus Kopien von einem Register und elends viel Code, der versucht festzustellen ob dieses eine Register noch den richtigen Wert hat. > Für Vorschläge, Erfahrungen und Denkanstöße bin ich dankbar. Du machst dir zuviele Gedanken. Letztendlich läufst du immer in das gleiche Problem rein: Wer überwacht die Überwacher?
>Sollte man in der Mainschleife gegebenenfalls Backups von wichtigen >Registern anlegen um so Störungen festzustellen? Nein. Du kannst und musst Dich darauf verlassen, dass wenigstens die "unterste Ebene" perfekt fehlerfrei funktioniert. Das schließt alles, was sich im Controller-IC befindet, ein. Insbesondere darfst Du davon ausgehen, dass Flash-, SRAM-, EEPROM-Zellen und Register ihren Zustand nicht von selbst ändern, und dass die Instruktionen eines µCs so ausgeführt werden, wie es im Datenblatt beschrieben ist. Natürlich unter der Voraussetzung, dass der µC innerhalb seiner zulässigen Grenzen betrieben wird (VCC, Temperatur etc.).
Ausschließen kann man ein Kippen der Bits im SRAM, Flash oder EEPROM nicht, nur meistens sind die Ursachen dafür bekannt, wie zum Beispiel ungenügend stabilisierte oder zusammenbrechende Betriebsspannung, radioaktive Teilchen und dergleichen mehr. Trägt man Sorge, daß diese Ursachen nicht stattfinden, sind die Controller sehr zuverlässig. Dafür wurden sie gebaut. Nicht der Controller verursacht Probleme, Programme tun dies.
MarioT schrieb:
> Wenn Du kein Windows drauf spielts, passiert da nicht viel.
Das gilt aber auch für Linux...
...
Travel Rec. schrieb:
> Und für Unix.
Stimmt, auch dafür ist der 8-Bit-AVR ein bissel zu klein...
...
Karl heinz Buchegger schrieb:
> Du machst dir zuviele Gedanken.
Nun ja, ganz so von der Hand zu weisen ist die Frage nicht. Allerdings
bezog sich die Frage spezifisch auf die Hauptschleife des Programms.
In sicherheitskritischen Anwendungen wird oft verlangt, dass
langlebige Daten (z.B. write-once Daten wie Konfiguration, usw.)
entsprechend gesichert werden, da hier das Zeitfenster für eine
kritische Auswirkung eines Fehlers besonders groß ist.
Gegenbeispiel: Wenn ich jede Millisekunde meine Ports einlese, um sie
anschließend zu entprellen, und das Ergebnis in main()
weiterzuverarbeiten, ist es nicht sinnvoll die gespeicherten Daten zu
sichern, da sie sofort wieder aufgefrischt werden und sich sporadische
Störungen vermutlich ohnehin nicht so dramatisch bemerkbar machen.
Je nach Größe des Bereichs und Rechenleistung legt man aber keine Kopie
an, sondern bildet eine CRC über den Speicherbereich. Periodisch (also
typischerweise nicht vor jedem Zugriff) wird die CRC verglichen und ggf
ein Fehler gemeldet.
--
Marcus
Hast Du schonmal ein (funktionierendes) Programm für einen Mikrocontroller geschrieben? Vermutlich nicht. Selbstverständlich werden Konfigurationen in einem nichtflüchtigen Speicher (EEPROM beim AVR) gesichert, damit sie nach einem Reset neu geladen werden können. Und selbstverständlich nutzt man die Versorgungsspannungsüberwachung (BOD bei aktuellen AVRs) zum Auslösen eines Resets bei instabilen Verhältnissen. Somit wird nach dem Blitzschlag das Ding neu gestartet, falls es noch leben sollte. Und es gibt auch den Watchdog, der einen Reset auslöst, falls das Programm sich mal verheddert. Der ist aber in der Entwurfsphase tabu, da sich Programme meist durch Fehler verheddern, fast nie durch EMV. ...
Ich fürchte Du hast nicht verstanden von welcher Art von Anwendungen die Rede war. Hannes Lux schrieb: > Selbstverständlich werden Konfigurationen in einem nichtflüchtigen > Speicher (EEPROM beim AVR) gesichert, damit sie nach einem Reset neu > geladen werden können. "Nicht-flüchtig" heißt ja nicht, dass Information auf gar keinem Weg verloren gehen könnte. Das Ding muss ja schließlich auch zum Programmieren verändert werden. Man schützt ja auch oft den Programmcode mit CRC, und der liegt auch in einem nicht-flüchtigen Speicher. Warum? Außerdem kann ich mir in o.g. Anwendungen eine Konfiguration nach dem Reset nicht einfach so aus einem Speicher laden (egal welchen Typs). Wer weiß was mit den Daten zwischenzeitlich geschehen ist. Die Konfiguration wird nach mehr oder weniger aufwändigem Selbsttest neu ermittelt. > Und es gibt auch den Watchdog, der einen Reset auslöst, falls das > Programm sich mal verheddert. Für die Fragestellung zwar irrelevant, aber in bestimmten Sicherheitsbereichen sind interne Watchdogs nicht ausreichend für solche Zwecke. -- Marcus
> Ich fürchte Du hast nicht verstanden von welcher Art von Anwendungen
die Rede war.
Aber du?
Der Fragesteller hat dazu nichts gesagt, du kannst das also garnicht
wissen- es sei denn, du bist das selbst unter anderem Namen.
Dann aber würde ich die Finger von sicherheitsrelevanten Anwendungen
lassen.
Marcus Harnisch schrieb: > Man schützt ja auch oft den Programmcode mit CRC, und der liegt auch > in einem nicht-flüchtigen Speicher. Warum? Auf einem AVR?
bensch schrieb: >> Ich fürchte Du hast nicht verstanden von welcher Art von Anwendungen > die Rede war. > > Aber du? Der Fragesteller hat ausdrücklich um "Vorschläge, Erfahrungen und Denkanstöße" gebeten. Da es neben sinnlosen Beiträgen (bezüglich Linux, Windows, Unix) hauptsächlich solche gab, die die in diesem Zusammenhang zugegebenermaßen etwas einfache Vorstellung des Fragestellers abgewiesen haben, denke ich, dass der Hinweis auf tatsächlich genutzte Sicherungsmechanismen angebracht war. -- Marcus
Ha Marcus Harnisch schrieb: > MarioT schrieb: >> Auf einem AVR? > > Warum nicht? > > > > > > Beitrag melden | Bearbeiten | Löschen | Hast Du zufallig mal ein Beispiel? Würde mich interisieren(die Vorgehensweise von so einem Programm) Danke.
Sieh es mal so: 1. Die Wahrhscheinlichkeit, dass ein Bit im Speicher kippt ist um Grössenordnungen kleiner als diverse andere Störungsmöglichkeiten. Merze zunächst mal all diese aus... 2. Selbsttests für die Fehlfunktion eines Controllers, die in diesem Controller selbst laufen, bringen eh nichts: Wenn irgendwo ein Bit kippt, ist die Wahrscheinlichkeit nämlich sehr gross, dass der Controller Amok läuft und damit auch die Selbtsttests nichts mehr bewirken. Wenn es sicher sein soll, dann: - einfachst möglich programmieren - Hardware sauber aufbauen (Schutz von Versorungsspannung, IO) - Fail-safe bauen: Wenn etwas ausfällt, dann fällt es automatisch in einen sicheren Zustand - Wenn irgend eine Prüflogik, dann auf jeden Fall extern
MarioT schrieb: >> Auf einem AVR? > Hast Du zufallig mal ein Beispiel? > Würde mich interisieren(die Vorgehensweise von so einem Programm) Ach so, hat ein bisschen gedauert :-) Das wird bei einem AVR natürlich schwierig. Ich hatte Deine Frage zuerst in Richtung "kleiner µC=>wenig Flash=>wozu testen" gedeutet. Aber es ging ja eben um die Aussage von Hannes, dass das Speichern von Informationen in einem nicht-flüchtigen Speicher irgendwie sicherer sei. -- Marcus
Marcus Harnisch schrieb: > Aber es ging ja eben um die Aussage von Hannes, dass das Speichern von > Informationen in einem nicht-flüchtigen Speicher irgendwie sicherer sei. Ich hatte Hannes Aussage aber auch so verstanden, das der Aufwand und Nutzen die Daten zu prüfen in einem µC nicht passt. Nicht das die Daten richtig sicher wären.
Ich wollte ja eigentlich nichts mehr dazu sagen, aber ich wurde namentlich angesprochen und mir wurde dabei das Wort im Munde verdreht... Marcus Harnisch schrieb u.A.: > Aber es ging ja eben um die Aussage von Hannes, dass das Speichern von > Informationen in einem nicht-flüchtigen Speicher irgendwie sicherer sei. Unter "nicht-flüchtigen Speicher" versteht man üblicherweise einen Speicher, der bei Ausfall der Versorgungsspannung seinen Inhalt behält. Das heißt noch lange nicht, dass der Inhalt nicht (gewollt) per Programmierung oder per Software verändert werden kann. > > -- > Marcus Ich habe den Eindruck, Du hast (zumindest mit 8-Bit-Controllern) noch keine realen Werte geschaffen und betätigst Dich eher als eine Art Unternehmensberater. Siehe: http://www.youtube.com/watch?v=ko5CCSomDMY ...
MarioT schrieb: > Ich hatte Hannes Aussage aber auch so verstanden, das der Aufwand und > Nutzen die Daten zu prüfen in einem µC nicht passt. Nicht das die Daten > richtig sicher wären. Wenn der Nutzen ist, dass Dir eine Institution ein von Dir begehrtes Zertifikat ausstellt (alternativ: verweigert), dann ist so ziemlich jeder Aufwand recht :-) In einer konkreten Anwendung mit einem 8 Bit µC (nicht AVR), an deren Entwicklung ich aktiv beteiligt war (nur um weiteren Vermutungen vorzubeugen) haben wir mal grob abgeschätzt, dass weit mehr als die Hälfe der verfügbaren Rechenleistung für Selbsttests verbraucht wurde. Der Rest stand der eigentlichen Applikation zur Verfügung. -- Marcus
Hannes Lux schrieb: > Ich wollte ja eigentlich nichts mehr dazu sagen, aber ich wurde > namentlich angesprochen und mir wurde dabei das Wort im Munde > verdreht... Nun ja, ich hatte darauf hingewiesen, dass man Konfigurationsdaten absichert und Du hast mir entgegnet: > Selbstverständlich werden Konfigurationen in einem nichtflüchtigen > Speicher (EEPROM beim AVR) gesichert, damit sie nach einem > Reset neu geladen werden können. Ich bin daher davon ausgegangen, dass Du davon ausgehst, die Daten seien dort sicherer aufgehoben und bedürften keiner Úberprüfung. Diese Annahme wäre falsch. > Ich habe den Eindruck, Du [...] betätigst Dich eher als eine Art > Unternehmensberater. Siehe: http://www.youtube.com/watch?v=ko5CCSomDMY Wie Du meinst. -- Marcus
klaus schrieb: > Sieh es mal so: > > [...] Dein Wort in Gottes (des TÜV Prüfers) Ohr. Aber Du hast die allerwichtigste Regel vergessen: 0. Wenn Dir die Prüfinstitution eine Maßnahme empfiehlt, diskutiere nicht, schlage die Hacken zusammen und implementiere sie! Glaube mir, ich hatte diese Diskussionen. Kostet nur Zeit und die hat ein Entwickler bekanntermaßen nicht. Ich habe hier einen Auszug aus dem BIA Handbuch 29, "Fehlererkennende Maßnahmen in Mikroprozessoren". Dort findet man interessante Anregungen zum Thema. Speichertests gehören da noch zu den sinnvolleren Maßnahmen. Was die Wahrscheinlichkeit von Fehlern angeht, musst Du beachten, das manche Industrieanlagen "ewig" laufen, ohne abgeschaltet zu werden. Selbst ein Ereignis mit geringer Häufigkeit kann sich da bemerkbar machen. -- Marcus
Leute macht die Läden dicht, die Schwarzmaler sind im Land. Man hat ja sonst nichts zu tun (Hand vor den Kopf klatsch...). Vielleicht glaubst Du´s nicht, aber ich habe -zig Controllerprojekte seit mehreren Jahren unabgeschaltet laufen und da ist noch nie ein Bit gekippt. Bugs, die auftraten, waren vorher eindeutig hineinprogrammiert worden. Inzwischen habe ich sie fast alle. Ich weiß ja nicht, was Mancher hier sich so anmaßt, aber die Leute, die µC bauen, sind in der Regel keine Warmduscher. Die Teile gurken sogar im Weltraum ´rum, also lehnt euch mal entspannt zurück!
Ich darf hier mal das Datenblatt vom ATmega32A zitieren:
1 | 4. Data Retention |
2 | Reliability Qualification results show that the projected data retention failure rate is much less |
3 | than 1 PPM over 20 years at 85°C or 100 years at 25°C. |
Je nachdem wie sicherheitskritisch die Anwendung ist, muss man dann auch den Aufwand treiben, herauszufinden, ob man nun die "6 Richtigen" gezogen hat. Ich denke da z.B. an tonnenschwere Maschinen, die nicht anhalten wollen. Frank
1ppm ist 1 Bit auf eine Million Bit. Bei 128kByte Flash erreicht man die eine Million Bits gerade so. Wenn mir da in 100 Jahren eins kippt? Da pell ich mir ´n Ei drauf! Bei dem Zitat aus dem DB ist von Flash die Rede. Die OP-Anfrage betraf Registerwerte und die liegen im SRAM. SRAM kippt nicht ohne Grund irgendwelche Bits, weil das sind bistabile FlipFlops. So what?!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.