Strahlungsresistente Chips

Ein gewisse Abschirmung kriegt man mit etwas Blei, aber halt keine 
perfekte. Es ist halt eine Abwägung was günstiger bzw. leichter ist - 
etwas Abschirmung oder weniger Empfindliche Chips. Etwas lokale 
Abschirmung kann im Einzelfall (z.B. Empfindlicher Sensor) passen. Das 
Problem sind dabei vor allem die wenigen sehr Energiereichen Teilchen, 
die dann lokal im Chip recht viele Ladungspaare generieren. Das sind 
ggf. auch Neutronen, die sich im Weltraum nicht praktisch abschirmen 
lassen.

Je gröber die Strukturen, desto mehr Ladung braucht es um einen Chip zu 
stören. Die sehr Energiereichen Teilchen werden zunehmend seltener, so 
dass robustere Chips seltener Fehler zeigen - ganz auszuschließen sind 
sie aber nicht.

MaWin und Schreiberling haben ja schon die passenden Links gepostet.
Praxistipp: man sollte sitzen, wenn man sich die Chipsatzpreise 
anschaut.
:(

Normales altes Zeug lebt bei dieser Einsatzart manchmal etwas länger.
Die Finnen haben für dieses Projekt 
https://wiki.aalto.fi/display/SuomiSAT/Summary
AT91RM9200 MCUs verwendet, weil die aufgrund ihrer verhältnismäßig 
großen Strukturen etwas später sterben.
Deswegen haben sie Ihre Firmware auch vorletztes Jahr noch auf 
www.centipad.de - Hardware entwickelt. :)

Die Preise sind schon spannend. Wir hatten uns mal einen ollen Virtex 4 
FPGA anbieten lassen, da war der schon längst veraltet. Xilinx wollte 
knapp 100.000 Dollar pro Chip bei knapp 1,5 Jahren Lieferzeit. Ohne Rad 
hard kostet der ca. 300 Euro. Wir haben dann beim Fraunhofer Sat lieber 
nicht mit gemacht.

@supachris: Nur Neugierdehalber: habt Ihr die Flexibilität vom FPGA 
gebraucht? Wäre es billiger geworden, einen eigenen ASIC mit großen 
Strukturen zu züchten?

Was im Weltraum fast vorherrscht sind Protonen mit hohen kinetischen 
Energien. Das ist nicht einfach Ladung, die man auf Metall einsammelt, 
sondern die gehen durch bis sie irgendwo steckenbleiben. Die 
Elementarladung ist eigentlich vernachlaessigbar ausser bei kleinsten 
Strukturen. Es koennen aber Isolationsschichten zerschossen verden, die 
muessen daher etwas dicker sein. Die Feldstaerke ueber einer SiO2 
Isolationsschicht liegt bei konservativen 3V / 50nm = 60kV/mm . Zum 
Glueck ist keine Luft da, sonst gaebe es grad Koronaentladungen.

Marcus H. schrieb:
> @supachris: Nur Neugierdehalber: habt Ihr die Flexibilität vom FPGA
> gebraucht? Wäre es billiger geworden, einen eigenen ASIC mit großen
> Strukturen zu züchten?

Naja, es ging darum ein bestehendes (FPGA basiertes) System für den 
Heinrich-Hertz Satelliten umzubauen, aber da es da einfach zu wenig Geld 
gab, haben wir´s gelassen. Es wäre sowieso nur ein Einzelstück gewesen, 
und die Analog-Chips gabs sowieso nicht in rad hard.

Einen ASIC zu bauen kann sich doch heute eh kaum noch einer leisten. Da 
sind FPGAs deutlich preiswerter. Man muß halt mit der geringeren 
Integrationsdichte und Geschwindigkeit auskommen.

Zoe

Hallo,

6A66 schrieb:
> OT: Ja das habe ich auch schon mitbekommen, ist aber von TÜV zu TÜV
> unterschiedlich. Wird IMHO absolut überbewertet wer sich in die Thematik
> einarbeitet. Softerrors könnten (absoluter Konjunktiv) nur durch
> Alpha-Strahlung entstehen durch Zerfälle im Mold-Compound, also der
> Gehäusemasse. Da die Alpha-Strahlung auch durch geringe Materialdicken
> von dichteren Materialien oder Papier bereits abgeschirmt werden kann
> ist fraglich, inwiefern diese Strahlung die Passivierung der Chips
> durchdringen kann. Wichtig ist da eher die enstrepechenden Fehler zu
> finden und dafür die Selbsttests ausreichend gut zu gestalten. Ist auch
> schon etwas aus der Mode.

Also das "könnten (absoluter Konjunktiv)" solltest Du in "können 
(absolute Sicherheit)" ändern - ich weiß aus zuverlässiger Quelle, dass 
erst vorletztes Jahr ein bekannter Hersteller seine Kunden angesprochen 
hat, dass bestimmte Chargen seiner Produkte eine (deutlich) erhöhte 
Softerror-Rate haben, da das Gehäusematerial höhere 
Alpha-Strahlungswerte als erwartet aufwies. Die Bare-Die-Versionen waren 
naturgemäß nicht betroffen.

In sicherheitsrelevanten Anwendungen werden deswegen sehr häufig bis 
praktisch immer Hardwaremaßnahmen zur Speicherüberwachung verwendet 
(Parity oder ECC), da Softwaremaßnahmen (z.B. Selbstteste) in der Regel 
nicht den benötigten diagnostischen Deckungsgrad aufweisen.

Nur um einmal eine Größenordnung zu nennen: Bei einem µC mit 256 kByte 
RAM wurde mir einmal eine Soft-Error-Rate von einem Doppelbit-Fehler pro 
32-Bit-Word alle 68 Betriebsjahre angegeben (also durch Parity alleine 
nicht entdeckbar). Klingt erst einmal selten, wenn man allerdings 1 Mio 
Einheiten im Auto im Feld hat, bedeutet das, dass mit rund 1800 
Doppelbit-Softerror pro Jahr zu rechnen ist - und jeder davon löst einen 
Reset des Steuergerätes aus (da nicht korrigierbar).

Dies ist sicherlich eine Worst-Case-Annahme, zeigt jedoch, warum überall 
dort, wo es darauf ankommt, mit ECC & Co gearbeitet wird (schönes 
Beispiel: Die Profi-Rechenkarten von AMD & NVIDIA haben im Gegensatz zu 
den sonst praktisch gleichen Spiele-Grafikkarten ECC zur 
Speicherüberwachung). Aus der Mode gekommen ist das also sicher nicht.

Schöne Grüße,
Martin

Ganz nett geschrieben:
http://www.jhuapl.edu/techdigest/TD/td2801/Maurer.pdf

@Zoe - da war der MaWin wieder schneller. :)
Es war noch nie so billig wie heute einen eigenen ASIC zu bauen. Das 
haben wir schon im letzten Jahrtausend als Diplomarbeiten vergeben. Als 
Designtool gab's damals ein aufgebohrtes TARGET. würg

Hallo,

Gustav schrieb:
> Martin L. schrieb:
>> da Softwaremaßnahmen (z.B. Selbstteste) in der Regel
>> nicht den benötigten diagnostischen Deckungsgrad aufweisen.
>
> Blödsinn. DC=hoch ist kein Problem.
>
> Problem ist die Zeit, die das frißt. Deswegen ist Hardwareunterstützung
> attraktiv, aber aus Kostengründen dennoch nicht unbedingt verbreitet.

 - warum muss hier eigentlich immer einer beleidigend werden ? -

Egal: Ja, ich hätte es wohl genauer spezifizieren müssen: Bei meinen 
(also Automotive) üblichen Anwendungen können Softwaremaßnahmen den 
benötigten diagnostischen Deckungsgrad nicht in der gegebenen 
Prozess-Sicherheitszeit darstellen - eine einmalige Überprüfung der 
Variablen pro Zeitscheibe ist zwar möglich (um die Unabhängigkeit 
zwischen Software-Partitionen zu gewährleisten), eine Überprüfung bei 
jedem Zugriff (die für einen hohen DC notwendig wäre) oder eine 
komplett-redundante Berechnung jedoch nicht. Und die an sich 
angesprochenen periodischen Selbstteste sind ebenfalls nicht mit der 
notwendigen Frequenz (alle Teste müssten innerhalb der kürzesten 
Prozess-Sicherheitszeit ggf. mehrfach ablaufen) implementierbar.

Auch ist mir keine SIL3 / ASIL C-D-Anwendung bekannt, bei der der 
Prozessor nicht ECC-geschützten Speicher hätte. Häufig werden dann noch 
Selbstteste zusätzlich implementiert, um die Latentfehlerrate zu 
reduzieren, da die ECC-Unit in der Regel erst bei Zugriff einen Fehler 
meldet. Als alleinige Maßnahme hingegen würde kein mir bekannter OEM 
(und das sind über ein Duzend) dies für ASIL C oder D akzeptieren.

Schöne Grüße,
Martin

Marcus H. schrieb:
> @Zoe - da war der MaWin wieder schneller. :)
> Es war noch nie so billig wie heute einen eigenen ASIC zu bauen. Das
> haben wir schon im letzten Jahrtausend als Diplomarbeiten vergeben. Als
> Designtool gab's damals ein aufgebohrtes TARGET. *würg*

Ich weiß nicht wo meine Antwort von vor dem Mittagessen hier ist, aber 
egal.

Es geht ja hier nicht darum, irgendein ASIC zu bauen, sondern eines in 
einer strahlungstoleranten Ausführung und meist auch in einer Größe und 
Komplexität, die man eben nicht in einem FPGA unterbringt. Da gibt und 
gab es nun mal nicht so arg viele Hersteller / Foundries und deren 
Preise sind ordentlich, nicht zuletzt deswegen hatte die ESA auch das 
Prinzip des Multi-Project-Wafers verfolgt.

Einen commercial naked die mit einem Hi-Rel strahlungstolerantem 
Komplettchip zu vergleichen hinkt etwas.

Zoe

Hi Zoe, dann lass Dir Suchen helfen:
Anja zoe Christen schrieb:
> Einen ASIC zu bauen kann sich doch heute eh kaum noch einer leisten. Da
> sind FPGAs deutlich preiswerter. Man muß halt mit der geringeren
> Integrationsdichte und Geschwindigkeit auskommen.
>
> Zoe

Deine Aussage war recht pauschal, darauf war auch meine Antwort 
abgestimmt. :)

Ich denke, wir sammeln hier doch schon einige recht interessante Ansätze 
zu dem Thema, aus denen man sich für die jeweilige konkrete Anwendung 
was zusammensuchen kann.
Primäre Entscheidungsparameter sind wohl:
Dosis, Lebensdauer, Anwendung, Budget.

Cheerio,
 Marcus

P.S.:
Der Auftraggeber darf sich zwei dieser drei Punkte aussuchen: 
"pünktlich", "funktioniert", "billig".

Meine Kunden wählen meistens zweimal "billig".

Marcus H. schrieb:

> Deine Aussage war recht pauschal, darauf war auch meine Antwort
> abgestimmt. :)

Klar, dafür haben wir ja im Threadtitel den Rahmen gesetzt :-)

> Ich denke, wir sammeln hier doch schon einige recht interessante Ansätze
> zu dem Thema

Auf jeden Fall. Mein Eindruck ist jedoch irgendwie, je mehr im 
kommerziellen Bereich geht, desto weniger geht im HiRel (insbes. 
Raumfahrt). Aber I might well be mistaken.

> Der Auftraggeber darf sich zwei dieser drei Punkte aussuchen:
> "pünktlich", "funktioniert", "billig".
>
> Meine Kunden wählen meistens zweimal "billig".

:-)

Das ist ja immerhin noch besser als dreimal "pünktlich", vor allem, wenn 
die endgültige Spec erheblich verspätet kommt oder sich - noch besser - 
nach dem logic review nochmal wesentlich ändert.

Zoe

Gustav schrieb:
> Martin L. schrieb:
>>  - warum muss hier eigentlich immer einer beleidigend werden ? -
>
> Warum fühlt sich eigentlich immer jemand beleidigt, obwohl weit und
> breit keine Beleidigung zu sehen ist?

Naja, vermutlich, weil man sich im realen Leben schon Beleidigt fühlt, 
wenn jemand eine eigene Aussage als "Blödsinn" bezeichnet (man hätte ja 
auch sagen können: "Kenne ich anders"...)

> Mir sind nur solche SIL3-Anwendungen bekannt.
>
> Das ist allerdings Industrie- und Prozeßautomation.

Interessant; über welche Prozess-Sicherheitszeiten und welche 
Komplexität (Anzahl abzusichernder Gefahren) reden wir dann? Bei mir 
geht es runter bis 50 ms (20ms in Spezialfällen) bei 10 bis 15 
abzusichernden Gefährdungen (jede mit 6 bis 10 auszuwertenden 
Eingangssignalen und dazugehörender Situationserkennung). Dazu kommt 
dann die Eigenabsicherung des Rechners (Instruction Test, AD-Check,...) 
Das ganze dann neben der eigentlichen Funktionalität. Und um den Bogen 
zum eigentlichen Thema zu schlagen: Ähnliche Komplexität würde ich auch 
in einer Raketen/Satellitensteuerung erwarten.

Hinzu kommt dann natürlich, dass die IEC61508 auf wenige Einzelstücke 
ausgelegt ist, während die ISO26262 auf Millionenstückzahlen 
spezialisiert ist. Entsprechend lassen sich die Auswirkungen von 
Soft-Errors in Industrieanlagen natürlich deutlich weniger häufig 
beobachten als im Automotive-Bereich. Dafür können die Auswirkungen 
allerdings erheblich größer sein - insofern entspricht die 
Raumfahrtapplikation hier mehr der Industrieapplikation.

Schöne Grüße,
Martin