Methoden zum Erkennen einer Fehlerbedingung in Microcontroller-Systemen

[Peter(TOO)]

Hallo,

ja, die Fragen, die sich stellen, sind doch:
1) ist es nur eine Spielerei oder ein kommerzielles Produkt (Ausschluss-Kriterium!)?
2) können unabhängig davon beim Betrieb Menschen oder andere Lebewesen gefährdet oder geschädigt werden?
(direkt oder indirekt, z.B. auch im Straßenverkehr, auf öffentlichen Wegen und Plätzen)
3) können erhebliche Schäden an fremden Gegenständen auftreten (Betrieb in und außer Haus)?
4) besteht ggf generell eine Gefährdungshaftung, sodass eine Haftpflichtversicherung abgeschlossen werden muss?

Ein wichtiger Punkt fehlt noch:
5) Kann das System im Fehlerfall einfach abgeschaltet werden?

In diesen Fall, kann man meist relativ einfach Parameter überwachen und im Störungsfall alles blockieren.
z.B. eine Hausheizung geht einfach auf Störung und die Bude wird kalt. Einer merkt dies dann und bestellt den Techniker. Bei einem nur zeitweise bewohnten Ferienhaus sieht es schon etwas anders aus. Wenn da gerade keiner wohnt, wird die Störung nicht bemerkt und es können dann Wasserleitungen einfrieren und platzen. Hier kann man mit unabhängigen Sekundärsystemen, wie z.B. Rohrheizung, arbeiten.

Bei einem Flugzeug kann man aber nicht einfach rechts ranfahren und den ADAC verständigen.

MfG Peter(TOO)

- - - Aktualisiert - - -

Will man mehr, muß man schon beim Hardare Design der Cotrollerkarte anfangen.

Hier steckt da ein weiteres Problem:
Die Ausfallwahrscheinlichkeit eines Systems steigt mit dessen Komplexität.
z.B. ist jede Lötstelle eine potentielle Fehlerquelle. Je mehr Lötstellen um so eher ist kommt es zu einem Ausfall.
Irgendwann wird dann das System so Komplex, dass die zusätzliche Sicherheit es unsicher macht.

Memory RAID geht halt nicht mit dem internen Speicher von µCs. Da muß man dann also ein Modell suchen, bei dem man vollständig auf externen Speicher wechseln kann.
Und diesen muß man dann mit allen Funktionen bauen. (addressierung, refresh, RAID Logik, etc.)

... und schon spielen die Lötstellen eine grössere Rolle, wie auch jedes zusätzliche Bauteil .

Da holt man eine zweiter Person, damit man den Denkfehler den man beim ersten System eingebaut hat und der später mal den Fehler verursachen wird, nicht auch in das Sicherheitssystem einbaut.
solche Sicherheitssysteme werden gerne von getrennten Teams entweickelt, die auch nicht direkt miteinander komunizieren, damit sie sich nicht gegenseitig beeinflussen können.

Diesen Fehler hatte Micro Soft bei Windows NT gemacht.
NT sollte eines der sichersten Betriebssysteme werden, weshalb man sich David N. Cutler als Chef holte. Eigentlich erreichte der Kernel auch alle Sicherheitsanforderungen, nur haben die MS-Programmierer dann, wie bei MS üblich, direkte Kernelaufrufe in ihren Programmen verwendet und so alles zu Nichte gemacht, worauf Cutler das Handtuch warf.
Bis etwa Win95 konnten MS-Programme Dinge, welche über das offizielle API gar nicht möglich waren. Es gab dazu eine Menge undokumentierte API-Aufrufe, teilweise auch direkt in den Kernel. Teilweise wurde auch direkt auf undokumentierte interne Datenstrukturen zugegriffen. Damals gab es auch Programme, welche Programme auf solche undokumentierte Aufrufe untersucht haben. Deswegen gab es auch einen Rechtsstreit mit MS.

Manche offiziellen Bugfixes von MS funktionierten auch nach dieser Art. z.B. gab es bei Win3.x einen Fehler im COM-Treiber: Die Abfrage auf Veränderung der Statusleitungen funktionierte nicht. Dadurch wurden auch keine Interrupts in einem solchen Fall ausgelöst. Der Bugfix bestand darin, direkt auf die interne Datenstruktur zuzugreifen und zwar einige Bytes hinter des offiziellen Struktur. MS garantierte auch, dass dies auch in späteren Win-Versionen funktioniert, was auch eingehalten wurde.
Im Win DDK war der Assembler Source-Code des Treiber vorhanden. Der Bug bestand in der Verwechslung zweier UART-Register, davon waren total 4 Source-Zeilen betroffen. Von MS gab es aber nie ein Update dieses Treibers Und wenn ich mich richtig erinnere, war der Bug auch in Win95 noch enthalten.

MfG Peter(TOO)