Hi, kann ich zwei Atmegas mit jeweils dem gleichen Programm synchron laufen lassen, das wenn einer der beiden ausfällt, der andere übernimmt? Wenn ja, hat das jemand schon mal versucht? Ich schreibe die Programme in Bascom falls jemand etwas in dieser Richtung gemacht hat. MfG Jens
Das ist eine schon länger bekannte Idee. Nennt sich Redundanz. Z.B. hat die NASA mehrere Rechner in den Raumfähren, die alle dieselben Eingangsdaten erhalten. Allerdings stellen sich dabei einige besondere Probleme. Zum einen würde man nicht nur zwei Rechner nehmen. Denn, wenn die Ergebnisse der beiden von einander abweichen, welches ist dann das richtige Ergebnis? Also nimmt man mindesten 3 (oder sogar 4) Rechner deren Ergebnisse man vergleicht und führt also eine Mehrheitsentscheidung herbei. Zum anderen wäre es zwar denkbar die Rechner selbst entscheiden zu lassen. Aber es muss eine Instanz vorhanden sein, welche die Ergebnisse des jeweils fehlerhaften Rechners unterdrückt. Falls das aber die Rechner sélbst machen und diese fehlerhaft arbeiten, so ist dies weniger zuverlässig als eine externe Entscheidung. Im Grunde ist das ja nur ein Vergleich, so das die Komplexität des Vergleichers im Grunde gering ist und die Fehlerwahrscheinlichkeite geringer als wenn die Rechner selbst den Vergleich anstellen. Weiter müsste man sich genau überlegen, ob man die Rechner alle am selben Takt hängen hat, dann würde der Ausfall des Taktes alle gleichzeitig betreffen; oder ob die Rechner jeweils einen eigenen Takt haben, dann werden diese nicht synchron laufen und der Vergleicher muss immer auf die Ergebnisse aller Rechner warten. Das kann unter Umständen, je nach Anwendung etwas komplexer werden.
@ Jens Goos (wacken2002) >kann ich zwei Atmegas mit jeweils dem gleichen Programm synchron laufen >lassen, Wirklich synchron wird schwierig, aber machbar. > das wenn einer der beiden ausfällt, der andere übernimmt? Sowas funktioniert anders. Die laufen zwar "synchron", tauschen gegenseitig Nachrichten aus, und wenn die irgendwann mal ausfallen oder nciht mehr stimmen, dann kann einer die "Oberhand" gewinnen. Ist aber nicht so einfach das Thema. >Bascom falls jemand etwas in dieser Richtung gemacht hat. Was solls denn werden? MFG Falk
Wenn ich zwei Prozessoren an den gleichen quarz hänge, müsste ich eigentlich beide synchron laufen lassen können oder? Das kann ich mal mit zwei alten Atmega 8 probieren. Es geht ja eigentlich nur darum, das sich beide Prozessoren gegenseitig überwachen ob einer abschmiert. Du hast recht mit dem "Nasa-Prinzip" ;-). Würde sagen das dies ein etwas größerer Aufwand ist.
@ Jens Goos (wacken2002) >Wenn ich zwei Prozessoren an den gleichen quarz hänge, müsste ich >eigentlich beide synchron laufen lassen können oder? Geht nicht so einfach, da die Resetdauer unterschiedlich lang ist. Ausserdem bringt es ncihts, wenn die im absoluten Gleichtakt arbeiten. Das Problem ist weit komplexer. >sich beide Prozessoren gegenseitig überwachen ob einer abschmiert. Du Das kann auch ein Watchdog. MFG Falk
Arbeite bei einem Flugzeugküchen-Hersteller und habe vor als Technikerarbeit eine Flugzeugküche über einen Touch-Screen zu steuern. Das Problem ist nur, wenn die Steuerung ausfällt wegen dem Prozessor, dass das Essen gefroren serviert wird ;-). Deshalb sollte die ganze Steuerung schon ein paar Sicherheiten liefern.
>Wenn ich zwei Prozessoren an den gleichen quarz hänge, müsste ich >eigentlich beide synchron laufen lassen können oder? Ja. >Es geht ja eigentlich nur darum, das sich beide Prozessoren gegenseitig überwachen ob einer abschmiert. OK. Das musst Du Dir nochmal genau überlegen und begrifflich etwas besser klären, denke ich. 1. Ausfallen Das hast Du in Deinem ersten Post so genannt. Da Du das inm Zsh. mit zwei Prozessoren beschrieben hast, bin ich von einem fehlerhaften arbeiten ausgegangen. D.h. sie arbeiten beide noch und liefern Ergebnisse. 2. Abschmieren/Ausfallen Das kann aber auch so verstanden werden, das ein Prozessor sein Programm nicht mehr in dem vorgesehenen Ablauf abarbeitet. Was man auch "in den Wald laufen", "in's Nirwana rennen" etc. nennt. Das wird meist durch nicht gesetzte Interrupt-Vektoren, fehlerhafte Sprungzielberechnung oder fehlerhafte Labels verursacht (mehr in ASM). Im zweiten Fall aber wird der Verwendung eines Prozessors mit Watchdog reichen. Was ist denn die Anwendung?
viel schlimmer als echte Hardwareausfälle (verdammt selten) des MC sind Softwarefehler. Und das führt dann das Prinzip mit 2 parallelen Prozessoren mit identischem Programm ins Nirwana, die machen dann nämlich exakt den selben Fehler. Das führt dann dazu, dass die Programme in sicherheitskritischen Anwendungen von verschiedenen Programmierern getrennt erstellt werden, mit verschiedenen Compilern (ja, auch dort können Fallen lauern), u.U. sogar in komplett verschiedenen Sprachen erstellt werden. Nach jeweils Teilprogrammschritten werden Ergebnisse ausgetauscht und verglichen, dann weiter geschaut. Kurz: vergiss deine Idee. Sauberes Design in Hard- und Software, dann klappt das auch mit einem :-)
Das wäre ja zu einfach ;-). Wenn muss es ja Boeing oder Airbus nachher freigeben wenn es denen gefällt. Es kommt auch auf deren Sicherheitsvorschriften an. Ein Sauberes Hardwaredesign versteht sich da von selbst.
Bei sicherheitskritischen Anwendungen werden nicht nur verschiedene Compiler verwendet. Meist sind auch unterschiedliche Prozessoren etc. am Werk. Machst du auch zwei Touchpanels ran, falls eines ausfällt? Bedenke: ein System ist immer so Zuverlässig wie sein unzuverlässigstes Teil. Man kann bereits sehr viel an Zuverlässigkeit gewinnen, wenn man die schwächsten Glieder verstärkt. Zum Beispiel durch Unterlast. Ich glaube nicht, dass die HW zuerst den Geist aufgiebt. Viel eher sind Softwarefehler zu erwarten... Ein Programmierer einer sicherheitskritischen Anwendung programmiert im Schnitt 1-2 Zeilen(!) pro Tag (dabei eingerechnet sind jedoch auch die Dokumentation/Spezifikaton)
Hmmm, meine Entwicklungen kommen zwar nicht in Flugzeuge, sondern nur in Bahnen, aber ich denke, Du machst Dir da zuviele Gedanken: Hier wie dort wird es verschiedene Sicherheitsanforderungen geben, je nachdem, wie wichtig eine Funktion für das Funktionieren des Fahr-/Flugzeuges ist. Und da dürfte eine Erwärmungseinrichtung in der Bordküche sicher nicht so furchtbar wichtig eingestuft sein. Ich meine auch, dass ein vernünftiges Design (Hard- und Software!) mit aktiviertem Watchdog ausreichen sollte.
@ Jens Goos (wacken2002) >Arbeite bei einem Flugzeugküchen-Hersteller und habe vor als >Technikerarbeit eine Flugzeugküche über einen Touch-Screen zu steuern. >Das Problem ist nur, wenn die Steuerung ausfällt wegen dem Prozessor, >dass das Essen gefroren serviert wird ;-). Deshalb sollte die ganze >Steuerung schon ein paar Sicherheiten liefern. Dir haben sie wohl ne Ecke zuviel Sicherheitsfanatismus eingetrichtert ;-) Bei der Flugzeugsteuerung, Navigation etc. OK, aber bei der Küche . . . Programiers solide, das reicht. MFG Falk P.S. Ja, als Lernprojekt kann man das auch mit Redundanz machen.
Hi Falk, nehm es mir nicht übel, aber weißt du was ein Ausfall der Küche kosten kann? Das sind Beträge die als Schadensersatz gefordert werden, die manche in zwei Jahren nicht verdienen. Eine 737 z.B. , die am Boden bleibt, weil die Gäste nicht versorgt werden können kostet 25000 bis ca. 35000 Dollar pro Tag. Was eine 747 bis 777 kostet willst du bestimmt nicht wissen. Den ganzen Spaß muss der Küchenhersteller tragen, bis wieder alles ok ist (Garantie bis zu 15 Jahre für die Küche). Da überlegt man sich doch was man dem Kunden anbietet. MfG Jens
@Falk: vergiss das mal ganz schnell. Ich hatte mal was auf dem Tisch, ein kleines, völlig unbedeutendes Teil eine Flugzeugs: Steuerung der Leselampen. Nach Lektüre der ersten Seiten der ca. 100 Seiten Lastenheft habe ich dankend abgelehnt..., der Preis passte ganz und gar nicht zu dem, was verlangt wurde. Einfach Lampe an oder aus, mit zentraler Steuerungsmöglichkeit. Klingt verdammt trivial :-)
Redundante Prozessoren für mehr Sicherheit? Da investiert man doch echt am falschen Ort! Die Prozessoren sind so ziemlich das letzte was ausfallen kann. Typischerweise hat man Probleme mit abstürzender Software, oder aber Probleme in Mechanik- oder Leistungsbauteilen. Denke also mal darüber nach, wo Probleme wahrscheinlich auftreten, und wie man sie beheben könnte.
@ Jens Goos (wacken2002) >nehm es mir nicht übel, aber weißt du was ein Ausfall der Küche kosten >kann? Das sind Beträge die als Schadensersatz gefordert werden, die >manche in zwei Jahren nicht verdienen. Kann schon sein, aber ob man das WIRKLICH mit Redundanz in den Griff bekommt, ist noch diskussionswürdig. Solides Design (tm) ist durch (fast) nichts zu ersetzten. Redundanz und Watchdogs sind "nur" Rettungsanker bzw. Feigenblätter zur VErdeckung von mangelhafter Entwicklung, von Ausnahmen mal abgesehen (Steuerung, Sicherheitszeugs etc.). > Eine 737 z.B. , die am Boden >bleibt, weil die Gäste nicht versorgt werden können kostet 25000 bis ca. >35000 Dollar pro Tag. Sollen die allen einen Snickers in die Hand drücken, " . . . wenns mal wieder länger dauert . . ." ;-) > Was eine 747 bis 777 kostet willst du bestimmt >nicht wissen. Muss ich die kaufen, wenn die Küche kalt bleibt? @ crazy horse (Gast) >Ich hatte mal was auf dem Tisch, ein kleines, völlig unbedeutendes Teil >eine Flugzeugs: Steuerung der Leselampen. >Nach Lektüre der ersten Seiten der ca. 100 Seiten Lastenheft habe ich >dankend abgelehnt..., der Preis passte ganz und gar nicht zu dem, was >verlangt wurde. Naja, kann ich mir schon irgendwie ausmalen. Pedanterie meets Hysterie meets amerikanische Produkthaftung meets amerikanische Rechtsabteilung. >Einfach Lampe an oder aus, mit zentraler Steuerungsmöglichkeit. Klingt >verdammt trivial :-) K.I.S.S. ist eines der besten Prinzipien der Welt. Und gilt bis auf wenige Ausnahmen fast überall. MFg Falk P.S. Anekdote. Ich hatte mal ein Vorstellungsgespräch, dort erzälte die Firma nicht ohne Stolz, dass sie die Heckklappensteuerung vom Phaeton entwickelt hat. Mit all den diversen Regelkreisproblemen, Schwingen etc. In dem Moment sagte mein simples Gemüt zu mir "Warum muss man Probleme mit High Tec lösen, die man ohne sie nie hätte? Ne simple Gasdruckfeder und Handbetätigung würden das billig und zuverlässig lösen. Zu einfach? Zu sehr Volkswagenniveau?". Wenn ich so sehe, was für tonnenweise Müll und Schnickschnack selbst in normalen Autos heute drinsteckt, wundern mich die Preise kein Bisschen mehr.
Wundert sich hier eigentlich keiner über das mit der Fluggesellschaft? Hier glaubt doch wohl keiner dass die einen beauftragen der von sowas absolut keine Ahnung hat, oder zumindest nicht viel. Jetzt nichts gegen den Threadersteller, ist aber so. Eher suchen die sich einen der mit sowas viel Erfahrung hat, besonders im Personenbeförderungsbereich.
Hi
>Ich schreibe die Programme in Bascom falls jemand etwas in dieser >Richtung
gemacht hat.
Ich lasse mich gern belehren, wenn ich falsch liege. Aber irgendwie habe
ich noch so eine Aussage im Kopf, das in USA noch nicht einmal C für
sicherheitsrelevante Aufgaben zugelassen ist. Dann dürfte BASCOM absolut
aussen vorliegen.
MfG Spess
Hast Recht. C geht nicht, weil über wildgewordene Pointer alles möglich ist.
> Hast Recht. C geht nicht, weil über wildgewordene Pointer alles möglich > ist. Achso?? Ist C da wirklich anfällig oder wird das nur unterstellt? KH
Ich denke nicht, daß C von sich aus Mist macht. Aber man kann eben mit C viel mehr Mist machen als z.B. mit ADA.
>Bei sicherheitskritischen Anwendungen werden nicht nur verschiedene >Compiler verwendet. Meist sind auch unterschiedliche Prozessoren >etc. am Werk. Immer unterschiedliche Architekturen, idealerweise unterschiedliche Programmiersprachen, unterschiedliche Programmierer, Denkweisen... >Ist C da wirklich anfällig oder wird das nur unterstellt? C ist nicht anfällig. Die schlampigen Programmierweisen sind es. Wenn du 2 Controller parallel laufen lässt (was sowieso nicht geht, denn schon ein einfacher Tastendruck wird von beiden nicht gleichzeitig erkannt ["gleichzeitig" gibt es gar nicht!!!]), woher willst du denn wissen, welcher spinnt? Dann muss also ein dritter her, quasi als Arbiter (Schiedsrichter). Nein, korrekterweise werden da Checkpoints im Programm eingebaut, an denen die beiden Controller miteinander ihre Erfahrungen austauschen. Und wenn die gleicher Meinung sind, gehts weiter. Und wenn nicht? Dann steht die Maschine, denn wenn 1 uC alleine die Sache schmeissen könnte, weshalb brauchst du einen zweiten? @ Jens Goos Glaub es mir: Du brauchst diese Redundanz nicht Und mit 1 Mikrocontroller eine ganze Küche ausfallen lassen? Da sind die Köche&Co viel zu erfinderisch. Bau lieber einen vernünftigen Notlauf ein.
Je nachdem wie weit man es treibt, kann so eine Küchensteuerung problematischer sein als die Steuerung der Querruder. Wenn die ausfallen, kann ein Pilot, der das ja trainiert hat, das Flugzeug immer noch sicher landen. Wenn aber aufgrund einer defekten Küchensteuerung ein Brand ausbricht ist das wesentlich kritischer. Und ich kann mir schon vorstellen, dass mit sowas unbedarfte Techniker beauftragt werden. Sowas kommt dabei raus, wenn ein Sub einen Sub einen Sub beauftragt. Gruss Axel
>defekten Küchensteuerung ein Brand ...
Sowas muss mit Hardware abgesichert sein, niemals mit Software.
Hallo, > Nein, korrekterweise werden da Checkpoints im Programm eingebaut, an > denen die beiden Controller miteinander ihre Erfahrungen austauschen. > Und wenn die gleicher Meinung sind, gehts weiter. > Und wenn nicht? Dann steht die Maschine, denn wenn 1 uC alleine die > Sache schmeissen könnte, weshalb brauchst du einen zweiten? in Sicherheitskritischen Steuerungen in Chemieanlagen werden darum ZWEI Paar Prozessoren eingesetzt. Wenn ein Paar sich über das Ergebnis uneinig ist, übernimmt das andere Paar. Gruß, Martin
> Sicherheitskritischen Steuerungen in Chemieanlagen... Da fallen mir schlimmere Fehlerauswirkungen ein, als nur ein knurrender Magen :-) > Wenn ein Paar sich über das Ergebnis > uneinig ist, übernimmt das andere Paar. Ein Unentschieden gibt es nur bei ungleicher Zahl von Teilnehmern. Ich würde salomonisch 3 Prozessoren verwenden. Wenn einer quertreibt, hängen die beiden Anderen ihn aus...
> Ein Unentschieden gibt es nur bei ungleicher Zahl von Teilnehmern. > Ich würde salomonisch 3 Prozessoren verwenden. > Wenn einer quertreibt, hängen die beiden Anderen ihn aus... Prinzipiell richtig, aber die Logik dieser "Fehler-Erkennung" ist wahrscheinlich bei 2x2 einfacher als bei 3x1.
1.Wie soll ich das mit unbedarfte Techniker verstehen? 2.Ich wollte nur wissen, ob es sinnvoll ist zwei Prozessoren parallel laufen zu lassen. Ich hatte es vermutet das es machbar ist und etwas übertrieben ist. Also werde ich nur einen Prozessor nehmen. 3.Alle Materialien, die im Flieger verbaut werden, dürfen generell nicht brennen. Das wird vom Maschienenhersteller kontrolliert. 4.Ich arbeite schon seit 7 Jahren im Flugzeugbereich und das soll nur mal eine Demo-Küche werden, die man mal auf Messen austellen kann. Es kann ja sein jemand hat bedarf nach sowas. Und der Gast, der meint das ich fast keine Ahnung von Bauvorschriften im Flugzeugbereich habe sollte mal lieber die Bälle flach halten. Hast du Ahnung was es für Verlegevorschriften für Kabel bei Boeing oder Airbus gibt(Spannung, Signalleitung etc.)? Beide Vorschriften sind unterschiedlich und bei Airbus um einiges komplizierter. Das ist noch das einfachste was es an Vorschriften gibt. Es gibt halt manchmal für einen gewissen Bereich nicht so viele Vorschriften. Ob ich den ganzen Scheiß später für meine Technikerarbeit genehmigt bekomme ist was anderes. Es ist nur eine Idee von mir und noch von keinem genehmigt.
Kenne mich mit Flugzeugtechnik nicht so aus, aber ich würde es folgendermassen machen: Für blockierende Fehler in der Software/Firmware würde ich einen Resettaster in der Hardware vorsehen, damit die Küche neu gestartet werden kann. Für den Fall, dass der komplette Rechner infolge eines Defekts ausfällt würde ich eine manuelle Steuerung der Apparate vorsehen, dann kann das Personal im Flugzeug noch improvisieren.
>Für blockierende Fehler in der Software/Firmware würde ich einen >Resettaster in der Hardware vorsehen, damit die Küche neu gestartet >werden kann. Zum Beispiel durch gleichzeitiges Drücken von drei Tasten Und automatische Firmwareupdates müsste es ja auch geben ;-)
an so etwas habe ich auch schon gedacht. Aber es Steckt ja noch in den kinderschuhen. (Mist Maschine mit "ie" geschrieben...peinlich)
Wenns schon sowas schickes aber anfälliges wie ein Touchscreen sein soll, dann folgender Vorschlag: Die wesentlichen Teile Steuerung in ein von Otto-Normal-Menschen tauschbares Modul packen und zwei davon mitliefern. Alles andere führt zu weit oder verfehlt das Ziel.
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.