Ich habe ein System bestehend aus 4 ATmega2560 Microcontrollern (leider kein FMEDA report oder ähnliches erhältlich) die über UART miteinander kommunizieren und mit eine paar Spannungsteilern Spannungen messen. Sie sind im Dauerbetrieb und die Umgebungsbedingungen sind recht moderat und konstant (Innenraum, aber in einem Schaltschrank wo es etwas wärmer werden kann) Nun würde mich interessieren, wie lange man bei so einem system rechnen könnte dass es mit einer gewissen Wahrscheinlichkeit nicht ausfällt. Gibt es da "Worst Case" Abschätzungen wenn keine besseren Daten bekannt sind? Wie berücksichtigt man z.B. Widerstände und Kondensatoren in Spannungsteilern und Filtern?
Luky S. schrieb: > Wie berücksichtigt man z.B. Widerstände und Kondensatoren in > Spannungsteilern und Filtern? Siemens SN29500 zum Beispiel - hat die grundlegenden Bauteile mit entsprechenden FIT-Werten und Formeln für thermische und elektrische Einflussgrößen parat. ICs kann man mit entsprechender Komplexität abschätzen, wenn es keine Herstellerangaben gibt.
Luky S. schrieb: > recht moderat und konstant dann halten die auch ziemlich lange Luky S. schrieb: > "Worst Case" Abschätzungen Das ist, wenn sie gleich nach Inbetriebnahme kaputt gehen Luky S. schrieb: > gewissen Wahrscheinlichkeit Es ist absolut sicher, dass da wahrscheinlich kaum was passiert SCNR... 😉
Gunnar F. schrieb: > SCNR... Genau das ist dein Problem, an dem du arbeiten solltest. si tacuisses, philosophus mansisses
Wolfgang R. schrieb: > Genau das ist dein Problem, an dem du arbeiten solltest. ...mach ich, danke für die Belehrung! Aber es war zu verlockend!
Luky S. schrieb: > Wie berücksichtigt man z.B. Widerstände und Kondensatoren in > Spannungsteilern und Filtern? In der erwähnten Siemensnorm gibt es für die verschiedenen Bauteiltypen wie Metallwiderstände, Kohleschichtwiderstände, ... ermittelte Werte, die man mit der BOM zu einer MTBF des Systems zusammenrechnen kann. Üblicherweise verwendet man dazu ein Excel-sheet. > Nun würde mich interessieren, wie lange man bei so einem system rechnen > könnte dass es mit einer gewissen Wahrscheinlichkeit nicht ausfällt. Erfährungsgemäß kommen bei der Siemens-MTBF-Berechnung für einen Praktiker unbrauchbare Zahlen raus, so MTBF ist 314159 Stunden.... Realistische Werte erhält man nach künstlicher Alterung und unter "enviromental Stress screening". Rechnen wird der Depp viel, wenn sein Tag lang ist. Wenn Du dein Multicontrollersystem ausfallsicher machen willst, dann bau Redundanzen ein und vermeide gemeinsam genutzte Ressourcen. Das wurde hier schon x-Mal durchgekaut, da muss man nur nachlesen und verstehen: * Beitrag "Ausfallsicherheit von Bauteilen" * Beitrag "Ausfallsicherheit/Redundanz von Mikrocontrollern in der Luft- und Raumfahrt." * Beitrag "wie Ausfallsicher sind AVRs?" * Beitrag "Redundante Stromversorgung mit 2xLM2576?" https://www.pulspower.com/fileadmin/global/common/Print/White_papers/AN56_Zuverl%C3%A4ssigkeit_DE_online.pdf https://www.relnetyx.com/wp-content/uploads/2016/02/2012-MTBF-MTTF-RELNETyX-AG.pdf https://de.wikipedia.org/wiki/Failure_In_Time
DSGV-Violator schrieb: > ... > Erfährungsgemäß kommen bei der Siemens-MTBF-Berechnung für einen > Praktiker unbrauchbare Zahlen raus, so MTBF ist 314159 Stunden.... > Die Siemensnorm enthält Erfahrungswerte. Die Ergebnisse können für übliche Geräte so genommen werden. > Realistische Werte erhält man nach künstlicher Alterung und unter > "enviromental Stress screening". > Jein. Die Siemensnorm sowie die FIT-Werte der Hersteller berücksichtigt schon einen angemessenen 'Grundstress'. Für den OP wohl völlig ausreichend. Lediglich für Bauteile die härter beansprucht werden muss man eine Korrektur einplanen. Auch dafür hält die Norm praxisgerechte Werte vor.
Bei Projekten mit MCs kann man eigentlich die puren Ausfallraten der Bauteile vollkommen vergessen. Fehler in der Software, in der Schutzbeschaltung und im Layout bewirken eine erheblich höhere Ausfallrate. Erstmal muß man alle IO-Pins vor zu hohen Spannungen schützen, insbesondere wenn noch keine VCC anliegt oder VCC schon abgefallen ist. Fremdspannungen können verhindern, daß der MC überhaupt einen sauberen Power-On Reset macht, z.B. über die UART-Pins. Dann muß die Software alle Werte von außen (Inputs, ADCs) auf Plausibilität prüfen. Dann müssen die Kommunikationsprotokolle fehlertolerant sein, d.h. sie müssen alle Fehler erkennen können und sich nach Fehlerzuständen wieder synchronisieren. Ein Protokoll darf niemals hängen bleiben. Natürlich muß auch alles gründlich getestet sein. In Busse kann man z.B. fehlerhafte Daten einspeisen oder willkürlich mit Tastspitzen mal GND oder VCC anlegen. Dann gibt es Bauteile, die intern abstürzen können. Ich hatte da z.B. mal mit einem PHY Probleme. Dann muß die CPU diesen IC resetten können oder notfalls dessen VCC kurz abschalten.
Lediglich als schnelle Abschätzung: Wie lange kann man davon ausgehen, das ein AVR Microcontroller im Dauerbetrieb bei Raumtemperatur funktionieren wird?
Roland E. schrieb: > Jein. Die Siemensnorm sowie die FIT-Werte der Hersteller berücksichtigt > schon einen angemessenen 'Grundstress'. Für den OP wohl völlig > ausreichend. Ein Problem der Siemensnorm ist, das sie weder "Montage" noch generelle Fertigungs-probleme (bspw. Lötungen, bspw thombstone) berücksichtigt. https://de.wikipedia.org/wiki/Montagsst%C3%BCck Funktionalle Betrachtungen kömmen auch nicht vor. So erhöht sich die MTBF rechnerisch wenn man die 100 nF Stützkondensatoren zw. Vcc und Gnd weglässt. :-O ESD und Einstrahlung sollte der TO bei seinem Szenario " ... Schaltschrank ..." auch beachten, solange er jemanden versichern will, das sein Apparillo nicht beim kleinsten "Gewitter" ausfällt. Ohne praktische Überprüfung der Sörfestigkeit lässt sich da keine belastbare Zahl ermitteln, egal auf wieviel Nachkommastellen die MTBF berechnet ist.
Luky S. schrieb: > Wie lange kann man davon ausgehen, > das ein AVR Microcontroller im Dauerbetrieb bei Raumtemperatur > funktionieren wird? Data retention: 20 years at 85°C/ 100 years at 25°C
Luky S. schrieb: > Lediglich als schnelle Abschätzung: Wie lange kann man davon ausgehen, > das ein AVR Microcontroller im Dauerbetrieb bei Raumtemperatur > funktionieren wird? Irgendwas zwischen 0 sekunden und 10E+5 h ... Herrgott Sakra, was nicht getestet ist, funktioniert nicht! Also macht wenigstens einen 24h Dauerlauf unter Last mit aktivierten Selbsttest in der Zielumgebung! Wenn innerhalb dieser Spanne keine Aussetzer auftreten, kann man mit einiger Sicherheit davon ausgehen, das die Gerätschaft einige Monate durchhält. In der Luftfahrt geht man für die typische inherente Ausfallwahrscheinlichkeit für Halbleiter von nicht besser als 10^-5 ... 10^-6 pro Stunde aus. Das ist für sicherheitskritische Systeme ziemlich mies.
DSGV-Violator schrieb: > Erfährungsgemäß kommen bei der Siemens-MTBF-Berechnung für einen > Praktiker unbrauchbare Zahlen raus, so MTBF ist 314159 Stunden.... Das wundert Praktiker, die den Begriff MTBF einfach nicht verstanden haben. Sie hat nichts mit der "Betriebsdauer" oder "Lebenserwartung" zu tun! Nichts! Sie wird nach Definition im Bereich konstanter Ausfallrate gemessen, und das ist nach dem Ende der Frühausfälle und vor Eintritt der Spätausfälle. Theoretiker nennen das auch Badewannenkurve. Das heißt, ich kann aus der MTBF einfach keinen Rückschluß auf die Lebensdauer ziehen, sie haben nichts miteinander zu tun. Luky S. schrieb: > Wie lange kann man davon ausgehen, > das ein AVR Microcontroller im Dauerbetrieb bei Raumtemperatur > funktionieren wird? Diese Art der Fragestellung hat mich vorhin zum Frotzeln verleitet: Die Frage hat keinen Sinn. Das falsche Wort ist "ein". Unter tausenden kannst du Wahrscheinlichkeiten angeben. Entsprechende Feldtests oder Berechnungen vorausgesetzt. Wie lange der eine Controller hält: Kismet!
Ok, habe ich falsch verstanden... Also angenommen ich hätte 100 Systeme mit je 4 AVRs im Einsatz, wie lange würde es dauern, bis ich den ersten Ausfall erwarten kann? Oder wie groß wäre die Wahrscheinlichkeit, das eines der 100 Systemen innerhalb von 10 Jahren ausfällt?
DSGV-Violator schrieb: > ... > > Ein Problem der Siemensnorm ist, das sie weder "Montage" noch generelle > Fertigungs-probleme (bspw. Lötungen, bspw thombstone) berücksichtigt. > Muss sie auch nicht. Tombstones sind keine Ausfälle im Betrieb. Die werden üblicherweise noch in der Fertigung aussortiert. Und für die Montage/Lötstellen an sich sieht die Norm einen FIT-Eintrag vor. Unterschieden nach Hand- oder Maschinenlötung. > https://de.wikipedia.org/wiki/Montagsst%C3%BCck > > Funktionalle Betrachtungen kömmen auch nicht vor. So erhöht sich die > MTBF rechnerisch wenn man die 100 nF Stützkondensatoren zw. Vcc und Gnd > weglässt. :-O > Ist auch nicht die Aufgabe der Norm, weil kein Bauteilausfall. Wie so oft: Werkzeuge richtig benutzen.
Luky S. schrieb: > wie groß wäre die Wahrscheinlichkeit, das eines der 100 Systemen > innerhalb von 10 Jahren ausfällt? 100% das mindestens eins ausfällt, die Wahrscheinlichkeit das genau eins ausfällt ist geringer. Hier macht die Frage, "Wieviel Systeme werden wahrscheinlich in den 10 Jahren ausfallen" mehr Sinn. > Wie berücksichtigt man z.B. Widerstände und Kondensatoren in Spannungsteilern und Filtern? Bei Filtern, also analoge Baugruppen berechnet man neben Ausfall eine Altersbedingte Parameterdrift (bspw. Zeitkonstante). Für Kondensatoren gibt es Typartbedingte Werte: https://de.wikipedia.org/wiki/Datei:Delta-Cap-versus-Zeit.svg
Ich habe dann also beispielhaft: 4x Mikrocontroller mit je 30 FIT = 120 4x RS232 Treiber: Je 15FIT = 60 4x je 4 X7R Kondensatoren mit je 2 FIT = 32 4x je 8 Widerstände mit je 0,2 FIT = 6,4 Annahme: der Ausfall eines dieser Komponenten führt zu einem Gesamtversagen des Systems. Macht also zusammngezählt 218FIT, also einen Ausfall alle 10^9h / 218 = 4580000h = alle 522 Jahre. Wenn 100 Systeme im Einsatz sind, kann ich mit 10Jahre / 522Jahre * 100 Systeme = 1,9 Ausfällen in dieser Zeit rechnen. Stimmt das so vom Prnzip her?
Die Software hat auf die Ausfallrate sicher einen größeren Einfluss, als die Hardware - wenn sie denn korrekt aufgebaut ist. Denn kein Programm ist fehlerfrei und Fehlertoleranz ist für viele Programmierer ein Fremdwort.
"Innerhalb des deutschsprachigen Raumes, mit Ausnahme von militärischen und Luftfahrtbereichen, ist der Siemens SN 29500 fast immer eine gute Wahl. Auch global gesehen ist der Siemens SN 29500 noch einigermassen geläufig." aus : http://www.angewandte-statistik.com/Siemens_SN_29500.html Die Bedeutung der Siemensnorm zur MTBF-Bestimmung ergibt sich wohl daraus, das der TÜV diesen als heiligen Gral ansieht. Die Formulierung "Einigermaßen geläufig" ist für international ausgerichtetet Firmen eher ein Grund, sich nach einer im Zielmarkt verbreitetetn Norm zu richten. Ach ja, nach anderen Standards kommen andere Zahlen raus, aber werden immer noch MTBF genannt. Dann mal fröhliches Zahlen raten.
Software sollte nicht so sehr das Problem sein, ist erstens sehr simpel (ADC einlesen und weiterschicken) und 2. gibts den Watchdog auch noch. Aber wäre meine Rechnung im Prinzip richtig?
Luky S. schrieb: > Software sollte nicht so sehr das Problem sein, ist erstens sehr simpel > (ADC einlesen und weiterschicken) und 2. gibts den Watchdog auch noch Trotzdem ist die Gefahr weitaus höher bei mehr als 10 Zeilen Code. Und ein watchdog, der Quarz, die Reset-Schaltung (power-on, Brown out) werden oft nur überschlagig berücksichtigt, was Temperaturschwankungen, Feuchtigkeit, Toleranzen, Störungen etc angeht Fertigst Du die Schaltung gar selbst oder in Kleinserie (weniger als 100), dann brauchst Du Dir keine Gedanken um die Zuverlässigkeit von Standard-uC oder gar Rs zu machen (solange nur halb belastet). Bei Cs oder LCDs vielleicht, Relais, Taster, Steckverbinder in jedem Fall. Also, ja, wenn Du die um Größenordnungen einflussreicheren Fehler weglässt, ist Deine Rechnung richtig
:
Bearbeitet durch User
Ich habe zwei ATTiny irgendwas (glaube ATTiny45) in ziemlich rauen Umgebungen eingesetzt. Einer steuerte über viele Jahre das Coming-Home-Licht, was ich für meinen VW T3 gebaut habe, der zweite verrichtet seit etwa 10 Jahren seinen Dienst im Außenbereich in einer Blitzlampe, die ein Kumpel als Signalleuchte für einen eingeschalteten Elektrozaun verwendet. Blitzlampe raus, LED-Bandwickel rein, ATTiny der das Ding alle etwa 1,5 Sekunden kurz zweimal aufblitzen lässt. Tag und Nacht, Sommer und Winter, Sonne und Regen. Also die Dinger sind ziemlich hart im Nehmen und scheinen sehr zuverlässig zu sein.
Luky S. schrieb: > = 1,9 Ausfällen in dieser Zeit rechnen. Eventuell:-) Aber nur im statistischen Mittel über unendlich viele Exemplare. Das ganze sagt dir nichts darüber aus ob der Ausfall in der ersten Stunde passiert oder eine Stunde vor Ende der Betrachtungszeit. Die ganze Rechnerei ist nur interessant, wenn du riesige Stückzahlen hast. Dann kannst du damit näherungsweise voraussagen welche Summen du z.B. für Garantierückstellungen vorsehen musst, weil mit x,x% Ausfällen pro Jahr gerechnet werden muss. Mit Beachtung der "Badewanne" kann man dann auch abschätzen wie lange man Garantie geben darf ohne dass die Kosten dafür zu hoch werden (gibt dann die üblichen Schlägereien zwischen Rechenschiebern und den Marketing Fuzzies). Für Einzelstücke (oder niedrige Stückzahlen) kannst du auf dem Weg überhaupt nichts vorhersagen. Nicht umsonst werden Systeme bei denen Ausfälle kritisch sind entsprechend redundant ausgelegt. Und selbst da ergibt die Praxis das immer mal was schiefgehen kann, nur halt nicht mehr so oft. Die Frühausfälle am Anfang der "Badewanne" kann man teilweise mit entsprechend langen "burn in tests" entschärfen. Da geht es dann aber ganz schnell richtig ins Geld...
Luky S. schrieb: > Software sollte nicht so sehr das Problem sein, ist erstens sehr simpel > (ADC einlesen und weiterschicken) und 2. gibts den Watchdog auch noch. > Aber wäre meine Rechnung im Prinzip richtig? Du meinst mit Rechnung :
1 | FIT ... Failure in Time |
2 | |
3 | 4x Mikrocontroller mit je 30 FIT = 120 FIT |
4 | 4x RS232 Treiber: Je 15 FIT = 60 FIT |
5 | |
6 | Annahme: der Ausfall eines dieser Komponenten führt zu einem |
7 | Gesamtversagen des Systems. |
... Da muss man mal länger drüber schauen, mein Bauchgefühl sagt, das eine solche Rechnung nicht der Realität antspricht. Geht man von eine Gaußverteilung aus, dürfte sich bei 4 controllern Die Systemausfallwahrscheinlichkeit nur gering vergrößern. Es könnte auch eine Binomialverteilung sein, und dann geistert mir irgendwie Weibull im Kopf herum: https://de.wikipedia.org/wiki/Weibull-Verteilung
Ben B. schrieb: > Ich habe zwei ATTiny irgendwas (glaube ATTiny45) > Einer steuerte über viele Jahre das > Coming-Home-Licht, was ich für meinen VW T3 gebaut habe, der zweite > verrichtet seit etwa 10 Jahren seinen Dienst im Außenbereich in einer > Blitzlampe, die ein Kumpel als Signalleuchte für einen eingeschalteten > Elektrozaun verwendet. > Also die Dinger sind ziemlich hart im Nehmen und scheinen sehr > zuverlässig zu sein. die Zuverlässigkeit von consumer-Halbleiter wird mit "nicht besser als 10E-5 bis 10E-6 /h" angegeben. Stunden sind dabei auf Gesamtbetriebsstunden/Dauerbetrieb bezogen. Da die elektrik eines Autos i.d. Regel nur eine Stunde am Tag eingeschaltet ist, erscheint die Zuverlässigkeit unheimlich hoch, entspricht aber nur dem üblichen "ein bis wenige Jahre". Der TO fragt nach eine Abschätzung für Zehn Jahre Dauerbetrieb 24/7, das ist schon eine immens hohe Zuverlässigkeit. Bei Gerätschaften, wo es auf Zuverlässugkeit ankommt wie Medizintechnik, Flugzeug oder kritische Infrastruktur setzt man Wartungsintervalle um die Komponenten zu prüfen und vor Defekt zu ersetzen. Mein Bauchgefühl sagt mir, das Wartungsintervalle nicht länger als ein Jahr sein sollten. Außer bei Consumerscheiss, wo die Folgen eines unerwarteten Ausfalls mit einer kurzen Fluchtriade ("Consumerscheiß, wieder mal!") abgetan sind.
Luky S. schrieb: > und 2. gibts den Watchdog auch noch. Lach. Vergiß den Watchdog, der hat noch nie eine fehlerhafte Software gerettet. Einfach ein wdt_reset(); irgendwo in die Mainloop zu klatschen, bringt überhaupt nichts. Ehe man viel Zeit darin versenkt, den Watchdog alle Fehlerquellen überwachen zu lassen, sollte man die Zeit besser für vollständige Unit-Tests verwenden. Du willst ja die UART verwenden. Was da manchmal an Protokollen fabriziert wird, da kräuseln sich die Nackenhaare. Selbst kommerzielle Geräte stürzen da gerne mal ab und dann hilft nur der Hauptschalter. Eine absolut minimale Sicherheitsmaßnahme ist, zyklisch Alive-Pakete zu übertragen und bei Ausfall den Bus neu aufzusetzen.
Ein schönes Beispiel für hohe Ausfallrate ist der Senseo-Kondensator. Da wird der billigste Scheiß verwendet und fällt schnell aus. Bei Entstörkondensdatoren fällt nicht auf, wenn die schleichend Kapazität verlieren. Die müssen ja nur den EMV-Test überstehen. Setzt man sie aber zweckentfremdet als Kondensatornetzteil ein, gehts schief. Enstörkondensatoren sind nicht als Kondensatornetzteil geeignet. Ich hab zu DDR-Zeiten normale 630V Styroflexkondensatoren verwendet, die funktionieren alle heute noch.
Bevor man sich zu stark in den Zahlen verheddert, sollte man die Fehlerfaelle betrachten und verstehen. Dann werden die Zahlen kleiner - EMV - Temperatur - Feuchte Scheint alles trivial, bis das Geraet das Labor verlaesst. - Haeufig wird ein Geraet etwas anders eingesetzt wie geplant, dies weil es funktioniert, sich die Anwendung gewandelt hat, das Geraet im Gestell steht, die Leute den urspruenglichen Zweck vergessen haben - die Umgebung etwas anders ist wie vom Spezifikationsteam ausgehandelt, resp akzeptiert. Der Kaeufer drueckt auf den Preis, der Lieferant verschiebt Richtung Laborbedingungen, 20 Grad & nicht kondensierend - Die verschiedenen O-Ringe im allseits dichten Gehaeuse sind doch nicht so dicht Soll man nun den schlimmsten Fall spezifizieren ? Natuerlich nicht. Ich hab's auch nicht geglaubt bis ich's sah. Leiterplatten nach wenigen Monaten gruen und blau korrodiert. Eingebaut in ein Kunststoff Schrankgehaeuse, mit O-Ringen ueberall. Es dauerte bis wir's rausfanden.. Der Touch Screen hinter der Folie war zusammen mit der Software zuwenig praktisch zu bedienen. Der Benutzer hatte jeweils eine Maus eingesteckt. Es gab natuerlich keine Durchfuehrung fuer eine Maus, es war gar keine Maus vorgesehen... Dann gibt's noch den Fall, dass alles super ist, getestet, zertifiziert, und der Einkaeufer bei der naechten Fabrikation eine Sparmoeglichkeit sieht..
:
Bearbeitet durch User
Die Frage nach MTBF / MTTF-Werten für Einzelkomponenten ist meist trivialer, als gedacht. Nach Maschinenrichtlinie muss die Zuverlässigkeit der Anlage statistisch gesehen belegt werden, dazu benötigt man die MTBF oder FIT-Werte der Einzelkomponenten. Diese kann man entweder durch Stichprobenprüfungen ermitteln (aufwändig aber dafür mit optimalen Ergebnissen) oder per component count mathematisch berechnen (z.B. nach SN29500 - simpel, stumpf aber dafür sehr konservativ und ungünstig). Windchill Quality Solutions bietet dafür ein gutes und teures Tool, alternativ eine Excel-Tabelle und die SN29500 an der Seite sind hier das Mittel der Wahl. Hier stellt sich übrigens nicht die Frage, ob der Ausfall eines Bauelements die Funktion beeinträchtigt - und in welcher Weise, sondern man geht davon aus, dass alle Bauelemente eine Daseinsberechtigung haben, sonst wären sie ja nicht drin. Bei einer FMEDA hingegen, die für Functional Safety notwendig wird, unterscheidet man genau zwischen gefährlichem und ungefährlichem Ausfall - Da gibt es sogar Tabellen, zu welchem Prozentsatz bestimmte Bauteile zu Kurzschluss, hochohmigem Ausfall oder einfacher Werteveränderung neigen.
Mir geht es ja erstmal um ein grundlegendes Verständnis. Dass sich die Software aufhängen kann/wird, ist erstmal völlig irrelevant. Ein Fehler, den man durch einen Neustart beheben kann, ist keiner ;-). Nein, im Ernst: es geht darum, mit wie vielen kaputten Systemen im Feld ich rechnen muss, also wie viele Ersatzteile bereitgehalten werden sollen oder vielleicht das Design doch noch mal überdenken, wenn die Fehlerwahrscheinlichkeit zu hoch wird. Konservativ und anerkannt passt dafür schon, also scheint die SN29500 das Mittel der Wahl zu sein. Fehlbedienungen etc. lassen wir mal außen vor, das muss natürlich extra behandelt werden und kann auch gegenüber einem ev. Kunden so argumentiert werden. Die grundsätzliche Frage stellt sich mir aber immer noch, ob meine einfache Rechnung mit der SN29500 so zulässig ist: - 4x Mikrocontroller mit je 30 FIT = 120 - 4x RS232 Treiber: Je 15FIT = 60 - 4x je 4 X7R Kondensatoren mit je 2 FIT = 32 - 4x je 8 Widerstände mit je 0,2 FIT = 6,4 Annahme: der Ausfall eines dieser Komponenten führt zu einem Gesamtversagen des Systems. Macht also zusammngezählt 218FIT, also einen Ausfall alle 10^9h / 218 = 4580000h = alle 522 Jahre. Wenn 100 Systeme im Einsatz sind, kann ich mit 10Jahre / 522Jahre * 100 Systeme = 1,9 Ausfällen in dieser Zeit rechnen. [Mod: Formatierung geändert, ein paar Leerzeilen eingefügt]
:
Bearbeitet durch Moderator
Ich hab's jetzt nicht nachgerechnet, aber die Annahme ist grundsätzlich korrekt, aber eben nur statistisch. Im schlimmsten, wenn auch sehr unwahrscheinlichen Fall kann dir das erste Gerät direkt beim Einschalten kaputt gehen. Interessanter Aspekt: Frühausfälle durch Fertigungsmängel - die filtert man gerne dadurch raus, dass man die komplette Charge für 24h im Klimaschrank schwitzen lässt...
:
Bearbeitet durch User
Peter D. schrieb: > Ein schönes Beispiel für hohe Ausfallrate ist der Senseo-Kondensator. Da > wird der billigste Scheiß verwendet und fällt schnell aus. Bei > Entstörkondensdatoren fällt nicht auf, wenn die schleichend Kapazität > verlieren. Die müssen ja nur den EMV-Test überstehen. Setzt man sie aber > zweckentfremdet als Kondensatornetzteil ein, gehts schief. > Enstörkondensatoren sind nicht als Kondensatornetzteil geeignet. So lange derjenige die Daten des Kondensators richtig verwendet, würde der auch in der MTBF auffallen, bzw tut er das wohl sogar. Aber der BWLer hat wohl nachgerechnet, dass die Ausfälle erst nach mehr als zwei Jahren auftreten. Bei Kondensatoren gibt es eine Matrix, die den FIT-Wert bei Betrieb zB über 50% Nennspannung erhöht. Dito für Strombelastung und Temperatur. Wenn man den konkreten Folienkondesator mit einem geeigneten Spannungswert austauscht, hält auch die Senseo ewig. Würde mich nicht wundern, wenn auf der Platine Platz und Footprint für die nächstgrößere Bauform ist. Wäre nicht der erste Fall...
Roland E. schrieb: > Peter D. schrieb: >> Ein schönes Beispiel für hohe Ausfallrate ist der Senseo-Kondensator. Da >> Enstörkondensatoren sind nicht als Kondensatornetzteil geeignet. > So lange derjenige die Daten des Kondensators richtig verwendet, würde > der auch in der MTBF auffallen, bzw tut er das wohl sogar. Meines Wissens unterscheidet die MTBF-Rechnung nach Siemens nicht, ob der C im Entstörfilter oder Kondensatornetzteil steckt. Die FIT für Kondensatoren sind auch nur sehr grob klassifiziert. > Bei Kondensatoren gibt es eine Matrix, die den FIT-Wert bei Betrieb zB > über 50% Nennspannung erhöht. Dito für Strombelastung und Temperatur. Das Problem bei C im Netzteil ist aber nicht die Strombelastung oder Temperatur sondern die (geringe) Impulsfestigkeit. Deshalb sehen viele Elektronik-Entwickler die MTBF-Rechnung nur als bürokratisch notwendigen Papiertiger.
Mag sein dass MTBF Einschränkungen hat, aber gibt es ernsthafte Alternativen außer zu hoffen, dass es ewig halten wird?
Luky S. schrieb: > Mag sein dass MTBF Einschränkungen hat, aber gibt es ernsthafte > Alternativen außer zu hoffen, dass es ewig halten wird? Klar: -Wartungszyklen, Maintenance -Redundanzen -BurnIn zwischen Fertigung und Auslieferung -Derating -robuster Aufbau -physische Kapselung/Schirmung ... Oder anders gesatg, das Hardware Entwickeln einem erfahrenen Hardwareentwickler überlassen und nicht einem Neumalklugen Informatikerheini, der ausser "Bits schubsen" nichts von der wirklichen Welt kennt. -- Hier könnte der TO bspw. mal drüber gehen wie man die MTBF-Rechnung verbessern könnte, wenn man beispielsweise einen Controller mit 4facher IO-Antahl statt 4 controller type tiny ('winzig') einsetzt und statt 4 Uarts einen mit vierfacher Baudrate einsetzt. Und dann sollte man mal überlegen, ob man nicht an dieser Stelle von der MTBF-Berechnung verarscht wird.
DSGV-Violator schrieb: > .. > > Hier könnte der TO bspw. mal drüber gehen wie man die MTBF-Rechnung > verbessern könnte, wenn man beispielsweise einen Controller mit 4facher > IO-Antahl statt 4 controller type tiny ('winzig') einsetzt und statt 4 > Uarts einen mit vierfacher Baudrate einsetzt. > > Und dann sollte man mal überlegen, ob man nicht an dieser Stelle von der > MTBF-Berechnung verarscht wird. Vor allem muss der OP verstehen, dass es einen Unterschied zwischen MTBF bestimmtem Ausfall und Verfügbarkeit gibt. Sein beschriebenes Multiprozesdorsystem wird erst einmal eine niedrigere MTBF haben, als ein Einzelprozessorsystem. Aber jenachdem wie er es anstellt, kann die Verfügbarkeit des Systems höher werden als das Singlesystem.
> Da die elektrik eines Autos i.d. Regel nur > eine Stunde am Tag eingeschaltet ist Das trifft nicht auf eine Coming-Home-Schaltung zu, diese muss ohne eingeschaltete Zündung funktionieren und hing daher etliche Jahren 24/7/365 am Dauerplus.
> Du willst ja die UART verwenden. Da kommt mir gerade im Zusammenhang mit AVR in den Sinn, das dort bei höheren Baudrate abgeraten wurde, den internen RC-Osczillator zu verwenden und statt dessen dem Chip einen Quarz-Oszillator zu spendieren, weil sonst der korrekte Abtastzeitpunkt nicht über den gesamten Lebenszyklus garantierbar ist. https://www.avrfreaks.net/s/topic/a5C3l000000UBdcEAG/t058534 Klar kann man versuchen mit Protokollgehampel auf höheren Softwareschichten diesen Hardwarefehler (weil an der falschen Stelle gespart) zu kompensieren. Aber die Lösung ist auch hier mehr (und die richtigen an der richtigen Stelle) Bauteile und nicht weniger wie die MTBF-Rechnung nach Siemens suggeriert: http://www.angewandte-statistik.com/mtbf.html
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.