Liebes Forum!
Wir haben das folgende Problem mit einer unserer Basiskarten:
An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen
RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren
werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler
entstehen durch starke Strahlung und sollen korrigiert werden.
Der Microcontroller besitzt dazu aber nicht die geforderte Bandbreite,
wir hätte also Bedarf für einen zwischen-Chip, der das leisten müsste.
Ist jemandem ein solche Chip bekannt, der das leisten könnte?
Oder muss dort etwas Eigenes her? Einen logischen programmierbaren
Schaltkreis könnte man keicht noch integrieren, es fragt sich, ob es für
sowas Standardschaltungen gibt.
Soweit mir bekannt, machen RAMs im Computer einen ECC - ich weiß aber
nicht, wer das auswertet und wie.
?
Danke
Gab es fuer solche Sachen vor vielen Jahren nicht ein Parity-Bit?
Wenn es z.B. moeglich ist, die Daten in 7 Bit unterzubringen, koennte
man das 8te als Parity verwenden und den Bereich zyklisch pruefen.
wendelsberg
Ein Parity wird meistens nicht ausreichen. Wir müssten schon mehrere
Bits redundant in die RAMs schieben um es sicher zu machen. Wieviel man
da braucht, wird noch analysiert.
Reinhard S. schrieb:> Soweit mir bekannt, machen RAMs im Computer einen ECC - ich weiß aber> nicht, wer das auswertet und wie.
Wenn es fertige ECC Bausteine für RAMs mal gegeben hat, dann gibt es die
sicherlich heute nicht mehr. Sowas ist längst in jene Komponenten
gewandert, die RAMs ansteuern. In heutigen Servern also ins
Speicherinterface der Prozessoren selbst.
Dürfte auf ein CPLD rauslaufen, wenn Software nicht in Frage kommt. Nur
kann sich natürlich auch ein CPLD was einfangen, oder der Controller...
oder sind nur die RAMs selbst exponiert?
Von RAM-Fehlern her gesehen, habe ich schon die wildesten Sachen erlebt.
Wenn ganze Reihen von Bits kippen, ist das ja noch schnell zu erkennen
wenn der RAM vorher mit Nullen oder Einsen getetstet wird. Interessanter
sind die manchmal auftretenden Fehler, die man NUR durch Zufallsmuster
erkennt wenn sich z.B. irgendwelche Adressbereiche spiegeln. Einen
Bereich mit bunter Mischung beschreiben und Prüfsummen über bestimmte
Bereiche bilden wäre ja möglich, solange es dauerhafte Daten sind. Aber
bei veränderlichen ist die Sache nicht ganz so trivial. Paritätsprüfung
zeigt auch nur Fehler WENN zufällig nur ein Bit betroffen ist, wenn es 2
sind, stimmt die Rechnung wieder.
Immer 16Bit verwenden, bei denen die oberen und unteren 8 Bits immer
gleich sind und das beim Lesen auch geprueft wird?
Ob das natuerlich mit sinnvollem Aufwand in C zu machen ist?
wendelsberg
wendelsberg schrieb:> Immer 16Bit verwenden, bei denen die oberen und unteren 8 Bits immer> gleich sind und das beim Lesen auch geprueft wird?
Ist im worst case nicht besser als parity.
Man sollte zudem vorher genau wissen, gegen was man sich absichern will.
Neben persistenten Fehlern in der RAM Zelle gibts ja auch noch
transiente Fehler irgendwo anders. Bitleitung, Wortleitung, ... Wenn man
einen Wortleitungsfehler korrigieren können will, dann muss man entweder
sehr genau wissen, wie das RAM intern aufgebaut ist, oder man nimmt
einen RAM-Baustein pro Bit.
wendelsberg schrieb:> mit sinnvollem Aufwand
Nicht umsonst werden bei Flugzeugen getrennte Rechner eingesetzt. Es
nützt ja wenig, wenn der RAM ok ist und der Fehler bei der Verarbeitung
eintritt.
Smartfusion2. Wahlweise mit dem integrierten Cortex-M3 oder einen 8Biter
drauf konfigurieren. SECDED von Haus aus. Mehr kann man implementieren.
Bei dem bisher angedachten Szenario sollte auch der SRAM im uC
"behandelt" werden. Gibt es noch 8Biter aus alten Zeiten, die das
effizient vorsehen? Oder gibt es so etwas in 8Bit auch als neu?
Frank K. schrieb:> TI hat MSP430 Prozessoren mit FRAM.
Ist eine nette Idee, aber deren FRAM adressiert wohl eher nicht die
Strahlung. Man hat nichts davon, wenn zwar das FRAM seinen Inhalt
behält, aber Prozessor und SRAM durch irgendwelche Fehler Unsinn
reinschreiben.
Da muss man sich schon eine Gesamtlösung überlegen, wenn es wirklich
kritisch ist. Sowas wie ein Master/Checker System beispielsweise, in dem
mehrere Systeme parallel laufen und auf Gleichlauf kontrolliert werden.
Dummerweise steigt die Komplexität um Grössenordnungen, wodurch die
Fehlerwahrscheinlichkeit ebenso absteigt.
Lars R. schrieb:> Bei dem bisher angedachten Szenario sollte auch der SRAM im uC> "behandelt" werden.
Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ...
>Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ...
Und das Flash. Die Strukturen sind noch kleiner als RAM.
Der beste Schutz wäre Strahlung gar nicht erst ran zu lassen.
A. K. schrieb:> Lars R. schrieb:>> Bei dem bisher angedachten Szenario sollte auch der SRAM im uC>> "behandelt" werden.>> Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ...
Ja, berücksichtigt werden müssen die auch. Aber deren Inhalt ändert sich
häufiger. Im Idealfall ständig. Es muss auch nicht jeder Treffer ein
Flipflop kippen. Wenn man aber den SRAM "länger" nicht "behandelt", so
steht nur noch Müll drin.
holger schrieb:>>Nicht nur RAM ist gefährdet. Auch normale Logik, Register, ...>> Und das Flash. Die Strukturen sind noch kleiner als RAM.
Für das Kippen einer Flashzelle ist der erforderliche Energiebedarf sehr
viel größer.
Wenn dann die Belastung so hoch ist, dass keine einzige Addition oder
Bitoperation mehr korrekt ausgeführt werden kann, so braucht man sich um
den Flash auch nicht mehr zu sorgen. Dann funktioniert auch Redundanz
mittels gegenseitiger Überprüfung mehrer Systeme nicht mehr.
wendelsberg schrieb:> Immer 16Bit verwenden, bei denen die oberen und unteren 8 Bits immer> gleich sind und das beim Lesen auch geprueft wird?
Du bist mir ein Schlaumeier. Wie willst du die Fehler korrigieren, wenn
du nicht weißt, welches Byte gestört ist.
Für Erkennung und Korrektur von Fehlern in Datenworten sollte man sich
mal mit dem Hammingabstand von Codeworten beschäftigen.
Reinhard S. schrieb:> An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen> RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren> werden
Wie kommst Du darauf, daß man einen SRAM testen müsse?
Gibt es eine Vorschrift, die Ihr einhalten müßt und in der das explizit
verlangt wird?
Eine 4-Transistor SRAM-Zelle ist so ziemlich der sicherste RAM-Speicher,
da kippt viel eher was in der CPU um.
Ein SRAM-Test war nur in den Anfängen nötig, wo die RAM-Baugruppen noch
extra Steckkarten waren und die ICs in billigen Sockeln steckten. Da
traten in der Tat sehr häufig Kontaktprobleme auf, die RAM-Fehler
vorgaukelten.
Peter D. schrieb:> und die ICs in billigen Sockeln steckten.
Das ist Deine Theorie. Auch eingelötete hatten Fehler und Zeitprobleme!
Wenn Du Dir Bussignale mal genauer ansiehst, wirst Du begeisteret sein,
daß es überhaupt so gut funktioniert.
A. K. schrieb:> Dürfte auf ein CPLD rauslaufen, wenn Software nicht in Frage kommt. Nur> kann sich natürlich auch ein CPLD was einfangen, oder der Controller...> oder sind nur die RAMs selbst exponiert?
Es ist auch der Controller betroffen, aber die RAMs sind die großen
Datenspeicher. Der Controller hat alles temporär und rechnet mehrfach
dasselbe.
Ob das hier die richtige Plattform für sowas ist? Wird wohl eher in
Richtung ganz schlechte, schlechte und halbgare Vermutungen gehen. Wie
man mit sowas umgeht, ist schon echtes Spezialwissen. Wenn
Spezialanforderungen bestehen, sollte auch Spezialwissen vorhanden sein,
nicht zusammengeklaubtes.
Mein Ansatz wäre:
-parallele Systeme (mindestens 3) Ganz grosses Achtung, wenn eins
abweicht (und nicht unbedingt annehmen, dass das eine abweichende falsch
ist, die anderen beiden aber richtig sind)
Vielleicht ist in der Raumfahrttechnik was zu finden, ist deren
tägliches Brot, Abschirmung auch nur sehr begrenzt möglich.
Ältere Technologien mit grösseren Strukturen können (nicht müssen!)
strahlungsfester sein.
Ringkernspeicher? :-)
Gerhard schrieb:> Ringkernspeicher? :-)
Sehr gutes Stichwort. Genau dafür habe ich mal ein FPGA-Design gemacht.
Die RAM-Bausteine und die internen Block-RAM-Areale sind leider von
Strahlen betroffen, weil CMOS-basierte S-RAM-Technologien aufgrund ihres
Herstellungsprozesses / Dotierung einen hohen Einfangquerschnitt für
Teilchen und Elektronen haben. Solange es nur Elektronen sind, kann man
von ausschließlich temporären Störungen ausgehen, ansonsten muss man
Altersdegradation unterstellen, messen und Teile tauschen.
Die Störsicherheitsthematik wurde damals ebenfalls mit Redundanz gelöst.
Alle benötigten Werte im FPGA und den RAM-Bausteinen mehrfach
hinterlegen und beim Laden auf Konsistenz prüfen bzw. durch
Mehrfachrechnen zu sichern. die Ist eine klassische Aufgabe für den
FPGA. Auch das Image des FPGAs selber kann man so prüfen.
Was an Aufwand zu treiben ist, liegt an der Exposition und die
Anforderungen (FMEA). Um eine genügende Sicherheit zu haben kann man
einfach die Redundanz steigern, also alle Werte 4x und dann einen
Mehrheitsvergleich. Das eventuell kaputte kann man so sehr sicher
detektieren und gleich wieder hinbiegen.
Da muss man dann halt bauen und auch einfach messen, was passiert.
oszi40 schrieb:> Wenn Du Dir Bussignale mal genauer ansiehst, wirst Du begeisteret sein,> daß es überhaupt so gut funktioniert.
Der beste RAM-Test nützt nicht die Bohne, wenn ein Anfänger das Layout
macht.
Ich hatte mal ein Board von nem externen Dienstleister machen lassen,
das sah aus, wie das Spiel Misthaufen. Das Oszi hat dann auch schöne
Unterschwinger gezeigt (-2V) und es lief unzuverlässig.
Ich habs dann selber gemacht und die Signale sahen aus, wie gemalt.
Hab vor Kurzem ein ähnliches Problem gehabt wie Reinhard!
Es gibt da so(ooooo) viele Möglichkeiten. Vor Redundanten Speicher (z.B.
TMR), über redundante Speicherblöcke (also alles mehrfach speichern und
dann Voten) oder über spezielle Checksummen,... bis hin zu alles in
Tantal einwickeln und und Worse Case Berechnungen der
Warscheinlichkeitshäufung.
Man ist sich da in der Raumfahrt auch nicht ganz einig ;-)
Ich habe dann für uns (weil u.A. der Platz für redundante
Bauteile/Module) nicht ausreichte und uns die Signale an der Logik
ausgingen auf ein "größers" MRAM von Everspin ausgewichen. Zusätzlich
hat das Latch-Up Protection der Stromversorgung und eine
Signalisolierung bei Latch-Up auslösung bekommen (nicht das der Latch-Up
von einem Signal gehalten wird).
Dadurch das der Platz im RAM größer ist als wir eigentlich brauchen ist
jetzt Platz für redundante Daten, Checksummen sowie (ich meine) Hamming
Codierte Daten.
PS
Wie sicherst du denn die Registerflips im µC durch Bestrahlung? Sind ja
auch nur "SRAM-Zellen". - Eine Methode ist Zeitliche Redundanz - Alles
mehrfach und Zeitlich versetzt durchführen und dann ein "Diff" über die
Einzelergebnisse ;-)
Ich meine das CNES dazu ein paar schöne Papers hat...
Wenn es eine Sicherheitsbaugruppe ist sollte eigentlich nach ISO26260 ja
auch ein Sicherheitskonzept erstellt worden sein.
Wurden Euch den die daraus abgeleiteten Sicherheitsziele übersendet?
Weil ansonsten ist die "Erfüllung" dieses Requirements ggf. eine
unendliche Geschichte, weil sich das ja fast endlos auf die einzelnen
Baugruppenkomponenten unterschiedlich dekomponieren lässt.
Reinhard S. schrieb:> An einem 8Bit-Mixrocontroller in einer Sicherheitsbaugruppe sollen> RAM-Bausteine angeschlossen werden, die mit Speichertestzyklen gefahren> werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler> entstehen durch starke Strahlung und sollen korrigiert werden.
Warum nimmst Du nicht, anstatt da einen zusätzlichen Chip
dazwischenzufrickeln, gleich ordentliches rad-hardened RAM?
BAE zum Beispiel hat soviel davon davon, daß sie die sogar verkaufen!
Beispielsweise sei für das SRAM "Independence" (BAE-Nummer 8427352)
die "Featureliste" aus dem BAE-Katalog zitiert:
"The 16 Mb monolithic SRAM 'Independance' has total-dose tolerance
of greater than 1 Mrad and an upset rate of less than 1E-12 upsets
per bit-day. Prompt dose levels are >1E9 rad/sec"
Die Anderen üblichen Verdächtigen dürften wohl ähnliche
Teile im Programm haben.
Jürgen S. schrieb:> Was an Aufwand zu treiben ist, liegt an der Exposition und die> Anforderungen (FMEA). Um eine genügende Sicherheit zu haben kann man> einfach die Redundanz steigern, also alle Werte 4x und dann einen> Mehrheitsvergleich. Das eventuell kaputte kann man so sehr sicher> detektieren und gleich wieder hinbiegen.
Warum wieder hinbiegen wenn man eines von den dreien nehmen kann?
Oder meinst du eintragen, damit die nicht wieder verwendet werden,
ein Speichermanagament auf der Suche nach fehelerhaften Speicherstellen?
Dann einen ASIC Baustein und das System von Grund auf aufbauen oder
sich bei den NAND oder anderen Herstellergruppen über APP Note
schlaumachen, wie die es machen.
'ASIC' meine 2 ct ;-)
Für sowas gibts extra Mikrocontroller. Sieh dich mal im Raumfahrtbereich
um. Da musst du dann aber RICHTIG viel Geld in die Hand nehmen.
Auch wenn du "mehrmals rechnest" nutzt dir das unter Umständen nichts:
Auch der Programmcounter, die Stelle des Mehrheitsentscheids etc. können
betroffen sein.
Daher gibt es für RAM spezielle Codes (z.B. den Hamming-Code) mithilfe
dessen du Fehlerkorrektur betreiben kannst. Das gleiche gibts dann auch
nochmal für die Prozessorregister. Ansonsten ist der restliche Chip auch
mit Rad-Hard Technologie aufgebaut, d.h. es werden Zellen verwendet, die
weniger empfindlich auf Strahlung reagieren.
Du darfst außerdem nicht nur SEU (single event upsets, also bitkipper)
betrachten, sondern musst auch weitere Einflüsse (latchup etc.) mit
einbeziehen, falls ihr wirklich Strahlung habt.
Das Problem ist insgesamt deutlich komplexer als es hier zu beschreiben
ist. Kurz gesagt: Such dir Profis die sowas schonmal gemacht haben!
.. schrieb:> Soviel Eigenlob kenn ich nicht von dir -
Ein sauberes 8-Bit Layout ist doch kein Hexenwerk.
Konkret war es ein DS80C320 an 32MHz. Daten-/Adreßbus in der Mitte
geführt und die ICs rechts und links davon angeordnet, fertig.
Wer allerdings denkt, das kann der Autorouter auch, der ist schief
gewickelt.
Tüddel schrieb:> Wie sicherst du denn die Registerflips im µC durch Bestrahlung? Sind ja> auch nur "SRAM-Zellen". - Eine Methode ist Zeitliche Redundanz - Alles> mehrfach und Zeitlich versetzt durchführen und dann ein "Diff" über die> Einzelergebnisse ;-)
Exakt das ist eine Methode, ja. Theoretisch kann jedes FF in einem FPGA
betroffen sein, wenngleich das jeweils auch sehr unwahrscheinlich ist.
Mehrfach Dasselbe zu rechnen ist im FPGA sehr leicht in einer pipeline
zu machen.
Oder aber gleich Redundant! -> Ist ja ein FPGA, der ist ja predetiniert
für Parallelität!
Gibt sogar Generatoren/Optimierer dafür die in TMR generieren/umwandeln!
Sowol Actel/Microsemi als auch Xilinx haben soetwas...
Ein in dem Zusammenhang vielleicht noch ganz interessantes Paper dazu,
wie eine software-basierte Lösung zum Schutz vor strahlungsinduzierten
transienten Speicherfehlern aussehen kann und wie gut sie funktioniert
(getestet u.a. in einem Satelliten):
Philip P. Shirvani, Nirmal R. Saxena, and Edward J. McCluskey:
Software-Implemented EDAC Protection Against SEUs,
Stanford University Center for Reliable Computing
Technical Report No. 01-3, May 2001
http://www-crc.stanford.edu/crc_papers/CRC-TR-01-3.pdf
-- Michael
Gegen geladenen Teilchen kommt man mit groesseren Strukturen an, wo eine
Ladung nicht viel aendert. Gegen schwere Teilchen, wie Neutronen, die
die Struktur beschaedigen, die Kurzschluessen hervorbringen, wird's
schwierig.
Wieviel elektrische Leistung hat man, welche Strahlenmenge an welchen
Teilchen erwartet man, welche Rechenleistung benoetigt man.
Allenfalls geht auch ein analoger Roehrenrechner ?
Lars R. schrieb:> Ja, berücksichtigt werden müssen die auch. Aber deren Inhalt ändert sich> häufiger. Im Idealfall ständig. Es muss auch nicht jeder Treffer ein> Flipflop kippen. Wenn man aber den SRAM "länger" nicht "behandelt", so> steht nur noch Müll drin.
Die Wahrscheinlichkeit, dass ein bestimmtes Bit während einer bestimmten
Zeitspanne kippt, ist aber für alle Bits mit gleichen elektrischen
Eigenschaften gleich gross. Oft den Inhalt zu ändern, hilft da nicht.
Ich würde sogar sagen, dass oftmaliges Neu-Schreiben die
Wahrscheinlichkeit für ein Kippen sogar erhöht, da sich das Bit für eine
längere Zeitspanne in einem Übergangszustand befindet, wo es besonders
anfällig für Störungen ist.
Wenn also der Programm- oder Stackcounter getroffen wird, viel Glück -
da hilft keine softwaremässige Redundanz mehr.
Generell halte ich es für fragwürdig, warum der Controller funktioniert,
das SRAM hingegen dauernd Fehler produziert. Riecht für mich stark
danach, dass hier Fehler vorliegen, die man anderweitig wegdesignen
sollte als mit einem RAM-Check.
Vermutlich hat der Prof mal was von RAM-Test gehört und verlangt nun,
daß das irgendwie reingepappt werden soll.
Ein sicheres Design sieht anders aus.
Das fängt zuerst damit an, daß man das keinen Anfänger machen läßt,
sondern Leute, die schon mit solchen Projekten Erfahrung haben.
Sicherheit kann man nicht einfach aus ner Kiste nehmen und
drüberstülpen.
P. M. schrieb:> Generell halte ich es für fragwürdig, warum der Controller funktioniert,> das SRAM hingegen dauernd Fehler produziert. Riecht für mich stark> danach, dass hier Fehler vorliegen, die man anderweitig wegdesignen> sollte als mit einem RAM-Check.
Da hab ich doch schon in meinem ersten Post drauf hingewiesen...
Register sind auch blos RAM-Zellen...
Tüddel schrieb:> P. M. schrieb:>> Generell halte ich es für fragwürdig, warum der Controller funktioniert,>> das SRAM hingegen dauernd Fehler produziert. Riecht für mich stark>> danach, dass hier Fehler vorliegen, die man anderweitig wegdesignen>> sollte als mit einem RAM-Check.>> Da hab ich doch schon in meinem ersten Post drauf hingewiesen...> Register sind auch blos RAM-Zellen...
RAM Zellen sind viel kleiner und deswegen empfindlicher.
Es gibt ja nicht nur eine Sorte FF in einem Design, sondern man nimmt
die immer nur so gross wie nötig. Im SRAM sind die eher klein und sehr
dicht gepackt, so dass jedes Strahlungsteilchen auch trifft, im
Controller sind die meist grösser und auch nicht so dicht gepackt.
Besonders kritisch wird es dann, wenn das RAM als Programmspeicher
dient, da wird es ewig nicht neu beschrieben und ein Bitkipper kann dann
irgendwann zuschlagen, wenn die Speicherzelle ausgelesen wird. Und bei
Programmspeicher wird sie irgendwann ausgelesen. Bei FF im Controller
ist die Wahrscheinlichkeit, dass ein Bitkipper keine Auswirkung hat,
viel höher. Das Ganze hängt aber auch noch mächtig von der Technologie
ab, bei 90nm und 1,8V sind die FF recht stabil, bei 10nm und 1V sieht
das schon anders aus.
Gruss
Axel
Oder D. schrieb:> Gegen schwere Teilchen, wie Neutronen, die> die Struktur beschaedigen, die Kurzschluessen hervorbringen, wird's> schwierig.
Es gibt speziell dotierte Abschirmungen mit Materialien, die einen für
die spezifische Strahlung hohen Einfangquerschnitt haben.
P. M. schrieb:> Die Wahrscheinlichkeit, dass ein bestimmtes Bit während einer bestimmten> Zeitspanne kippt, ist aber für alle Bits mit gleichen elektrischen> Eigenschaften gleich gross. Oft den Inhalt zu ändern, hilft da nicht.> Ich würde sogar sagen, dass oftmaliges Neu-Schreiben
Die Mimik ist ja die, die RAMs mehrfach aufzuziehen und dann durch
Neuschreiben die defekten Infos zu korrigieren. Also ein
Mehrheitsentscheid.
Axel L. schrieb:> RAM Zellen sind viel kleiner und deswegen empfindlicher.
Das haben wir auch gefunden. Wenn es Fehler gab, waren die überwiegend
im RAM.
Peter D. schrieb:> Das fängt zuerst damit an, daß man das keinen Anfänger machen läßt,> sondern Leute, die schon mit solchen Projekten Erfahrung haben.
+1! D:
Reinhard S. schrieb:> werden, so dass man erkennt, ob Fehler entstanden sind. Die Fehler> entstehen durch starke Strahlung und sollen korrigiert werden.
Du sprichst das etwas zu gelassen aus. Es besteht nämlich ein
himmelweiter Unterschied zwischen "Fehler sollen erkannt werden" und
"Fehler sollen korrigiert werden". Ersteres ist vergleichsweise sehr
viel einfacher. Das sollte selbst dir klar sein.
> Der Microcontroller besitzt dazu aber nicht die geforderte Bandbreite,> wir hätte also Bedarf für einen zwischen-Chip, der das leisten müsste.
Unsinn. Was man braucht, ist in diesem Fall ein µc mit der geforderten
Bandbreite. Und nicht irgendwelche "Zwischen-Chips".
> Soweit mir bekannt, machen RAMs im Computer einen ECC - ich weiß aber> nicht, wer das auswertet und wie.
Gemeldet wird das per NMI-Interrupt. Behandelt wird es durch den
entsprechenden Handler des OS. Wobei "behandelt" z.B. auch einfach
bedeuten kann: "Bluescreen" of death. Was z.B. genau dann passiert, wenn
eben nur Fehlererkennung, nicht aber Fehlerkorrektur in diesem Handler
implementiert ist.
Letzteres ist einfach so komplex, dass man es nicht mal eben mit ein
bissel trivialer Logik implementieren kann, das würde mindestens einen
passend programmierten FPGA erfordern. Oder halt einfach einen
hinreichend leistungsfähigen µC.
Aaaber: wenn der RAM strahlungsbedroht ist, dann ist es wohl auch der
µC. Dann wird es erst richtig kompliziert...
Immer wieder süß wenn monatealte oder jahrealte Threads ausgebuddelt
werden :-P
"Wickelblei" ist schon innovativ :-P
Da könnte man das ganze auch in HF-Gehäuse eingloddern ;-)
OK verscuhen wir mal ernst zu bleibeb (ja ich weiß sit schon drei Jahre
alt).
Welche Art von Strahlung, Alpha, Beta, Gamma ?
ECC RAMs mit eigenen Controller gibt es mit Fheler erkennen, 1bit Fehler
beheben bis 3bit Fehler beheben und 4bit erkennen war glaube ich das
aktuellste.
Suchen könnte helfen aber ich bin genauso faul wie der Thread-Starter
:-P
Dann gäbe es noch die Variante SD-Karte in Alufolie verpackt und jedes
Datum mehrfach mit HASH versehen.
Wie funktioniert nochmal RAID6 ?
scherzkeks schrieb:> Wie funktioniert nochmal RAID6 ?
Nur sooo lange, bis der damit beschäftigte Contoller oder andere
GEMEINSAME Baugruppen keine Lust mehr zum funktionieren haben. Goto
Start 13.07.2015
scherzkeks schrieb:> Immer wieder süß wenn monatealte oder jahrealte Threads ausgebuddelt> werden :-P
Schön, dass sich nochmals ein jemand dazu geäussert hat. Ich lese die
Beiträge mit Interesse.
Ein kleines update an die Leser: Wie schon angedeutet, wurde ein
FPGA-Schaltkreis verwendet, der die Daten dupliziert, mehrfach speichert
und sich die richtigen heraussucht.
meckerziege schrieb:> Für sowas gibts extra Mikrocontroller. Sieh dich mal im Raumfahrtbereich> um. Da musst du dann aber RICHTIG viel Geld in die Hand nehmen.
Genau das wollte man nicht, bzw konnte man nicht.
Jürgen S. schrieb:> Und wie geht das dann mit der Sicherheit bei internen> Prozessorregistern?
Das ist eine gute Frage, muss ich sagen. Eine Frage, auf die ich keine
Antwort habe. Ich denke, dass man mit Störungen des Controllers leben
muss.
Es war aber auch so, daß die RAMs die kritischen Stellen waren.
Gfs ist es so, dass RAMs empfindlicher sind?
> Es war aber auch so, daß die RAMs die kritischen Stellen waren.
Theoretisch oder tatsächlich?
Wenn irgendein Computer (abgesehen vom Totalausfall) nicht tut, was er
soll, würde ich als allerletztes den Fehler beim RAM suchen. Das gilt
ganz besonders für Mikrocontroller jenseits der Gigahertz Welt.
c-hater schrieb:> Du sprichst das etwas zu gelassen aus. Es besteht nämlich ein> himmelweiter Unterschied zwischen "Fehler sollen erkannt werden" und> "Fehler sollen korrigiert werden". Ersteres ist vergleichsweise sehr> viel einfacher. Das sollte selbst dir klar sein.
Der Unterschied liegt im Hammingabstand der verwendeten Code-Worte und
Nutzung dieser Redundanz beim Auslesen, Paritätssicherung von Blöcken
ist eigentlich das Gleiche, nur strukturell anders angelegt.
Dann nimm halt einen µC der das kann was gebraucht wird und bastel nicht
extern noch was dran.
Wie willst du denn sicherstellen das die Verbindung von 8 Bitter zu FBGA
keine Fehler hat ?
Du brauchst einen µC mit ausreichend internem Ram.
Der folgendes Kann.
ECC auf RAM und Flash
ECC auf allen internen Bussen ; Daten-, Adress-, Peripherie-, ....
LockStep auf dem Rechenkern
Finden kann man sowas zb im Automobilbereich.
Also Automotiv Freigaben nach ASIL "D"
zb von
TI die HERCULES Reihe (TMS 570), das sind ARM Cortex Rx
Infineon die AURIX Reihe, das sind Tricore
Die sind zwar von der Rechenleistung im Vergleich zu dem 8 bitter etwas
übertrieben. Aber das ist in dem Fall egal, da bei der Anwendung andere
Kriterien gelten.
Nur, um das damalige Thema zu einem Abschluss zu bringen diese Info:
Das System mit dem FPGA funktioniert gut. Es wurden auf alle
Controllerfunktionen in den FPGA hineingenommen. Der Controller arbeitet
doppelt und existiert zweimal, d.h. das Problem eventueller Störungen
der Prozessorregister (der offene Punkt) ist damit entschärft.
Der neue Prozessor ist ein modifizierter NIOS. Er ist langsam, aber
sicher und gut zu überwachen.
Die ursprünglicher Frage mit dem sicheren RAM ist ebenso gelöst: Drei
Einheiten, die alle dieselben Daten in den RAMs haben und sich
austauschen, ob sie stimmen.
Eine Fehlfunktion läuft maximal einige Takte bis der Überwacher es
merkt.
Alle Ausgänge sind bis dahin verzögert und gegen nur GUTE Informationen
an das Leitwerk weiter.
