Hi holzi,
was sich als Schlagwort easy und cool anhört - fail safe - ist eine komplexe Sache, die viel Verständnis, Wissen und viele Kenntnisse erfordert.

Zitat von
holzi
... Was ist ein kleines System? Was ist eine Geschwindigkeit? Wer oder durch wen wird das festgelegt? ...
Genau das sind die Fragen, die bei der Konzipierung komplexer Systeme aufgestellt werden, noch bevor allzuviel "auf dem Papier" steht. Du liegst mit diesen Fragen goldrichtig. Manchmal ist nur der Zeitpunkt falsch (zu spät? nie? immer?), an dem diese Fragen gestellt werden.
Eine gründliche Analyse zeigt, was für ein System überhaupt vorliegt, FMEA uä. erlaubt Dir die "Teile" - hard- und softwareseitig - abzustufen nach verschiedenen Gefährdungs- und Sensibilitätsstufen und so gibt es mehrere Vorgehensweisen (alternativ, additiv oder nebeneinander). Für die sensibelsten und gefährllichsten Abschnitte wird man vollständige Matrizen alternativer Lösungen entwerfen und wenn irgendwie möglich die sichersten Varianten wählen - wenn die Wahl noch möglich ist. (Anmerkung: das klingt als würde man >>hinterher<< alles neu aufrollen - Reengineering. Ist nicht. Dieses Vorgehen begleitet den Entwurfsprozess schon nach den ersten Ideenskizzen und wird immer und wieder durchgegangen - sonst verliert man Faden und Übersicht). So, und nun kann man (ich bleib mal jetzt softwareseitig) kritische Pfade mit Markern belegen. Denk Dir so eine Art watchdog, kleine Programmabschnitte, die etwas tun - rechnen - messen, beispielsweise Laufzeiten - etc. Diese watchdogs haben eben wieder watchdogs, von denen die Ergebnisse überprüft werden. Die Ergebnisse müssen leicht überprüfbar sein. Und wenn nun eine "Unsauberkeit" auffällt, dann wird beispielsweise ein Zähler angeworfen, der je nach Gefährdungsstufe unterschiedlich schnell rauf- und runterzählt. Wenn die vorgegebene Schwelle erreicht wird, dann wird mit Warnung, wann immer möglich mit Fehlermeldung - nicht mit Notaus - abgefahren oder bei geringeren Gefahren (blos) eine Warnung, ein Fehler gemeldet. Überleg doch selbst, wie oft Dir an mancher Sache etwas "faul vorkommt". Meist stimmen solche vagen Vermutungen - und ebenso etwas kann man nachempfinden. Übrigens kennst Du sicher solche Entscheidungswege: Du wirst einen Taster mehrfach abfragen und erst wenn überwiegend "offen" erkannt wird, wirst Du die 0-1-Entscheidung "ist offen" treffen. So einfach ist das manchmal.
Redundanz ist möglich, hat aber auch ihre Grenzen: wenn zwei Sensoren unterschiedliche Werte zeigen, welcher hat recht? Also muss ein dritter her. Wenn der auch aus der Reihe fällt - worauf soll dann entschieden werden?
Eine weitere Möglichkeit ist die Vorhersage von Toleranzfeldern und die Überprüfung, wie gut man in der aktuell zugelassenen Bandbreite ist. Ein hübscher, großer Simulator ist mal in einer extremen Lage stehen geblieben - er hatte vorhergesehen (gerechnet !), dass er in ein unzulässiges Gebiet kommt - er war noch garnicht drin! Denn in einem Punkt hast Du völlig recht: hinterherdackeln und den Stecker ziehen (oder in die Endlagen rauschen) ist die dööfste Lösung.
Es läuft hard- und softwareseitig darauf hinaus, dass Sensorik aufgebaut und Gesetzmässigkeit, Systemkenntnis und Erfahrung genutzt wird, um den korrekten Ablauf zu überwachen. Das alles hat natürlich auch Grenzen: technologische, wirtschaftliche oder zeitliche (oder persönliche bzw. teaminterne Fähigkeiten). Und da sind wir dann bei "unseren" Hobbyteilen: quick´nd dirty, "mal eben" oder
Code:
Program: 16400 bytes (100.4% Full)
(.text + .data + .bootloader)
Data: 1228 bytes (120.0% Full)
(.data + .bss + .noinit)
Die Skizze oben ist weder bindend, noch vollständig, noch bestehe ich darauf, dass so etwas öfters gemacht wird. Aber ähnliche iterative Entwurfs- und Entscheidungsprozesse sind gang und gäbe - und wers nicht tut, fällt nicht immer, aber immer wieder auf die Nase.
Ich weiß jetzt aber nicht, ob Dir diese paar Sätze geholfen haben.
Nachtrag: dass vor diesen Aktionen eine Projektidee steht, mit Machbarkeits- und evtl. (Großindustrie bitte herhören
Marketingstudie, ein Pflichtenheft etc. ist klar. Dass die Systemanalyse auch die Wechselwirkungen - mögliche, gewünschte, erlaubte und zulässige Wechselwirkungen und deren Grenzen - zwischen Deinem System und der Umwelt einschließt, sollte vorausgesetzt werden (können *gggg*).
Lesezeichen