Funktionale Sicherheit
Aufgrund grosser Veränderungen auf dem Markt und in unserer Firma muss
ich mich einem anderen Thema widmen und zwar Funktionale Sicherheit. Die
IEC61508 ist gelesen und soweit auch verstanden. Die Normen sind aber
sehr allgemein gehalten.
Ich bin gerade dabei für CPU Selbst Test Bibliotheken zu entwickeln.
Laut IEC61508-2 Anhang A müssen die CPU Bestandteile auch periodisch
geprüft werden. Nehmen wir an ich habe für Trumb V7 für jedes Befehl
eine Test-Funktion nach „walking bit (one-channel)“ Technik
geschrieben. Jetzt stellt sich die Frage - Wie soll ich aber die
Units-Tests für diese Funktionen implementieren. Ich nehme ein
Beispiel:
1
ADC <Rd>, <Rm>+ Add the register value and the C-flag to the register value.
2
Rd = Rd + Rm + C
1
PUSH {R14}
2
BL stlCpuInitApsr
3
ADCS R0, R1
4
5
POP {R14}
6
B stlCpuSaveApsr
7
8
9
END
Wie kann man dort einen Fault Injection produzieren?
Danke an alle
A. S. schrieb:> Diagnose wird nicht diagnostiziert.
Abschnitt 5 beschreibt die Verwendung des Fehlerinjektionssystems zur
Validierung der generischen Selbsttests anhand der IEC
61508-Anforderungen für CPU-Selbsttests.
Russe schrieb:> Ich bin gerade dabei für CPU Selbst Test Bibliotheken zu entwickeln.
Der Hersteller hat keinen solchen, den er dir bereitstellen kann?
Russe schrieb:> Wie kann man dort einen Fault Injection produzieren?
Breakpoint setzen, Fehler injizieren, weiterlaufen lassen, schauen ob es
wie erwartet knallt?
Achim M. schrieb:
> Breakpoint setzen, Fehler injizieren, weiterlaufen lassen,> schauen ob es wie erwartet knallt?
Meine Erfahrung:
Erstens knallt es anders - und zweitens als man denkt.
Probleme an "problematischen Punkten" werden natürlich gut erkannt,
weil man sie vorher identifiziert und mit Testpunkten/Testroutinen
umzingelt hat. - Gähn, schnarch, ...
Was hilft sowas gegen Schwachstellen in der Programmierung, die noch
nicht erkannt sind? Eher NIX.
Jucki schrieb:> Achim M. schrieb:>> Breakpoint setzen, Fehler injizieren, weiterlaufen lassen,>> schauen ob es wie erwartet knallt?>> Meine Erfahrung:> Erstens knallt es anders - und zweitens als man denkt.>> Probleme an "problematischen Punkten" werden natürlich gut erkannt,> weil man sie vorher identifiziert und mit Testpunkten/Testroutinen> umzingelt hat. - Gähn, schnarch, ...>> Was hilft sowas gegen Schwachstellen in der Programmierung, die noch> nicht erkannt sind? Eher NIX.
Es geht nicht darum ob etwas knallt. Es geht um ein Produkt der nach
IEC61508 (SIL2)entwickelt wird. Wir waren zur Abklärung beim Tüv Süd und
grob geschildert was wir vorhaben. Die waren im Grunde mit dem Prinzip,
was wir vorgeschlagen hatten, einverstanden. Jetzt geht es darum wie man
nach den Normen das Ganze implementiert. Und natürlich sind die
Selbst-tests von der Hardware enorm wichtig. Leider ist der Tüv da nicht
wirklich eine Hilfe, da Sie immer betonen - Sie machen wir schauen
drüber. Wie man etwas genau machen sollte sagen die nicht. Und in so
einem Fall geht es um die Zeit und das liebe Geld. Die Stunde kostet
dort 165 Euro + MwSt.
Russe schrieb:> da Sie immer betonen - Sie machen wir schauen> drüber. Wie man etwas genau machen sollte sagen die nicht. Und in so> einem Fall geht es um die Zeit und das liebe Geld.
Eben. Die Normen sollen einen dazu verleiten, viel mehr Geld auszugeben,
als notwendig. Da macht man lieber zu viel als zu wenig, den mehrere
Runden durch den Audit zu drehen wird auch wieder teurer.
Das ist wie bei den Juristen eine Branche, die sich selbst Arbeit
beschafft.
Konkrete Anweisungen bekommst du nicht, weil man sich ja später im
Schadenfall darauf berufen könnte. Dazu müsste dann ja jemand
Verantwortung tragen. Vielleicht ist es dir noch nicht aufgefallen, aber
heutzutage wälzt man Verantwortung auf die Leute ab, die nicht schnell
genug weglaufen können und nicht die finanziellen Mittel haben, sich
dagegen zu wehren.
Russe schrieb:> Leider ist der Tüv da nicht> wirklich eine Hilfe, da Sie immer betonen - Sie machen wir schauen> drüber.
Jepp. Die müssen unabhängig sein und bewerten.
Wenn Sie die Lösung vorgeben sind sie befangen.
Es gibt Dienstleister die so etwas machen. kostet halt wieder.
In welcher Branche wird das Gerät genutzt ?
High/Low demand ?
Ein oder mehrkanalige HW?
Stefan ⛄ F. schrieb:> Eben. Die Normen sollen einen dazu verleiten, viel mehr Geld auszugeben,
Du musst keine Normen anwenden, sie sind kein Gesetz.
Gesetzte und Richtlinien (der EU) musst du einhalten.
Mit Normen ist dies meist einfacher (Beweisslastumkehr)
Jucki schrieb:> Achim M. schrieb:>> Breakpoint setzen, Fehler injizieren, weiterlaufen lassen, schauen ob es>> wie erwartet knallt?>> Meine Erfahrung: Erstens knallt es anders - und zweitens als man denkt.
Es geht hier aber um einen Negativ-Test mit erwarteten Ergebnis. Also
keinen Sunshine-Test. Danke für nichts.
Geht es hier um
a) einen Selbsttest zur Laufzeit
b) einen Integrations-/Unit-Test
wenn es auf letzteres argumentierbar ist, umso besser.
Um auf b) zu kommen, hilft meist die Argumentation, dass dieser
Sicherheitsmechanismus gegen einen latenten Fehler testet. Damit muss
kein Fault-Injection zur Laufzeit, sondern nur zur Entwicklung gemacht
werden.
mfg mf
FuSiX schrieb:> Russe schrieb:>> Leider ist der Tüv da nicht>> wirklich eine Hilfe, da Sie immer betonen - Sie machen wir schauen>> drüber.>> Jepp. Die müssen unabhängig sein und bewerten.> Wenn Sie die Lösung vorgeben sind sie befangen.>> Es gibt Dienstleister die so etwas machen. kostet halt wieder.>> In welcher Branche wird das Gerät genutzt ?> High/Low demand ?> Ein oder mehrkanalige HW?
Es wird in Robotik eingesetzt. High demand System, an sich nichts
komplexes nur zwei Analogwerte miteinander vergleichen. Zur Absicherung
haben wir uns für ein zweikanaliges System entschieden.
Wenn es ein Dienstleister macht dann hat er knowhow und beim nächsten
System sind wir dann genauso weit wie jetzt.
Achim M. schrieb:> Jucki schrieb:>> Achim M. schrieb:>>> Breakpoint setzen, Fehler injizieren, weiterlaufen lassen, schauen ob es>>> wie erwartet knallt?>>>> Meine Erfahrung: Erstens knallt es anders - und zweitens als man denkt.>> Es geht hier aber um einen Negativ-Test mit erwarteten Ergebnis. Also> keinen Sunshine-Test. Danke für nichts.>> Geht es hier um> a) einen Selbsttest zur Laufzeit> b) einen Integrations-/Unit-Test> wenn es auf letzteres argumentierbar ist, umso besser.>> Um auf b) zu kommen, hilft meist die Argumentation, dass dieser> Sicherheitsmechanismus gegen einen latenten Fehler testet. Damit muss> kein Fault-Injection zur Laufzeit, sondern nur zur Entwicklung gemacht> werden.>> mfg mf
Die Norm erfordert 100%ges Code Covering. Und da stelle ich mir die
Frage wie ich alle else abdecken soll.
1
u32Result=(*(*pfnCpuAddFunc))(
2
*pu32AddInputValueA,
3
*pu32AddInputValueB,
4
*pu8AddInputValueAPSR);
5
6
if(*pu8AddInputValueAPSR!=0xFF){
7
u8APSRValue=stlCpuGetApsr();
8
/** Calculating value or APSR value error occur */
Achim M. schrieb:> Um auf b) zu kommen, hilft meist die Argumentation, dass dieser> Sicherheitsmechanismus gegen einen latenten Fehler testet. Damit muss> kein Fault-Injection zur Laufzeit, sondern nur zur Entwicklung gemacht> werden.
Das Feindbild ist das eine PPM an defekten CPUs (Maskenfehler oder
Schädigung durch Umwelteinflüsse)zu finden bevor der Fehler einen
Menschen verletzt.
Da hilft keine Argumentation.
Die Tests müssen in der Regel auch so angelegt sein daß die
Fehlerreakton (hochzählen einens Fehlerzählers zur Abschaltung der
Endstufen) mitgetestet wird.
Gruß Anja
FuSiX schrieb:> Mit Normen ist dies meist einfacher (Beweisslastumkehr)
Das ist leider zu kurz gedacht. Kommt es zu einem Schaden gilt das
Produkthaftungsgesetz. Da mußt Du dann beweisen daß Du alles nach dem
Stand der Technik (Enhaltung der zum Zeitpunkt des Inverkehrsbringens
gültigen Normen) getan hast um den Schaden zu verhindern.
Gruß Anja
>> Achim M. schrieb:>>> Breakpoint setzen, Fehler injizieren, weiterlaufen lassen,>>> schauen ob es wie erwartet knallt?Russe schrieb:> Es geht nicht darum ob etwas knallt. Es geht um ein Produkt der nach> IEC61508 (SIL2)entwickelt wird.
Dann konkretisiere Dein Problem.
Wenn es nur um die Diagnose geht, dann ist die Methode von Achim M. OK.
Russe schrieb:> Wenn es ein Dienstleister macht dann hat er knowhow und beim nächsten> System sind wir dann genauso weit wie jetzt.
Nein, dann habt Ihr ein Referenzsystem und macht es beim nächsten analog
dazu.
Russe schrieb:> Die Norm erfordert 100%ges Code Covering. Und da stelle ich mir die> Frage wie ich alle else abdecken soll.
Aber in einem anderen Kontext. Beschreibe doch mal Dein Problem, dass Du
nicht mit Breakpoint und knallen lassen lösen sollst, kannst, willst.
Prinzipiell ist 100% Code Coverage ja kein Problem, da Du jede Routine
wie auch immer gemocked aufrufen kannst.
Anja schrieb:> Das ist leider zu kurz gedacht. Kommt es zu einem Schaden gilt das> Produkthaftungsgesetz
Volle Zustimmung. Ich hab's nur stark vereinfacht. Produkthaftungsgesetz
gilt halt immer. Auch bei nicht safety...
Russe schrieb:> Es wird in Robotik eingesetzt. High demand System, an sich nichts> komplexes nur zwei Analogwerte miteinander vergleichen. Zur Absicherung> haben wir uns für ein zweikanaliges System entschieden.
Für ein SIL2, HFT1, HighDemand System mit Complexen Bauteilen (uCs...)
müsst Ihr ein SFF ≥ 60% nachweisen. Das müsst Ihr in Eure Argumentation
einbauen. Ich braucht keine hohe Diagnosedeckung in jedem Subsystem.
Ich habe solche Systeme schon komplett ohne CPU Selbsttest realisiert.
Das hängt davon ab, wie gut man die Datenverarbeitung der beiden Kanäle
zur Laufzeit vergleichen kann. Dann decken die Kanäle die Fehler
gegenseitig auf.
(Vorischt: jedes System ist anders... ich behaupte nicht, dass es bei
Euch auch geht!! )
> Wenn es ein Dienstleister macht dann hat er knowhow und beim nächsten> System sind wir dann genauso weit wie jetzt.
Falsch gedacht, er ist Dienstleister und liefert Dir natürlich alle
Ergebnisse in Dokumentation und Quellcode.
CPU Selbsttests würde ich selber nicht machen sondern zukaufen.
Der Aufwand wir IMMER unterschätzt. Und was machst Du mit dem Know How?
Dein Produkt Know How ist IMHO wichtiger.
<Ironie>Ich kauf meine uCs auch zu und designe sie nicht selber....
</Ironie>
Russe schrieb:> Die Norm erfordert 100%ges Code Covering.
Nach Tabelle B.2 (EN61508-3) braucht Ihr für SIL2 eine 100%
Testabdeckung für Anweisungen (nicht für Verzweigungen oder
Bedingungen).
Lies Dir das mal genau durch.
Und gerade bei CPU Tests ist es oft schwer 100% aller Verzweigungen und
Bedingungen abzudecken. Da gilt:
Ausnahmen sind zu dokumentieren / zu begründen.
Was man immer verinnerlichen sollte:
Wir können nicht alle Fehler beseitigen.
Wir können nur versuchen zufällige (HW) Fehler zu beherrschen und
systematische Fehler zu minimieren.
Kein System ist 100% sicher. (Wer das behauptet hat das Prinzip nicht
verstanden).
Ergänzung:
Unabhängig ob Ihr 100% Codecoverage in den Tests Eurer Diagnose
erreicht:
ihr müsst in der Verifikation nachweisen, dass die Diagnose im kleinen
auch am Ende das Große abschaltet.
Früher gab's auch schon nicht angeschlossene Nothalt Schalter.
A. S. schrieb:> Russe schrieb:>> Die Norm erfordert 100%ges Code Covering. Und da stelle ich mir die>> Frage wie ich alle else abdecken soll.>> Aber in einem anderen Kontext. Beschreibe doch mal Dein Problem, dass Du> nicht mit Breakpoint und knallen lassen lösen sollst, kannst, willst.>> Prinzipiell ist 100% Code Coverage ja kein Problem, da Du jede Routine> wie auch immer gemocked aufrufen kannst.
Eben, das ist die Frage wie kann ich z.B. bei oben genannter Funktion
alle Abzweige abdecken. Ich habe um die 80 unterschiedlichen CPU
Komandos und sollten zyklisch aufgerufen werden.
1
PUSH {R14}
2
BL stlCpuInitApsr
3
NEGS R0, R1
4
5
POP {R14}
6
B stlCpuSaveApsr
Also heisst es ich setze einen Breakpoint nach NEGS Befehl und ändere
über Debug Interface den Inhalt des Registers. So lande ich im
Else-Zweig. Verstehe ich es richtig?
FuSiX schrieb:> Und gerade bei CPU Tests ist es oft schwer 100% aller Verzweigungen und> Bedingungen abzudecken. Da gilt:> Ausnahmen sind zu dokumentieren / zu begründen.
vielen Dank für die konstruktiven Anmerkungen! Könntest du mir sagen wie
die Argumentation lauten soll? technisch nicht realisierbar, da man in
der CPU Architektur keine Möglichkeit für Fault Injection vorgesehen
hat?
FuSiX schrieb:> Nach Tabelle B.2 (EN61508-3) braucht Ihr für SIL2 eine 100%> Testabdeckung für Anweisungen (nicht für Verzweigungen oder> Bedingungen).> Lies Dir das mal genau durch.
Die Anforderungen in der Robotik sind zum Glück nicht so hoch wie bei
der Ind. Automatisierung. Aber die werden sicher strenger werden. Somit
dachten wir für die Zukunft, orientieren wir uns an SIL3.
Russe schrieb:> Ich habe um die 80 unterschiedlichen CPU> Komandos und sollten zyklisch aufgerufen werden.
zyklisch nur der Test. Die Verifikation nur einmal. Und die Kommandos
jeweils mit jeder Adressierungsart.
Russe schrieb:> Also heisst es ich setze einen Breakpoint nach NEGS Befehl und ändere> über Debug Interface den Inhalt des Registers. So lande ich im> Else-Zweig. Verstehe ich es richtig?
Ja.
Wobei ich immer noch nicht weiß, wo Du genau bist:
Wenn Du ein Kommando testest, dann ändert ein Kommando einen
Kontrollfluss oder einen Wert. Das kannst Du automatisch testen.
Funktioniert increment? 4 vorgeben, incrementieren, schauen ob jetzt 5
drin steht. Fehlerreaktion testen? 4 vorgeben, incrementieren, schauen
ob jetzt 6 drin steht.
Russe schrieb:> Die Anforderungen in der Robotik sind zum Glück nicht so hoch wie bei> der Ind. Automatisierung. Aber die werden sicher strenger werden. Somit> dachten wir für die Zukunft, orientieren wir uns an SIL3.
OK. Argument. Aber ein gefährliches...
Oft macht man für die Zukunft zuviel...
>Könntest du mir sagen wie die Argumentation lauten soll?> technisch nicht realisierbar, da man in der CPU Architektur keine Möglichkeit
für Fault Injection vorgesehen hat?
Du hast die Antwort schon gegeben.
(Man sollte natürlich dass auch geprüft haben und schriftlich
festgehalten was man nicht per fault injection test getestet hat.)
Wie hast du ermittelt welche Assembler Befehle du per CPU Test testest?
FuSiX schrieb:> Wie hast du ermittelt welche Assembler Befehle du per CPU Test testest?
Alle die verwendet werden, in jeder Adressierungsart. Da ist es
einfacher, zu schauen ob man überhaupt welche ausschließen kann. Ist bei
einem C-Compiler schwierig.
Russe schrieb:> Nehmen wir an ich habe für Trumb V7
Was soll das sein, baut Donald jetzt auch CPUs?
Ich würde erstmal die Hersteller fragen, welche Controller speziell für
Sicherheitsanwendungen im Programm haben. Die haben bestimmt schon
fertige Libs im ROM-Code, Flash/RAM mit ECC, Taktüberwachung,
Fertigungstests usw.
Sicherheit läßt sich auch nie allein durch Software erreichen. Immer
noch State of the Art ist der Interlockschalter, der abschaltet, sobald
ein Mensch die Schutzhaube öffnet.
Russe schrieb:> Wenn es ein Dienstleister macht dann hat er knowhow
Dienstleister kochen auch nur mit Wasser. Du bezahlst Sie für die
Anwälte und Versicherungen, falls mal was schief läuft.
Oder sie beraten Dich unverbindlich, d.h. die volle Verantwortung bleibt
bei Dir.
Russe schrieb:> /** Set error flag */> b1TimeErrorFlag = TRUE;
Ein anderes Thema: Das ist kein guter Kommentar. Generell sollte man
nicht das im Kommentar wiederholen was man mit vernünftiger
Variablenbenennung ohnehin dem Code entnehmen kann. Stattdessen sollte
man kommentieren warum man etwas mach.
Peter D. schrieb:> Russe schrieb:>> Nehmen wir an ich habe für Trumb V7>> Was soll das sein, baut Donald jetzt auch CPUs?>> Ich würde erstmal die Hersteller fragen, welche Controller speziell für> Sicherheitsanwendungen im Programm haben. Die haben bestimmt schon> fertige Libs im ROM-Code, Flash/RAM mit ECC, Taktüberwachung,> Fertigungstests usw.>> Sicherheit läßt sich auch nie allein durch Software erreichen. Immer> noch State of the Art ist der Interlockschalter, der abschaltet, sobald> ein Mensch die Schutzhaube öffnet.
In der Ind. Automatisierung ist es unüblich spezielle Hardware für die
funktionelle Sicherheit zu verwenden. Beckhoff setzt z.B bei den
Safety-Produkten auf die einfachen PIC24E -16 bit Mikrocontrollern. ST
empfiehlt auch ihre universale STM32 Serie. Die Hersteller haben selbst
keine Bibliotheken und verweisen gen auch solche Firmen wie Hitex oder
Embex …
physicist schrieb:> Russe schrieb:>> /** Set error flag */>> b1TimeErrorFlag = TRUE;> Ein anderes Thema: Das ist kein guter Kommentar. Generell sollte man> nicht das im Kommentar wiederholen was man mit vernünftiger> Variablenbenennung ohnehin dem Code entnehmen kann. Stattdessen sollte> man kommentieren warum man etwas mach.
Danke, solche Kritik ist sehr willkommen.
A. S. schrieb:>> Wie hast du ermittelt welche Assembler Befehle du per CPU Test testest?> Alle die verwendet werden, in jeder Adressierungsart. Da ist es> einfacher, zu schauen ob man überhaupt welche ausschließen kann. Ist bei> einem C-Compiler schwierig.
Du hast die Frage nach dem "was" beantwortet, er hat aber nach dem "wie"
gefragt. Woher willst du wissen, dass durch eine Fehlfunktion nicht
viele Testfälle übersprungen wurden?
Peter D. schrieb:> Immer noch State of the Art ist der Interlockschalter, der abschaltet, sobald
ein Mensch die Schutzhaube öffnet.
Das änder sich gerade.
Viele Applikationen arbeiten ohne Schutzzaun z.B. Kollaborierende
Roboter.
Auch bei autonomen Autos hängt die Sicherheit mehr an der Software als
an der ausführenden Hardware....
Stefan ⛄ F. schrieb:> Woher willst du wissen, dass durch eine Fehlfunktion nicht viele Testfälle
übersprungen wurden?
Die Online Diagnose sollte über eine Programmlaufkontrolle gekapselt
sein,
die erkennt, wenn einzelne Tests nicht ausgeführt wurden.
(bzw. andersrum, die einen Watchdog nur dann triggert, wenn alle Tests
durchlaufen wurden).
Peter D. schrieb:> Eine kurze Suche ergab z.B. die Hercules Familie von TI mit integrierten> Diagnosefunktionen (BIST usw.):> https://www.ti.com/de-de/microcontrollers/hercules-safety-mcus/overview.html
Diese Controller "können" helfen. Sind allerdings auch komplex und haben
auch Fehler. Sie machen dann Sinn, wenn man z.B. ein einkanaliges System
aufbaut.
Kein Aufwand für Datenaustausch zw. Kanälen, keine Probleme der
Synchronisation. zw. den Kanälen.
In zweikanaligen Systemen findet man sie seltener. Dort kommen oft
"normale" Controller zum Einsatz.
FuSiX schrieb:> Diese Controller "können" helfen. Sind allerdings auch komplex und haben> auch Fehler. Sie machen dann Sinn, wenn man z.B. ein einkanaliges System> aufbaut.> Kein Aufwand für Datenaustausch zw. Kanälen, keine Probleme der> Synchronisation. zw. den Kanälen.>> In zweikanaligen Systemen findet man sie seltener. Dort kommen oft> "normale" Controller zum Einsatz.
Falsch. Wir setzen sie in der Luftfahrt in 3 und 4-kanaligen Systemen
ein. Warum sollte ein Controller, der bzgl. functional safety optimiert
ist, in zwei- oder mehrkanaligen Systemen nicht helfen können, bestimmte
Objectives zu erreichen?
Wie testet man denn eigentlich Hint-Anweisungen wie "dsb" oder
Cache-Maintenance-Operations wie "DCCMVAC"? Es lässt sich nur schwierig
prüfen ob die ausgeführt wurden oder ob die CPU die Operation sowieso
schon gemacht hatte und die Instruktion ohnehin wirkungslos war, aber
ggf. nicht immer funktioniert.
Wenn man Werte in den RAM schreibt die dann per DMA abgeholt werden,
sollte man ja sicherstellen können dass die DMA-Einheit auch die
aktuellen Werte sieht...
Dinge wie "SVC" oder "CPS" sind da ja noch "vergleichsweise einfach".
Wie stellt man sicher dass man die MMU korrekt konfiguriert hat und
Register-Zugriffe auch wirklich bei der Peripherie landen und nicht
sporadisch (so 1x in 1000000 Fällen oder so) alte Werte gelesen werden?
Wie prüft man atomic Zugriffe (LDREX+STREX) - hier bestimmte Fälle zu
"mocken" stelle ich mir ziemlich kompliziert vor weil man mehrere
CPU-Kerne oder ISRs synchronisieren muss.
Was ist mit den SIMD-Instruktionen?
DO-178C schrieb:> Falsch. Wir setzen sie in der Luftfahrt in 3 und 4-kanaligen Systemen
Sorry, zu sehr verallgemeinert. Alles eine Frage des Sicherheitslevels,
der Applikation, der Restrisiko Sicht der entwickelnden Menschen (oder
derer die dem Teil ausgeliefert sind) und natürlich des Geldbeutels...
In Industriellen Anlagen im Bereich SIL2 und SIL3 wird das "häufig" so
gemacht. Vermutlich setzt Ihr aber auch nicht 4mal den gleichen
Controller mit den gleichen Bugs in einem System ein....
Programmierer schrieb:> Wie testet man denn eigentlich Hint-Anweisungen wie "dsb" oder>...>...>...
Genau deshalb halte ich nichts davon, die gesamte Sicherheit der CPU
über solche Selbsttests zu begründen. Zuviele Internas, die wenig/nicht
dokumentiert sind oder beeinflussbar sind.
Du wirst nicht alle Fehler aufdecken. (Denk an Deine SFF=90%).
Selbst bei den ICs wie die obigen von TI bekommst Du nur einen
Diagnosedeckungsgrad < 100%.
>Wie stellt man sicher dass man die MMU korrekt konfiguriert hat und>Register-Zugriffe auch wirklich bei der Peripherie landen und nicht>sporadisch (so 1x in 1000000 Fällen oder so) alte Werte gelesen werden?
Indem man die Signalverarbeitung als Ganzes betrachtet (denn Fehler
passieren ja nicht nur auf Registerebene...) und Top-Down mögliche
Fehler in der Kette analysiert, prüft wie sie sich auswirken und ob die
genutzten Diagnosen ausreichen oder ergänzt werden sollten.
Habt Ihr bei der Prüfstelle nur einzelne Maßnahmen vorgestellt oder habt
Ihr ein "schlüssiges" Sicherheitskonzept präsentiert?
(davon unabhängig kann man eine MMU natürlich auch zyklisch testen)
Thread beobachten
Seitenaufteilung abschalten