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?
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!
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.
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.(?)
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.
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?
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.
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.
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?
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".
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
Diese Szenarien muss man aber auch erst mal herstellen und welche Bitkippfehler will man da annehmen?
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.
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?
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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
Christoph schrieb: > Wir in unserer Firma untersuchen diese Datenblattwerte nicht Kann man euch buchen oder braut ihr eigene Produkte?
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.
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?
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.
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.
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).
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.
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.
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.
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?
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.
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
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.