Hallo, ich entwickle momentan auf einem ARM9 ARM926EJ-S Software, die für SIL 2 Zulassung bekommen soll. Nun ist es ja nötig alle relevanten Speicher, Core und Hardware auch auf Fehler zu überprüfen. Das meiste ist auch schon sehr gut gelöst, nur mit der MMU mache ich mir gerade noch einige Gedanken. Die MMU leuft auch sehr gut und auf die Performance der MMU möchte ich nicht verzichten, obwohl ich kein Multitasking (Betriebssystem) benutze. Jetzt meine Fragen: - Wie kann ich den ICache Speicher der MMU Testen? - Gibt es eine Möglichkeit direkt zu lesen oder zu schreiben? Mit den MMU Debug und Test register kann ich die TLB nachprüfen, das ist klar. Den DCache Speicher kann man leichter testen das geht schon recht gut. Um hilfreiche Infos bin ich sehr dankbar, Gruß Sascha
Hallo Sascha, was soll denn der Funktionstest am Ende aussagen? Ja, der ICache funktioniert generell oder aber der komplette Speicher vom ICache z.B. 16kB funktioniert einwandfrei? Gruß Microman
Hallo Microman, der Test muss sicherstellen, das jede Speicherstelle in dem 16K Cache funktionstüchtig ist. Das Genaue Bit oder wo der Fehler genau ist, ist nicht wichtig. Ist ja etwas mehr wie nur Speicher beteiligt. Es geht darum, wenn ich den I-Cache verwende und er hat einen Fehler, wird ein Befehl nicht richtig ausgeführt und mein Programm hat ein anderes Verhalten. Somit würde bei einer Überwachungselektronik unter Umständen ein Menschenleben gefährdet, weil ein Alarm oder ein Notaus usw. nicht kommt. Wird der Fehler aber festgestellt, kann die Steuerung in einen definierten Zustand gebracht werden (Störung). Also muss als Testergebniss nur herauskommen, dass der I-Cache einwandfrei funktioniert. Gruß Sascha
darf man fragen, welcher baustein? ggf kann man den cach auch als sram ansprechen, wenn dieser nicht für den cach verwendet wird. (hab das mal irgendwo so gesehen)
Der Baustein ist ein Atmel AT91SAM9G10. Aber als SRAM zum direkten anspechen würde nur die hälfte des Tests erbracht. Auserdem kann ich mir das von der Struktur des Speichers nicht vorstellen. Gruß Sascha
Hallo, so habe gerade den Link mal nachgelesen, ich vermute nur es handelt sich hier um einen 920er Kern und ich habe einen 926EJ-S. Die MMU ist leider nicht die gleiche. Aber dort würde es ohne Probleme gehen. Gruß Sascha
Hallo Sascha, mich würde sehr interessieren, warum Du unbedingt die Caches so intensiv testen mußt? Was für einen Anspruch an den Sicherheitslevel besteht denn, bzw. welcher soll am Ende erreicht werden? Gruß Stranger
Hallo Stranger, also Cache ist auch ein Speicher durch den Fehler entstehen können. Oder man benutzt ihn nicht. Dann bleibt es nur noch an den BUS Strukturen intern hängen, die werden aber bei einem normalen Memory Test sowieso getestet. Also der Cache kann eine sehr komplexe Sache sein. Bin da nun auch schon sehr weit gekommen. Uff ist aber wenn man ins Detail geht etwas aufwendiger. So, mein Programm muss Menschenleben retten, dabei brauche ich auch noch einiges an Rechenleistung alleine für die Grafik (SVGA). Keine Sorge ich mache keine automotive Entwicklung. Erreicht soll SIL 2 Anforderungen, die auch real eingeschätzt zu schaffen sind. Das Programm läuft mit meinen optimierten Cache Einstellungen ca. 23 mal schneller als ohne Verwendung des Cache. Aber der I-Cache,D-Cache und Write Buffer muss dann natürlich fehlerfrei sein. Woher willst du ohne zu testen wissen, ob dein Baustein 100% O.K. ist? Bitte kein Gedanke daran zu verschwenden, "habe ich doch erst neu gekauft". Dann kommt hinzu das mein Prozessor Strahlungen ausgesetzt ist und auch einen Schaden nehmen kann. Also muss auch im fortlaufenden Betrieb periodisch getestet werden. Auche alle Register, die im Prozessor die Funktion des Programms beeinträchtigen, müssen permanent überbrüft werden. Gruß Sascha
Hallo Sascha, einen I-cache zyklisch zu testen ob er noch fehlerfrei ist um SIL2 zu erreichen stelle ich mir äußerst spannend vor da ja die Instruktionen zum test nicht gecached werden dürfen (könnten ja das Testergebnis selbst verfälschen). Dankbar wäre es, den Test in eine Phase des Ablaufs zu legen in dem der cache nicht gebraucht wird, diesen dann abzuschalten da sonst Dein Test gecached wird. Und jetzt brauchst Du einen intelligenten Algorithmus um einige wenige Zellen trotzden zugreifen zu können und diese zu testen. Danach Cache wieder an, Programm normal ausführen bis zum nächsten Mal. Das nächste Mal dann wieder ein Stück, .. Sowas wie Galpat auf den Speicher in kleinen Schritten nur auf den I-Cache. Kniffelig ist nur wie Du die Pattern in den I-Cache reinkriegst, aber vielleicht gibt es da ein Hintertürchen zum Cache? rgds
Sascha schrieb: > also Cache ist auch ein Speicher durch den Fehler entstehen können. Oder > man benutzt ihn nicht. Dann bleibt es nur noch an den BUS Strukturen > intern hängen, die werden aber bei einem normalen Memory Test sowieso > getestet. Ist es denn wichtig zu unterscheiden, ob der Fehler im Cache oder dem "richtigen" Speicher entstanden ist? Ich nehme an, Du bist bereits auf das cache lockdown register gestoßen (cp15, c9) damit Du die Testdaten im Cache auch zuverlässig wiederfindest. > Also muss auch im fortlaufenden Betrieb periodisch getestet werden. > Auche alle Register, die im Prozessor die Funktion des Programms > beeinträchtigen, müssen permanent überbrüft werden. Dynamische Tests der CPU Interna sind schwierig zu beurteilen. Jeder Einzeltest wird bestenfalls wahrscheinlich nur alle soundsoviel Millisekunden durchgeführt. Sollte in der Zwischenzeit ein Fehler, sagen wir mal in einem Register aufgetreten sein, dann kannst Du davon ausgehen, dass lange vor der möglichen Erkennung das Programm aufgrund des Fehlers bereits irgendwohingelaufen ist, wo Programme nun mal zum Sterben hingehen.
Hallo Marcus und 6A66, ja ich gebe euch recht, das ist in der Tad nicht ganz einfach, aber nehmen wir mal folgendes an: Ich schreibe ein Programm das von A nach B ableuft und mir in den Registern Ergebnisse bringt. Das Programm ist so groß das es genau in den Cache passt. Es greift auf keine Daten zu nur auf Literale. Das Programm leuft einmal mit und einmal ohne Cache ab. Das Ergebniss ist sozusagen bekannt. Nun lässt sich das Ergebniss prüfen. (wird natürlich noch etwas aufwendiger gemacht...) Der Daten Cache ist einfacher zu testen, in dem man so groß wie der Daten Cache ist einfach über Read Modify Write einen Memory Test ablaufen lässt. Auch der Galpad muss nicht sein oder Walking Bit, es gibt auch einfachere Testmethoden, die auch sicher genug sind. Invalidiert man nun den Cache, so darf keine Veränderung im RAM sein, und nach Test und Clean muss der Richtige Inhalt ins RAM übertragen werden. Auch die TLB Flags muss man dazu lesen und überprüfen. Auch die TLB muss natürlich bezüglich der Speicherzuordnung überprüft werden. Lockdown ist ein eigener Bereich im Cache, den ich nicht benutze und somit nur gestreift prüfe. So viel ich weiß ist der Lockdown Bereich aber nur dazu da um permanent Code oder Daten für schnelle repetirende Aufrufe bereit zu stellen. Mein Problem mit dem Memory Test ist nur, ich habe 32Mbyte Arbeitsspeicher in meinem Chip zu 4 Bänke (SDRAM 32Bit) da wirds mit einem Galpad oder Walking Bit schon Zeitaufwendig. So viel ich weiß sind aber keine speziellen Memory Tests für SIL 2 vorgeschrieben. Einige sind hingegen empfholen und es ist auch immer von der Struktur des Speichers abhängig. Also mechanischer Aufbau Row/Column usw. Ich habe natürlich auch gelesen das SRAM bevorugt ist, aber SDRAM ist prinzipiell nicht verboten, man muss nur die Refresh Zeiten straffer einstellen. Ist aber alles gar kein Problem. Das Problem, dass der Prozessor irgendwo hinleuft ist bei einem ARM9 System, wenn es noch halbwegs geht abfangbar. Gerade deshalb auch die MMU. Das System hat auch noch einen zweiten Prozessor, der die Taskabfolge des ARM9 überprüft. Ein Worst Case Zenario muss definiert sein, dass ist klar. Gruß Sascha
Sascha schrieb: > Lockdown ist ein eigener Bereich im Cache, den ich nicht benutze und > somit nur gestreift prüfe. So viel ich weiß ist der Lockdown Bereich > aber nur dazu da um permanent Code oder Daten für schnelle repetirende > Aufrufe bereit zu stellen. Nein, ich glaube das verwechselst Du mit den lock-down entries des TLB. Beim Cache verhindert man damit allocation in bestimten ways, was Dir dabei helfen könnte einzukreisen, wo im Cache die Information liegt. Womit wir schon beim nächsten Problem wären: Ohne Kenntnis der Implementierungsdetails ist es schwierig überhaupt einen wirksamen Test zu erstellen. Daher arbeiten Firmen bei denen es tatsächlich drauf ankommt oft mit dem Prozessorhersteller zusammen. > Das Problem, dass der Prozessor irgendwo hinleuft ist bei einem ARM9 > System, wenn es noch halbwegs geht abfangbar. Gerade deshalb auch die > MMU. Hmm, und den Code der das dann abfängt hast Du ausschließlich unter Verwendung der noch funktionierenden Register geschrieben? > Das System hat auch noch einen zweiten Prozessor, der die Taskabfolge > des ARM9 überprüft. Wenn man den Prozessor extern überwacht, die Funktion dieser Überwachung nachgewiesen ist, bieten (vermeintlich) ausgefeilte Selbstests der CPU zur Laufzeit meiner Meinung keinen Mehrwert. Insbesondere vermutlich häufigeren, sporadischen Fehler (Strahlung) lassen sich damit nicht aufdecken. > Also mechanischer Aufbau Row/Column usw. Also in den 70ern mag es vielleicht noch einen direkten Zusammenhang zwischen Adresse und Ort der Speicherzelle gegeben haben, aber heutzutage darfst Du nicht davon ausgehen.
Hallo Marcus, danke deine Antwort bringt mich ein Stück nach vorne. In der Tat muss ich zugeben, dass ich vermutlich das mit den TLBs noch nicht ganz verstanden habe. Aber die Doku von ARM ist nicht besonders hilfreich, oder wo gibts mehr Infos? Bitte die MMU aber nicht mit der des ARM920 verwechseln. Diese ist einfacher in dem Punkt. Das mit dem SDRAM Row/Column ist sicherlich eine gute Frage, ob es noch reale Angaben von den Herstellern gibt. Wie dem, das ist auch momentan das etwas kleinere Problem. Die zweite CPU überprüft keine Laufzeiten, das ist natürlich unsinnig bei dem Speed was der ARM9 hat. Also egal was für ein Code beim Abflug des ARM9 irgendwo steht, er bringt keine richtige Sequenz mehr zum zeiten Prozessor, somit kann das System in einen definierten Zustand übergehen. Da sehe ich auch einmal das kleinere Problem drin. Gruß Sascha Literatur ???
Sascha schrieb: > In der Tat muss ich zugeben, dass ich vermutlich das mit den TLBs noch > nicht ganz verstanden habe. Die TLBs speichern page translations, die ja sonst recht viel Zeit in Anspruch nehmen können. Bei kritischen pages (ISR, vector table) kann man den Vorgang dadurch deterministischer gestalten, dass man einen der lock-down entries selektiert, und dann die nächste translation dort gespeichert wird bis der selbe entry erneut selektiert wird. > Die zweite CPU überprüft keine Laufzeiten, das ist natürlich unsinnig > bei dem Speed was der ARM9 hat. Ich meinte das auch gar nicht, sondern datenerhaltende Tests zur Laufzeit (im Gegensatz zu start-up Tests, die den Systemzustand im Allgemeinen beliebig umpflügen können). > Also egal was für ein Code beim Abflug des ARM9 irgendwo steht, er > bringt keine richtige Sequenz mehr zum zeiten Prozessor, somit kann das > System in einen definierten Zustand übergehen. Da sehe ich auch einmal > das kleinere Problem drin. Genau.
Sascha schrieb: > ja ich gebe euch recht, das ist in der Tad nicht ganz einfach, aber > nehmen wir mal folgendes an: Ich schreibe ein Programm das von A nach B > ableuft und mir in den Registern Ergebnisse bringt. Das Programm ist so > groß das es genau in den Cache passt. Es greift auf keine Daten zu nur > auf Literale. > Das Programm leuft einmal mit und einmal ohne Cache ab. Das Ergebniss > ist sozusagen bekannt. Nun lässt sich das Ergebniss prüfen. > (wird natürlich noch etwas aufwendiger gemacht...) Hallo Sascha, damit ist die Funktion des Caches noch nicht geprüft. Wie stellst Du fest, ob nicht durch mehrere unabhängig voneinander existierende Fehler das Literal falsch geladen wird und oder der Prozessor eine Sprung an's Ende macht und dann "Fertig" signalisiert? Ich denke dass einzig die Möglichkeit besteht, mit einem Cache-externen Test einzelne Zellen im rollierenden Verfahren zu testen - also ein Speichertest. Schwierig wird des auf den Cache zu kommen. Und der test muss ja nicht zwangsläufig in 1s durch sein (Siehe Speichertests). Was sagt eigentlich die zertifizierende Behörde (TÜV?) dazu, haben die Vorschläge? rgds
Hallo, ja was sagt der TÜV dazu? Das ist sowieso das nächste Problem. Eine SIL 2 ist auch wie CE eine Hersteller Selbsterklärung. Ich will damit jetzt aber auf gar keinen Fall sagen, dass ich irgendetwas vernachlässigen will. Natürlich kann man eine Zertifizierung machen und dadurch wird es auch Sinnig. Bei Atex wird auch SIL2 als voraussetzung gebraucht und muss von der BAM abgenommen werden. Kommt halt immer darauf an, in Welche Bereiche man mit der Zulassung rein will. Eigentlich brauche ich im Moment keine SIL 2 für mein Produkt, habe aber schon gehört es könnte verlangt werden. So aber nun zurück zur Technik. Hat jemand eine Idee wie man den I-Cache testen könnte? Es geht mehr darum wie lese ich die Daten aus dem I-Cache aus? Gruß Sascha PS. mein core Test geht schon und ich habe einige Fehler bei Keil und IAR im Simulator gefunden. Die Compiler Software ist weit aus mit mehr Fehler behaftet als mir lieb ist. Zum Glück programmiere ich die ernsten Dinge mit Assembler. Gibt es Zertifizierte Software Tools ??? Sind die dann auch Fehlerfrei ???
Sascha schrieb: > Eigentlich brauche ich im Moment keine SIL 2 für mein > Produkt, habe aber schon gehört es könnte verlangt werden. Kläre das zuerst. Vermeide die deutsche Ingenieurstugend des over-engineering mit scheinbar perfekten Produkten die es zu spät oder gar nicht auf den Markt schaffen. > PS. mein core Test geht schon und ich habe einige Fehler bei Keil und > IAR im Simulator gefunden. Die Compiler Software ist weit aus mit mehr > Fehler behaftet als mir lieb ist. Zum Glück programmiere ich die ernsten > Dinge mit Assembler. Wie hast Du die Fehler nachgewiesen? Bist Du sicher, dass es sich nicht um eine mögliche Fehlinterpretation des C Standards, bzw. des ARM ABI handelt? Davon abgesehen enthält jede Software Fehler. Auch Deine. > Gibt es Zertifizierte Software Tools ??? Ja. > Sind die dann auch Fehlerfrei ??? Das ist nicht Dein Ernst, oder?
Hallo Marcus, das mit dem C können wir definitiv ausklammern, da ich alle low level Routinen bis jetzt nur in Assembler schreibe. Würde in C auch gar keinen Sinn machen. Würde eh nur die C Anweisung ASM überall stehen..... Und der Code muss zur Kontrolle vor und zurück übersetzt werden können, so steht das bei SIL 2. Also was ist dann einfacher C oder Assembler? Aber bitte keine Grundsatzdiskusion über C oder Assembler das kann ich nicht mehr hören. Ich programmiere den ARM9 in Assembler im Schlaf, ist doch ein sehr einfacher und super durchdachter Befehlsatz. Habe meine ganze Grafik GUI bis hin zu Bresenham Linie,Kreis,Fontausgabe und Bildausgabe alles super schnell in Assembler programmiert. Wobei ich eigentlich eher von der CISC Schiene komme, als von der RISC. Also z.B. zu einem Fehler des Simulator bei IAR QDADD und QDSUB stimmt das Ergebnis nicht wenn die Quelle negativ in Sättigung ist und man addiert man eine kleine positive Zahl drauf. Bei QDSUB ist das in entsprechender Richtung auch so. Gruß Sascha
Sascha schrieb: > [...]Grundsatzdiskussion[...] Du hast geschrieben, dass Du Fehler in der "Compiler Software" gefunden hättest. Daher meine Frage. Andererseits ist mir schon aufgefallen, dass nicht ganz klar formuliert war, ob Du einen Fehler im Compiler oder dem Simulator vermutest. > Also z.B. zu einem Fehler des Simulator bei IAR QDADD und QDSUB stimmt > das Ergebnis nicht wenn die Quelle negativ in Sättigung ist und man > addiert man eine kleine positive Zahl drauf. Bei QDSUB ist das in > entsprechender Richtung auch so. Reine Neugier: Du hast das mit dem "echten" Prozessor verglichen? -- Marcus
Hallo Marcus, ich habe den Coretest auf dem echten Prozessor geschrieben, und wollte die Routine nur geschwind wegen einer CRC32 selbstüberprüfung auf dem Simulator testen dann kam das zum Vorschein. Ich war auch etwas verwundert ist aber so. Ich wundere mich da aber schon lange nicht mehr wirklich. Ich melde auch keine Fehler mehr, denn das entgegenkommen war all die Jahre super mittelmäßig. Es gibt da noch viel brutalere Fehler, die ich aber hier im Forum nicht rauslasse. Sonst könnten mir noch juristische Schritte drohen. Wenn z.B. eine Firma XXX ein automotive Produkt damit entwickelt und die Floating Point Routine hat einen Fehler ist das echt schockierend. Auf der Messe habe ich dieses Problem angesprochen und bin dabei noch angeraunzt worden. Was soll ich da noch dazu sagen, man passt nicht ins Bild. Wer unbequem ist wird Heute aus dem System entfernt oder ignoriert. Deshalb mache ich meine Soße nur noch für mich alleine. Gruß Sascha
Sascha schrieb: > vor und zurück übersetzt werden können, > so steht das bei SIL 2. Hallo Sascha, was meinst Du damit? rgds
Hallo 6A66, ganz einfach DIN EN 61508-1 bis -7 oder genauer DIN EN 61508-3 der Softwareteil lesen. Unter anderem heißt es, die Tools zur Generierung des Codes müssen überprüft werden. D.H. es muss jeder Code der erzeugt wird auch rückwärts übersetzt werden (Kontrolliert werden) um sicher zu stellen, dass das was man haben will (an Code) auch dem entspricht was man programmiert hat. Es genügt nicht den Compiler,Assembler und Linker zu evaluieren, da die Kombination von aufeinandertreffenden Opcodes nicht vorhersehbar ist. Dem kann ich nur zustimmen, wenn man bedenkt, was manche Produkte (Compiler usw.) durch ihre optimierungsphase alles verfälschen. Was natürlich noch besser ist man arbeitet mit zwei verschiedenen Tools. Z.B. GNU,Keil,IAR usw. man muss natürlich aufpassen das kein Tool vom anderen übernommen/abgeleitet oder weiterentwickelt wurde, sonst können ähnliche Fehler enthalten sein. Gruß Sascha
Sascha schrieb: > die Tools zur Generierung > des Codes müssen überprüft werden. D.H. es muss jeder Code der erzeugt > wird auch rückwärts übersetzt werden (Kontrolliert werden) um sicher zu > stellen, dass das was man haben will (an Code) auch dem entspricht was > man programmiert hat. Es genügt nicht den Compiler,Assembler und Linker > zu evaluieren, da die Kombination von aufeinandertreffenden Opcodes > nicht vorhersehbar ist. Hallo Sascha, das würde ich aber mit den zertifizierenden Stellen mal diskutieren! Bei einem Code von 128kB in C müssten 128kB Op-Code von Hand zu Assembler und C zurückinterpretiert werden und dann der Erfolg verifiziert werden? Das ist nach meinem dafürhalten NICHT die Intention der 61508! Dafür sollte es zertifizierte Compiler und Assembler geben! rgds
Sascha schrieb: > die Tools zur Generierung > des Codes müssen überprüft werden. Da hast Du recht. Aber das kann auch durch den Hersteller der Werkzeuge geschehen. Und du musst nicht das Ergebnis der Werkzeuge sondern die Werkzeuge selbst prüfen. rgds
Hallo, abgesehen davon gibt es auch andere Methoden als das Rückübersetzen, um das Ergebnis der Toolkette zu validieren. Richtig angesetzt fällt dann der Compiler und Linker häufig in die nicht zu qualifizierenden Bereiche. Ich habe schon Beispiele gesehen, bei denen aus einer Toolkette mit 40 verschiedenen Tools nur zwei als kritisch angesehen wurden. Und das waren Tools zum Verwalten von Requirements und zum Validieren der Testergebnisse. Hinweise zur Toolqualifikation können auch die von der 61508 abgeleiteten Fachnormen geben z.B. die ISO 26262 (Automotive) oder die DO-178C (Luftfahrt). Zum ursprünglichen Thema: Hast Du den Hersteller Deines µC mal befragt, ob es schon fertige Ebene-3-Bibliotheken gibt? Denn das Problem, was Dir gerade in Form des I-Cache begegenet, gibt es eine Ebene tiefer noch zu Hauf in den Prozessoren: Pipelines, Out-of-Order-Execution, Branch Predictions,... die alle dafür sorgen (so sie einen Fehler enthalten), dass Dein Ebene-2-Code eventuell nicht mehr so funktioniert, wie erwartet. So richtig beherrschen kann man das entweder nur mit Hilfe des µC-Suppliers, oder indem man so viele der laufzeitveränderlichen Elemente wie möglich abschaltet (Caches, MMU,...) und dann die Ebene-2-Software mit Testdatensätzen als Instruction-Set-Test durchrechnen lässt. Allerdings kommt man damit auch in Bereiche, in denen normalerweise redundante Systeme eingesetzt werden. Apropos redundant: Wie stellst Du sicher, dass bei einem falsch arbeitenden µC trotzdem immer der sichere Zustand angesteuert werden kann? Watchdog oder kleiner Zweit-µC? Ausserdem erweckt es den Anschein, als ob Du zwar Teile der 61508 verwendest, um Dein Produkt zu designen, Du allerdings nicht die 61508 vollständig umgesetzt hast. Als erstes wird nach der Item-Definition normalerweise eine Gefahren- und Risikoanalyse für das Zielsystem durchgeführt, und daraus dann der maximale SIL bestimmt, nach dem entwickelt werden muss. Damit entfällt dann in der Regel das "...habe aber schon gehört es könnte verlangt werden". Ebenso scheinst Du noch nicht ganz sicher in der Interpretation der 61508 zu sein - diese fordert aber, dass die Mitarbeiter entsprechend ihrer Aufgaben kompetent sind (und entsprechend weitergebildet werden). Ebenso muss ein entsprechender Sicherheitslebenszyklus aufgesetzt werden (siehe Teil 1 der Norm), inkl. unabhängiger Prüfung der erarbeiteten Ergebnisse (soviel zur Selbst-Zertifizierung). Ohne dass jedoch die ganze Norm abgearbeitet wurde, ist das System nicht IEC61508-konform und Du stehst ggf. mit einem Bein im Gefängnis, wenn Du die Verantwortung dafür übernimmst. Insofern kann ich nur empfehlen, mit dem (oder einem möglichen zukünftigen) Auftraggeber die Anforderungen durchzusprechen und basieren darauf (auch mit den Zulieferern der Teile und Tools) die notwendigen Maßnahmen festzulegen (und Disassemblieren gehört dann ziemlich sicher nicht dazu...) Schöne Grüße, Martin
Hallo Martin, Ich habe alle Teile der DIN gelesenen, habe aber viele Anwendungen für das Gerät. Muss aber alles einbeziehen, damit die Hardwarebasis auch für eine SIL 2 Entwicklung hinreicht. Das alles hier im Vorum geschwind zu erklären würde den Rahmen sprengen. Ich arbeite schon ca. 16 Jahre in dieser Branche und kenne auch Produkte für SIL 1 und SIL 2. Da leider nicht nur mein Steuergerät in die Bewertung der gesammten Anlage eingeht, ist es unheimlich komplex. Eine SIL 2 wird meistens nicht verlangt, weil die Sicherheit an anderer Stelle des Systems erzeugt wird. Nur geht meine Weiterentwicklung die kommenden Jahre Richtung ATEX mit BAM Zulassung, und da ist SIL 2 verlangt. Ich werde mich in der Tat nach einem Berater umschauen müssen, der die SIL2 Geschichte begleitet. Gruß Sascha
Sascha schrieb: > Hallo Martin, > Ich habe alle Teile der DIN gelesenen, habe aber viele Anwendungen für > das Gerät. Muss aber alles einbeziehen, damit die Hardwarebasis auch für > eine SIL 2 Entwicklung hinreicht. Das alles hier im Vorum geschwind zu > erklären würde den Rahmen sprengen. Ich arbeite schon ca. 16 Jahre in > dieser Branche und kenne auch Produkte für SIL 1 und SIL 2. Da leider > nicht nur mein Steuergerät in die Bewertung der gesammten Anlage > eingeht, ist es unheimlich komplex. Eine SIL 2 wird meistens nicht > verlangt, weil die Sicherheit an anderer Stelle des Systems erzeugt > wird. Nur geht meine Weiterentwicklung die kommenden Jahre Richtung ATEX > mit BAM Zulassung, und da ist SIL 2 verlangt. Ich werde mich in der Tat > nach einem Berater umschauen müssen, der die SIL2 Geschichte begleitet. > Gruß Sascha Hallo Sascha, vielleicht hilft Dir so etwas: "IAR hat ARM-Workbench nach IEC61508 zertifiziert". http://marketing.iar.com/acton/rif/1011/s-0478-1304/-/l-sf-rpt-00O30000005pcvK-6988:52e/l-sf-rpt-00O30000005pcvK-6988/showPreparedMessage rgds
Hallo 6A66, Ja super, der Link ist klasse, das bringt mich auch mal in die richtige Richtung. Die SIL Einstufung und Bewertung kann ich bei meinem Projekt nicht alleine bestimmen sondern bekomme die Vorgaben von meinem Prüfingeneur (Projektingeneur), der die Systemberwertung macht vorgegeben. Ich muss nur alle Maßnahmen dafür ergreifen, das mein Part sozusagen conform ist. Danke, Gruß Sascha
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.