Hallo, ich beschaeftige mich seit neuestem mit Modellentwurf von Systemen mit FPGA-Implementierungen und zur Zeit vertiefe ich mich in die Fragestellung, was alles gemacht werden muss, damit ein System mit einem FPGA zertifiziert werden kann. Wenn man ein Modell mit verschiedenen FPGA Funktionen hat, kann man diese Funktionen zum BSP. aus Simulink raus mit Xlinx oder aehnlichen Code-Generator entwickeln. Oder eben selber mit VHDL oder Verilog per Hand schreiben. Die Frage ist, sind solche Code Generatoren wie eben Xlinx selbst irgendwie nach zum Bsp. IEC 61508 Edition 2 zertifiziert, bzw. gibt es welche die so zertifiziert sind, damit auch der Endcode zertifiziert werden kann? Bei der Suche habe ich diesen hier gefunden: http://www.dspace.com/de/gmb/home/products/sw/pcgs/targetli.cfm Allerdings bin ich mir nicht sicher ob dieser tatsaechlich fuer FPGA Implementierungen verwendet wird. Des Weiteren, wenn man zum Bsp. keinen Code Generator benutzt, geh ich recht in der Annahme, dass jeder Teil des Codes genaustens dokumentiert werden soll, in der Dokumentation dann steht, welcher Teil des Codes manipulierbar ist und welcher nicht? Diese Dokumentation muss dann fuer die Zertiefizierung des Messgeraetes bei der PTB-Behoerde mit der Kopie des Codes vorliegen? Ich hoffe ihr koennt mir weiter helfen, Vielen Dank und mit freundlichen Grueßen, bmtil
Mir wäre es neu, wenn der Xilinx-Systemgenerator zertifiziert wäre und
ich würde mich auch sehr wundern, wenn irgendjemand diesem Viech eine
Funktionsbescheinigung austellen würde.
Vorlegbar sind bestenfalls die Verfikationsergebnisse aus dem Simulator,
egal, ob der Code per Hand oder automatisch erzeugt wurde. Ich würde
sogar sagen, dass man mit derart automatisch generierten Codes mehr
Aufwand haben wird / müsste, da der Zusammenhang von Code-Zeile und
Funktion nicht in der üblichen Weise gegeben ist. Der Strichen im
Simulink darf man jedenfalls nicht trauen.
Eine Frage: Was verstehst Du hieruntern?
> welcher Teil des Codes manipulierbar ist
Wozu soll das Zertifikat gut sein? Werden tatsächlich Geräte produziert, die irgendwie Menschenleben gefährden könnten, oder will nur irgendein Qualitäts-Auditor oder Kunde ein Papier sehen? http://de.wikipedia.org/wiki/IEC_61508
Xilinx-User schrieb: > Eine Frage: Was verstehst Du hieruntern? >> welcher Teil des Codes manipulierbar ist Naja, zum Beispiel ich habe ein eichfaehiges Messgeraet entworfen mit verschiedenen implementierten Funktionen. Funktion A ist die Grundfunktion (zum Bsp. ein AD-Wandler), Funktion B ist irgendein Feature (zum Bsp. die Moegichkeit sich die Messdaten per Knopfdruck in verschiedenen Einheiten anzeigen zu lassen) Den Code davon habe ich bei der PTB-Behoerde mit der zugehoerigen Doku abgegeben. Nun zwei Jahre spaeter habe ich fuer die Funktion B ein Update geschrieben, dass zum Bsp. neue Einheiten dazugekommen sind, oder ich kann sie mir parallel anzeigen lassen oder sowas eben. Um das Update auf das Geraet (welches bei irgendeinem Unternehmen steht) draufzuspielen zu koennen, muss ich den urspruenglichen Code der Funktion B manipulieren. Wie genau muss ich also die Codes fuer die Funktion B dokumentieren, dass nur dieses Stueck eben veraenderbar ist, und Code der Funktion A halt geschuetzt ist?
Gute Frage, die ich so nicht beantworten kann. Das Problem beim FPGA ist, dass man zwar auf der Systemebene gerne 2 Code-Stücke unterschiedlicher Sicherheit und Manipulierbarkeit halten kann, sich das auf der Datenebene aber nicht halten lässt, weil die Synthese alles mit allem verwäscht. Man muss also regressiv immer wieder alles testen - es sei denn , man brächte es in zwei verschiedenen Bausteinen unter oder betriebe partical reconfig, die aber auch wieder als solche getestet werden müsste. Ich finde das Thema aber spannend, da es bislang gängige Praxis war, FPGAs zu nutzen in Fällen, in denen man gewillt war, Softwaretesting zu umgehen, um eine erleichterte Zulassung zu erreichen, da FPGA=Hardware.
Christoph Kessler (db1uq) schrieb: > Wozu soll das Zertifikat gut sein? Werden tatsächlich Geräte produziert, > die irgendwie Menschenleben gefährden könnten, oder will nur irgendein > Qualitäts-Auditor oder Kunde ein Papier sehen? Naja, eine Zertifizierung braucht man immer wenn man irgendein eichfaehiges Messgeraet verkaufen will, nicht unbedingt welche, die die Menschenleben gefaehrden. In erster Linie geht es um das reine Interesse, weil die ganze Geschichte mit den FPGAs oder auch zum Bsp. ASICs noch gar nicht so sehr im deutschen oder irgendeinem Gesetz verankert ist. > http://de.wikipedia.org/wiki/IEC_61508 Die Norm kenne ich, speziell die zweite Edition davon ist interresant wenn es um die Software geht. Sehr interresant in diesem Zusammenhang ist ja auch das hier: http://www.welmec.org/fileadmin/user_files/publications/WG_07/WELMEC_Guide_7_2_Ausgabe5_DE.pdf Wobei das natuerlich der allg. Softwareleitfaden ist. Aber nirgendwo steht zum Bsp. wie die Schnittstelle zwischen Modellentwurf und tatsaechlichem Code auszusehen hat, bzw. wie der Code vom Modell generiert werden soll, ob per Hand oder automatisch. Und natuerlich wie das geschuetzt werden soll, ob ueberhaupt, oder unbedingt (zum Bsp. copyright) oder ist es jedem selbst ueberlassen, etc.
Xilinx-User schrieb: > umgehen, um eine erleichterte Zulassung zu erreichen, da FPGA=Hardware. Naja, das sehen wir hier (Fachgebiet Rechnerarchitektur) aber etwas anders. Ein FPGA ist sowohl Hard- als auch Software. Die Hardware ist ja nur der Chip selber, der irgendwo verbaut wird, das was in dem Ding drin steckt, was halt eben aus der Gattermatrix ensteht ist jeher Software und eben deswegen auch manipulierbar. Das ist ja das Schoene an den FPGAs, dass man davor alles durchsimulieren kann und dadurch jede Menge Kosten gespart werden koennen.
M. V. schrieb: > Naja, das sehen wir hier (Fachgebiet Rechnerarchitektur) aber etwas > anders. Es geht dabei aber nicht um die technische Erklärung, sondern um die Zertifizierung. In vielen Normen werden FPGAs einschließlich Inhalt als Hardware angesehen und nicht als Software. Und damit muss nur nachgewiesen werden, dass das Bauteil elektrisch korrekt beschaltet ist. Die im FPGA enthaltene Beschreibung fällt dabei einfach durch das Zertifizierungsraster. Dies galt bis vor kurzem sogar für DO-178 und DO-254, in denen die Prozesse und Zertifizierungen für die zivile Luftfahrt geregelt sind, und wurde erst neuerdings korrigiert. Gibt es also Softwarebestandteile, die an einer Zertifizierung scheitern, packt man sie einfach in ein FPGA, z.B. in eines darauf befindlichen - ebenfalls nicht zertifizierungsbedürftigen! - Softcore. Das dies aus technischer Sicht natürlich katastrophal ist, wird auch nicht bestritten. Dieser Weg wurde/wird aber durchaus gegangen, um Zertifizierungskosten zu minimieren. Mittlerweile haben allerdings die meisten Herausgeber von Zertifizierungsvorschriften diese Lücke erkannt und geschlossen. Ggf. kann aber bei Arbeiten im Rahmen der Produktpflege noch ein Bestandsschutz existieren. Das muss man aber für jede einzelne Norm und ihre Anwendungsbereiche einzeln betrachten. Ein früherer Kunde von mir hatte Probleme, für ein Sicherheitsmodul eine hinreichend splitterfeste Vergussmasse zu finden. Dort gab es Unmengen an Versuchen und gescheiterten Sicherheitsevaluierungen. Irgendwann wurde ein Berater hinzugezogen, der die Testvorschriften eher juristisch als technisch auslegte. Er fand heraus, dass man nur eine sehr weiche Vergussmasse verwenden musste, die einfach nicht splittert. Das Gerät bestand damit umgehend die Zulassungsprüfungen, obwohl sich die weiche Vergussmasse sehr einfach herauspulen ließ. Ein "Herauspulschutz" wäre nämlich erst bei einen höheren Sicherheitsstufe erforderlich geworden.
M. V. schrieb: > Naja, das sehen wir hier (Fachgebiet Rechnerarchitektur) aber etwas > anders. Ein FPGA ist sowohl Hard- als auch Software. Die Hardware ist ja > nur der Chip selber, der irgendwo verbaut wird, das was in dem Ding drin > steckt, was halt eben aus der Gattermatrix ensteht ist jeher Software > und eben deswegen auch manipulierbar. Antifuse-FPGA? FLASH-basierte FPGA mit verriegelter Programmierschnittstelle? Da ist nix manipulierbar, dasmuss wohl dann aus Leerstuhl-Sicht Hardware sein! Oder auch wieder nur Software?
M. V. schrieb: > Naja, das sehen wir hier (Fachgebiet Rechnerarchitektur) aber etwas > anders. Ein FPGA ist sowohl Hard- als auch Software. Ich bin da absolut Deiner Meinung. Schon immer waren FPGAs ein Softwarethema, allein schon wegen des Programmiervorgehens und auch wegen interner Abläufe in FSMs und der Abhänfigkeit von äusseren Signalen. Spätestens mit Softcores ist das Thema evident. Aber trotzdem wurden FPGAs gerne als HW angesehen, um es sich leicht zu machen.
Andreas Schweigstill schrieb: > ckt man sie einfach in ein FPGA, z.B. in eines darauf > befindlichen - ebenfalls nicht zertifizierungsbedürftigen! - Softcore. Definitiv ein Schlumpfloch und sachlich nicht begründbar.
Werner Wehmut schrieb: > FLASH-basierte FPGA mit verriegelter Programmierschnittstelle? Das waere aufjedenfall eine Idee. Vielen Dank fuer die aufschlussreichen Antworten, es hat mir wirklich weiter geholfen. Ich bin tatsaechlich auch schockiert, dass man zur Zeit anschneinend jede Zertifizierung mit Layout Design Regeln aus jedem kompetenten Elektronikbuch erschlagen kann (einfach gesagt). Dass die Xlinx Geschichte nicht zertifziert ist wundert eigentlich nicht, wenn man darueber nachdenkt, es ist ja nicht so dass sie sich von einer Pruefstelle in die Karten schauen lassen wollen. Vermutlih ist der ehrlichste Weg also tatsaechlich alles selber von Hand zu proggen und vernuenftig zu dokumentieren. Grueße.
M. V. schrieb: > Vermutlih ist der ehrlichste Weg also tatsaechlich alles selber von Hand > zu proggen und vernuenftig zu dokumentieren. Bei den meisten Zertifizierungen wird viel zu viel Papier und viel zu wenig Code getestet. Der Zeitbedarf für das Bekritzeln toter Bäume bzw. ihrer elektronischer Äquivalente fehlt dann natürlich für tatsächliche Implementierung und Tests. Erschreckend finde ich auch, wie viele Kunden auf irgendwelchen Zertifizierungen bestehen. Auf die Nachfrage, welche denn gewünscht ist, habe ich schon mehrmals gehört: "Völlig egal, Hauptsache irgendwie zertifiziert! Unsere Kunden wollen nämlich auch nur zertifizierte Produkte kaufen."
Ich kenne den IEC61508 nicht im Detail, aber vergleichbare Standards aus dem Avionik-Bereich. Deswegen ein paar Anregungen/Fragen - Wie wird der VHDL-Code in der IEC behandelt? Wie normale Software? Sind spezielle Verfahren bei der Verifikation anzuwenden? - Generell gilt bzgl. automatisierter Codegenerierung: Eine Toolqualifizierung ist nur dann nötig, wenn durch den Einsatz des Tools Verifikationsschritte automatisiert/substituiert werden. Wenn man den Code eines Codegenerators wie manuell geschriebenen Code behandelt, ist keine Qualifizierung nötig. - Eine Zertifizierung eines Codegenerators bedeutet in der Regel, dass man ihn nach den gleichen Standards entwickeln muss wie die Software, die er erzeugt. Jetzt frage dich, ob dies für die Toolkette Matlab-Simulink-Codegenerator-Xilinx-Generator mit vertretbarem Aufwand möglich ist. Die Antwort ist vermutlich nein. Ein Programm mit GUI ist imho (lt. RTCA-DO178B/DO-330) nicht qualifizierbar, nur als Beispiel. - Eine Qualifizierung/Zertifizierung ist nur durch den Hersteller des Tools möglich. - Nichtsdestotrotz muss der Anwender der Software i.d.R. weitere Aktivitäten im konkreten Anwendungsgebiet durchführen. - Generell entstehen extrem hohe Kosten. Beispiel aus der Avionik: SCADE (Modellierungstool vergleichbar mit Simulink, inklusive Codegenerator, qualifizierbar als Development Tool nach DO-178B Level A) mitsamt dem Qualification Support Kit kostet >200K€
> wegen interner Abläufe in FSMs und der Abhänfigkeit von äusseren > Signalen. Spätestens mit Softcores ist das Thema evident. Naja ich hab schon immer FSMs aus Countern (FFs), und Schaltnetzen bzw. Logicgattern gebastelt. Ne CPU ist halt ne komplexe, programmierbare FSM, bleibt aber immer noch Hardware. Dann die ganze zusätliche Peripherie, wie DMA, MMU, FPU, Interuptvektocontroller, IO-Controller usw. alles Hardware. Erst die programmierung dieser ist die Software.
Uwe schrieb: > Ne CPU ist halt ne komplexe, programmierbare > FSM, bleibt aber immer noch Hardware Eine CPU ist nur als echter Controller eine Hardware. Als Soft-CPU ist es eine Software, welche die Logikzellen programmiert und zu einem virtuellen Ablauf führt. Virtuelle Abläufe sind immer eine Software. Die Frage wäre nun, ob es zertifizierte Softcores gibt, sodass man sich bei den Test auf die firmware der CPU konzentrieren und die CPU selbst als ok ansehen kann. Ansonsten muss man beides in einem mittesten sage ich mal. > FSMs aus Countern Sobald das kein festgelegter Ablauf ist, der von selber rennt, sondern Einwirkungen von Aussen zu abweichendem Verlauf führen, ist das absolut eine zu überprüfende Eigenschaft. Ob man sie SW oder sonst wie nennt, ist Jacke wie Hose - es bleibt eine zu bewertende Funktion. So oder so ist es glaube ich aber nur von theoretischem Wert, auf zertifizierte und vorgeprüfte Teilfunktionen zu setzen. Am Ende muss der Funktionsnachweis der Geräte erbracht werden. Für VHDL meine ich gibt es aber doch das Code Coverage, das in ModelSIm angeboten wird. Ich weiss nicht, was das konkrte kann, vielleicht liesse sich damit aber auch etwas abdecken.
>Als Soft-CPU ist es eine Software, welche die Logikzellen programmiert und >zu einem virtuellen Ablauf führt. Wie bitte ??? Hab ich jetzt schon viermal gelesen, mir will sich der Sinn nicht erschließen. Also wenn ich ne CPU in einer Technologie synthetisiere die ich auch früher schon benutzt habe. 74xxx, GAls, MUXen usw. ist das Hardware. Wenn ich das ganze dann in welcher technologie auch immer in ein ASIC gieße (von mir aus mit Verilog, RTL, VHDL) ist das auch Hardware. Wenn ich das ganze in ein FPGA gieße ist es keine ? Dort ist auch eine Verdrahtungsmatrix (aus Metall) drin wie in ASICs. Und nur weil Transistoren dort mit LUTs ausgetauscht worden sind bleibt das trotzdem Hardware und keine Software. Nen Softcore ist Hardware und keine Software Emulation.
Uwe schrieb: > Also wenn ich ne CPU in einer Technologie synthetisiere die ich auch > früher schon benutzt habe. 74xxx, GAls, MUXen usw. ist das Hardware. wenn Du ein CPU aus echten 74ern aufbaust, so verbirgt sich der Ablauf in der logischen Verschaltung Deiner Hardware. Einmal fix und getestet ist die hart und unveränderlich. Es bleibt hier der funktionslogische Test der Schaltung, als UserInteraktion etc. Wenn die Hardware einmal getestet wurde und in der Produktion ein Endtest erfolgt, dann muss einmal die Funktioslogik geprüft werden. Diese war und ist Soft, sei sie auch noch so simpel. Beim FPGA ist es insofern schon dasselbe, nur ist der Prüfungsaufwand stark gestiegen, weil die Abläufe komplexer sind und damit sind diese nicht mehr einfach durchs Angucken zu validieren. Der Unterschied ist also die Komplexität. Der immer schon vorhandene Softanteil tritt nun zutage. Es gibt aber noch einen Punkt: > Dort ist auch eine Verdrahtungsmatrix (aus Metall) drin wie in ASICs. Nein, es ist eine programmierbare = umschaltbare Interconnection-Matrix die nur so lange funktioniert, so lange dort die richtigen Ladungen drinstehen. Das ist also in der Entwicklung als fehlerhaft und im Betrieb als vulnerabel anzusehen, daher gibt es bei kritischen Anwendungen auch die Vorschrift, die FPGA-programmierung per CRC in Echtzeit zu checken.
Aber wenn's schon soweit ist, dann ist auch jedem Register in einer harten CPU nicht mehr zu trauen und man braucht Majority-Voting-FFs und ECC für Registerbänke und den ganzen Speicher.
Ja, wird bedarfsweise auch exakt so gebaut und verlangt. Das Ganze ist letzlich eine reine Betrachtung der FMEA: Braucht man es oder geht es noch ohne? Wie gross ist die Wahrscheinlichkeit dass ein Datenfehler vorliegt, weil das RAM nicht richtig liefert? Wie gross ist p, dass irgendwo die Übertragung klemmt? Bei simplen PLDs von früher, war die Wahrscheinlichkeit, dass die Mini-FSMs, die da liefen, ausfallen, sehr gering. Nichtsdestotrotz, war sie da. Sie waren aber leicht überschaubar und validierbar. Eigentlich hat sich heute auch nichts geändert, nur wenn man einen Softcore draufstopft, diesen mit SOPC pipe basierten Verknüpfungen füttert und das ganze kaputtgehen kann, wenn ein einziges Config-Bit kippt, ist das vom Ausfallrisiko bedeutend höher, als manch andere typische Fehlerquelle in der Schaltung, die FMEA-relevant ist. Die Software, die auf der CPU laufen soll, kommt noch obendrauf.
Also eine Zertifizierung des VHDL-Codes ist m.E. völlig unzureichend, da FPGA-Ausfälle (kippen eines Bits) abhängig vom Slizium sind, also Strukturbreite etc.. Dem VHDL-code ist es nun meist völlig wurscht auf welchen FPGA Spartan3 Artix etc er gerät, der Ausfallrate dagegen nicht. Auch hat der clock-jitter (DCM-settings, Taktaufbereitung) einen deutlichen einfluß auf Fehlverhalten (Synchronisierversagen). All diese Faktoren die zur Ausfallrate beitragen werden nicht vom Codegenerator beeinflußt, folglich kann diese auch nicht angeben in welchen PFH (probability of dangerous failure per hour) - Bereich der erzeugte Code fällt. Ergo, vergiß das mit der Zertifizierung eines FPGA-Code-Fragmentes, egal ob generiert oder Hand geschrieben. Salute,
Es scheint als ob sich die Welt tatsächlich nicht ganz einig ist als was die FPGAs behandelt werden müssen. Von der PTB http://www.ptb.de/cms/dieptb.html bekam ich eine Antwort, dass diese aufjedenfall f"ur eine Zertifizierung von ihrer Seite aus einen Code des eichfähigen Systems benötigen wo ein FPGA (oder auch meinetwegen ein ASIC) drin verschaltet ist. Sie sehen das ganze als Software. Des Weiteren, Möglichkeit zum Verändern der Funktionen bedeutet dass alle möglichen Schnittstellen gegenüber Veränderungen geschützt werden sollen. Auch der Weg zwischen Modell und (im Falle eines Code Generators) Code Generators. Natuerlich ist die Zertifizierung und der ganze Papierkram erforderlich, schließlich will der Endverbraucher eine gewisse Sicherheit. Wenn dem Kunden dass Vertrauen in die Technik nicht reicht und er ein Dokument mit einem Stempel von Behörde XY braucht um das Gerät zu kaufen, dann ist es wohl so. Einem Unternehmen nützt es nichts tollste funktionierende Geräte zu bauen und sie nicht verkaufen zu können. Das diese Tatsache natürlich dem reinen Ingeneurgeist was die Hard- und Software Design angeht unglaublich lästig ist, ist offensichtlich. Grüße.
M. V. schrieb: > Sie sehen das ganze als > Software. und wenn man sieht, wie in vielen Firmen gefrickelt wird, ist das auch gut so
> Nein, es ist eine programmierbare = umschaltbare Interconnection-Matrix > die nur so lange funktioniert, so lange dort die richtigen Ladungen > drinstehen. Du hast vollkommen recht. Und ich weiß das alles auch selber. Aber es ist und bleibt Hardware und verhält sich auch wie Hardware auch wenn daß Rissiko gestiegen ist das was schiefgeht. Es geht mir nur darum, daß wenn das ganze in einem FPGA implementiert ist kann man keine allgemeingültige Risikobewertung machen, wenn das FPGA unbekannt ist. Es kann ja sein das dein FPGA jede RAM-Zelle einzeln mit ECC ausgestattet ist und im FPGA drei mal vorhanden ist (vileicht sogar auf unterschiedlichen) und es in Blei eingegossen ist usw. Ich kann ein VHDL Design nicht einfach als Software abtun.
Schau dir mal deren SmartFusion2 FPGAs an. Die sind immun gegen "single bit" Fehler. Damit kannst du die Hardware-Zuverlässigkeit um "Zehnerpotenzen" steigern. http://www.microsemi.com/products/fpga-soc
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.