Halli Hallo ihr Lieben, ich möchte eine Schaltung aufbauen, bei der zwei Mikrocontroller paralell geschalten werden, um Redundanz zu erwirken. Dabei ist immer nur einer im Betrieb. Der 2. Aktiviert sich erst, wenn der 1. aus irgendeinem Grund nicht mehr funktioniert und ein externer Hardware WD ausgelöst wird. Meine Frage nun: Was passiert mit den Pins und dem Stromverbrauch wenn ich das mache, ohne die beiden Kontroller zu trennen (z.B. mit Dioden)? Einmal für den Fall, dass einer der beiden komplett von der Versorgungsspannung getrennt ist und für den anderen Fall, wenn einer der beiden dauerhaft stillgelegt wird, indem er ein dauerhaftes Reset-Signal bekommt. Meine Vermutung ist, dass es für Inputs, wie ADCs kein Problem darstellt. Aber es könnte Probleme geben, wenn man Ausgänge paralell schält, weil ja immer ein Controller ausgeschalten oder stillgelegt ist und damit ja die Pins nicht konfiguriert sind. Was meint ihr dazu? Oder habt ihr eine Idee, wie man das Realisieren könnte mit möglichst geringen Platzaufwand? Vielen lieben dank im Voraus. Ich freue mich auf eure Antworten. Edit: Ich lese heraus, dass ich weiter ausholen muss: Ich bin Student und soll für Forschungszwecke eine mögliche Onboardcomputer Architektur für einen CubeSat (Das ist ein kleiner Satellit ca. 10cm x 10cm x 10cm)entwickeln. Und fall es zu Ausfällen der MCU kommt, (z.B. durch Bitflop fehler oder Spannungsspitzen) ist es meine überlegung, ob es möglich wäre, eine zweite MCU auf das Board zu packen. Im Falle des Ablebens oder aufhängens des 1. MCU (Das wird durch einen Externen HW-Watchdog festgestellt) soll die 2. MCU die Aufgaben der 1. MCU übernehmen, und durch Resetten und neu Flashen der Firmware (die in 3 verschiedenen Speichen gespeichert ist, oder von der Bodenstation gesendet werden könnte) versucht den 1. Microcontroller wieder in Gang zu setzten. Danach wird die 2. MCU wieder in "Dornröschenschalf" versetzt.
:
Bearbeitet durch User
So wie du dir das vorstellst wird das nichts. Die Controller werden niemals synchron laufen, und damit kann man die Ausgänge nicht verbinden. Die Taktquellen allein schon driften auseinander. Bei Eingängen geht das im Normalfall schon, aber auch da gibts Probleme. Zwei µC zwecks Redundanz gibt es. Aber das tut man (Aufgrund der Schwierigkeiten) üblicherweise nur bei Sicherheitstechnik. Jetzt wäre es an der Zeit zu schreiben, was du eigentlich erreichen willst.
Felix B. schrieb: > weil ja immer ein Controller ausgeschalten oder stillgelegt ist und > damit ja die Pins nicht konfiguriert sind. Bei welchem Controller sind denn die Pins im Reset-Zustand nicht "konfiguriert"? > ich möchte eine Schaltung aufbauen, bei der zwei Mikrocontroller > paralell geschalten werden, um Redundanz zu erwirken. Du solltest diese Idee noch einmal gründlichst(!!) überdenken. Oder mal anschauen, wie andere das machen. Denn du bist ja nicht der erste mit diesem "Problem".
Felix B. schrieb: > Aber es könnte Probleme geben, wenn man Ausgänge paralell > schält, Eine Parallelschaltung kommt hier nicht in Frage, sondern eine spezielle Logik, die entscheidet, was zu tun ist, wenn die Signale nicht gleich sind. Besser ist es meist, wenn drei parallelgeschaltete Computer genommen werden. Dann kann die zwischengeschaltete Logik einen Mehrheitsentscheid machen.
soso... schrieb: > Die Controller werden niemals synchron laufen, und damit kann man die > Ausgänge nicht verbinden. Die Taktquellen allein schon driften > auseinander. Es soll immer nur ein Crontroller im Betrieb sein, und falls der aus irgendeinem Grund stirbt/sich aufhängt, aktiviert ein externer Hardware WD den zweiten Mikrocontroller, der die Aufgaben übernimmt. Lothar M. schrieb: > Oder mal > anschauen, wie andere das machen. Denn du bist ja nicht der erste mit > diesem "Problem". Wenn du da ein Beispiel für mich hättest, wäre das der Hammer, ich habe schon gesucht, aber vermutlich die falschen Schlagwörter verwendet oder so.
Felix B. schrieb: > Aber es könnte Probleme geben, wenn man Ausgänge paralell > schält, weil ja immer ein Controller ausgeschalten oder stillgelegt ist > und damit ja die Pins nicht konfiguriert sind. Im Datenblatt stehen die Grenzwerte für IO-Pins drin. Die beziehen sich teilweise auf die anliegende Versorgungsspannung. Wenn du die bei einem der Prozessoren auf 0 setzt, verstößt du gegen diese Absolut Maximum Ratings.
Felix B. schrieb: > ich möchte eine Schaltung aufbauen, bei der zwei Mikrocontroller > paralell geschalten werden, um Redundanz zu erwirken. Losgelöst von der Frage, ob ein simples parallel schalten "geht", oder ob da doch andere Lösungsansätze notwendig sind, frage dich auch: 1. warum möchtest du Redundanz haben? 2. wie möchtest du feststellen, welcher der beiden MC "richtig" arbeitet, und welcher ausgefallen ist (oder etwas anderes als der andere macht?) 3. was möchtest du machen, wenn du festgestellt hast, das es Abweichungen gibt?
Felix B. schrieb: > Oder habt ihr eine Idee 2 CPUs 1:1 parallel verdrahten geht zu 99,9% schief, sobald ein Takt nicht stimmt und das ist sehr wahrscheinlich. http://www.elektronik-kompendium.de/sites/com/index.htm
Was soll das Ganze ? Spezifisch bitte ? Ein eigener Satellit, eigene Fahrzeugsteuerung, Flugzeugsteuerung ? Das geht anders und diese Technologien hast du nicht, sonst wuerdest du nicht fragen. Unter anderem muessen 3 verschiedene Teams daran arbeiten, denn du wuerdest denselben Fehler wiederholen...
Du könntest den aktuell nicht aktiven Prozessor auf Dauer-Reset halten. Zumindes bei AVR werden dann alle Pins hochohmig. Wenn Du einen Quarz benutzt, brauchst Du hier natürlich für jeden Prozessor einen. Dein Watchdog (der muss natürlich auch redundant sein) muss natürlich dafür sorgen, dass nie beide Prozessoren gleichzeitig laufen. Obwohl ich den Fall eines "Absturzes" anders lösen würde. Auch muss man sich die Gründe für das Ableben eines Prozessors ansehen. Möglicherweise reisst es den zweiten Prozessor und den Watchdog gleich mit in die ewigen Jagdgründe.
Felix B. schrieb: > Es soll immer nur ein Crontroller im Betrieb sein, und falls der aus > irgendeinem Grund stirbt/sich aufhängt, ...und wie stellst Du das fest? Sinn macht es eigentlich nur, mehrere Rechner gleichzeitig laufen zu lassen und die Ergeb- nisse zu vergleichen.
Felix B. schrieb: > bei der zwei Mikrocontroller paralell geschalten werden, um Redundanz zu > erwirken. So, wie du das angehst, offenbar mit einem aktiven µC und einem, der parallelgeschaltet im Reset "lauert", ist deine "Redundanz" rein bauteiltechnisch. Denn in diesem Gedankenmodell fehlt jetzt ja einer, der sicher beurteilt und entscheidet, dass es Zeit ist, den "Reserve-µC" zu aktivieren und den anderen in den Reset zu zwingen... Was soll denn deine Redundanz bewirken? Warum soll der erste µC überhaupt kaputtgehen? Und wie kommst du dann auf die Idee, dass der zweite µC die Aufgabe besser könnte? Redundanz wird erzeugt, indem wichtige Rechnungen von einem zweiten µC paralell gemacht und vom ersten µC (oder beiden gegenseitig) auf Gleichheit verglichen werden. Und wenn das Ergebnis nicht in bestimmten Grenzen(!!!) übereinstimmt, dann schaltet einer der beiden das System in "Notlauf" oder ganz ab.
:
Bearbeitet durch Moderator
Kann sich bitte mal ein Moderator wenigstens der Überschrift annehmen? Grausig ...
Forist schrieb: > Grausig ... Man kann die Absicht gerade noch so erkennen. Es gibt Schlimmeres. ;-)
Lothar M. schrieb: > Und wenn das Ergebnis nicht in bestimmten > Grenzen(!!!) übereinstimmt, dann schaltet einer der beiden das System in > "Notlauf" oder ganz ab. Und welches wird abgeschaltet? Normalerweise braucht man drei Rechner, um entscheiden zu können. Ich glaube, das nennt man drei-Uhren-Problem. Denn schon die alten Segler wussten, das zwei Uhren an Bord nicht viel besser als eine Uhr ist. Erst bei drei Uhren kann man entscheiden.
Felix B. schrieb: > Es soll immer nur ein Crontroller im Betrieb sein, und falls der aus > irgendeinem Grund stirbt/sich aufhängt, aktiviert ein externer Hardware > WD den zweiten Mikrocontroller, der die Aufgaben übernimmt. Ich zweifle ehrlich an, ob das nötig ist. Im Übrigen ist das konzeptionell schon viel schwieriger als du glaubst: Steuern zwei Controller ein Gerät, woher weiß das Gerät, welcher Befehl "legitim" ist, und welcher eine Nebenwirkung des Aufhängens? Du müsstest erkennen können, das ein Controller defekt ist. Und dann auf den zweiten umschalten. Woher nimmst du diese Information, und welche Instanz entscheidet, einen Controller umzuschalten? Was ist, wenn der, der das erkennen muss kaputt wird? Und so weiter. Ich empfehle dir dazu die Themen um die EN61508. Ein echte Schlafmittel. Sonst würde ich dir raten, dich mit Themen wie Exception hanlder und watchdog zu beschäftigen. Einige Firmwareprobleme kann man damit abfangen, ganz ohne zweiten Controller.
Felix B. schrieb: > Es soll immer nur ein Crontroller im Betrieb sein warum? und wenn sich dieser irrt? nee, aber das sagten dir schon andere!
Hallo Brummbär, vielen Dank für die Antwort, Brummbär schrieb: > Du könntest den aktuell nicht aktiven Prozessor auf Dauer-Reset halten. > Zumindes bei AVR werden dann alle Pins hochohmig. Wenn Du einen Quarz > benutzt, brauchst Du hier natürlich für jeden Prozessor einen. Das Ganze ist im Moment noch im werden. Das sind erste Ideeen, daher ist es noch nicht klart welcher Prozessor es werden wird. Aber vielen Dank für den Hinweis der AVR MCU. Jeder Prozessor hat seine eigene "Versorgungsstrucktur" (Boot-Mode selection, Qaurz, Reset-Schaltung, Power-Schaltung, ...) Nur die Pereferie soll geteilt werden (Sensoren, Aktoren) Brummbär schrieb: > Dein Watchdog (der muss natürlich auch redundant sein) muss natürlich > dafür sorgen, dass nie beide Prozessoren gleichzeitig laufen. Das hab ich auf dem Schrim und ist so angedacht. Brummbär schrieb: > Obwohl ich den Fall eines "Absturzes" anders lösen würde. > Auch muss man sich die Gründe für das Ableben eines Prozessors ansehen. > Möglicherweise reisst es den zweiten Prozessor und den Watchdog gleich > mit in die ewigen Jagdgründe. Ich lese bei dir und auch bei anderen heraus, dass ich weiter ausholen muss: Ich bin Student und soll für Forschungszwecke mir eine mögliche Onboardcomputer Architektur für einen CubeSat (Das ist ein kleiner Satellit ca. 10cm x 10cm x 10cm). Und damit, fall es zu Ausfällen des MCU kommt, (z.B. durch Bitflop fehler oder Spannungsspitzen) ist es meine überlegung, ob es möglich wäre, eine zweite MCU auf das Board zu packen, die im Falle des Ablebens oder aufhängens des 1. MCU die Aufgaben übernimmt, und durch Resetten und neu Flashen der Firmware (die in 3 verschiedenen Speichen gespeichert ist, oder neu von der Bodenstation gesendet werden könnte) versucht den 1. Microcontroller wieder in Gang zu setzten, wodurch , bei gelingen der 2. wieder in "Dornröschenschalf" versetzt wird.
Harald W. schrieb: > Und welches wird abgeschaltet? Keines. Der "Notlauf" ist quasi Handbetrieb. Für Sicherheitstechnik reicht sowas aus. Die praktische Ausführung ist allerdings länglich und es gibt ganze Bücher darüber. Mehrere. > Normalerweise braucht man drei Rechner, um entscheiden zu können. Deshalb meine Frage nach der Art der gewünschten "Redundanz".
:
Bearbeitet durch Moderator
Die spannende Frage ist auch, wie soll der zweite Prozessor "übernehmen", wenn er aus dem Reset kommt? Sämtliche Bus-Kommunikation usw. hat der ja verschlafen. Also ein mal alles neu initialisieren? Geht das gefahrlos? Was passiert wenn z.B. ein Antrieb grade fährt und dadurch hart gebremst wird? Oder sind die Aufgaben so simpel, dass nur durch Eingangskombinationen die Ausgänge gesetzt werden? Dann wäre es deutlich einfacher und robuster das Projekt in TTL Logik zu bauen.
Felix B. schrieb: > Und damit, fall es zu Ausfällen des MCU kommt, (z.B. durch Bitflop > fehler oder Spannungsspitzen) ist es meine überlegung, ob es möglich > wäre, eine zweite MCU auf das Board zu packen, die im Falle des Ablebens > oder aufhängens des 1. MCU die Aufgaben übernimmt wer stellt denn fest das es einen Ausfall gibt, viele "Irre" halten sich für normal, das kann also nur festgestellt werden wenn mehrere ihre Ergebnisse vergleichen. Klassische Klausurlösung, der Prof fragt: wer hat 42 als Ergebnis. Der einfache Weg 42 Studenten bestätigen, einer nicht ist kein Beweis. 42 können irren auf Grund falscher Daten!
Lothar M. schrieb: > Denn in diesem Gedankenmodell fehlt jetzt ja einer, der sicher beurteilt > und entscheidet, dass es Zeit ist, den "Reserve-µC" zu aktivieren und > den anderen in den Reset zu zwingen... Dafür würde ich auf externe Hardware Watchdogs zurück greifen. Oder meinst du, dass das unzureichent ist?
Felix B. schrieb: > Ich bin Student und soll für Forschungszwecke mir eine mögliche > Onboardcomputer Architektur für einen CubeSat (Das ist ein kleiner > Satellit ca. 10cm x 10cm x 10cm). Aua. Da Reparaturen vor Ort da ja recht schwierig sind, solltest Du wirklich ein "echtes" Sicherheitssystem wie oben beschrieben aufbauen. Und vermutlich müssen zumindest wichtige Sensoren auch dreifach vor- handen sein.
Felix B. schrieb: > CubeSat Oh, ganz großes Kino. Naja, zumindest nichts sicherheitsrelevantes (ich gehe mal davon aus, dass der CubeSat nicht davon gelenkt werden soll).
Felix B. schrieb: > Oder meinst du, dass das unzureichent ist? Kommt drauf an, auf welche Art der "Haupt-µC" Amok läuft. Wenn der einfach immer nur ein beliebiges Bit umkippen lässt, dann helfen die Watchdogs nichts, denn sie werden regelmäßig zurückgesetzt, obwohl der µC nur Müll abliefert. Felix B. schrieb: > ob es möglich wäre, eine zweite MCU auf das Board zu packen, die im > Falle des Ablebens oder aufhängens des 1. MCU die Aufgaben übernimmt Die Erfahrung (Murphy und so) zeigt, dass im nötigen Fall das Flash der "Rettungs-CPU" auch an relevanter Stelle korrumpiert ist. Du solltest also in das Programm der ersten CPU was einbauen, das laufend den "Rettungsfallschirm" kontrolliert und ggfs. "repariert".
Harald W. schrieb: > Und vermutlich müssen zumindest wichtige Sensoren auch dreifach vor- > handen sein. wieso vermutlich? Jeder µC muss alle Daten unabhängig bekommen! zumindest 3 µC und einer der entscheidet.
Andre schrieb: > Die spannende Frage ist auch, wie soll der zweite Prozessor > "übernehmen", wenn er aus dem Reset kommt? Ich gebe zu, ich bin kein Software spezialist. Aber die Idee ist es, regelmäßig Protokolle in externen Speichern ab zu legen, mit denen die MCU dann weiß was zu tun ist. Andre schrieb: > Oder sind die Aufgaben so simpel, dass nur durch Eingangskombinationen > die Ausgänge gesetzt werden? Dann wäre es deutlich einfacher und > robuster das Projekt in TTL Logik zu bauen. TTL-Logik, geht leider nicht. Da auch (sehr simple) Bildverarbeitung gefragt ist.
Felix B. schrieb: > Ich bin Student und soll für Forschungszwecke mir eine mögliche > Onboardcomputer Architektur für einen CubeSat auswählen? https://www.elektronik-informationen.de/sil-4-tauglicher-single-board-computer/150/23206/299967 Felix B. schrieb: > Es soll immer nur ein Crontroller im Betrieb sein, und falls der aus > irgendeinem Grund stirbt/sich aufhängt, aktiviert ein externer Hardware > WD den zweiten Mikrocontroller, der die Aufgaben übernimmt. Wenn schon beide vorhanden sind dann können diese auch zusammen laufen. Oder in einem Gehäuse: https://www.elektroniknet.de/elektronik/halbleiter/funktionale-sicherheit-in-der-praxis-teil-2-99055-Seite-2.html
Felix B. schrieb: > Ich gebe zu Sobald alle µC die selbe Stromversorgung, SW, HW nutzen, werden sie wohl auch die gleichen Probleme haben. SPOF https://de.wikipedia.org/wiki/Single_Point_of_Failure
Thomas F. schrieb: > auswählen? Es ist ein Forschungsprojekt. Es gibt auch einige OBC speziell für CubeSats zu kaufen. Gerade die Uni Würzburg hat einen mit eben dem von mir beschribenen System. Leider gibt es zu dem erst nähere Informationen zur Schaltung usw. wenn man einen Kauft. ;) Ich arbeite auch mit anderen zusammen und kann auch Proffesoren an meiner Uni frgaen, ich dachte nur auf diesem Weg lassen sich vieleicht ganz ausgefuchste Ideen finden. Vll auch etwas an das noch niemand gedacht hat, aber super simpel und effizent ist. Harald W. schrieb: > Aua. Da Reparaturen vor Ort da ja recht schwierig sind, solltest Du > wirklich ein "echtes" Sicherheitssystem wie oben beschrieben aufbauen. > Und vermutlich müssen zumindest wichtige Sensoren auch dreifach vor- > handen sein. Das Problem ist immer der Platz und der Stromverbauch. Ein CubeSat hat nur 10x10x10cm. Da muss ein Onboardcomputer, ein Telemetriedatenmodul, eine Kamera, ein Lagecontroller, Funk, Batterie, Solarpanel und Energiemanagement rein. Und der Stromverbauch all dessen sollte <2W besser max. 1W sein. Daher macht es wenig Sinn ALLES redundat zu gestalten. Aber zumindest das Herz (MCU) und die Daten (Speicher) sollten das sein. Lebensdauer eines solchen Satelliten ist mit ca. 6 Monaten angedacht. Danach ist er eh irgendwann wieder so weit zur Erde herab gestunken, dass er verglüht.
Andre schrieb: > Dann wäre es deutlich einfacher und > robuster das Projekt in TTL Logik zu bauen. Warum gerade TTL? Diese Reihe galt schon bei der Einführung als besonders störempfindlich.
Felix B. schrieb: > beschribenen wenn man einen Kauft. > Ich arbeite auch mit anderen zusammen und kann auch Proffesoren spätestens bei deiner Bachelorarbeit und Folgende solltest du eine Fehlerkorrektur bemühen, es wirkt sonst nicht sehr gut.
oszi40 schrieb: > Sobald alle µC die selbe Stromversorgung, SW, HW nutzen, werden sie wohl > auch die gleichen Probleme haben. SPOF Nein, keineswegs. Im Weltraum kann es durch Strahlung gezieht zu z.B. sogenannten Bit-Flops kommen, oder im schlimmsten Fall zur zerstörung. Du hast natürlich recht, dass im Schlimmstem Fall beide MCUs zerstört werden können, aber die Hardware zur Stromversorgung usw. ist längst nicht so fragiel und die internen Beschaltungen nicht so klein wie bei einer MCU. Ich würde am liebsten auch alles komplett redundant entwickeln aber das geht auf Grund von Platz und Enegieversorgung nicht.
Joachim B. schrieb: > spätestens bei deiner Bachelorarbeit und Folgende solltest du eine > Fehlerkorrektur bemühen, es wirkt sonst nicht sehr gut. Meinst du jetzt die Fehlerkorrektur des Mikrocontrollers oder meiner Rechtschreibung? :D
wenn du nicht in der Lage bist fehlerfrei zu schreiben, wer glaubt dir das du µC Redundanz fehlerfrei umsetzt?
Felix B. schrieb: > Fehlerkorrektur des Mikrocontrollers oder Rechtschreibung? Beides! Es gibt auch SW, die sich selbst prüft und wer nicht schreiben kann, hat eine Sekretärin. Die passt aber nicht in Deinen Würfel.
oszi40 schrieb: > Felix B. schrieb: >> Fehlerkorrektur des Mikrocontrollers oder Rechtschreibung? > > Beides! Es gibt auch SW, die sich selbst prüft und wer nicht schreiben > kann, hat eine Sekretärin. Die passt aber nicht in Deinen Würfel. Das Weiß ich. Aber ich muss zum Glück keine Software machen. Und ich habe einen kleinen Rechtschreibnazi Zuhause, der mich in dem Fall Korrigieren kann ;)
Streng genommen kann man davon ausgehen, dass der amoklaufende µC seine Ausgänge (und Eingänge) beliebig beschaltet. Das heißt, die Eingänge müssen so realisiert sein, dass dieser sie nicht übersteuern kann. Der Amok-µC darf außerdem nicht in der Lage sein, die Aktoren zu steuern. D.h. da muss es eine schaltbar Trennung dazwischen geben. Das ist alles kein Hexenwerk. An den Eingängen könnten das hochohmige Widerstände erledigen, für die Ausgänge gäbe es Muxer oder Tristatebuffer. Man könnte die Versorgung schalten, aber das hat auch so seine Tücken. Alles das setzt aber voraus, dass es eine dritte Instanz gibt, die das macht. Im einfachsten Fall könnte man einen Window-Watchdog nehmen. Der senkt schon einmal die Wahrscheinlichkeit, dass der Amok-µC den Watchdog versehentlich zurücksetzen kann. Das Ganze ist rein logisch betrachtet ein hübsch verzwicktes Problem. Als erstes würde ich mal vorhandene Literatur sichten. Dann würde zunächst ein Konzept ausformulieren und das mit deinen Kommilitonen durchdiskutieren. Mit einem sauberen Konzept steht und fällt die Sache. Erst wenn das steht, würde ich mir den µC suchen, nicht vorher ;-)
Hat denn keiner eine Idee, wie man das Realisieren könnte. Oder wie man die MCU sonst redundant gestalten könnte? Was ich wirklich spannend fände wären eure Ideen, wie bei einem Gerät, welches man nicht Physisch erreichen kann, mit möglichst einfachen Mitteln den Ausfall der MCU, bzw. die Behebungen eines Ausfalls der MCU realisieren könnt. Mein bisher einfachster einfall war eben die Nutzung einer Ersatz MCU. Übrigens vielen Dank für eure bisherigen Beiträge!! Ich hätte nicht gedacht, dass so schnell so viele antworten! :D
Für Sat Anwendungen sollte man wohl eher einen geeigneten µC verwenden, einen wie den z.B.: TSC695FL Aus dem Datenblatt: • Tested up to a Total Dose of 300 Krds (si) according toMIL STD 883 Method 1019 • No Single Event Latch-up Below an LET Threshold of 80 MeV/mg/cm2 • Single Event Upsets Error Rate Better than: – 2 E-7 Error/Component/Day in GEO Orbit – 5 E-5 Error/Component/Day in LEO Orbit (53°, 1000 km) • Quality Grades: ESCC, and QMLQ or V with 5962-03246 Der kostete mal ca. 7000€/Stück.
soso... schrieb: > Streng genommen kann man davon ausgehen, dass der amoklaufende µC seine > Ausgänge (und Eingänge) beliebig beschaltet. Das heißt, die Eingänge > müssen so realisiert sein, dass dieser sie nicht übersteuern kann. > Der Amok-µC darf außerdem nicht in der Lage sein, die Aktoren zu > steuern. D.h. da muss es eine schaltbar Trennung dazwischen geben. > > Das ist alles kein Hexenwerk. An den Eingängen könnten das hochohmige > Widerstände erledigen, für die Ausgänge gäbe es Muxer oder > Tristatebuffer. > > Man könnte die Versorgung schalten, aber das hat auch so seine Tücken. > > Alles das setzt aber voraus, dass es eine dritte Instanz gibt, die das > macht. > > Im einfachsten Fall könnte man einen Window-Watchdog nehmen. Der senkt > schon einmal die Wahrscheinlichkeit, dass der Amok-µC den Watchdog > versehentlich zurücksetzen kann. > > Das Ganze ist rein logisch betrachtet ein hübsch verzwicktes Problem. > Als erstes würde ich mal vorhandene Literatur sichten. Dann würde > zunächst ein Konzept ausformulieren und das mit deinen Kommilitonen > durchdiskutieren. > > Mit einem sauberen Konzept steht und fällt die Sache. Erst wenn das > steht, würde ich mir den µC suchen, nicht vorher ;-) Vielen Dank für den konstruktiven Beitrag. Wie du schon am Ende angemerkt hast, geht es tatsächlich um die Entwicklung eines eben solchen Konzepts. Die MCU ist mir total egal. Es geht um die beschaltung und die Überwachung außen herum. Letztlich kann man dann mit einem solchen Konzept jede MCU einsetzten. Die Idee eines Window-Watchdog ist super!! Werde ich auf jeden Fall weiter verfolgen!
Forist schrieb: > Kann sich bitte mal ein Moderator wenigstens der Überschrift annehmen? > > Grausig ... parallelschalten OT/Herr Duden kommt gleich aus der Versenkung/OT oder parallel schalten. Einmal Drähte zusammenknoten. zum andern beide Relais gleichzeitig "schalten". ok. Mir fällt da spontan ein: ein Co-Prozessorprinzip? Oder ein Direct Memory Access bei "Fault". Die Frage nach der Kontrollinstanz wurde schon erwähnt. ciao gustav
Die Firma Sun hat das mal mit der "Netra FT1800" versucht. Eine unglaublich aufwändige, teure und lahme Maschine, wo alles mindestens doppelt vorhanden und durch Hotplug-Fähige Treiber gekoppelt war. Laut Sun konnte man dort eine Schraube hinein werfen, ohne dass es zu einer Fehlfunktion kommt. Hat aber nicht funktioniert. Vodafone hatte eine dieser Maschinen gekauft. Es stellte sich heraus, dass diese Maschine die unzuverlässigste war, die diese Firma jemals gesehen hatte. Bei jeder zweiten Reparatur musste sie trotz der "ausgeklügelten" Hardware rebooted werden. Selbst durch einen kompletten Austausch wurde es nicht besser. Ständig war etwas kaputt und sie stürzte alle paar Wochen trotz ab. An der Anwendungs-Software lag es nachweislich nicht. Wenn die Software fehlerhaft gewesen wären, hätte der ganze Aufwand zudem nichts genutzt. Z.B: Gegen einen falschen Löschbefehl auf der Festplatte nützt auch 100-Fache Redundanz gar nichts.
Felix B. schrieb: > Was ich wirklich spannend fände wären eure Ideen, wie bei einem Gerät, > welches man nicht Physisch erreichen kann, mit möglichst einfachen > Mitteln den Ausfall der MCU, bzw. die Behebungen eines Ausfalls der MCU > realisieren könnt. Ganz einfach: Zwei Geräte aufstellen, zwischen denen man manuell oder automatisch umschaltet.
Markus M. schrieb: > Der kostete mal ca. 7000€/Stück. Das ist ja das Tolle an einem CubeSat. Er bewegt sich im LEO (LowEarthOrbit) und ist dadurch 1. schonmal ein bisschen durch das Magnetfeld der Erde geschützt und hat 2. nur eine kurze Lebensdauer (ca. 6-12 Monate) bevor er verglüht. Dadurch kann man durchaus auch Consumer Hardware verwenden, die zwar kaum Single-Event geschützt sind, aber der Radioaktivität des LEO min. 6 Monate und länger (MOVE I der LMU ist jetzt 3 Jahre oben und funktioniert immernoch. Trotzt der Verwendung von bloß einer MCU).
Felix B. schrieb: > Das ist ja das Tolle an einem CubeSat. Er bewegt sich im LEO > (LowEarthOrbit) und ist dadurch 1. schonmal ein bisschen durch das > Magnetfeld der Erde geschützt und hat 2. nur eine kurze Lebensdauer (ca. > 6-12 Monate) bevor er verglüht. Punk1 1 & 2 haben es in sich: du brauchst also nur dafür zu sorgen, dass dein technisches Machwerk auf der Erde bleibt(VLEO!) und musst sofort nach dem Flashen mit dem 5 kg Hammer (aka Mottek) draufschlagen (kurze Lebensdauer!).
Wie wäre es denn mit einem Cortex-R, die haben meines Wissens nach schon eine Redundanz im Rechenwerk. Da weißt du dann zwar nicht welcher der beiden Kerne Müll ausgibt aber du merkst zumindest das etwas schief gelaufen ist und kannst die Kiste durch geordnete Eingriffe (z.B. Reset) wieder in einen definierten Zustand bringen.
Parallel schalten funktioniert so nicht, bzw. die Ausfallrate erhöht sich sogar. Zuerst muß man dafür sorgen, daß die VCC, Eingänge, Ausgänge entsprechend geschützt sind. Dann muß die Zusatzbeschaltung entsprechend sorgfältig aufgebaut sein, die CPU kann ja nicht einen durchgebrannten Transistor abschalten. Dann muß man die Software entsprechend sorgfältig planen, schreiben und prüfen. Und erst weit dahinter kommen Fehler durch die CPU. Man kann dann natürlich nicht 2 identische Programme laufen lassen. Eine CPU führt das normale Programm aus und die 2. überwacht die erste und führt im Fehlerfall ein abgerüstetes Notprogramm aus.
Peter D. schrieb: > die 2. überwacht und baut dabei Scheiße und schaltet die eigendlich funktionierende 1. ab.....
Ich bin der Meinung, daß die einfachste Lösung die die wirklichen Hauptanforderungen erfüllt, die richtige Lösung ist und sich Klaren zu sein "Was ist für LEO Anforderungen gut genug?" Und zu vermeiden eine eilegende Wollmilchsau konstruieren zu wollen. Dann würde ich auch evalieren, was sind die Folgen eines WD Reset und kompletter Neustart aller Subsysteme. Also muß das Watchdogsystem so zuverläßig und zweckmäßig wie möglich sein und auch schnelle Vcc Abschaltung und Strombegrenzung haben, so daß möglicherweise vorkommende Latchups keinen permanenten Schaden anrichten können. Bei vielen Space Anwendungen kommt es mehr darauf an HW und SW Katastrophen zu vermeiden. Ein gelegentlicher Reset ist da auch keine Katastrophe. Auch gewisse Datenverluste sind manchmal tragbar, zumindest im Erdorbit. Wenn der LEO nur Sensordaten zur Erde senden muß, ist ein seltener Reset und Neustart sowieso keine Katastrophe. Bei Experimenten ist sowieso ein eigener Versuchsprozessor dafür verantwortlich. Auch würde ich so viel wie möglich mit Serial Bussen wie Serial, I2C, SPI und CAN zu arbeiten und Arbeiten aufteilen. Der Hauptprozessor sollte nur der "great Coordinator" sein und delegieren. Auch sollte man Interrupts nur dort verwenden wo absolut kein Risiko besteht und alles nach Möglichkeit mit Pollen und State-Machines erledigen, so daß man alles berücksichtigen kann. Auch Rechenoperationen nüssen "Bullet proof" sein. Divide by zero und ähnliche Missgeschicke dürfen nicht vorkommen. Zusammen mit einem vernünftig verbundenen externen WD dürfte das ausreichend zuverläßig für die Anwendung sein. Das elektrische Design muß sehr robust sein und 100% autark funktionieren können. Man sollte auch nicht vergessen, daß in vielen Space Produkten früher mit recht langsamen Prozessoren gearbeitet wurden und Arbeitsgeschwindigkeit oft nicht ausschlaggebend ist. Etwaige I2C Peripherien müssen einen Power Cycle zulassen, so dass bei einem Bus lockup die Peripherie wieder neu gestartet werden kann. Nicht alle Bausteine haben Clock Reset wie Smb. Jedes Peripherie Sub System muß eine Power Control haben um alles gezielt initialisieren zu können. Nichts darf nach Möglichkeit dem Zufall ausgeliefert sein. Mit einem EERAM oder FRAM lassen sich Zwischenzustände speichern, so dass nach einem Neustart Kontext erhalten bleibt. Ein WD restart sorgt zumindest für klare Verhältnisse nach dem Neustart. Also, was mich betrifft bin ich gegen parallel aktiver Operation. Nur vielleicht als Standby im Umschaltbetrieb. Und wenn es doch wirklich parallel sein soll, alle Literatur diesbezüglich durchforsten. Ich würde auch vorschlagen mal im Internet bezüglich anderer LEO Projekte zu stöbern. Es ist ganz nützlich zu sehen wie andere Studenten bevor Dir diese Probleme gelöst haben, was funktioniert und was nicht.
:
Bearbeitet durch User
Du kannst auch bei RUAG (die bauen Sateliten) oder direkt bei der ESA nachfragen. Mit einem guten Konzept und viel Hartnäckigkeit und Glück kommt man an die richtigen Leute ran..
Moin Felix, Vielleicht suchst du dir mal ein paar Infos zum Mars Rover Curiosity. Der hat auch zwei SBC mit an Bord. Vielleicht findest du mit etwas Literaturrecherche ja heraus, wie die NASA die Redundanz bzw. Überwachung da umsetzt. Gruß
Hallo, ich möchte, obwohl ich mich mit Weltraumanwendungen nicht auskenne, auch einen Vorschlag unterbreiten. Wie ich heraus gelesen habe, ist das grösste Problem im All, das bei einem Prozessor durch die Strahlung, ein Bit im Speicher (Flash/RAM/Register) umkippen kann und so der µC nur noch Müll produziert. Meine Idee ist nun: 1. den µC regelmässig (alle 2-24h) durch externe HW zurückzusetzen, um evt. Fehler in (RAM/Register) zu beheben. Und 2. regelmässig den Flash-speicher zu überprüfen, in dem ein weiterer µC den Flash-Inhalt mit redundanten Kopien (eigene Speicherchips) vergleicht. Dieser µC müsste natürlich durch den "Haupt"-µC wieder kontrolliert werden. LG und viel Spass beim diskutieren...
Warum nicht einen Dual-Core mit Lockstep verwenden? Z.B. TI Hercules oder diverse SPCxx von STM. Jörg
> Bit im Speicher (Flash/RAM/Register) umkippen
Sich selbst testende Software wir auch auf der Erde benutzt. Ob ein
täglicher Rest immer glücklich macht, oder alle Werte killt, ist die
Kunst der Programmierer.
Wundert mich auch etwas, dass das Wort Lockstep erst jetzt fällt. Das ist doch genau das, was der TE sucht.
Harald A. schrieb: > Wundert mich auch etwas, dass das Wort Lockstep erst jetzt fällt. Das > ist doch genau das, was der TE sucht. Das hilft ja auch nur bei der Fehlererkennung nicht aber bei der redundanten Systemauslegung. Wenn ein SEU (Single Event Upset) eine Flashzelle im Programm kippt hat man trotzdem kein funktionierendes System. Das reicht also gerade so mal für ASIL-B. (ggf. Übergang in einen sicheren Zustand). Hier wären Anforderungen aus der Luftfahrt (DO-254, DO-178 etc.) zu erfüllen. Gruß Anja
Gehen wir mal von destruktiven Strahlenschaeden aus. Dh der Code macht Muell, oder Daten sind Muell. Und das bleibt so. Ich wuerde einmal ueber 3 CPUs nachdenken, die geometrisch senkrecht zueinander moniert sind. zB auf 3 Seiten eines Wuerfels. Eine AVR benoetigt extrem wenig Strom, kann also 3 fach laufen. Ich wuerde das Problem in mehrere Funktionalitaeten unterteilen, die verschieden sicher laufen muessen. Im sinne von : - was geschieht, wenn eine Funktionalitaet ausfaellt ? - welches ist die wichtigste Funktionalitaet, ohne die der Satellit wertlos ist ? Die laeuft dann redundant. - Wie kann entschieden werden, ob und welche CPU einen Fehler macht ? Den Code kann man mit einer periodischen CRC Ueberpruefung testen. zB alle Sekunde oder alle Minuten. Das kann die CPU selbst machen. Daten koennen doppelt abgelegt werden. Und auch periodisch auf Duplizitaet ueberpruft werden. Welche Fehler werden so uebersehen ? Und und und. Gehen wir von nicht destruktive Schaeden aus. Dh der Code macht Muell, oder Daten sind Muell. Und das muss nicht so bleiben. Auf welcher Zeitskala kann sich die CPU erholen? Was geschieht wenn ein Sensor defekt ist ? Wie kann ein defekter Sensor erkannt werden ? Koennte man den allenfalls redundant haben ?
глупний форентроль schrieb: > Gehen wir von nicht destruktive Schaeden aus. Dh der Code macht Muell, > oder Daten sind Muell. Und das muss nicht so bleiben. Auf welcher > Zeitskala kann sich die CPU erholen? Es gibt auch noch die Möglichkeit, dass der Code zu Müll geworden ist, z.B. weil ein Bit des Programmspeichers gekippt ist oder ein Teil des Speichers ausfällt. Dann muss der Prozessor sein Programm neu bekommen oder ein neues Programm mit einem work around, also Upload - Check - Flash.
Sind Eproms eigentlich Weltraum-tauglicher als Flash Speicher? Und gibt es eigentlich noch Einweg PROMs?
Wolfgang schrieb: > auch noch die Möglichkeit, dass der Code zu Müll geworden ist Das muß es aber einer merken und noch reagieren können. Dazu brauchst Du alles 3x im Speicher um zu erkennen welche 2 richtig sind und dann gibt es noch veränderliche Daten...
... was ich hier so lese ist viel unsinn und ich lege noch was dazu. - kalte und heise redundanz, schon mal gehört? - abhängige versus unabhängige ereignisse bzgl. zuverlässigkeit verstanden? daraus folgt, wenn man die zuverlässigkeit erhöhen will ... nur komplett unabhängige systeme verbessern diese! bedeutet stromversorgung, taktsystem, messfühler, reset system, ... muss alles getrennt sein, plus! extra pcb, örtliche trennung, ... sonst wirken die gleichen stör-/fehlerursanchen auf alle systeme gleich und diese sind nicht mehr UNABHÄNGIG von einander! heise redundanz macht eigentlich nur sinn, sprich die parallel systeme sind alle aktiv zu jeder zeit, und wie schon erwähnt es müssen drei sein um entscheidungsfähig zu sein. die angedachte schaltungstechnische "parallelschaltung" bzgl. zuverlässigkeit ist völliger unsinn, weil größtmögliche physikalische entkopplung die voraussetzung für unabhängige ereignisse ist! beispiel: fahrrad, 2 reifen mit jeweils 0,1 ausfallwahrscheinlichheit ... frage, wie gross ist die ausfallwahrscheinlichkeit vom fahrrad? wer von den klugscheisern hier hat eine antwort + begründung und wie kann ich das fahrrad zuverlässiger machen bzgl der reifen?! will sehen ..., mt 1.p.s. ein system läßt sich nur gegen vorher bestimmte/eingegrenzte fehler und ursachen tolerant auslegen und es besteht auch die möglichkeit, dass die zuverlässigkeit sinkt, da jedes extra bauteil/lötstelle! die zuverlässigkeit auch wieder negative beeinflusst - logisch! 2. p.s. kalte redundanz, beispiel notstromversorgung ... man weis nie, ob diese auch anspringt oder wenn nicht "physisch entkoppelt" sprich z.b alles steht im keller und ist im wasser abgetaucht, dann geht trotz redundanz nichts mehr! darum wird wichtige datensicherung auch auf physikalisch unterschiedlichen datenträgern umgesetzt, spricht optisch und magnetisch und ...
ElektroHeini schrieb: > Wie ich heraus gelesen habe, ist das > grösste Problem im All, das bei einem Prozessor durch die Strahlung, ein > Bit im Speicher (Flash/RAM/Register) umkippen kann und so der µC nur > noch Müll produziert. wer sagt das? es könnte auch jede einzelene lötstelle oder bonddraht ein grösseres problem mitbringen?! wie wirken den auf der "erde induzierte" sw fehler im weltall unter teilchenstrahlung?! - ich sag nur, kein wichtiges redundantes system hat die gleiche sw und schon garnicht vom gleichen team mit gleichen sw werkzeugen erzeugt. ok, nochmal zur frage hier, sinn macht hier nur ein nicht redundantes system entsprechend zuverlässig auszulegen! sprich top stromversorgung, beste bausteile, bombenfeste mechanik, zuverlässige verbindungstechnik,... plus fehlertolerante sw funktionen! und z.b. bzgl. frühausfälle die bauteile im "backofen" voraltern. das alleine wird schon teuer und aufwendig! mit hausmittel würde hier jede erhöhung der komplexität im sinne von redundante systeme die zuverlässigkeit garantiert verschlechtern!!! mt
:
Bearbeitet durch User
Wie wäre es mit dem hier? https://www-verimag.imag.fr/~sifakis/papers_pdfs/Architecture-based%20DesignRep.pdf https://res.mdpi.com/aerospace/aerospace-05-00121/article_deploy/aerospace-05-00121.pdf?filename=&attachment=1 https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=2070&context=etd https://commons.erau.edu/cgi/viewcontent.cgi?article=1031&context=mcnair https://uknowledge.uky.edu/cgi/viewcontent.cgi?article=1588&context=gradschool_theses http://www.space.aau.dk/cubesat/documents/DTU_kursus_Architecture_of_onboard_systems.ppt https://www.nasa.gov/sites/default/files/atoms/files/nasa_csli_cubesat_101_508.pdf http://org.ntnu.no/studsat/docs/proposal_1/A8%20-%20Cubesat%20Design%20Specification.pdf ...
Stefanus F. schrieb: > Sind Eproms eigentlich Weltraum-tauglicher als Flash Speicher? Und gibt > es eigentlich noch Einweg PROMs? Zumindest kann man sich das Zukleben des Fensters sparen, weil die Strahlung im Zweifel sowieso von unten kommt. :) Im Verdoppelnwollen der CPU sehe ich aber eine Parallele zum Threadtitel: Einfach irgendwas verdoppeln macht eine Sache nicht besser, wenns nicht das richtige ist.
глупний форентроль schrieb: > Ich wuerde einmal ueber 3 CPUs nachdenken, die geometrisch senkrecht > zueinander moniert sind. zB auf 3 Seiten eines Wuerfels. Eine AVR > benoetigt extrem wenig Strom, kann also 3 fach laufen. 3 unterschiedliche Systeme sind noch besser.
Apollo M. schrieb: > nur komplett unabhängige systeme verbessern diese! Dafür habe ich ein -1 bekommen.
Erst einmal muss klar sein, was der CubeSat genau tun soll. Welche Sensoren sind vorhanden und was muss gesteuert werden? Was passiert, wenn einzelne Komponenten ausfallen (auch Sensoren können ge-/zerstört werden)? Am besten alle Ausfallvarianten gegenüber stellen und die Ausfallwahrscheinlichkeit bestimmen/schätzen. ZB. wie schlimm ist es, wenn die rote Betriebs-LED ausfällt? Dann kann man sich überlegen, welche Ausfälle abgesichert werden können und welcher Aufwand dahinter steckt. Es muss ja auch der verfügbare Platz und eventuell das Gewicht berücksichtigt werden. Mehr Elektronik braucht auch mehr Strom, wodurch die Batterien größer sein müssen und auch mehr Platz verbrauchen. Einfach vorweg zu sagen, dass alles abgesichert werden soll, bringt nichts.
Ach ja. Es geht hier "nur" um ein Forschungsprojekt welches irgend welche Messwerte erfasst, filtert und zur Erde schickt. Die Auswertung erfolgt nicht im SAT (hoffe ich mal). Wenn irgendwelche Messwerte nicht erfasst werden können ist es lediglich ein finanzieller Schaden. Es geht hier nicht um Menschenleben. Echte Redundanz kann hier nur durch mehrere identische CubeSat geschaffen werden.
>Wenn irgendwelche Messwerte nicht erfasst werden können ist es lediglich ein
finanzieller Schaden.
Dann wird die Mission nicht erfuellt, und das Investment ist weg. Plus
die Reputation. In welcher Groessenordnung liegt das Investment ?
Bru schrieb: > Echte Redundanz kann hier nur durch mehrere identische CubeSat > geschaffen werden. Gleicher Typ, gleiche SW, gleiche Risiko = gleiche Fehler? Schon erlebt.
Die Massnahmen die ich durchfuehren wuerde wurden schon genannt, ich moechte es noch begruenden: 2 parallele Prozessoren haben statistisch doppelt so viele Ausfaelle wie einer. Der TE will einen aber schlafen lassen, ist also erstmal kein Problem. Im Fehlerfall wird der Ersatzcontroller geweckt. Warum nicht einfach einen Reset durchfuehren? Eigentlich hilft das Umschalten im Vergleich zum Reset nur bei genau einem zusaetzlichen Fall: Wenn die Hardware des Controllers kaputt ist. Mir scheint das aber nicht sehr wahrscheinlich, vorher kommt es zu Speicherfehlern (Bit-Kippen). Der schlafende Controller kann aber auch schon Fehler "gesammelt" haben. Ausserdem wird es schwer sein, den Hardwarefehler zu erkennen. Deshalb wuerde ich meinen Augenmerk auf den Flashspeicher richten. Also zyklische Ueberpruefungen. Natuerlich nutzt es nichts, einen Fehler nur zu finden (mittels CRC bspw.), sondern der korrekte Wert muss auch wiederhergestellt werden. Auch da gilt, man braucht mindestens drei Instanzen fuer den Vergleich. Z.B. ueber doppelten Code und Checksumme. Oder dreifachen Code. Der Einfachheit halber soll das alles in einem Controller liegen.
Angehängte Dateien:
-
Eprom_27128_.jpg
30 KB
Stefanus F. schrieb: > Sind Eproms eigentlich Weltraum-tauglicher als Flash Speicher? Und gibt > es eigentlich noch Einweg PROMs? Hi, komisch bei C* gibt es über SOS Subunternehmer nur für Geschäftskunden dieses Teil: 27 C 010-70 PLCC32 Die 27-er mit dem Fenster liegen bei mir nur noch rum. Wenn kräftig lichtundurchlässiger Lack auf das Fenster gekleistert wurde, war von Datenverlust kaum die Rede. Es sind auch IMHO mehr Elektronen vorhanden, die erst einmal bis zur kritischen Minderzahl durch kosmische Strahlung herausgeschossen werden müssten. Bei der Flashtechnologie bin ich da nicht ganz so sicher. Wenn die Wahrscheinlichkeit des Treffens eines geladenen Teilches durch kosmische Einflüsse auch von der Fläche abhängt, dann ist diese bei möglichst kleiner Fläche folglich auch geringer. Wie sieht das jetzt bei den Flash-Speichern aus? Da gab es bei den EPROMs welche ohne Fenster, die konnte man nur einmal brennen und nicht mit UV-Licht löschen, die waren in den BIOS-ICs der 286-er bis Pentium-PCs noch drin. ciao gustav
:
Bearbeitet durch User
Ich habe hier ein System aus zwei, ja.. man kann es SPSen nennen am laufen, die solch einen BackUp-Betrieb machen. Das sind FM1 und FM2. Die Dinger haben allerdings keine normalen I/O-Ausgänge, sondern hängen nur an einem Bus. Beide bekommen sämtliche Infos die auf dem Bus laufen mit, und verarbeiten die ganz normal, aber nur die gerade aktive FM schickt ihr Ergebnis auf den Bus. Und dann schicken die sich noch gegenseitig ein Lebenszeichen, fällt das aus, schaltet die passive FM auf den aktiven Modus um. Ich würde jetzt versuchen, dass ganze um eine weitere FM zu erweitern und einen Mehrheitsentscheid unterzukriegen. Und wenn ich ganz sicher gehen wollen würde, würde ich jede FM mit einem anderen Team auf anderer Hardware und einem anderen Softwarekonzept aufbauen.
@Matthias Mach bitte einen eigenen Thread auf, anstatt einen anderen zu kapern.
oszi40 schrieb: >> auch noch die Möglichkeit, dass der Code zu Müll geworden ist > Dazu brauchst Du alles 3x im Speicher um zu erkennen > welche 2 richtig sind und dann gibt es noch veränderliche Daten. Nein, dafür benutzt man redundante Codes mit grosser Hamming- Distanz. Sowas wird ja schon auf der Erde benutzt z.B. auf CDs. https://de.wikipedia.org/wiki/Hamming-Abstand
Stefanus F. schrieb: > Apollo M. schrieb: >> nur komplett unabhängige systeme verbessern diese! > > Dafür habe ich ein -1 bekommen. Ja, weil Du zwei benannt hast. (Ich war es nicht). @TO: Mach es wie im Flugzeug, da gibt es genügend Literatur drüber. Nicht die Mcs trennen, sondern vier komplett redundante Boards mit vier Gehäusen und vier Anschlüssen, die a) alles dasselbe rechnen und b) ihre Ergebnisse untereinander vergleichen. Rechnet einer davon nur noch Müll wird dieser ausgeschlossen. Der Punkt hierbei ist, sowiel Hardware wie möglich zu duplizieren, und nicht nur ein Mc. Und nicht eine weitere Instanz für das Monitoring hinzubauen, weil diese müsste dann ebenfalls redundant ausgelegt werden. Du musst soweit gehen, dass Du an Unit (a) im laufenden Betrieb den Stecker ziehen kannst, sämtliche Litzen abisolieren und zusammenzwirbeln kannst ohne dass der Betrieb beeinträchtigt wird.
:
Bearbeitet durch User
Hallo Felix, > Ich arbeite auch mit anderen zusammen > und kann auch Proffesoren an meiner Uni frgaen, Nun, was sagen denn die Professoren? Vielleicht ja sogar "/Redundanz ist in eurem Fall Kanonen auf Spatzen. Schön das ihr daran gedacht habt, aber [...]/". Immerhin schreibst du ja: > MOVE I der LMU ist jetzt 3 Jahre oben > und funktioniert immernoch. Trotzt der Verwendung von bloß einer MCU Natürlich wäre es doof, wenn der CubeSat nach einer Woche Betrieb ausfällt. Aber für euch als Studenten steht doch sicher das Design im Vordergrund und weniger der (Dauer-) Betrieb? Außerdem ist der LEO ja auch voll mit Weltraumschrott ;) Da macht die Redundanz dann auch nichts mehr, wenn ihr getroffen werdet. Klar könnt ihr euren Satelliten beliebig komplex machen. Aber gerade als studentisches Team sollte man sich da vielleicht kleinere Ziele stecken statt sich zu überheben.
Wenn man 2 µC parallel haben möchte ist so ziemlich das einfachste einen µC zu verwenden der das schon im Chip hat, Beispiel: LPC4357 von NXP Der Cortex-M4 rechnet schnell & Leistungsfähig, der Cortex-M0 überwacht diesen und kann ggf. übernehmen. Die Peripherie im µC können beide Kerne verwenden. Damit ist man die ganzen Probleme los, die man hätte wenn man 2 µC auf einer Platine unterbringen wollte die sich gegenseitig überwachen und zudem ist diese Variante noch so ziemlich das leichteste vom Gewicht her. Bietet natürlich nicht die Sicherheit von komplett redundanten Systemen.
:
Bearbeitet durch User
Eventuell die eigentliche Fehlerkorrektur auf der Erde lassen? Drei Sensoren messen die Temperatur und senden diese unabhängig zur Erde. Dort hast Du genügend Ressourcen, die korrekten Werte auszusuchen. (Das ist jetzt nur ein Beispiel, was auch für andere Messwerte funktionieren kann).
Wie wäre es hiermit: https://de.wikipedia.org/wiki/LEON Das bedeutet allerdings den Einsatz eines FPGA. Wenn ich mich recht erinnere, gab es auf opencores auch andere fehlertolerante CPU-Kerne für genau diesen Anwendungsfall.
Spitzer schrieb: > Deshalb wuerde ich meinen Augenmerk auf den Flashspeicher richten. Also > zyklische Ueberpruefungen. Natuerlich nutzt es nichts, einen Fehler nur > zu finden (mittels CRC bspw.), sondern der korrekte Wert muss auch > wiederhergestellt werden. Auch da gilt, man braucht mindestens drei > Instanzen fuer den Vergleich. Z.B. ueber doppelten Code und Checksumme. > Oder dreifachen Code. Der Einfachheit halber soll das alles in einem > Controller liegen. Im letzten Punkt stimme ich dir nicht zu, da auch erkannt werden muss, ob die Routine, die den Flash-speicher kontrollieren soll einen Fehler hat. Sollte die nämlich einen haben und falsche Daten herstellen, so hätte man sich den Aufwand auch sparen können. Zum Bsp. sowas halte ich für geeignet: Markus M. schrieb: > Damit ist man die ganzen Probleme los, die man hätte wenn man 2 µC auf > einer Platine unterbringen wollte die sich gegenseitig überwachen und > zudem ist diese Variante noch so ziemlich das leichteste vom Gewicht > her. > Bietet natürlich nicht die Sicherheit von komplett redundanten Systemen. Stimmt, ich glaube aber, dass das gar nicht notwendig ist. Bru schrieb: > Eventuell die eigentliche Fehlerkorrektur auf der Erde lassen? > Drei Sensoren messen die Temperatur und senden diese unabhängig zur > Erde. Das bringt mich auf die Idee, zwei redundante Programmer für den µC einzubauen, die von der Erde aus gesteuert den Haupt-µC jederzeit neu Programmieren können. Natürlich müssen die beiden über eine eigene Funkverbindung und Stromversorgung verfügen. Die könnte man jeweils mit unterschiedlicher Hardware aufbauen, um die Ausfallsicherheit noch etwas zu steigern.
> zwei redundante
Kurz: Aufwand,Nutzen und Zuverlässigkeit abschätzen. Evtl. reichen 2
völlig autonome Systeme, wovon man das 2. erst aktiviert, wenn das 1.
keine Lust mehr hat? Die SW sollte sich natürlich sich gelegentlich
prüfen und Status liefern. Der Sputnik hatte auch nicht alles in
mehrfacher Ausführung? Je weniger Schnickschnack man einbaut, desto
weniger Strom wird verschwendet, was die Laufzeit verlängert. Ein Teil
der Vorbereitung muß natürlich ein strenger HW-Test mit EMV, Temperatur,
Resonanzen, Erschütterung, Vakuum usw. sein.
ElektroHeini schrieb: > Das bringt mich auf die Idee, zwei redundante Programmer für den µC > einzubauen, die von der Erde aus gesteuert den Haupt-µC jederzeit neu > Programmieren können. Natürlich müssen die beiden über eine eigene > Funkverbindung und Stromversorgung verfügen. Die könnte man jeweils mit > unterschiedlicher Hardware aufbauen, um die Ausfallsicherheit noch etwas > zu steigern. Das ist auf jeden Fall eine Idee, die ich weiter verfolgen werde. Danke!
Microchip PIC18F8722 in space: https://microcontroller.com/news/microchip_SuitSat1_NASA.asp https://www.esa.int/Our_Activities/Space_Engineering_Technology/Onboard_Computer_and_Data_Handling/Onboard_Storage https://www.esa.int/Our_Activities/Space_Engineering_Technology/Onboard_Computer_and_Data_Handling/Microcontrollers https://www.militaryaerospace.com/articles/2018/09/radiaton-hardened-cubesat-space.html https://www.militaryaerospace.com/articles/2018/02/radiation-hardened-microcontroller-for-space-satellites-introduced-by-microchip-technology.html https://nepp.nasa.gov/mapld_2009/talks/083109_Monday/06_Troxel_Ian_mapld09_pres_2.pdf https://thememoryguy.com/memory-issues-in-space-medical-applications/
Meiner Meinung nach geht die größte Gefahr von "Bitkippern" und Frühausfällen aus. Moderne "größere" automotive Controller wie die oben von mir genannten haben ECC bei Flash, RAM und Cache. Damit löst ein gekipptes Bit ggf. erst mal nur eine Exception beim Lesen aus. Außerdem sind sie im Allgemeinen für einen größeren Temperaturbereich ausgelegt und haben auch schon ein Burn-In absolviert. Gegebenenfalls müssen halt noch weitere Redundanz-Maßnahmen getroffen werden. Jörg
Joerg W. schrieb: > Meiner Meinung nach geht die größte Gefahr von "Bitkippern" und > Frühausfällen aus. Bedenke auch die Lötstellen und die verwendeten Platinen. Ich könnte mir vorstellen, dass eine kalte Lötstelle im All nicht so gut ankommt. Nachlösten wird ein Problem sein. Wäre es hier vielleicht besser, auch Blei-Lot zu gehen? (keine Ahnung, nur so ein Gedanke)
Bru schrieb: > Wäre es hier vielleicht besser, auch Blei-Lot zu gehen? (keine Ahnung, > nur so ein Gedanke) kein falscher Gedanke, für Bleilot gibt es einige Ausnahmen vom Verbot, besonders wo es auf Ausfallsicherheit ankommt.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.