Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller Paralell schalten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Felix B. (Firma: Student) (fefo)


Bewertung
-5 lesenswert
nicht lesenswert
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
von Max M. (jens2001)


Bewertung
-3 lesenswert
nicht lesenswert
Felix B. schrieb:
> dauerhaftes
> Reset-Signal

RTFM!

von soso... (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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".

von Harald W. (wilhelms)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Wegstaben V. (wegstabenverbuchsler)


Bewertung
1 lesenswert
nicht lesenswert
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?

von oszi40 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von глупний форентроль (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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...

von Brummbär (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Harald W. (wilhelms)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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
von Forist (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Kann sich bitte mal ein Moderator wenigstens der Überschrift annehmen?

Grausig ...

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Forist schrieb:
> Grausig ...
Man kann die Absicht gerade noch so erkennen. Es gibt Schlimmeres.   ;-)

von Harald W. (wilhelms)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Begeistert!!! (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Felix B. (Firma: Student) (fefo)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Andre (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Felix B. (Firma: Student) (fefo)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Harald W. (wilhelms)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Brummbär (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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".

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Thomas F. (igel)


Bewertung
-1 lesenswert
nicht lesenswert
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

von oszi40 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Felix B. (Firma: Student) (fefo)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Harald W. (wilhelms)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
wenn du nicht in der Lage bist fehlerfrei zu schreiben, wer glaubt dir 
das du µC Redundanz fehlerfrei umsetzt?

von oszi40 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
-1 lesenswert
nicht lesenswert
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 ;)

von malsehen (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Felix B. schrieb:
> Bit-Flops

Das Projekt wird wohl ein Flip.

von soso... (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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 ;-)

von Felix B. (Firma: Student) (fefo)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
-2 lesenswert
nicht lesenswert
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!

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Felix B. (Firma: Student) (fefo)


Bewertung
0 lesenswert
nicht lesenswert
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).

von A. Defgenowitsch (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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!).

von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Max M. (jens2001)


Bewertung
4 lesenswert
nicht lesenswert
Peter D. schrieb:
> die 2. überwacht

und baut dabei Scheiße und schaltet die eigendlich funktionierende 1. 
ab.....

von Gerhard O. (gerhard_)


Bewertung
3 lesenswert
nicht lesenswert
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
von Petra (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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..

von Lars F. (flemmy)


Bewertung
0 lesenswert
nicht lesenswert
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ß

von ElektroHeini (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Warum nicht einen Dual-Core mit Lockstep verwenden? Z.B. TI Hercules 
oder diverse SPCxx von STM.

Jörg

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Harald A. (embedded)


Bewertung
0 lesenswert
nicht lesenswert
Wundert mich auch etwas, dass das Wort Lockstep erst jetzt fällt. Das 
ist doch genau das, was der TE sucht.

von Anja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von глупний форентроль (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
глупний форентроль 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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Sind Eproms eigentlich Weltraum-tauglicher als Flash Speicher? Und gibt 
es eigentlich noch Einweg PROMs?

: Bearbeitet durch User
von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Apollo M. (Firma: @home) (majortom)


Bewertung
0 lesenswert
nicht lesenswert
... 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 ...

von Apollo M. (Firma: @home) (majortom)


Bewertung
2 lesenswert
nicht lesenswert
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
von Cubesat Frickler (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Wollvieh W. (wollvieh)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
глупний форентроль 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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Apollo M. schrieb:
> nur komplett unabhängige systeme verbessern diese!

Dafür habe ich ein -1 bekommen.

von Bru (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bru (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Purzel H. (hacky)


Bewertung
0 lesenswert
nicht lesenswert
>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 ?

von oszi40 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bru schrieb:
> Echte Redundanz kann hier nur durch mehrere identische CubeSat
> geschaffen werden.

Gleicher Typ, gleiche SW, gleiche Risiko = gleiche Fehler? Schon erlebt.

von Spitzer (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Matthias S. (da_user)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Bru (Gast)


Bewertung
1 lesenswert
nicht lesenswert
@Matthias
Mach bitte einen eigenen Thread auf, anstatt einen anderen zu kapern.

von Harald W. (wilhelms)


Bewertung
0 lesenswert
nicht lesenswert
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

von Philipp G. (geiserp01)


Bewertung
0 lesenswert
nicht lesenswert
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
von Lars F. (flemmy)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
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
von Bru (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von der Profi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ElektroHeini (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von oszi40 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> 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.

von Felix B. (Firma: Student) (fefo)


Bewertung
-1 lesenswert
nicht lesenswert
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!

von Cubesat Frickler (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bru (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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)

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.