Hallo,
meiner vielleicht kurzsichtigen Meinung nach,
ist es nicht notwendig das komplette Ram eines uC zu testen.
D.h.,
falls ein Projekt nur 10% des zur Verfügung stehenden Ram benötigt,
muss ich auch keinen grösseren Bereich testen?
Es sollte ja eigentlich genügen, nur nach dem Reset das gesammte
adressierbare Ram und im laufenden Betrieb,
z.B. mit einem Hintergrund Prozess,
nur den verwendeten und auch im Linker-Config-File festgelegten Bereich
zu prüfen?
Sorry, falls ich Euch mit offensichtlichen Tatsachen langweile ...
Hätte trotzdem gerne eine Antwort :-)
lg
Urlauber
Urlauber schrieb:> und im laufenden Betrieb,> z.B. mit einem Hintergrund Prozess,> nur den verwendeten und auch im Linker-Config-File festgelegten Bereich> zu prüfen?
Du willst in einem laufenden System das RAM testen?
MfG Klaus
konnte bei den AVR gehen wenn man den Stackpointer versetzt einen
Bereich testet und dann den Stack inkl. des Inhaltes wieder dorthin
setzt. RAMEND setzt ja der Assembler je nach Auswahl des µC im AVR
Studio, aber das kann man bestimmt auch manuell machen.
init: ;Stackpointer initialisieren
ldi temp, RAMEND
out SP, temp
oder bei den größeren Typen
ldi temp, low(RAMEND) ;Stackpointer initialisieren
out SPL, temp
ldi temp, high(RAMEND)
out SPH, temp
ich kann mir aber nicht vorstellen das ein µC mit defektem RAM die
Produktion verlässt. Das sollte doch ein 1A Kriterium zum Aussortieren
sein.
denke nicht, ich hatte auch noch nicht das Bedürftniss danach, habe da
mal ATMEL vertraut und bisher noch keine Enttäuschung erfahren.
Ich glaube aber mal gelesen zu haben das im Automotivbereich
irgendwelche Tests vorgeschrieben sind, keine Ahnung ob es sich um das
Programm selber handelt -> Checksumme oder ob explizit ein RAM Test
erforderlich ist.
Urlauber schrieb:> falls ein Projekt nur 10% des zur Verfügung stehenden Ram benötigt,> muss ich auch keinen grösseren Bereich testen?
Das hängt möglicherweise auch mit der Sicherheitsstufe zusammen die du
erreichen willst / mußt. Für SIL2 / ASIL B sollte es reichen.
Urlauber schrieb:> und im laufenden Betrieb,> z.B. mit einem Hintergrund Prozess,> nur den verwendeten und auch im Linker-Config-File festgelegten Bereich> zu prüfen?
Je nach Sicherheitsstufe reicht eventuell auch nur der RAM-Bereich der
Überwachungsfunktionen.
Klaus schrieb:> Du willst in einem laufenden System das RAM testen?
Interruptsperre nicht vergessen. Insbesonders für die Stack-Bereiche.
Thomas O. schrieb:> ich kann mir aber nicht vorstellen das ein µC mit defektem RAM die> Produktion verlässt. Das sollte doch ein 1A Kriterium zum Aussortieren> sein.
In sicherheitskritischen Anwendungen geht es darum die (< 1ppm)
Bauteilausfälle herauszufinden, die z.B. bei den Temperaturextremen die
in der Fertigung nicht getestet werden können, auftreten.
Gruß Anja
Thomas O. schrieb:> Ich glaube aber mal gelesen zu haben das im Automotivbereich> irgendwelche Tests vorgeschrieben sind, keine Ahnung ob es sich um das> Programm selber handelt -> Checksumme oder ob explizit ein RAM Test> erforderlich ist.
Die Tests sind generell für sicherheitskritische rechnergesteuerte
Systeme ab einem bestimmten Sicherheitslevel vorgeschrieben. Es gibt
verschiedene Normen hierfür.
Einen Einstieg gibts z.B. in AN1229
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en537355
Wobei Class B einer der niedrigeren Level ist.
Die Bibliothek ist auch nicht vollständig.
Gruß Anja
Urlauber schrieb:> Hätte trotzdem gerne eine Antwort :-)
Dann solltest Du erstmal Informationen rüberbringen:
Was für ein Sicherheitslevel?
Was für eine konkrete CPU?
Interner oder externer RAM?
Ältere Rechner hatten ja noch externen Komponenten, die über Lötstellen
verbunden waren. Und da Lötstellen mit Abstand am unzuverlässigsten
sind, macht ein Test durchaus Sinn.
Irgendwelche hirnlosen Bürokraten hatten den Zusammenhang aber nicht
kapiert und das auch für interne Komponenten gefordert. Ist zwar völlig
sinnlos, aber eben Bürokratie, also einzubauen für bestimmte
Sicherheitslevel.
Interne Komponenten prüft ja schon der Hersteller und zwar um Längen
besser, als es je eine Testroutine könnte. Nur er weiß nämlich, was zu
prüfen ist und kann auch Temperatur, VCC, Frequenz, Last usw. variieren,
was in der Applikation nicht möglich ist.
Peter
Thomas O. schrieb:> konnte bei den AVR gehen wenn man den Stackpointer versetzt einen> Bereich testet und dann den Stack inkl. des Inhaltes wieder dorthin> setzt.
Geht einfacher. Einerseits weil man für einen RAM-Test auf den Stack
verzichten kann. Andererseits weil man, wenns denn schon sein muss, ihn
auf Adresse 15 setzen kann. Da sind ja auch ein paar Bytes "RAM".
Peter Dannegger schrieb:> Ältere Rechner hatten ja noch externen Komponenten, die über Lötstellen> verbunden waren. Und da Lötstellen mit Abstand am unzuverlässigsten> sind, macht ein Test durchaus Sinn.
Steckverbindungen sind schlimmer. Behauptete zumindest IBM bei einer
High-End Kiste, in die sie die Speichermodule nicht gesteckt sondern
eingelötet hatten (Spötter sagen freilich, das sei nur geschehen, um die
Kunden davon abzuhalten, den Speicher für 30-50% der Kosten anderswo zu
kaufen ;-).
Vielen Dank für die bisherigen Antworten ...
SIL2 wird verlangt, SIL3 gewünscht ;-)
uC -> MC9S08DZ60, es wird also nur das (der) interne Ram verwendet.
Class B Bibliothek von Freescale ist vorhanden,
Class C Lib -> bisher Fehlanzeige.
Es ist geplant das Ram im Hintergrund mit dem "Transparent Galpat"
zu testen.
Da dieser Test extrem langsam und in Häppchen abläuft, sind wichtige,
eigentlich sogar die meissten Daten auch invers abgespeichert.
Aber zurück zur Ausgangsfrage:
In einem nicht verwendeten Rambereich kippt ein Bit.
Dieses Bit ist (dynamisch) mit einem Bit im verwendeten Bereich
verbunden und verfälscht es dadurch.
So eine Verfälschung kann eigentlich nur durch einen kompletten Ramtest
erkannt werden? Muss ich nun meine ursprüngliche Meinung ändern?
Anderseits habe ich die wichtigen Daten auch invers abgespeichert
und sollte Fälle wie diesen (oder wilde Zeiger) erkennen können?
lg
Urlauber
Hallo,
als allererstes würde ich mir überlegen, was denn das System tun soll,
wenn tatsächlich ein RAM-Fehler auftritt.
Daten, die Block-oder Recordweise organisiert sind (z.B. Parameter und
Messdaten) sichere ich jeweils mit Prüfsummen ab. Werden z.B. die
Parameter fehlerhaft gelesen, so werden sie durch Standard-Parameter
ersetzt, Messwerte sind im Zweifelsfall alle 0.
Gruss Reinhard
Urlauber schrieb:> Es ist geplant das Ram im Hintergrund mit dem "Transparent Galpat"> zu testen.
Gibt es ein Zeitlimit für den Test?
Ich würde nen Timerinterrupt aufsetzen, der so langsam ist, daß er
wichtige Prozesse nicht stört.
Und der prüft dann jeweils nur ein einzelnes Byte, damit seine
Ausführungszeit die wichtigen schnellen Interrupts nicht behindert.
Urlauber schrieb:> Da dieser Test extrem langsam und in Häppchen abläuft, sind wichtige,> eigentlich sogar die meissten Daten auch invers abgespeichert.
Ist sowas denn gefordert?
Wenn nicht, würde ich es sein lassen.
Es erhöht die Komplexität und damit die Gefahr, daß der Programmierer
selber nen Fehler einbaut.
Peter
Peter schrieb:
> Gibt es ein Zeitlimit für den Test?
Eigentlich sollte der komplette uC inkl. Peripherie, Ram, Flash,
Programmablauf, ... innerhalb 100ms getestet werden.
Das Flash ist kein Problem, kann ich auch in Häppchen unterteilen.
Peripherie werden wir noch sehen, aber zumindest der Watchdog lässt sich
bei dieser CPU nicht im Betrieb testen.
> Ich würde nen Timerinterrupt aufsetzen, ...
Ja, so ungefähr hab ich mir das auch gedacht, obwohl ein zyklischer
Aufruf mit gesperrten Interrupts von der Hauptschleife aus vielleicht
besser wäre, weil ich da weiss was die CPU gerade macht und der Stack
fast leer ist ...
Das invertierte Ram ist nicht gefordert, aber da ein hochwertiger
Ramtest unmöglich in 100ms als Nebenjob unterzubringen ist, hoffe ich,
mit den invertierten Daten die Zeit in der ein Fehler unerkannt bleibt,
hinaufsetzen zu können.
Ausserdem hilft diese Methode z.B. auch gegen wilde Zeiger, die
unbemerkt irgendwo eine Variable verändern.
Das müsste man sonst aufwendiger mit Signaturen erledigen,
obwohl ich zugebe, das diese Lösung noch besser wäre.
> Es erhöht die Komplexität und damit die Gefahr, daß der Programmierer> selber nen Fehler einbaut.
Ja das stimmt schon, erzeugt aber andererseits irgendwie ein Gefühl der
Sicherheit (wenns funktioniert).
lg
Urlauber
Die viel interessantere Frage ist doch: Wie geht es dann eigentlich
weiter, wenn der Test tatsächlich einen Fehler entdeckt?
Denn, wenn dein RAM fehlerhaft ist, kannst du dem auch nicht mehr
vertrauen, dass du zb Funktionen aufrufen kannst und das alles wie
gewohnt funktioniert.
Reinhard schrieb:
> als allererstes würde ich mir überlegen, was denn das System tun soll,> wenn tatsächlich ein RAM-Fehler auftritt.
Da Fehler im internen Ram angeblich extrem selten auftreten, werde ich
in diesem Fall wohl das ganze Modul abschalten.
Kann gut sein, das ich diesen Notfall selber nicht mehr erleben werde
;-)
Eine Datenverfälschung durch fehlerhafte Software macht mir mehr Sorgen
...
lg
Urlauber
Karl Heinz schrieb:
> Die viel interessantere Frage ist doch: Wie geht es dann eigentlich> weiter, wenn der Test tatsächlich einen Fehler entdeckt?
In unserem Fall können wir einfach das Modul/Gerät abschalten und warten
bis der Techniker kommt.
Fehlertolerante Software zu entwickeln muss hingegen wohl die Hölle
sein.
lg
Urlauber
Urlauber schrieb:> Fehlertolerante Software zu entwickeln muss hingegen wohl die Hölle> sein.
Wieso ist doch ganz einfach: man entwickelt mehrere B-Class module und
überträgt die Verantwortung einem Voter (möglichst in Hardware bzw.
VHDL) der aus 3 verschiedenen Antworten die Richtige Auswählt ;-)
Gruß Anja
Anja schrieb:
> Wieso ist doch ganz einfach: man entwickelt mehrere B-Class module und> überträgt die Verantwortung einem Voter (möglichst in Hardware bzw.> VHDL) der aus 3 verschiedenen Antworten die Richtige Auswählt ;-)
So gesehen schon, mit Redundanz lässt sich dieses Problem wohl wirklich
erschlagen ;-)
Aber ich hab noch eine Frage zum Watchdogtest:
Verwendet wird der Interne und ein externer Watchdog.
Beide werden nach einem Reset getestet, im Betrieb hingegen nicht mehr.
Da unser Modul aber über einen Feldbus laufend Meldungen absetzt,
müsste sich ein Programmabsturz anhand der Daten der Meldungen bemerkbar
machen.
Mir scheint, als wäre ein zyklischer Watchdogtest eher an "Standalone"
Geräte gerichtet.
lg
Urlauber
Urlauber schrieb:> Aber ich hab noch eine Frage zum Watchdogtest:> Verwendet wird der Interne und ein externer Watchdog.> Mir scheint, als wäre ein zyklischer Watchdogtest eher an "Standalone"> Geräte gerichtet.
Ich weiß nicht was Du unter einem Watchdog verstehst. Der interne ist
meist nichts wert da er dieselben Ressourcen wie der Prozessor verwendet
(Versorgungsspannung, Takt).
In sicherheitsrelevanten Systemen stellt der externe Watchdog
(unabhängiger Takt und unabhängige oder überwachte Versorgung) dem
Prozessor Fragen die dieser innerhalb einer definierten Zeit richtig
beantworten muß. Ist die Antwort falsch oder nicht im Zeitfenster so
werden die Sicherheitskritischen Endstufen + Kommunikationswege
abgeschaltet.
Gruß Anja
Hallo,
ich habe beruflich mit der Entwicklung von Software im Automotive
Bereich zu tun. Bei den Maßnahmen die wir manchmal ergreifen, um eine
Software möglichst sicher zu machen, wird einem oft schwindelig. RAM/ROM
sind bei den meisten Micros mit ECC abgesichert um alle ein Bit Fehler
erkennen und korrigieren zu können, und um alle zwei Bit Fehler zu
erkennen. Damit ECC zuschlagen kann, muss auf die Zelle lesend
zugegriffen werden, also schnell mal mit DMA über das ganze RAM lesend
drüber um die Logik zu triggern.
ECC wird natürlich vorher oder auch zyklisch getestet, ob Fehler auch
erkannt werden können.
Zusätzlich läuft noch ein Algorithmus, der alle Zellen im RAM rettet,
beschreibt, liest und wieder herstellt.
Während dem Startup laufen noch RAM Tests(inkl RAM der Peripherien) die
in Hardware realiert sind (PBIST).
Bei ROM nutzt man auch ECC und CRC Checksummen.
CPU Kerne sind oft doppelt vorhanden und führen um 1,5 Taktzyklen
versetzt die gleich Instruktion aus. CPU werden zyklisch mit einem LBIST
getestet.
Da werden alle CPU Register gesichert, der LBIST gestartet, einmal über
den Reset Vector und nach Herstellen der Register gehts im
Betriebssystem normal weiter.Man ergreift eher mehr Maßnahmen als nötig
bevor man sich nachher irgendwas nachsagen lassen kann...Teilweise wird
Software komplett in ASIL D
nach ISO26262 entwickelt.
Bei Interesse kann mal ja mal nach TMS570LS suchen.
Anja schrieb:
> Ich weiß nicht was Du unter einem Watchdog verstehst. Der interne ist> meist nichts wert da er dieselben Ressourcen wie der Prozessor verwendet>(Versorgungsspannung, Takt).
Ich verstehe das darunter, was als Watchdog im Datenblatt beschrieben
ist.
So ein Snob bin ich nicht, als das ich einen eingebauten Watchdog auch
wenn er primitiv ist, von vornherein nicht benütze ;-)
> In sicherheitsrelevanten Systemen stellt der externe Watchdog> (unabhängiger Takt und unabhängige oder überwachte Versorgung) dem> Prozessor Fragen die dieser innerhalb einer definierten Zeit richtig> beantworten muß. Ist die Antwort falsch oder nicht im Zeitfenster so> werden die Sicherheitskritischen Endstufen + Kommunikationswege> abgeschaltet.
Also ein eigener uC ...
Das bringt mich zu meiner vorher vergessenen Frage:
Falls eine laufende zyklische Kommunikation (über einen Feldbus) mit
anderen Busteilnehmern vorausgesetzt wird, verliert eigentlich der
Watchdog und somit sein Test an Bedeutung?
Ist im Grunde ganz ähnlich wie von Dir oben beschrieben, nur nicht am
selben Print ...
lg
Urlauber
Maxwell schrieb:
> Zusätzlich läuft noch ein Algorithmus, der alle Zellen im RAM rettet,> beschreibt, liest und wieder herstellt.
Ist das der eigentliche (altmodische) Ramtest?
"beschreibt" soll heissen, mit einer Signatur beschrieben?
"alle Zellen" soll heissen, alle Zellen auf einmal, oder Häppchenweise
nur Teilbereiche des Ram testen bis es komplett durch ist?
Nicht übel der TMS570LS, würde mir die Arbeit sicher leichter machen.
Vielen Dank für den interessanten Einblick :-)
lg
Urlauber
Anja schrieb:> Wieso ist doch ganz einfach: man entwickelt mehrere B-Class module und> überträgt die Verantwortung einem Voter (möglichst in Hardware bzw.> VHDL) der aus 3 verschiedenen Antworten die Richtige Auswählt ;-)
Und wer garantiert die korrekte Funktion des Voters?
So einfach betrachtet führt einen das Konzept von Redundanz und
Überwachung in eine endlose Rekursion. Ich habe mal auf Anforderung des
TÜV an einem medizinischen Gerät eine unabhängige Überwachung der
Ausgangsspannung vorgesehen, worauf gefordert wurde, dass auch die
Funktion dieser Überwachungsschaltung wiederum überwacht werden müsste.
Auf meinen Einwurf, das könnte man ja endlos so fortsetzen, dabei würden
aber immer mehr Bauteile eingesetzt und daher die
Ausfallwahrscheinlichkeit erhöht, hiess es dann, mit der Überwachung der
Überwachung sei es genug. Aber das ist natürlich eine rein willkürliche
Festlegung.
Gruss Reinhard
Reinhard Kern schrieb:> So einfach betrachtet führt einen das Konzept von Redundanz und> Überwachung in eine endlose Rekursion.
Ist das nicht prinzipiell so? Letztlich läuft das darauf hinaus,
Fehlerwahrscheinlichkeiten ausreichend weit drücken zu können. Ganz los
wird man sie nie. Das geht doch runter bis auf die Elektronik, wo
irgendwelche gesampelten Inputs eine zwar sehr kleine aber nicht
wegzukriegende Chance auf Metastabilität haben.
In die Rekursionsfalle läuft man freilich, wenn das Überwachungssystem
(im Sinne eines anspruchsvollen Watchdogs oder eines Voters) von
ähnlicher Komplexität ist wie das überwachte. Das muss man schon
deutlich einfacher ansetzen.
Maxwell schrieb:> CPU Kerne sind oft doppelt vorhanden und führen um 1,5 Taktzyklen> versetzt die gleich Instruktion aus.
Das halte ich für unmöglich.
Dann dürften ja keine Interrupts ausgeführt und keine Daten eingelesen
werden. Denn nach 1,5 Taktzyklen könnte ein Interrupt anliegen oder ein
ADC eine Wandlung beendet haben. Und schon führen beide CPUs etwas
völlig anderes aus.
Peter
Peter Dannegger schrieb:> Dann dürften ja keine Interrupts ausgeführt und keine Daten eingelesen> werden. Denn nach 1,5 Taktzyklen könnte ein Interrupt anliegen oder ein> ADC eine Wandlung beendet haben. Und schon führen beide CPUs etwas> völlig anderes aus.
Wieso? Gleiche Daten / gleicher Input => gleiches Verhalten. Beim
erwähnten TMS570LS sind nur die Kerne doppelt, nicht die Peripherie.
Bei IBM Mainframe-Prozessorchips einer der letzten Generationen war das
ähnlich (weiss nicht mehr ob heute auch noch).
Da existiert ausserdem noch ein Hintereingang zum letzten sicheren
Zustand. Der wird dann von einem Maintenance-Prozessor ausgelesen und in
einen Reserveprozessor geladen, der nahtlos weiter macht. Hat den
Nachteil, dass man den internen Cache nur write-through auslegen kann.
Maxwell schrieb:> Bei den Maßnahmen die wir manchmal ergreifen, um eine> Software möglichst sicher zu machen, wird einem oft schwindelig.
Das mag sein, aber man hat den Eindruck, daß es überhaupt nichts bringt.
Es wird immer die Hardware verdächtigt, daß sie fehlerhaft ist, aber die
meisten Fehler entstehen in der Software selber.
Deshalb wird auch die Firmware geupdated, bis die Schwarte kracht.
Daß ein RAM unmotiviert seine Daten ändert, liegt viel eher an
schlechtem Platinenlayout oder dreckiger VCC, als an einen wirklichen
Defekt bei der Chipfertigung.
Es wird leider keine echte Fehleranalyse gemacht, sondern völlig blind
mit der Bürokratikeule zugeschlagen und irgendwelche Tests implementiert
in der irrigen Hoffnung, viel hilft viel.
Peter
Peter Dannegger schrieb:> Daß ein RAM unmotiviert seine Daten ändert, liegt viel eher an> schlechtem Platinenlayout oder dreckiger VCC, als an einen wirklichen> Defekt bei der Chipfertigung.
Die Wahrscheinlichkeit ist zwar über die Jahrzehnte dank besserem
Gehäusematerial gesunken, aber transiente Fehler aufgrund von
radioaktiver Strahlung sind auch in normaler Umgebung immer noch mit auf
der Rechnung. Zumal schrumpfende Strukturen gegenüber Quellen solcher
transienter Fehler immer empfindlicher werden.
> Es wird leider keine echte Fehleranalyse gemacht, sondern völlig blind> mit der Bürokratikeule zugeschlagen und irgendwelche Tests implementiert> in der irrigen Hoffnung, viel hilft viel.
Dieser Ansatz ist natürlich Unfug. Aber mit Fehleranalyse kann
Hardware-Redundanz durchaus sinnvoll sein, zumal man - wenn man es ernst
meint - bei Software auch ein bischen besser vorgehen kann als so lange
try-and-error durchzuziehen, bis es leidlich funktioniert und die Kunden
als unfreiwillige Betatester zum Zuge kommen.
A. K. schrieb:> Wieso? Gleiche Daten / gleicher Input => gleiches Verhalten.
Die Daten kommen aber von außen, also müssen sie nach 1,5 Zyklen nicht
mehr gleich sein.
Selbst wenn Du 2 CPUs exakt synchron laufen läßt und einen externen
Interrupt an beide anlegst, müssen ihn nicht beide im gleichen Zyklus
erkennen. Und schon sind sie asynchron.
Nimm 2 D-FFs (74HC74), lege Takt und Daten parallel an und ein EXOR
dahinter.
Die Daten werden asynchron zum Takt erzeugt und Du wirst an beiden
Ausgängen manchmal unterschiedliche Pegel haben.
Peter
Peter Dannegger schrieb:> Selbst wenn Du 2 CPUs exakt synchron laufen läßt und einen externen> Interrupt an beide anlegst, müssen ihn nicht beide im gleichen Zyklus> erkennen. Und schon sind sie asynchron.
Das setzt voraus, dass die beiden CPUs asynchrone Signale erhalten. Tun
sie beim TMS570LS aber nicht, zumindest nicht wenn der Rest vom Chip
noch sauber funktioniert. Da sind nur die Cores gedoppelt.
Peter Dannegger schrieb:> Deshalb wird auch die Firmware geupdated, bis die Schwarte kracht.
Die Hardware lässt sich leider (noch?) nicht online updaten.
Und manch ein Softwareupdate dient dazu, Unzulänglichkeiten in der
Hardware auszubügeln.
Oliver
Oliver schrieb:> Die Hardware lässt sich leider (noch?) nicht online updaten.
Bei FPGAs gewissermassen schon. Theoretisch sogar mit Rerouting um
defekte Elemente herum.
>meiner vielleicht kurzsichtigen Meinung nach,>ist es nicht notwendig das komplette Ram eines uC zu testen.>D.h.,>falls ein Projekt nur 10% des zur Verfügung stehenden Ram benötigt,>muss ich auch keinen grösseren Bereich testen?
Nun ja, wenn Du einen Compiler verwendest, dann legt doch der Linkler
fest, wo die Variablen stehen. Das hat zur Folge, dass das irgendwo im
RAM sein kann. Legst Du die Variablen händisch fest, hast Du diese
Problem nicht und Du kannst Deinen Bereich vorher testen.
>Es sollte ja eigentlich genügen, nur nach dem Reset das gesammte>adressierbare Ram und im laufenden Betrieb,>z.B. mit einem Hintergrund Prozess,>nur den verwendeten und auch im Linker-Config-File festgelegten Bereich>zu prüfen?
Wenn Du weisst, wo Deine Variablen stehen, sollte es genügen.
Für solche Tests im Vorfeld bietet sich vielleicht ein kleiner
Bootloader an, der erst einmal das RAM testet und danach ins
Hauptprogramm springt.
Kläre aber erst einmal Deinen Anspruch an den Sicherheitslevel!!!
Rosa
Hallo,
Peter Dannegger schrieb:> Das halte ich für unmöglich.>>>> Dann dürften ja keine Interrupts ausgeführt und keine Daten eingelesen>> werden. Denn nach 1,5 Taktzyklen könnte ein Interrupt anliegen oder ein>> ADC eine Wandlung beendet haben. Und schon führen beide CPUs etwas>> völlig anderes aus
also das mit den 1,5 Zyklen versatz stimmt so. Ich spare mir die
Erklärung
und verweise auf das Datenblatt ->4.9.1 Dual Core Implementation
Es ist ja nicht so, dass jeder Kern die Interrupts vom VIM bearbeitet.
Das kann nur von einem gemacht werden.
Peter Dannegger schrieb:> Es wird leider keine echte Fehleranalyse gemacht, sondern völlig blind>> mit der Bürokratikeule zugeschlagen und irgendwelche Tests implementiert>> in der irrigen Hoffnung, viel hilft viel.
Dazu kann ich nur sagen, dass während dem Software Entwicklungsprozess
einige Maßnahmen ergriffen werden, um die Software Fehler auf einen sehr
kleinen Wert zu bringen. Stichwort polyspace, QA C, Cantata...
Die von mir angesprochenen Maßnahmen dienen nur der Sicherstellung, dass
die Hardware funktioniert. Die Auftretenswahrscheinlichkeit von RAM
Fehler wird vom Halbleiter Lieferant berechnet und ist sehr sehr gering.
Aber trotzdem rechtfertig die kleine Zahl nicht, den Test zu
unterlassen.
Urlauber schrieb:> Ist das der eigentliche (altmodische) Ramtest?>> "beschreibt" soll heissen, mit einer Signatur beschrieben?>> "alle Zellen" soll heissen, alle Zellen auf einmal, oder Häppchenweise>> nur Teilbereiche des Ram testen bis es komplett durch ist?
Altmodisch würde ich jetz nicht sagen, man muss halt jederzeit in der
Lage eine Variable im RAM von 1 auf 2 zu setzen. Würde der Schreibbefehl
nicht durchgeführt werden können, würde die Software das so erstmal
nicht mitbekommen. Damit testet die Software auch die Kette CPU->BUS(evt
Bus Matrix->RAM). Üblicherweise wählt man ein Muster was möglichst viele
Bits betrifft, aber auch möglichst viele Wechsel zwischen den Bits.
0xAAAAAAAA bietet sich da an. Den Test kann man prima in kleinen
Häppchen durchführen.
Peter Dannegger schrieb:> Daß ein RAM unmotiviert seine Daten ändert, liegt viel eher an>> schlechtem Platinenlayout oder dreckiger VCC, als an einen wirklichen>> Defekt bei der Chipfertigung.
Dafür gibt es auch Maßnahmen. Bei Teilen die in sicherheitsrelevanten
Umfeld millionenfach verkauft werden, wird man kein schlechte VCC
zulassen.
Bis jetzt hatte ich nur wenige Fälle, wo das RAM ein Problem hatte.
Das war ein 8-bit Micro und selbst nach Freilegung des Die's konnte der
Hersteller nicht sagen, wo das Problem lag.
Meine Meinung...
Einen einfachen RAM Test zu implementieren kostet nicht viel Zeit.
Bei einer Hello World Anwendung würde ich das nicht machen. Sobald aber
im Fehlerfall Leben davon betroffen sind, oder Kosten verursacht werden,
lässt mich ein RAM Test besser schlafen :)
Urlauber schrieb:> Also ein eigener uC ...
Nicht zwangsläufig es gibt ASICs die das mit entsprechender Markov-Kette
schaffen. Einschließlich Logik zum Abschalten sicherheitsrelevanter
Endstufen.
Der Prozessor überwacht den Watchdog indem zyklisch falsche Antworten
Eingestreut werden und der Fehlerzähler zurückgelesen wird. Bei einem
Defekt des Watchdogs schaltet der Prozessor ab. Falls der Prozessor
keine sinnvollen Antworten liefert schaltet der Watchdog ab.
> Das bringt mich zu meiner vorher vergessenen Frage:> Falls eine laufende zyklische Kommunikation (über einen Feldbus) mit> anderen Busteilnehmern vorausgesetzt wird, verliert eigentlich der> Watchdog und somit sein Test an Bedeutung?
Den Watchdog brauchst du nur bei sicherheitskritischen Aktoren. Oder
falls du sicherheitskritische Sensorsignale hast die entsprechende
Systemreaktionen zur Folge haben. In dem Fall sollte das "save silent"
Prinzip gelten. D.H. defekte Sensorknoten werden vom Kommunikationsbus
getrennt um einen "babbling idiot" zu deaktivieren.
Reinhard Kern schrieb:> Und wer garantiert die korrekte Funktion des Voters?
Natürlich der Zulieferer dem man die Verantwortung überträgt ;-)
Reinhard Kern schrieb:> Ich habe mal auf Anforderung des> TÜV an einem medizinischen Gerät eine unabhängige Überwachung der> Ausgangsspannung vorgesehen, worauf gefordert wurde, dass auch die> Funktion dieser Überwachungsschaltung wiederum überwacht werden müsste.> Auf meinen Einwurf, das könnte man ja endlos so fortsetzen, dabei würden> aber immer mehr Bauteile eingesetzt und daher die> Ausfallwahrscheinlichkeit erhöht, hiess es dann, mit der Überwachung der> Überwachung sei es genug. Aber das ist natürlich eine rein willkürliche> Festlegung.
Im Normalfall reicht es jeden schlafenden Fehler gelegentlich (POST) zu
testen. Wichtig ist daß der Fehler irgendwie dem Benutzer mitgeteilt
wird und im Handbuch entsprechende Hinweise sind (sofort Werkstatt
aufsuchen). Wenn man es geschickt macht kann man die Hardwareüberwachung
auf 3 Chips verteilen (Prozessor + intelligente Endstufen mit
Spannungsüberwachung + Watchdog) und das ganze so regeln daß alle
Überwachungsfunktionen ineinander greifen.
Gruß Anja
