mikrocontroller.net

Forum: FPGA, VHDL & Co. Microcontroller-Sicherheit in MIL-Systemen durch FPGAs erhöhen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer entwickelt uc-applikationen im MIL-Bereich?

Mich würde interessieren, was hier im Bereich der Anforderungen schon 
umgesetzt wurde und wird. Vor allem im Bezug auf Ersatz von Controllern 
durch FPGAs.

Beispiel hier:
http://www.elektroniknet.de/halbleiter/sonstiges/artikel/99055/

Wie geht man mit den Validierungsanforderungen bei existenter, zu 
portierender Software um?

Autor: Vakuum (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Habe ich mal...
Jetzt eher "Hoch-Vakuumanwendungen im dunken Raum" ;-)

Eigentlich "erstetzt" man nicht! Es wird einfach 100Jahre lang genau so 
gebaut, wie es qualifiziert wurde - mit den selben Teilen und der selben 
Software. Man kauft gleich alles für mehrere Jahre Produktion ein und 
Lagert dies ein.

Für Code gibt es Guidlines (und zwar viele - eine der bekanntesten 
sollte wohl MISRA sein) und zugelassene Compiler wie auch Sprachen (z.B. 
Ada) - wir hatten noch einen "Analyser" für Codes der die Guidlines 1:1 
gegengecheckt hat.

Für FPGAs gibt es spezielle Typen, die lange lieferbar sind und 
spezielle Anforderungen erfüllen (Temperatur, Oberflächenbeschichtung, 
Latchup-Verhalten, Verschlüsselung,...).

Und zur Not: Teste alles bis zum erbrechen auf Tauglichkeit, teste alles 
bis du weißt wo die Grenzen deines Device sind (und ja, teste auch bis 
zur Zerstörung - auch das ist eine Grenze).

Mit diesem Thema kannst du mehrere Doktorarbeiten füllen und dann deckst 
du nur ein paar Promill des Themas ab!

Autor: Oliv-Grüner Bereich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg B. schrieb:

> Mich würde interessieren, was hier im Bereich der Anforderungen schon
> umgesetzt wurde und wird. Vor allem im Bezug auf Ersatz von Controllern
> durch FPGAs.


Wühl dich mal durch die STANAG's:

https://en.wikipedia.org/wiki/Standardization_Agreement

Wenn's MIL auch fliegen soll dann schau dir mal DO-254 und DO-178 an.

Autor: Nicht-mehr-Militone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg B. schrieb:
> Wie geht man mit den Validierungsanforderungen bei existenter, zu
> portierender Software um?

Jede Firma hat da so ein bisschen ihre eigenen Anforderungen, neben dem, 
was inzwischen gesetzlich geregelt ist. Hat sehr viel damit zu tun WAS 
die jeweils herstellen.

Bei Software waren die Bestimmungen ab Schärfsten. Teilweise gab es 
zeilenweise Code Reviews mit 6 Augen-Prinzip (Entwickler, Co-Entwickler 
als Prüfer und ein Co-Prüfer, als Überwacher des formellen Prozesses). 
Geprüft wurden die formellen guide lines, die Inhaltlichen Erläuterungen 
und vor allem die Bezüge zu den Anforderungen.

Nett fand ich, dass das später in einer anderen Firma, die (aus meiner 
Sicht) "gefährlichere" Geräte hergestellt haben, lockerer gehandhabt 
wurde. Gedrückt und geprüft werden gerne die Zulieferer, während man bei 
eigenen Abteilungen weniger streng ist. Außerhalb der Branche habe ich 
das z.B. genau umgekehrt erlebt: Die Internen haben gestöhnt, weil ihnen 
die QM die Hölle heiß macht, aber das, was von Extern eingekauft wurde, 
ist durchgewunken worden, weil die ja die Einhaltung der Prozesse im 
Vertrag hatten und es nicht von Außen geprüft werden kann, ob sie es 
wirklich auch machen.(?)

Autor: J. S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht-mehr-Militone schrieb:
> aber das, was von Extern eingekauft wurde,
> ist durchgewunken worden, weil die ja die Einhaltung der Prozesse im
> Vertrag hatten und es nicht von Außen geprüft werden kann, ob sie es
> wirklich auch machen.

Das hört sich aber etwas schräg an. Warum sollte nicht geprüft werden 
können, wie Externe und Zulieferer arbeiten? Ok, wenn jemand nur 
behauptet, nach Standards zu arbeiten und es dann nicht tut, ist 
zunächst wenig zu machen, aber ohne dokumentierte Prozesse und Vorgänge 
fliegt der eben irgendwann zwangsläufig durchs Audit. Zudem empfehlen 
sich Kundenaudits bei neuen Zulieferern. In bestimmten Branchen und 
Feldern sind die auch vorgeschrieben.

Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht-mehr-Militone schrieb:

> Bei Software waren die Bestimmungen ab Schärfsten. Teilweise gab es
> zeilenweise Code Reviews mit 6 Augen-Prinzip (Entwickler, Co-Entwickler
> als Prüfer und ein Co-Prüfer,

Gilt die FPGA-Entwicklung bei euch dann auch als Softwareentwicklung?

Autor: Oliv-Grüner Bereich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg B. schrieb:
> Nicht-mehr-Militone schrieb:
>
>> Bei Software waren die Bestimmungen ab Schärfsten. Teilweise gab es
>> zeilenweise Code Reviews mit 6 Augen-Prinzip (Entwickler, Co-Entwickler
>> als Prüfer und ein Co-Prüfer,
>
> Gilt die FPGA-Entwicklung bei euch dann auch als Softwareentwicklung?

Um diese Spielchen, "Wenns mir als sicher Software zu teuer in der 
Entwicklung ist, dann schiebs ichs halt auf einen FPGA" zu beenden, 
wurden zwei Standards geschaffen der DO-178 und DO-254. Die haben dann 
ähnliche Anforderungen je nach Sicherheitslevel aka DAL.

Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mir bekannt. Sehr richtig! Allerdings drücken sich da ja wieder 
viele drum herum, dass sie FPGAs als HW einstufen und dann als 
Elektronik validieren. Genauer: Gar nicht validieren sondern einfach 
mittesten.

Autor: Oliv-Grüner Bereich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
G. B. schrieb:

>  dass sie FPGAs als HW einstufen und dann als
> Elektronik validieren. Genauer: Gar nicht validieren sondern einfach
> mittesten.

Hm, interessante Zusammenfassung, was fehlt neben dem Mittesten Deiner 
Meinung nach das die Validierung komplett ist?.

-Simulation mit spezifizierten Testvektoren?
-Papierkram alla Systemarchitektur etc (die sollte es aber unabh. von 
Hard/Soft geben)?
-FMEA für die Hardware alleine?
-Diagnosekonzept?

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,


G. B. schrieb:
> Das ist mir bekannt. Sehr richtig! Allerdings drücken sich da ja wieder
> viele drum herum, dass sie FPGAs als HW einstufen und dann als
> Elektronik validieren. Genauer: Gar nicht validieren sondern einfach
> mittesten.

Das empfinde ich ab einem gewissen Punkt etwas fahrlässig, nämlich dann, 
wenn eine Soft-CPU im FPGA Code ausführt. Höre aber obiges auch immer 
wieder ("Gilt als Hardware"). Aber mit Verlaub, NIOS/uBlaze und 
Konsorten scheinen mir nicht weit genug validier/verifizierbar...
Die Thematik ist generell für den Safety-Bereich interessant, auch wenn 
die Anforderungen viel niedriger liegen. Aber auch da kommt es mir vor, 
dass teils übelst gefrickelt wird und die TüV-Anforderungen in einer 
Farce münden.

Oliv-Grüner Bereich schrieb:
> -Simulation mit spezifizierten Testvektoren?

Damit kann man alle erwarteten Szenarien abdecken. Aber ich will u.U. 
bei einer CPU auch sehen, wie sie auf Störungen reagiert ("Was, wenn auf 
dem Stack ein Bit kippt").
Mich würde mal interessieren, wie die "Grossen" das machen. Gibt sicher 
Simulatoren, die generell überall Fehler injizieren können, aber das ist 
nicht meine Liga..
Es gibt zu einigen Architekturen Papers, aber die gingen mir teils nicht 
weit genug bzw. fallen bei mir unter "akademische Träumerei".

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Gibt sicher
> Simulatoren, die generell überall Fehler injizieren können, aber das ist
> nicht meine Liga..

Mit VHDL-2008 kann man problemlos Bits kippen lassen (external names und 
force release). Geht zumindest mit ModelSim SE 10.1.

LG

Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Szenarien muss man aber auch erst mal herstellen und welche 
Bitkippfehler will man da annehmen?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beispielsweise State Machines, da es so zu einem Hangup in einem 
illegalen State kommen kann. Spezielles FSM Encoding mit Hamming 
Distance 3 oder so... und wenn ein SEU detektiert wird, wird in einen 
bekannten, definierten und sicheren Zustand gewechselt.
Ansonsten werden RAMS mittels ECC oder Ähnliches geschützt.

Es hängt immer vom Design ansich ab, wie und ob man etwas schützt. 
Komplett im Detail weiß ich es allerdings auch nicht (im Sinne einer 
universalen Antwort). Teilweise IMO auch schon unsinnige Punkte gehört 
bzgl Hangups.

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Matthias schrieb:
> Strubi schrieb:
>> Gibt sicher
>> Simulatoren, die generell überall Fehler injizieren können, aber das ist
>> nicht meine Liga..
>
> Mit VHDL-2008 kann man problemlos Bits kippen lassen (external names und
> force release). Geht zumindest mit ModelSim SE 10.1.
>

Ja, schon. Aber trotzdem musst du das programmieren, und für 
"vektorisierte Angriffe" bei der Komplexität einer CPU bist du da massiv 
beschäftigt. Ich kann nur sagen, dass ich bei einer etablierten offenen 
32-Bit-Opcode Architektur das Handtuch geschmissen habe und im 
VHDL-Ansatz nicht wirklich ein realistisch absehbares Ende der Aktion 
gesehen habe.
Im konkreten Anwendungsfall ging es um 8-Bit-Opcodes, die schon mal 
einiges an Komplexität rausnehmen. Aber wenn man da nun alle 
Coverage-Szenarien für random gekippte Bits in zwei beliebigen 
aufeinanderfolgenden Befehlen haben will, rödelt "der Gerät" schon 
nächtelang. Wie soll das dann erst bei einem ARM mit deutlich 
komplexeren Zuständen und ev. fehlerhaften Registern ausarten?

Autor: J. S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt Verfahren, solche Schaltungen auf Fehler hin zu untersuchen, 
indem man abstrakte Testmustermengen auf der Basis von 
Fehlersimulationen generiert (DALGO) und optimiert. Diese eignen sich 
grundsätzlich auch zur Beobachtung von Fehlern, die während des Betriebs 
entstehen, wenn man einen Teil der Fehlervektoren als Freiheitsgrad 
(Einfluss von Usern und Physik, EVM) vorsieht.

Die Problematik ist aber immer die der Effizienz: Bei der Programmierung 
von FPGAs kann und muss man annehmen, dass die Fehler überwiegend 
infolge von Nichtbeachtung der möglichen use cases and false cases 
entstehen, also Designfehler sind. Die daraus entstehende Vielfalt an 
Fehlern ist sehr schnell in einem Bereich, der nicht mehr gänzlich 
testbar ist.

Es bleibt also oft nichts über, die Grenzen für Validierung, 
Verifikation und Test entsprechend der Möglichkeiten längst durchs 
System zuziehen und gewisse Fehler einfach im Rahmen der funktionellen 
Tests abzufangen, statt unten alles zu simulieren.  Viele andere, 
theoretische muss man FMEA-mässig fangen, d.h. mit Redundanz und 
Sicherheitsfunktionen unterlegen, die allemöglichen Massen an Fehlern 
auf den unteren Ebenen der Komponenten zusammenfassend behandeln und 
"oben" funktionell erledigen.

Daher auch das ansteigende Thema "Funktionelle Sicherheit".

Konkret simuliert man also nicht alle erdenklichen Fehler bei einem 
RAM-Zugriff eines Controllers durchs FPGA aufs DDR durch sondern ersinnt 
eine Strategie, wie man im Betrieb sicherstellt, dass man Daten auf 
unterschiedliche Weisen und Wegen erhält und plausibilisiert, also immer 
annimmt, dass ein Fehler aufgetreten sein könnte.

Klassisches Verfahren für kippempfindliche Bits gepaart mit mieser 
Übertragungskette: Daten zweimal (gfs invers) speichern und mehrfach 
lesen und übertragen. Dann werden auch Strahlungseinflüsse, 
Fehltaktungen und gerade kaputtgehende RAMs oder EEPROMs abgefangen.

Von der früher propagierten tatsächlichen Sichermachung der 
Übertragungswege, in der Hoffnung, hohe Sicherheiten zu erzielten, hat 
man sich heute weitestgehend verabschiedet. Maßgeblich ist die FMEA, die 
ausweist, mit welcher Wahrscheinlichkeit am Ende überhaupt noch ein 
Fehler auftauchen kann. Man zeigt, dass der Fehler tolerierbar ist, 
abgefangen wird oder im Rauschen untergeht, bzw. keinen Schaden 
anrichtet, oder eben alle Jubeljahre mal auftritt.

Absolut sichere Elektronik-Systeme gibt es heute nicht mehr.

: Bearbeitet durch User
Autor: J. S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Strubi schrieb:
> Das empfinde ich ab einem gewissen Punkt etwas fahrlässig, nämlich dann,
> wenn eine Soft-CPU im FPGA Code ausführt.

Ich denke, nicht nur dann. Schon das Vorhandensein von state machines, 
die von äußeren Faktoren abhängig sind, sind als Software zu werten, 
wobei man korrekterweise so agieren sollte, wie oben beschrieben: 
Fehlereinflussanalyse! Eine zyklische FSM im FPGA ist auch bei vielen 
Verzweigungen definitiv sicherer, als ein SW-Ablauf gleicher Funktion 
auf einem Controller mit z.B. einem Echtzeitsystem, wenn zudem noch 
andere Prozesse laufen. Das muss man halt genauer ansehen.

> Höre aber obiges auch immer wieder ("Gilt als Hardware").
Ja, Ich habe selber schon vor etlichen Jahren ein Design deshalb in 
einen FPGA geschoben, weil er damit als HW galt und einfacher 
validierbar war. Das Ding ging aber auch in einen ASIC und hatte dann 
HW-Qualität. D.h. ein eindesignter Fehler war drin und verifizierbar und 
andere gab es nicht. Der ASIC säuft nicht ab :-)

Inzwischen gibt es aber auch in der FPGA-Thematik dieselben 
Anforderungen und das ist auch richtig so!

> Aber mit Verlaub, NIOS/uBlaze und
> Konsorten scheinen mir nicht weit genug validier/verifizierbar...
Das wäre dann sogar ein negativer Punkt! Ich meine aber, dass NIOS etc 
so gut getestet sind, dass sie mindestens so unanfällig sind, wie 
aktuelle Controller. Vor allem sind gut simulierte NIOS, die nicht 
verändert werden, definitiv mal sicherer, als neue gerade eingeführte 
Controller.

Das Problem ist halt die SW und da sind die tools im FPGA-Bereich noch 
nicht so weit, wie die im SW-Bereich. Ich denke, man kann behaupten, 
dass man eine normale 8Bit-SW extern besser und schneller sicher 
bekommt, als eine Microblaze-SW.  Damit hängt es wieder am Endtest!

> Die Thematik ist generell für den Safety-Bereich interessant
Die Hersteller haben ja deshalb reagiert: Genau deshalb gibt es ja einen 
ARM im FPGA, um die SW extern unterstützt entwickeln zu können und 
gleichzeitig eine eingeführte Architektur zu haben. Die Mechanismen zur 
Sicherstellung von SW können direkt angewendet und übertragen werden.

Lustigerweise führt das bei nicht wenigen Firmen zu der falschen 
Schlussfolgerung, man könne durch Verlagerung der Funktion vom FPGA in 
den ARM eine erhöhte Sicherheit und Testbarkeit erzielen. Das ist nicht 
der Fall. Die maximale Sicherheit im FPGA ist nach wie vor höher. Nur 
ist die gleiche Sicherheit in der CPU mitunter preiswerter und schneller 
erreichbar.

> Aber auch da kommt es mir vor,
> dass teils übelst gefrickelt wird und die TüV-Anforderungen in einer
> Farce münden.

Ja, klar, wo ein Schlupfloch, da ein Nutzer. Man geht immer den 
preiswertesten Weg. Aber wie gesagt: Die noch vor Jahren existierenden 
Schlupflöcher sind ja überwiegend gestopft.

Interessant ist, dass sich seit dem auch die SW-QM-Leute vermehrt für 
die FPGAs interessieren, wo sie zuvor noch lieber nichts vo wissen 
wollten und froh waren, dass es eine black box gibt, wo  man 
Testanforderungen verstecken konnte :-)

: Bearbeitet durch User
Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Lustigerweise führt das bei nicht wenigen Firmen zu der falschen
> Schlussfolgerung, man könne durch Verlagerung der Funktion vom FPGA in
> den ARM eine erhöhte Sicherheit und Testbarkeit erzielen. Das ist nicht
> der Fall. Die maximale Sicherheit im FPGA ist nach wie vor höher. Nur
> ist die gleiche Sicherheit in der CPU mitunter preiswerter und schneller
> erreichbar.

Also ARM läuft bei mir unter höchst unsicher. Die Architektur macht bei 
gekippten Registerbits schnell "garbage in, garbage out", ohne dass der 
Fehler als solcher registriert wird. Man kann natürlich alles mit 
CRC-Checks zukleistern, aber da irgendwo eine Abfrage in SW gemacht 
wird, ist sie teils für die Katz, wenn ein gekipptes Bit ein "true" 
suggeriert.
Auch bei NIOS bin ich von der Komplexität her skeptisch. Bei einem 
8051-Core sieht's schon anders aus und mit der ZPU-Architektur 
(Stackmachine) lassen sich interessante Sachen machen.
Meist sind auch die meisten Watchdog-Applikationen der Art vom 
Safety-Betrieb-Aspekt her ausreichend.
Nur mit dem ganzen IoT-Hype-Krempel werden wir derart mit 
netzwerkfähigen Geräten vollgemüllt, die nach irgend einer gezielten 
Attacke auf die Architektur schreien. Insofern wären auch langsam mal 
bei Industriegeräten ein paar Safety-Aspekte wünschenswert, und zwar 
welche, die über MISRA und wie sie alle heissen hinausgehen. Nur stellt 
sich nach wie vor die Frage, wie sich das die 
Consumer/Enterprise-Branche leisten kann, ohne sich an Tools vom grossen 
M oder C zu verausgaben.

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Matthias schrieb:
> Beispielsweise State Machines, da es so zu einem Hangup in einem
> illegalen State kommen kann. Spezielles FSM Encoding mit Hamming
> Distance 3 oder so... und wenn ein SEU detektiert wird, wird in einen
> bekannten, definierten und sicheren Zustand gewechselt.
> Ansonsten werden RAMS mittels ECC oder Ähnliches geschützt.

Das ist leider nur ne kleinteilige Lösung, bitfehler in nicht per ECC 
oder ähnlichen geschützten kann man so nicht erkennen, beispielsweise in 
Registern mit Parametern oder in den Konfigurations-SRAM selbst.

Da passt IMHO Vervielfacher/Comperator-Ansatz besser:

Mehrfache Instanziierung des Designs/Softcore und Überwachung der 
Designsoutputs der einzelnen Instanzen miteinanader durch einem 
Vergleicher. Differiert der Output der Instanzen, verhält sich wohl eine 
Instanz nicht mehr deterministisch und ein fail safe wäre angebracht.

G. B. schrieb:
> Diese Szenarien muss man aber auch erst mal herstellen und welche
> Bitkippfehler will man da annehmen?

Gängig ist da SEU Single Event Upset.
https://en.wikipedia.org/wiki/Single_event_upset

"Herstellung eines solches Szenarios" macht man per "Error Injection". 
Das geht beispielsweise wenn man in der Netzliste alle FF durch 
spezielle Shadow-FF-Paare ersetzt und die dann zu einem langen 
Schieberegister wie beim Scanpath verbindet.
http://publications.eas.iis.fraunhofer.de/papers/2000/016/slides.pdf

Neben diese technischen Methoden setzt man auch gerne Organisatorische 
Massnahmen ein: Man definiert also Prozesse und Vorgehensweise bei deren 
Befolgung davon auszugehen ist, das die meisten Fehler entdeckt werden. 
So macht es jedenfalls die DO-254.
https://en.wikipedia.org/wiki/DO-254

"Die DO-254 enthält Leitlinien zur Qualitätssicherung bei der 
Entwicklung elektronischer Hardware zur Gewährleistung einer sicheren 
Funktion. Sie bietet einen Rahmen von Überlegungen für die 
Zertifizierung der gesamten  Entwichlung" aus:
http://www.2solution.de/knowlede/15-do-254-eine-einfuehrung.html

-> es wird also nicht das Design als sicher qualifiziert, sondern das 
Design-Team und desen etablierten Prozesse.

: Bearbeitet durch User
Autor: Markus K. (markus-)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Strubi schrieb:
> Also ARM läuft bei mir unter höchst unsicher. Die Architektur macht bei
> gekippten Registerbits schnell "garbage in, garbage out", ohne dass der
> Fehler als solcher registriert wird.

Den Cortex-R5 Dualcore im Xilinx Zynq Ultrascale kann man im Lockstep 
betreiben, dann sollte sowas auffallen. Der A53-Quadcore hat ECC auf dem 
Speicher/den Caches, aber was mit den Registern ist, das steht nicht 
dabei.

Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Nur mit dem ganzen IoT-Hype-Krempel werden wir derart mit
> netzwerkfähigen Geräten vollgemüllt, die nach irgend einer gezielten
> Attacke auf die Architektur schreien. Insofern wären auch langsam mal
> bei Industriegeräten ein paar Safety-Aspekte wünschenswert, und zwar
> welche, die über MISRA und wie sie alle heissen hinausgehen.

Gab es schon. Nur will der normal-Kunde nicht immer für zusätzliche 
Sicherheit zahlen.

Fpga K. schrieb:
> Das ist leider nur ne kleinteilige Lösung, bitfehler in nicht per ECC
> oder ähnlichen geschützten kann man so nicht erkennen, beispielsweise in
> Registern mit Parametern oder in den Konfigurations-SRAM selbst.

Man kann auch 2-3 normale Hardware-CPUs verwenden und mit diskreter 
Logik eine Fehlerüberwachung aufbauen. In vielen Fällen ist das 
wirtschaftlicher wie die Verwendung spezialisierter Bauteile.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> Das ist leider nur ne kleinteilige Lösung, bitfehler in nicht per ECC
> oder ähnlichen geschützten kann man so nicht erkennen, beispielsweise in
> Registern mit Parametern oder in den Konfigurations-SRAM selbst.

Parameter kann man schon per CRC schützen. FPGA-Konfig zB wurde mal 
geschützt durch Flash basierte FPGAs. SEU Anfälligkeit hängt von den 
Strukturgrößen ab und ich habe gehört, dass BRAMs meist kleinere 
Strukturen hat als Distributed RAM und deshalb ECC geschützt wird. Aber 
wie gesagt: Experte bin ich keiner, aber doch schon in DO-254 Projekten 
mitgearbeitet und von Kollegen aus anderen Space/DO-Projekten ein 
bißchen mitbekommen ☺

Matthias schrieb:
> Es hängt immer vom Design ansich ab, wie und ob man etwas schützt

Und auch von den Systemanforderungen. Die Redundanz wird dann oft dort 
implementiert. Im Falle von kompletten SoCs wird vermutlich eine TMR 
einfacher sein.

Was mich wundert ist, warum immer die Rede von SEU ist und nicht auch 
MEU. Und wenn jedes gekippte Bit (im FPGA) immer erkannt werden muss, 
ist das schon ein sehr spezielles Requirement und sollte mMn in einem 
Layer oberhalb gemacht werden.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias schrieb:
> ich habe gehört, dass BRAMs meist kleinere
> Strukturen hat als Distributed RAM und deshalb ECC geschützt wird.
Das ist eher so zu interpretieren, dass bei RAMs gerne mal ECC betrieben 
wird. Daher bieten die gerne noch ein Bit mehr an, je Register.

Bei distributed RAM kann man das gar nicht vorsehen, weil dieses RAM ja 
nur aus FFs zusammengebastelt wird. Ob man da ECC nutz, hängt von der 
Implementierung ab. Geht natürlich ohne Weiteres.


> Was mich wundert ist, warum immer die Rede von SEU ist und nicht auch
> MEU. Und wenn jedes gekippte Bit (im FPGA) immer erkannt werden muss,
> ist das schon ein sehr spezielles Requirement und sollte mMn in einem
> Layer oberhalb gemacht werden.
Das macht nicht wirklich Sinn. Da ist es besser, die Funktion zu 
schützen indem man es überwacht. Extra noch HW vorzusehen, wäre viel zu 
teuer. Solche Spezialanforderungen hat eh kaum einer.

Die meisten haben Datenverarbeitungssysteme und da kann man input und 
output ganz gut berechnen und überwachen. Standardmethode: Stecke 3 
Karten in das System und lasse es parallel rechnen. Damit kannst Du Mio 
erdenklicher Fehler in den Subsystemen abfangen und auch gleich 
korrigieren, weil 2 sagen, was zu machen ist und der dritte neu gebootet 
wird.

Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich komme nochmal auf den Tenor zurück:

Die eingangs gestellte Frage war in der Annahme getätigt, dass selbige 
funktionelle checks nicht reichen und man daher Lösungen in die HW 
verschieben möchte. Der Grund war, dass man durch Prüfungen von außen 
herum, wie es einige der Beitragenden vorschlagen, zwar  herausarbeiten 
kann, ob ein Fehler auftritt, man kann ihn aber nicht verhindern. Die 
Schwierigkeit ist nun, die Redundanz des Systems sicher und schnell zu 
machen.

Es reicht dann nicht, 3 oder mehr Controller zu benutzen, um die 
Sicherheit zu haben, wenn es alle paar Sekunden zu einem Ausfall kommt. 
Da muss die HW eingreifen und das System sichern, dass so etwas nur alle 
paar Stunden vorkommt.

Ein einem ERC-System auf einem RAM wird auch die HW aktiv, weil der 
Microcontroller nicht 10mal denselben Wert lesen soll, bis er ihn sicher 
hat. Klar wird er mehrfach gelesen, aber das muss in der Mehrzahl der 
Fälle erfolgreich sein. Sonst ist das System nicht tauglich.

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
G. B. schrieb:
> Es reicht dann nicht, 3 oder mehr Controller zu benutzen, um die
> Sicherheit zu haben, wenn es alle paar Sekunden zu einem Ausfall kommt.
> Da muss die HW eingreifen und das System sichern, dass so etwas nur alle
> paar Stunden vorkommt.

Wo kommt sowas vor, bzw. wo muss man mit sowas leben und kann das 
Problem nicht anderweitig beheben?
Bei Datentransfer fiele mir jetzt Forward Error Correction ein, aber die 
bringt auch nix, wenn die Korrekturmethode nicht in einer "gehärteten" 
Umgebung abläuft. Bei ALUs wirds schon mal kniffliger, aber da gibts 
auch fehlertolerante Methoden, die sicher besser im FPGA aufgehoben sind 
als in redundanten klassischen CPU-Systemen.

Autor: Edi M. (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Vakuum schrieb:
> it den selben Teilen und der selben
> Software. Man kauft gleich alles für mehrere Jahre Produktion ein und
> Lagert dies ein.

Das ist aber auch nicht so ganz einfach und billig, alles lange 
einzulagern. Das muss z.B. bei manchen Teilen Sauerstofffrei geschehen, 
weil du dann die alterung hast.

Autor: Vakuum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edi M. schrieb:
> Das ist aber auch nicht so ganz einfach und billig

Reden wir über einen "billigen" Sektor? -> Nö!

Edi M. schrieb:
> Das muss z.B. bei manchen Teilen Sauerstofffrei geschehen

Jepp, Stickstoff ist das Mittel deiner Wahl - und zwar bei allen, nicht 
nur manchen!
Einlagerung kann man sich mittlerweile auch als Dienstleistung 
einkaufen.

Autor: M. W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vakuum schrieb:
> Jepp, Stickstoff ist das Mittel deiner Wahl - und zwar bei allen, nicht
> nur manchen!
War auch schon mal mit dem Thema konfrontiert und es kam darauf raus, 
dass sich das Einlagern nicht lohnen würde.

> Einlagerung kann man sich mittlerweile auch als Dienstleistung
> einkaufen.
Das könnte aber bei militärischen Produkten schwer werden.

Wie könnte man das denn im heimischen Lager machen? Gibt es da Anlagen, 
die man sich hinstellen können, die das leisten?

Ich habe ein Problem, mir vorzustellen, wie man ein Volumen total 
sauerstofffrei bekommen könnte. Einfach Stickstoff reinpumpen und 
ausspülen? Oder wird da vorher evakuiert? Wohl kaum, nehme Ich an.

Gibt es Werte wie lange man was lagern kann? Mit und ohne Stickstoff?

Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich erweitere aus aktuellem Anlass das Thema um den Aspekt der 
Sicherstellung von Funktion auch auf handelsüblichen 
Prozessorplattformen der Intel-Liga.

Jemand damit Erfahrung?

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehr zur Vollständigkeit:

> Und auch von den Systemanforderungen. Die Redundanz wird dann oft dort
> implementiert. Im Falle von kompletten SoCs wird vermutlich eine TMR
> einfacher sein.

Triple modular redundancy (TMR) ist eine verbreitete Methode bei Chips 
die ionisierender Strahlung ausgesetzt sind (z. B. Weltraum). Speicher 
und Caches werden dann typischerweise nicht nur ECC sondern mit 
Forward-Error-Correction Codes geschützt.

Das wird nicht nur bei SoCs gemacht (z. B. die Sparc CPUs von Geissler) 
sondern es gibt auch FPGAs (RTAX, RTG4 von Microchip), bei denen die 
ganzen Logic-Blocks schon als TMR gebaut sind und man entsprechend als 
FPGA Designer viel weniger Validierungsaufwand hat.

> Was mich wundert ist, warum immer die Rede von SEU ist und nicht auch
> MEU.

Die redundanten Elemente müssen Räumlich etwas auseinander liegen, dann 
wird die Wahrscheinlichkeit sehr schnell sehr klein, dass genau 
gleichzeitig mehrere Bits (der selben Funktion) kippen, da ein einzelner 
Event nur lokal begrenzt aktiv ist.

Ist natürlich ein aktiv diskutiertes Thema bei den kleiner werdenden 
Strukturgrössen. (Es gibt eigene Konferenzen zu Rad-Hard wie z. B. die 
RADECS).

> Und wenn jedes gekippte Bit (im FPGA) immer erkannt werden muss,
> ist das schon ein sehr spezielles Requirement und sollte mMn in einem
> Layer oberhalb gemacht werden.

Wie oben geschrieben, man kann es auch ins Layer unterhalb schieben :-)
Wird aber nur dann eingesetzt, wenn es nötig ist, da es eine sehr teure 
Lösung ist (10k und mehr für einen FPGA). Die erwähnten Methoden wie 
Lock-Step Prozessoren sind viel häufiger anzutreffen.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> man entsprechend als
> FPGA Designer viel weniger Validierungsaufwand hat.

Du meinst damit, dass ein etwaiger Verifikationsaufwand bei der Prüfung 
einer selbst gebauten Struktur, die selbiges leistet, nicht anfällt, 
oder?

Weil ein Validierungsaufwand der Redundanz als solcher fällt ja schon 
an, weil deren Qualität untersucht werden und ins System eindesigned 
werden muss.

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5554537:
> Christoph schrieb:
>> man entsprechend als
>> FPGA Designer viel weniger Validierungsaufwand hat.
>
> Du meinst damit, dass ein etwaiger Verifikationsaufwand bei der Prüfung
> einer selbst gebauten Struktur, die selbiges leistet, nicht anfällt,
> oder?

Ja, genau. Wir können uns auf die Validierung der höheren Schichten 
konzentrieren. Also Funktionalität, Verhalten wenn Fehler auftreten, 
wenn Eingangsdaten Fehler aufweisen etc.

Obwohl unsere FPGAs TMR drin haben müssen wir z. B. die Daten im 
Block-RAM selber absichern und haben entsprechend eine eigene Library 
mit EDAC RAMs und FIFOs. Aber ist schon sehr komfortabel, dass bei einem 
EDAC FIFO die dazu nötige Logik nicht auch noch auf Single-Event 
Einflüsse validiert werden muss.

> Weil ein Validierungsaufwand der Redundanz als solcher fällt ja schon
> an, weil deren Qualität untersucht werden und ins System eindesigned
> werden muss.

Natürlich. Der Hersteller hat Datenblattwerte bis zu welcher 
Strahlungsdosis (und welche Strahlung) die TMR Struktur Fehler erkennen 
und korrigieren kann. Je nach Einsatzort reicht diese 
Fehlerwahrschenlichkeit dann nicht und man muss beim Systemdesign 
zusätzliche Redundanz einplanen.

Wir in unserer Firma untersuchen diese Datenblattwerte nicht. Es gibt 
aber eine ganze Forschergemeinschaft, die sich mit dem Testen und 
Qualifizieren von Rad-Hard Komponenten beschäftigt. Da werden auch immer 
wieder kommerzielle Komponenten auf ihre Anfälligkeit untersucht oder 
neuere Technologien.

Die diesjährige Liste der IEEE Paper ist doch recht breit gefächert, 
BLDC Treiber, FRAM, GPU etc. Oder gleich umgekehrt, 20nm Flash Chips als 
Dosimeter verwenden :-)
http://www.nsrec.com/radiation-effects-data-workshop.html

Autor: Ge. B. (georg2011) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> Wir in unserer Firma untersuchen diese Datenblattwerte nicht

Kann man euch buchen oder braut ihr eigene Produkte?

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg B. schrieb:
> Kann man euch buchen oder braut ihr eigene Produkte?

Beides :-)

Wir machen aber Space für zivile Applikationen (das meiste ist ESA oder 
damit verbandelt) und kein MIL.

Autor: J. S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> Obwohl unsere FPGAs TMR drin haben
Ich nehme an, ihr nehmt dafür auch ACTEL?

Autor: Weltraumtourist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:

> Triple modular redundancy (TMR) ist eine verbreitete Methode bei Chips
> die ionisierender Strahlung ausgesetzt sind (z. B. Weltraum). Speicher
> und Caches werden dann typischerweise nicht nur ECC sondern mit
> Forward-Error-Correction Codes geschützt.

Nanü? Mit was für FEC Codes wird den ein MCU/CPU Cache da draußen im 
Weltraum gesichert?

Wird da wirklich mehr als die üblichen 72 Bit für 64 Bit Daten 
verwendet?

Autor: Klakx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> [..] Speicher und Caches werden dann typischerweise nicht nur ECC sondern
> mit Forward-Error-Correction Codes geschützt.

Diesen Satz kann ich so nicht unterschreiben, denn ECCs können auch 
korrigieren (beispielsweise DRAM), beziehungsweise ist der Begriff ECC 
ein Überbegriff.


Zu Triple-Redundancy:
Diese Architekturen werden auch in kritischen Teilen des 
Automobilbereichs verwendet.

Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, habe endlich meinen Account mal wieder aktiviert. Möchte hier ja 
nicht nur Gast sein, sondern auch ein Hilfskoch ;-)

Jürgen S. schrieb:
>> Obwohl unsere FPGAs TMR drin haben
> Ich nehme an, ihr nehmt dafür auch ACTEL?

Ja, im Moment gibt es da keinen Weg an Microchip vorbei (Microsemi wurde 
diesen Frühling aufgekauft). Die Rad-Hard FPGAs von Xilinx machen das 
nach meiner aktuellen (Un)Kenntnis auf anderem Weg.

Atmel hatte mal einen einzigen Typ.

Mit etwas Glück dürfen wir aber bald die Europäischen Space-Grade FPGAs 
von nanoXplore (FR) ausprobieren. Die ESA hat da ein grosses 
Förderprogramm (VEGAS) dazu: http://vegas.nanoxplore.com/project.html

Weltraumtourist schrieb:
> Nanü? Mit was für FEC Codes wird den ein MCU/CPU Cache da draußen im
> Weltraum gesichert?
>
> Wird da wirklich mehr als die üblichen 72 Bit für 64 Bit Daten
> verwendet?

Wenn es für die Anforderungen reicht, nehmen wir schon das, was die RAM 
Blöcke im FPGA gut unterstützten. Kann aber auch noch breiter werden.

An Codes wird auch nichts "ausserirdisches" eingesetzt, gut 
dokumentierte Techniken sind ja sowieso viel beliebter :-) Die erwähnten 
internen Cores nutzen klassische Hamming-Codes.

Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klakx schrieb:
> Zu Triple-Redundancy:
> Diese Architekturen werden auch in kritischen Teilen des
> Automobilbereichs verwendet.

Interessant, hast du ein Beispiel dazu?
Wir da auf unterster Ebene (FFs, Kombinatorik) TMR gemacht oder auf 
höherer Ebene (3x uC Core und Voter)?
Auf höherer Ebene war mir das bekannt. Die Anforderungen an funktionale 
Sicherheit einer Airbag Steuerung sind (berechtigterweise) sehr hoch.

Solche Bauteile sind, gerade wenn sie auch 125 °C zugelassen sind, sind 
schon recht nahe dran, um auch weg zu schiessen (und viel viel Billiger 
als das was wir sonst verbauen).

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei einem System, an dem ich mitgearbeitet hatte, wurde das "System" vor 
dem Einsatz durch den Startbehälter konfiguriert. Wird das "System" 
gestohlen, ist der FPGA nackt. wird das "System" abgeschossen, fällt die 
Versorgung aus und die Konfiguration geht flöten.

Autor: Klakx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Interessant, hast du ein Beispiel dazu?

Ein Beispiel sind die Arbeiten am automatischen Bremssystem (Vorstufe 
zum autonomen Fahren). "3x uC Core und Voter" wurde mal vorgestellt.
https://www.automotive-iq.com/autonomous-drive/articles/first-level-3-automated-vehicle-road-iso-functional-safety-and-analysis
Der Link zeigt eine gute Übersicht.

Autor: D.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Nehmen wir mal an, dass wir TMR mit drei FPGAs machen. Kommt auf 
alle drei FPGAs der selbe Bitstream? Oder wird von separaten Teams zur 
selben Spezifikation jeweils eine Lösung entwickelt?

Ich weiss, dass in Tradingsystemen die Tradingstrategies von separaten 
Teams doppelt gecoded werden. Es gibt eine Spezifikation, eine schnelle 
Produktionsimplementierung, und eine langsame auf Korrektheit getrimmte 
Implementierung gegen die dann die Productionimplementation validiert 
wird.

Autor: FPGA-Masochist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D.M. schrieb:
> Es gibt eine Spezifikation, eine schnelle
> Produktionsimplementierung, und eine langsame auf Korrektheit getrimmte
> Implementierung gegen die dann die Productionimplementation validiert
> wird.

Es gibt zwei Qualitäten der Implementierung?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FPGA-Masochist schrieb im Beitrag #5559177:
> Es gibt zwei Qualitäten der Implementierung?

Das hat Microsoft in Debug-Builds auch gemacht (vermutlich machen die 
das noch immer). In Excel liefen z.B. zwei Berechnungsalgorithmen 
parallel, einer naiv, langsam und (vermutlich) korrekt implementiert, 
einer schnell und optimiert. Gleiches für die Speicherverwaltung.

Wenn beide unterschiedliche Ergebnisse ausgeben, platzt die Anwendung 
sofort.

Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D.M. schrieb:
> Ok. Nehmen wir mal an, dass wir TMR mit drei FPGAs machen. Kommt auf
> alle drei FPGAs der selbe Bitstream? Oder wird von separaten Teams zur
> selben Spezifikation jeweils eine Lösung entwickelt?

Das kommt wieder darauf an, welche Fehler zu erwarten sind (schon wieder 
FMEA...).

Mit dem selben Bitstream erschlägst du Probleme die durch Single-Event-* 
oder durch Ausfall/Defekt entstehen. Also klassische Redundanz (sollte 
dann auch die Speisung etc. drei mal vorhanden sein).

Mit dem doppelten Coden werden ganz andere Fehlerquellen behandelt. 
(Also eigentlich genau eine, nähmlich, dass wir Menschen Fehler begehen 
und es die ganze Zeit schaffen uns falsch zu verstehen :-) In deinem 
Beispiel kommt noch Sabotage und Diebstahl dazu)

Noch weiter geht es, wenn die drei FPGAs noch von min. zwei 
verschiedenen Herstellern sind (und unterschiedliche Synthesetools 
etc.).

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.