mich interessiert ob man bei einem embedded System die Sicherheit erhöhen kann indem man zwei Microcontroller verwendet, die über I²C verbunden sind.
Meine Vorstellung ist, dass die beiden Contoller regelmäßig Statusmeldungen austauschen und innerhalb eines bestimmten Zeitfensters eine Antwort zurückerwarten, die zeigt, dass die Nachricht verarbeitet worden ist. Das könnte mithilfe von einem kleinen RAM geschehen (PCA8570) das ebenfalls am I²C angeschlossen ist.
Beide Controller würden also regelmäßig ihre Lifeticks in das gemeinsame RAM schreiben und nach ein paar ms nachschauen, dass dort eine Quittung z.B. in Form einer Checksum abgelegt ist. Wenn das nicht mehr klappen sollte schalten sie die Endstufe aus und bringen das System so in den sicheren Zustand.
Weiss jemand ob es so funktionieren würde oder bessere Konzepte gibt, die bei einem Fehler die Rückkehr in den sicheren Zustand garantieren?
Dafür würde es ja erst einmal reichen, wenn jeder Prozessor den anderen direkt anspricht. Dann hast Du nur das Problem, sicherzustellen, dass alle Defekte eines Prozessors es dem anderen prozessor erlauben, diesen Zustand zu erkennen (eher einfach) und den sicheren Zustand zu erreichen (genau prüfen).
Gruß, Kurt
--
Kurt Harders
PiN GITmbH http://www.pin-gmbh.com
Sicherheit ist nicht eine Frage einer Einzelmaßnahme. Sicherheit will zuerst einmal sorgfälltig definiert werden: Welche Risiken bestehen? Welche Latenzzeit habe ich? Welche Maßnahmen kann ich ergreifen um mein Schutzziel zu erreichen? Wie und wann bemerke ich Fehlerzustände? Welche Folgefehler sind möglicherweise unausweichlich? Gibt es mögliche Common-mode Fehlerquellen (wie unlängst in Schweden beim Kernkraftwerks-fast-GAU)?
Hier jetzt ohne Kenntnis des Systems und der Randbedingungen irgendwas spezielles zu sagen ist einfach nur Unfug.
Konkret: Um welches Gerät dreht es sich? Endstufen gibt es viel ;-)
Es wuerde die Sicherherit erhoehen, dass ein Fehler erkannt wird. Aber was dann?
Sieh Dir einmal Flugzeugsysteme an. Dort gibt es fuer manche Funktion drei oder sogar fuenf vollstaendig unabhaengige Systeme. Bei denen wird der korrekte Zustand oft durch Mehrheitsentscheidung gewaehlt und gleichzeitig geht eine Warnlampe an. Fly-by-Wire ist hier besonders streng.
Du mußt das System aus Sicht der Fehler komplett beschreiben. Überlege zu jeder Komponente wie sie ausfallen kann, wie wahrscheinlich das ist und wie schlimm die Folgen sind (probability/severity-Betrachtung).
Daraus entsteht dann eine Prioritätsliste, welche Fehler abgefangen werden müssen. Daraus ergibt sich aber meist eine Veränderung (Erweiterung) des Systems. Es ist aber das Gesamtsystem (also inklusive der eingebrachten Schutzmaßnahmen), was betrachtet werden muß. Daraus folgt, dass man ein System durch zusätzliche Schutzmaßnahmen nicht automatisch besser macht.
Generell hat es seine Tücken, ein System durch einen gleichartigen Zwilling überwachen zu lassen. Nicht selten sind Fehler systematisch begründet und so wird der Zwilling gemeinsam mit dem ersten System ausfallen. Die NASA hat auf diese Weise schon Raumsonden verloren.
Ein anderer Ansatz ist, das System durch ein völlig anders (meist simpler) aufgebautes System überwachen zu lassen, was gerade mal in der Lage ist, Alarm zu schlagen. Das nennt man einen "Watchdog".
sagen wir mal einer der beiden Prozessoren macht die aufwendigen Sachen wie TFT-Display, Tastatur und USB-Schnittstelle und läuft mit einem Betriebssystem. Der andere macht die kritischen Sachen wie Steuerung der Endstufe und schnelle Vorgänge wie Remote Interlock und Not-Aus. Die beiden kommunizieren und kontrollieren sich gegenseitig.
Gut! Es müsste reichlich Möglichkeiten geben das zu realisieren. Aber ich bin bestimmt nicht der erste der sowas versucht. Vielleicht gibt es ja Erfahrungen, eine Application Note oder ein paar Stichworte für Google, die mich weiterbringen?
sagen wir mal einer der beiden Prozessoren macht die aufwendigen Sachen wie TFT-Display, Tastatur und USB-Schnittstelle und läuft mit einem Betriebssystem. Der andere macht die kritischen Sachen wie Steuerung der Endstufe und schnelle Vorgänge wie Remote Interlock und Not-Aus. Die beiden kommunizieren und kontrollieren sich gegenseitig.
Es geht mir konkret um Softwarefehler, die dazu führen, dass sich einer der beiden Controller aufhängt.
Die Anwendung ist übrigens ein Medizingerät, dass Energie an den Patienten abgeben kann (aber kein Lifesupport!). Abschalten ist als Ausweg immer okay.
Das Problem ist, dass die schicken Programmierumgebungen, wo die Verwaltung von Schnittstellen und Displays so bequem ist, gewöhlich nicht "open source" sind und wegen der Softwarehauptakte in einem kritischen Bereich nicht genommen werden können.
bei meinem Problemchen hilft das Abschalten garantiert. Wenn man bei einem Flugzeug die gesamte Energieversorgung lahmlegt, könnte es sich natürlich um eine "Verschlimmbesserung" handeln. Das würde ich mir dann auch nochmal überlegen ;-)
Ich würde das RAM weglassen. Die Statusmeldungen sollten das jeweilige Gegenüber in seinen Zuständen eindeutig beschreiben. Mit Historie. Daran kann man erkennen, wie lange das System in welchem Zustand verharrt (timeout bei Hängern) und ob die Zustandswechsel erlaubt sind.
Die Zustände des Gesamtsystemes eindeutig zu definieren, gerade bei einem preemptien Multitaskingsystem, ist allerdings nicht wirklich einfach. Da kann man froh sein, wenn man sein System schon z.B. mit einem Case-Tool beschrieben hat.
--
B.Eckstein, eck@ivu.de Cheap, Fast, Good - pick any two of them
Die FAQ zu de.comp.hardware.netzwerke: http://how.to/dchn
Mozilla-Tips: http://mozilla-anleitung.de/ http://www.holgermetzger.de/
Marte hatte die richtige Frage gestellt, nur muss man die Risiken (und zwar alle) in eine Liste bringen. Ich arbeite auch in der Medizinelektronik, ebenfalls mit sicherheitskritischen Modulen. Wir erstellen zuerst eine Hazard Analysis, die hauptsaechlich aus beliebig vielen Eintraegen mit je vier Spalten besteht:
a. Was fuer ein Fehler koennte passieren? In deinem Fall wahrscheinlich Regelungsausfall usw.
b. Welche "Alarmstufe" soll er bekommen?
c. Was koennte durch diesen Fehler alles passieren?
d. Wie kann man dem Fehler entgegenwirken?
Die Hazard Analysis bleibt bis zum Projektende ein offenes, aber revisions-kontrolliertes Dokument. Punkt "d" ist dabei natuerlich immer die meiste Arbeit. Doch oft gibt es bestechend einfache Loesungen. Sagen wir, in Deinem Fall muesste induktive Leistungsuebertragung gemacht werden und Du muesstest dazu eine Serienresonanzbedingung halten. Nun koennte die Regelschleife dazu aufhaengen.
Letzteres hatte ich oft zu beackern. Dann liess ich z.B. nebenher einen HW-Timer laufen und der wurde von einem Signal, das aus selbiger Regelungsroutine kam, zurueckgesetzt. Der Timer erwartete abwechselnd positive und negative Flanken. Blieben sie aus, schaltete er die Chose ab. Mein Kunde taufte das dann "Fail-Safe Circuit".
In anderen Faellen laesst sich relativ einfach ein DC Error Signal erzeugen. Z.B. bei einem Kunden, der eine HF Quelle auf Reflektion regeln musste. Da konnten wir per Stockton-Bridge einen DC Wert herausholen, der proportional zur reflektierten Leistung war. Wenn der einen Schwellwert ueberschritt, kam der Not-Aus.
Wichtig ist, dass die Erkennung moeglichst in Hardware erfolgt und nach Moeglichkeit von jemandem entwickelt wird, der unabhaengig und ansonsten nicht tief in das Projekt einbezogen ist.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.