Nehmen wir mal an wie haben so etwas einfaches wie eine Waschmachine. Diese speichert einen Teil ihrer Sensorauswertung in einem Statuswort. 0. Bit = Ventil für Wassereinlauf 0 = geschlossen, 1 = offen 1. Bit = Türe, 0 = geschlossen, 1 = offen usw. Programm könnte jetzt lauten (Pseudocode) Prüfe ob 1. Bit auf 0, dann öffne Ventil für Wassereinlauf. Der Zustand der Sensoren wird zwar normalerweise immer dann abgefragt, wenn man den Zustand wissen will. Aber nehmen wir mal an, die Konstellation wäre hier etwas anders. Z.B. dass der Zustand nur einmal, z.b. beim Start abgefragt wird und dann die Zustände in einem Statuswort gespeichert werden, wo sie dann später von den Algorithmen wieder abgefragt werden. Dann wäre das recht ungünstig, wenn sich der Code auf das Statuswort verlässt und in der Zwischenzeit ein Bitflip stattfindet. Es könnte dann bedeuten: Sensor hat zwar gemeldet, dass Türe offen, 1. Bit im Statuswort wird somit auf 1 gesetzt, aber durch ein Bitflip steht im Statuswort jetzt eine gesetzte 0. Obiger Pseudocode prüft also nur das Statuswort und sagt, prima, Türe geschlossen, setze Ventil für den Wassereinlauf auf offen (1). Und schon läuft die Bude voll. Eine Rettung die so etwas verhindern könnte, wäre somit entweder eine erneute Abfrage der Sensoren (will man in dem Fall vielleicht aber nicht machen, ist jetzt nur eine Annahme für unser Beispiel) oder eine Fehlerkorrektur für das Statuswort, womit für einen Zustand mehr als 1 Bit belegt werden und dies entsprechend programmiert werden müsste, wenn das die Software erledigen soll. Die Frage ist nun, wir das bei Consumergeräten so gemacht? Im Luftfahrtbereich und im Auto wird man wohl defensiven Code schreiben, aber im Consumerbereich? Ich frage auch deswegen, weil ich neulich bei jemandem bei Besuch war. Der hatte eine Kaffemaschine mit solchen Kaffeepads. Das Problem war, die Maschine war nicht richtig geschlossen und nach dem Einschalten lief das ganze Wasser nicht nur durch den Hahn zur Tasse, durch den es fließen sollte, sondern auch über den nicht richtig geschlossenen Schließdeckel. Es könnte natürlich auch ein mechanischer Fehler gewesen sein, aber eine gescheite Software mit entsprechendem Sensor hätte das auch merken und verhindern können. Ein Bitflip wäre ebenso möglich.
Nimmst Du wirklich an, darum kümmert sich heute jemand? Bei den Wegwerfgeräten und Preisen? Es muss nur gut genug funktionieren dass es sich verkauft und ideal sollten vor Ende der Gewährleistung nicht allzu viele Ausfälle passieren die man ersetzen muss. Darüber hinaus dürfen sich die Werkstoffkundler austoben und die Lebendauer des Geräts auf die Gewährleistungdauer optimieren... Software wird ausgeliefert sobald sie die absoluten Mindestanforderungen erfüllt ODER sobald der Updater läuft wenn es einen gibt. Das kann bei besonders hochwertiger Hardware natürlich schon auch höhere Ansprüche erfüllen, aber wir reden doch hier gerade von der Masse, nicht von den Top 0,x%?
Nano schrieb: > Ein Bitflip wäre ebenso möglich. Bin gestern in eine Verkehrskontrolle geraten und das Messgerät zeigte 2.1‰ Habe dem Polizisten erklärt, dass ein Bitflip nicht auszuschließen sei. Durfte weiter fahren.
Bananenware schrieb: > Nimmst Du wirklich an, darum kümmert sich heute jemand? Und ob sich darum jemand kümmert! Die Geräte müssen vor der Markteinführung einen Approbationsprozess durchlaufen. Und dabei wird die Erfüllung der zutreffenden Sicherheitsnormen z.B. vom VDE (oder UL, CCCC, ...) recht penibel überprüft. Dazu gehören auch entsprechende Sicherheitskonzepte und deren Realisierung in Hard- und/oder Software. Da steckt schon erheblich mehr Aufwand drin, als sich manch einer vorstellt! Ich habe das jahrelang von der Entwicklerseite aus mitmachen "dürfen". Das ist wirklich keine Spaß.
Frage ist doch eher - muss eine Kaffemachiene überhaupt idiotensicher sein? Hab hier eine alte Espressokanne. Aufschrauben - Wasser rein - Pulver rein - zuschrauben - auf die Flamme stellen. Wenn man die nicht richtig zuschraubt, pfeift der Dampf raus. Früher fanden die Leute so etwas ganz normal. Muss man sich halt mit auskennen. Heute haben wir dutzende von Sensoren, Programme und blinkende rote LEDs. Damit der Preis stimmt wird dann das billigste vom billigen verbaut. Nach 2 Jahren geht ein Sicherheitssensor kaputt und wir müssen die Kaffeemaschine wegwerfen. Dann doch lieber ohne Steuerung, ohne Sensoren und ohne blinkende LEDs. Was nicht eingebaut ist, kann auch nicht kaputt gehen. Kommt halt ab und zu mal ein Liter Wasser raus.
Noch ein Kommentar schrieb: > Frage ist doch eher - muss eine Kaffemachiene überhaupt idiotensicher > sein? > > Hab hier eine alte Espressokanne. Aufschrauben - Wasser rein - Pulver > rein - zuschrauben - auf die Flamme stellen. > So etwas wird heute ganz hip überteuert verkauft: https://www.manufactum.de/espressokocher-giannina-induktion-a16358/ Falls mal der Strom weg ist und so ... > Wenn man die nicht richtig zuschraubt, pfeift der Dampf raus. Früher > fanden die Leute so etwas ganz normal. Muss man sich halt mit auskennen. > > Heute haben wir dutzende von Sensoren, Programme und blinkende rote > LEDs. Damit der Preis stimmt wird dann das billigste vom billigen > verbaut. Nach 2 Jahren geht ein Sicherheitssensor kaputt und wir müssen > die Kaffeemaschine wegwerfen. Das ist das Problem! Wegwerfgesellschaft! > > Dann doch lieber ohne Steuerung, ohne Sensoren und ohne blinkende LEDs. > Was nicht eingebaut ist, kann auch nicht kaputt gehen. Kommt halt ab und > zu mal ein Liter Wasser raus.
> die Erfüllung der zutreffenden Sicherheitsnormen > recht penibel überprüft Wird halt so konstruiert, dass es gerade eben durch die Prüfungen kommt. Mein Entsafter war defekt. Die hatten eine Sicherung zwischen Kabel und Platine gelötet. Ist abgerissen. Wahrscheinlich durch die andauernden Vibrationen. Da vermute ich, es gab eine neue Vorschrift. Bei so einem dünnen Anschlusskabel muss eine zusätzliche Sicherung eingebaut werden. Neue Platine und neue Halterungen konstruieren war zu teuer. Haben die einen Schrott gebaut, der zwar die Vorschriften einhält, aber nach wenigen Jahren kaputt geht.
Nano schrieb: > Ich frage auch deswegen, weil ich neulich bei jemandem bei Besuch war. > Der hatte eine Kaffemaschine mit solchen Kaffeepads. > Das Problem war, die Maschine war nicht richtig geschlossen und nach dem > Einschalten lief das ganze Wasser nicht nur durch den Hahn zur Tasse, > durch den es fließen sollte, sondern auch über den nicht richtig > geschlossenen Schließdeckel. > Es könnte natürlich auch ein mechanischer Fehler gewesen sein, aber eine > gescheite Software mit entsprechendem Sensor hätte das auch merken und > verhindern können. Ein Bitflip wäre ebenso möglich. Das Ganze wird als Konstruktions- und nicht allein als Softwareproblem abgehandelt. Da gibt es auch Standards für https://de.wikipedia.org/wiki/Funktionale_Sicherheit
Nano schrieb: > Eine Rettung die so etwas verhindern könnte, wäre somit entweder eine > erneute Abfrage der Sensoren ... Die Frage sollte eher heißen, ob die Softwerker über ihren Tellerrand hinaus schauen und verantwortungsbewusst agieren. Fehlertoleranz und Plausibiltätskontrollen sind vielen fremd und stehen nur selten im Pflichtenheft. Horst V. schrieb: > Und ob sich darum jemand kümmert! Die Geräte müssen vor der > Markteinführung einen Approbationsprozess durchlaufen. Und dabei wird > die Erfüllung der zutreffenden Sicherheitsnormen z.B. vom VDE (oder UL, > CCCC, ...) recht penibel überprüft. Dazu gehören auch entsprechende > Sicherheitskonzepte und deren Realisierung in Hard- und/oder Software. > Da steckt schon erheblich mehr Aufwand drin, als sich manch einer > vorstellt! Ich habe das jahrelang von der Entwicklerseite aus mitmachen > "dürfen". Das ist wirklich keine Spaß. Ich weiß nicht, was Du für Prozesse durchlaufen hast, würde das aber keinesfalls verallgemeinern. Ich kenne Zertifizierungen als sehr Papierlastig, aber niemand bemerkt, dass der Kram nicht über längere Zeiträume stabil arbeitet. Das sage ich nicht als Entwickler der Saftware, sondern als Systemtester, den die Kollegem eher gehasst als unterstützt haben. Matthias 🟠. schrieb: > Falls mal der Strom weg ist und so ... Meine Heimwerkererfahrung: In einem älteren NiCd-Ladegerät ist die mechanische Zeitschaltuhr verstorben. Als Ersatz habe ich einen Arduino als Timer gebaut und nach bestem Können getestet. Monate später gab es einen Netzausfall und das Ding hat danach Vollgas geladen anstatt in Ruhe zu bleiben. Die Stellung des Relais nach Reset war in der Software binnen 5 Minuten korrigiert, ich habe es zuvor beim Test ganz einfach übersehen. Software eben, wem das nicht passiert, der werfe den ersten Stein.
> und in der Zwischenzeit ein Bitflip stattfindet
Warum sollte ein Bitflip stattfinden? Hast du Angst, dass dein
Mikrocontroller kaputt ist? Glaub mir, dann wäre eine offene Tür dein
kleinstes Problem ... Insb eine Fehlerkorrektur in einem einzelnen
Register bringt dir gar nichts - dann kippt halt ein anderes Bit.
Als Programmierer verlässt du dich darauf, dass die Controller nach
Spezifikationen arbeitet. Wenn da Bitkipper erwähnt werden, behandelst
du die; wenn nicht, dann nicht. Die Teile arbeiten deterministisch -
tun sie das nicht, hast du verloren. Sich (bedingt) dagegen zu schützen
erfordert eine Riesenaufwand, der nur in Spezialbereichen getrieben
wird. Deine Waschmaschine solltest du daher besser im gefliesten
Waschraum mit Ablauf aufstellen als auf den Perser im Wohnzimmer ;-)
foobar schrieb: >> und in der Zwischenzeit ein Bitflip stattfindet > > Warum sollte ein Bitflip stattfinden? Hast du Angst, dass dein > Mikrocontroller kaputt ist? Glaub mir, dann wäre eine offene Tür dein > kleinstes Problem ... Z.B. durch natürliche Hintergrundstrahlung. > Insb eine Fehlerkorrektur in einem einzelnen > Register bringt dir gar nichts - dann kippt halt ein anderes Bit. Um das zu vermeiden genau dafür wäre die Fehlerkorrektur ja dann da. Der Wert würde mehrere Bits einnehmen, das wäre nicht mehr nur 1 Bit, sondern mehrere und zwar genau so viele, damit die Fehlerkorrektur den Fehler erkennen und korrigieren kann. > Als Programmierer verlässt du dich darauf, dass die Controller nach > Spezifikationen arbeitet. Wenn da Bitkipper erwähnt werden, behandelst > du die; Das steht in keiner Spec, damit musst du selber rechnen. Und ob man es machen sollte, hängt davon ab, ob es wichtig ist. Eine Waschmaschine bei der das Wasser in die Wohnung läuft, willst du nicht, da wäre es also durchaus angebracht. Bei weniger wichtigen Dingen, ist es eher egal, da kann man es weglassen. > Die Teile arbeiten deterministisch - > tun sie das nicht, hast du verloren. Strahlung ist ein Einfluss von außen. Das ist zwar extrem selten, aber nicht unmöglich. > Sich (bedingt) dagegen zu schützen > erfordert eine Riesenaufwand, der nur in Spezialbereichen getrieben > wird. Nun ja, es ist geringfügig etwas mehr Programmierarbeit. Wenn man dafür eine Bibliothek schreibt, muss man den Aufwand nur einmal betreiben und kann die dann beim nächsten mal wieder benutzen.
Nano schrieb: > Nun ja, es ist geringfügig etwas mehr Programmierarbeit. > Wenn man dafür eine Bibliothek schreibt, muss man den Aufwand nur einmal > betreiben und kann die dann beim nächsten mal wieder benutzen. Ich denke, dass dieses theoretische Problem in einer normalen Umgebung mit industriellen Temperaturen nicht auftritt. Wären Bit-Flips ein ernst zu nehmendes Problem, so könnten diese in jedem Teil des Mikrocontrollers auftreten, inklusive der CPU- und Peripheral-Register. Sich dagegen abzusichern ist schwer und meiner Ansicht nach zwecklos. Es schadet sicherlich nicht, periodisch den Zustand des Systems zu überprüfen und bei unerwarteten Abweichungen in einen sicheren Modus zu schalten, jedoch sollten diese Checks mit Bedacht gewählt werden, sodass sich das Gerät durch einen Softwarefehler oder eine leichte Grenzwertüberschreitung nicht andauernd selbst abschaltet und den Kunden verrückt macht.
> jedoch sollten diese Checks mit Bedacht gewählt werden
Stimmt! Jeder hat einen Bekannten, der mit seinem Auto andauernd in die
Werkstatt muss. Die finden nichts, löschen nur den Fehlerspeicher. Läuft
wieder 1/2 Jahr.
Mir ist mal ein alter Zeitschrifteinartikel aufgefallen. Wegen dieser
Bitflips waren Unterprogrammaufrufe in Rechnern für Flugzeuge verboten.
Bzw. Rücksprungadressen ins RAM schreiben. Dann gaben die Hersteller
Gutachten in Auftrag: Die Verwendung von Hochsprachen und
Unterprogrammen vermeidet mehr Fehler, als sich mit dieser Vorschrift
vermeiden lassen.
Noch ein Kommentar schrieb: >> jedoch sollten diese Checks mit Bedacht gewählt werden > > Stimmt! Jeder hat einen Bekannten, der mit seinem Auto andauernd in die > Werkstatt muss. Die finden nichts, löschen nur den Fehlerspeicher. Läuft > wieder 1/2 Jahr. > > Mir ist mal ein alter Zeitschrifteinartikel aufgefallen. Wegen dieser > Bitflips waren Unterprogrammaufrufe in Rechnern für Flugzeuge verboten. Auf der ISS hat man sich für einen 386er entschieden, weil der damals bereits erhältliche 486er über einen 8 KiB großen 1st Level Cache verfügte und der im Weltraum anfälliger gegen Strahlung war als eine CPU ohne Cache. Der 386er hatte keinen Cache und war schneller als ein 486er mit abgeschaltetem Cache: https://ntrs.nasa.gov/citations/19910016373
Nano schrieb: > Es könnte natürlich auch ein mechanischer Fehler gewesen sein, aber eine > gescheite Software mit entsprechendem Sensor hätte das auch merken und > verhindern können. Ein Bitflip wäre ebenso möglich. Im Programm bzw. in einem Ablauf können sehr viele Fehler passieren. Meistens sind sie aber nicht kosmischer Natur, sondern weil bei sehr vielen Machern (Politiker, Scrum-Master, Projektmanager, Entwickler, Sportler, Künstler, Ingenieure, Handwerker usw.) die Hände aus dem Gesäß wachsen bzw. beide lknks sind oder sie haben ihren logischen Verstand ständig im Standby modus.
Noch ein Kommentar schrieb: > Mir ist mal ein alter Zeitschrifteinartikel aufgefallen. Wegen dieser > Bitflips waren Unterprogrammaufrufe in Rechnern für Flugzeuge verboten. Eben, Flugzeugbereich, hier ist aber von Consumer die Rede. ein Flugzeug ist der kosmischen Strahlung stärker ausgesetzt und im Fluge kann man nicht mal eben rechts ranfahren und den Warnblinker einschalten.
> Der hatte eine Kaffemaschine mit solchen Kaffeepads. > Das Problem war, die Maschine war nicht richtig geschlossen und nach dem > Einschalten lief das ganze Wasser nicht nur durch den Hahn zur Tasse, > durch den es fließen sollte, sondern auch über den nicht richtig > geschlossenen Schließdeckel. Bevor man über die Erkennung von „Bitflips“ spricht müsste man ja erstmal klären, was der Sensor überhaupt gesehen hat. Nur weil Wasser oben rausläuft kann man daraus nicht schließen, dass der Sensor ebenfalls „offen“ detektiert hat. Du wirst die Maschine des Bekannten ja nicht dahingehend untersucht haben. Darüber hinaus kann man auch nicht sagen, dass man aus der Kategorie Commercial/Professional einen resultierenden Programmierstil ableiten könnte. Es kann so oder so sein. In der Firma KÖNNTE es sein, dass der Programmierer nur sehr wenig Zeit bekommt und daher einige Szenarien nicht bedenkt. Das muss aber nicht so sein, kann auch sein, dass die Software schon sehr lange (aus vorhergehen Serien) gereift ist oder generell der Programmierer einen guten Job machen konnte - warum auch immer. Ich selber habe jedenfalls schlampige Programmierung auch schon oft genug bei Produkten erlebt, wo das nicht hätte sein dürfen.
Nano schrieb: >> Als Programmierer verlässt du dich darauf, dass die Controller nach >> Spezifikationen arbeitet. Wenn da Bitkipper erwähnt werden, behandelst >> du die; > > Das steht in keiner Spec Selbstverständlich steht das in der Spec. Wenn ich Wert darauf lege, bekomme ich natürlich vom µC-Hersteller eine Spec mit Wahrscheinlichkeiten zu allen möglichen Hardwarefehlverhalten. Die lassen sich das natürlich bezahlen. Sollte klar sein.
Wenn wir mal beim Beispiel mit den beiden Bits der Waschmaschine bleiben, werden irgendwelche Bitflips normalerweise von der Statemachine schon verarbeitet. Flippt also das 'Tür Offen' Bit, wird die Maschine den Status überprüfen und im Wasch/Spül/Trocken/Schleuder Modus sofort stoppen und eine der so beliebten Fehlermeldungen aufs Display werfen. Flippt das Wassereinlassbit, ist es ähnlich. Wenn das zum Status passt, wird Wasser eingelassen, bis der Drucksensor den nötigen Füllstand meldet und dann ist Schluss. Passts nicht zum Status - Stop und Fehlermeldung. Aber in all den vielen Jahren, die ich schon mit MC verbracht habe, ist noch nie ein Bit von sich aus gekippt (ausser in alten EPROMs). Der Dummkopf war immer der Programmierer, nicht der MC. Mit den alten EPROMs hingegen hatte ich schon viel Spaß...
:
Bearbeitet durch User
Nano schrieb: > Obiger Pseudocode prüft also nur das Statuswort und sagt, > prima, Türe geschlossen, setze Ventil für den Wassereinlauf > auf offen (1). > Und schon läuft die Bude voll. Lt. BDA darf man die Maschine ohnehin nicht unbeaufsichtigt laufen lassen. - Problem gelöst!
"Wird heutzutage auch im Komsumerbereich auf Bitflips geachtet [...]" Horst V. schrieb: > Bananenware schrieb: >> Nimmst Du wirklich an, darum kümmert sich heute jemand? > > Und ob sich darum jemand kümmert! Also ich kenne keinen einzigen Mikrocontroller, der irgendwie gegen Birflips abgesichert waere. Und das in Software zu tun ist nur fuer reine Daten moeglich, nicht fuer den Code. Es wurde weiter oben schon angesprochen, wenn es einen Bitflip in einer Ruecksprungadresse gibt, laeuft das Programm Amok. Oder wenn es einen Bitflip im Maschinenbefehl gibt, ist das ploetzlich ein ganz anderer Befehl. Wenn dann aus einer Addition ein Sprungbefehl wird, kann viel passieren. Wie gesagt, ich kennne keinen Mikrocontroller, der das absichert. (Heisst aber nicht, dass es das nicht gaebe). In Hardware gibt es den Watchdog, mit dem man zumindest einen Totalabsturz des Programms erkennen kann. Was bei sicherheitsrelevanten Systemen z.T. gemacht wird, ist mehrere Prozessoren parallel zu betreiben, die sich dann gegenseitig ueberwachen. Sehr aufwendig. Das Gesamtsystem muss so konstruiert sein, dass eine Fehlfunktion des Prozessors nicht zur Gefahr wird. Z.B. durch Verriegelungsschaltungen in Hardware. Wie wird das eigentlich bei Steuergeraeten im Auto gemacht, bspw. bei der Servolenksteuerung?
Nano schrieb: > Die Frage ist nun, wir das bei Consumergeräten so gemacht? https://www.microchip.com/en-us/solutions/functional-safety/iec-60730
Rein praktisch betrachtet würde ich mir eher Sorgen machen, daß die Vibrationen der WaMa im Schleudergang zu einem Haarriß in der Wasserzuleitung in der Wand verursachen, als das ein Bitflip genau im richtigen Moment das passende Bit flippt und mir die WaMa deshalb die Wohnung überflutet.
Maxe schrieb: > Wenn dann aus einer > Addition ein Sprungbefehl wird, kann viel passieren. Wenn das flippige Bit im Program-Counter daheim ist, brauchts zum Springen ja noch nicht mal einen Sprung-Befehl; aber meist wird das sehr schnell in einem Absturz enden. Rein praktisch würde mir ein bedingter Sprung, dessen Bedingung ins Gegenteil flippt weit mehr Sorgen machen, denn das kann leicht direkt ins Desaster führen. Maxe schrieb: > Verriegelungsschaltungen in Hardware Auch Hardware soll gelegentlich defekt werden und sogar die ganz harte Ware - also eine mechanische Verriegelung - bricht irgendwann und hat ab und an einen Materialfehler… Mit Bitflips bewegen wir uns rein von den Wahrscheinlichkeiten vermutlich in ähnlichen Größenordnungen.
Nano schrieb: > Die Frage ist nun, wir das bei Consumergeräten so gemacht? Die Frage kann man so nicht beantworten, weil mit Sicherheit nicht alle Geräte von den gleichen Leuten nach den gleichen Anforderungen entwickelt werden. Nano schrieb: > Das Problem war, die Maschine war nicht richtig geschlossen und nach dem > Einschalten lief das ganze Wasser nicht nur durch den Hahn zur Tasse, > durch den es fließen sollte, sondern auch über den nicht richtig > geschlossenen Schließdeckel. Lass mich raten: Es war eine Senseo. Von der kenne ich das. Es gibt eine Menge Consumer Geräte, die nur unter Aufsicht verwendet werden dürfen. Da gelten die geringsten Sicherheitsanforderungen.
Klar kann man bit flip absichern. 1. Sicherheitsstufe davon wären 2inv bits. Also 10=0 01=1. Dann nur nicht die Fehlerauswertung vergessen. Den Programspeicher (flash) aber auch regelmäßig per crc testen und hoffentlich ist die test routine nicht defekt. Macht man halt 2 rein. Diesen Aufwand macht man nur leider nicht in konsumer Kram rein. Wer soll das bitte bezahlen. Die meisten Haushaltsgeräte haben schon etwas mehr Sicherheit drin, aber auch die haben keine medizinischen Sicherheitsanforderungen.
Nano schrieb: > eine gescheite Software mit entsprechendem Sensor hätte das > auch merken und verhindern können. Sensoren können aber auch versagen. Ich hatte drei Wochen eine eiskalte Wohnung (15 - 16 °C) weil ein Drucksensor in der neuen Heizungsanlage versagte und sie auf "Störung" ging, obwohl gar nichts gestört war (außer halt der Sensor).
nicht mal in Industrieanlagen macht man das. Wenn es sicher sein muss, dann kommt eine Sicherheits SPS rein. Da müssen z.B. Kontakte doppelt ausgeführt sein, Relaisansteuerungen werden auf Drahtbruch geprüft. Von 'Bitflips' habe ich da auch noch nicht gehört. Bei Anforderung von Strahlensicherheit nimmt man eher FPGAs und überprüft das auf Bitfehler, so habe ich es jedenfalls verstanden. Die sind aber teurer als eine Waschmaschine.
:
Bearbeitet durch User
Manfred schrieb: > Ich kenne Zertifizierungen als sehr Papierlastig, aber niemand bemerkt, > dass der Kram nicht über längere Zeiträume stabil arbeitet. Das sage ich > nicht als Entwickler der Saftware, sondern als Systemtester, den die > Kollegem eher gehasst als unterstützt haben. Vodafone hatte mal einen Schrank von Sun gekauft, für mehrere hundert tausend Euro. Da war alles doppelt und dreifach drin, super redundant, super abgesichert, aber auch super lahm (langsamer als ein normaler Desktop PC). Der Hersteller versprach, dass man alles im laufenden Betrieb wechseln und sogar einen Schraubenschlüssel hinein werfen kann, ohne dass das laufende Programm ausfällt. Nun hatte ich als Testcase notiert, dass ich einen Netzteil-Lüfter blockieren will. Erwartetes Ergebnis: Netzteil schaltet ab ohne kaputt zu gehen, ein Alarm wird generiert, die Software läuft weiter. Sun hatte dringendst davon abgeraten dies zu testen. Im Fall des Falles sei ein defektes Netzteil zwar durch die Garantie abgedeckt, aber sie sorgten sich um unsere gespeicherten Daten. Was soll man davon halten? Das habe ich bis zum Hauptabteilungsleiter eskaliert, der ordnete dann an, diesen Test mit allen 6 Netzteilen jeweils drei mal durchzuführen. Guter Mann. Der Test verlief erfolgreich. Dafür hatten wir aber kurze Zeit nach der Inbetriebnahme mehrmals einen CPU-Modul Ausfall, der doch zum Abbruch der Software führte. Schade um das viele Geld. Das Vertrauen in die Maschine war nach dem 3. erfolglosen Reparaturversuch im Arsch.
Peter schrieb: > Klar kann man bit flip absichern. > 1. Sicherheitsstufe davon wären 2inv bits. Also 10=0 01=1. Dann nur > nicht die Fehlerauswertung vergessen. Nö das wäre keine Sicherheit, weil man die zu "00" oder "11" geflippten Bites nicht deren Korrekten Zustanden zuordnen kann. Dann erkennt man zwar das was nicht in Ordnung ist, aber nicht wie es richtig sein sein. bei stuck-at Fehlern könnte man zwar das Fehlerbit erkennen und dann umgehen, aber nicht bei zufälligen ('Heisen(berg)-bug') bits. https://de.wikipedia.org/wiki/Heisenbug Dann bitte schön dreifach statt doppelt redundant Bits. und dann anhand der Mehrzahl entscheiden. '010' -> '0' '110' -> 1 Kann man dann statt bits auch mit Modulen zu TMR https://en.wikipedia.org/wiki/Triple_modular_redundancy erweitern.
Beitrag #7282030 wurde von einem Moderator gelöscht.
Klapperkopp schrieb im Beitrag #7282030:
> Die Anlage hat sicher gemerkt, daß ihr Betreiber gestört ist.
Komm her, dann zeige ich dir den Reparaturbericht des Handwerkers.
Bitflips sind für die Konstrukteure von Waschmaschinen genauso relevant, wie es für einen Langstreckenläufer relevant ist, wie viele Meter er bis zum Taxi gehen muss, das ihn nach dem Marathon ins Hotel fährt.
Nano schrieb: > Z.B. durch natürliche Hintergrundstrahlung. Dieses trollige Forum. Wenn die Strahlung in seiner Wohnung so hoch ist, solltest du über einen Umzug nachdenken und der Waschmaschine danken.
Maxe schrieb: > Also ich kenne keinen einzigen Mikrocontroller, der irgendwie gegen > Birflips abgesichert waere. Naja bei den neueren STM32 besitzt schon der Flash ECC. Teilweise hat der RAM einen Party Check oder auch schon ECC. Das gibt es heute quasi für lau. Und bei TI oder Infineon bekommt man dann auch FUSI Controller mit Lockstep und co... Kostet halt... Und für Bier Flips sollte die Baugruppe lackiert oder vergossen sein...
Einen Bitflip habe ich noch nie bemerkt. Es gibt aber viele Programmfehler, die so aussehen als ob. Z.B. habe ich mal eine Reaktion erlebt, die lt. Programmablauf unmöglich wäre. Die Analyse ergab, daß der Autor um RAM zu sparen, IO-Pins mehrmals eingelesen hat. Da aber externe Ereignisse asynchron sind, kam es dazu, daß verschiedene Pegel eingelesen wurden. Der Ablauf ging jedoch davon aus, daß alle Signale im Zyklus konstant sind. Nach Umstellung des Programms auf EVA funktionierte alles und es gab keine undefinierten Zustände mehr. Die Eingänge werden zu Beginnn eines Zyklus eingelesen und dann nur noch mit dieser Kopie gearbeitet. Die kann nämlich nicht flippen. EVA sorgt auch dafür, daß an den Ausgängen keine Spikes auftreten können, d.h. die werden auch erstmal in einer Kopie gesetzt. Daher benutzt auch jede SPS EVA.
Peter D. schrieb: > Nach Umstellung des Programms auf EVA funktionierte alles Klingt vernünftig, auf jeden Fall besser als ADAM Ausprobieren Dumm gucken Anders Machen
Maxe schrieb: > Wie wird das eigentlich bei Steuergeraeten im Auto gemacht, bspw. bei > der Servolenksteuerung? Die µCs in diesen Bereichen haben ECC-Memory, Lockstep-CPUs und teilweise mit ebensolchen Mechanismen abgesicherte Peripherie. Und die Software ist dann auch nach Prinzipien der Funktionalen Sicherheit programmiert. Das beinhaltet dann redundante Prüfungen, Speicherchecksummen, Strikten Regeln für die Programmierung ansich, etc...
Peter D. schrieb: > Einen Bitflip habe ich noch nie bemerkt. Gibt es aber recht häufig, so einmal im Monat und nicht einmal in Zehntausend jahren wie gern erzählt. Google hat da mal überraschende Ergebnisse aus ihren Server mi ECC gezogen. https://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html
Stefan F. schrieb: > Ausprobieren > Dumm gucken > Anders > Machen Sowas habe ich leider auch oft erlebt. Statt den Fehler zu finden, werden Delays eingefügt und Timeouts hochgesetzt. Eine goldene Regel der Fehlersuche ist, wenn eine Änderung nicht die erwartete Wirkung zeigt, sucht man an der völlig falschen Stelle.
:
Bearbeitet durch User
Manfred schrieb: > Die Frage sollte eher heißen, ob die Softwerker über ihren Tellerrand > hinaus schauen Das tun sie selten - schon weil ihnen die dazu nötigen Fähigkeiten meistens gar nicht vermittelt worden sind oder sie es ohne ihre Vorgesetzten nicht dürfen. > und verantwortungsbewusst agieren. Das tun sie meistens. Jedenfalls, soweit sie es können. Für die Einweisung und den innerbetrieblichen Blick über den Tellerrand fehlen meistens die Zeit und oft auch diejenigen, die die Dinge ordentlich und nachhaltig vermitteln könnten. Und die in manchen Unternehmen "gepflegte" "Kultur", Entwickler nur als Codemonkeys zu sehen, das Unternehmen eh wieder verlassen, wenn sie ausgebrannt sind, macht langfristige Investitionen in deren Wissen wenig sinnvoll. > Fehlertoleranz und > Plausibiltätskontrollen sind vielen fremd und stehen nur selten im > Pflichtenheft. Die stehen schon drin, im Kleingedruckten: "Die Software sollte fehlertolerant programmiert sein und alle Daten vor der Verwendung validieren". > Das sage ich > nicht als Entwickler der Saftware, sondern als Systemtester, den die > Kollegem eher gehasst als unterstützt haben. Das kann eine extrem undankbare Rolle sein.
MaWin schrieb: > Nano schrieb: >>> Als Programmierer verlässt du dich darauf, dass die Controller nach >>> Spezifikationen arbeitet. Wenn da Bitkipper erwähnt werden, behandelst >>> du die; >> >> Das steht in keiner Spec > > Selbstverständlich steht das in der Spec. > Wenn ich Wert darauf lege, bekomme ich natürlich vom µC-Hersteller eine > Spec mit Wahrscheinlichkeiten zu allen möglichen Hardwarefehlverhalten. > Die lassen sich das natürlich bezahlen. Sollte klar sein. Dann zeig mir mal eine Spec eines Consumer µC mit Angaben zu Wahrscheinlichkeiten von Bitkips durch natürliche Hintergrundstrahlung. Du sagst, das steht drin, also zeig mal.
Matthias S. schrieb: > Wenn wir mal beim Beispiel mit den beiden Bits der Waschmaschine > bleiben, werden irgendwelche Bitflips normalerweise von der Statemachine > schon verarbeitet. > Flippt also das 'Tür Offen' Bit, wird die Maschine den Status überprüfen > und im Wasch/Spül/Trocken/Schleuder Modus sofort stoppen und eine der so > beliebten Fehlermeldungen aufs Display werfen. Das setzt allerdings voraus, dass der Status ständig bzw. regelmäßig geprüft wird.
Maxe schrieb: > Und das in Software zu tun ist nur fuer > reine Daten moeglich, nicht fuer den Code. Es wurde weiter oben schon > angesprochen, wenn es einen Bitflip in einer Ruecksprungadresse gibt, > laeuft das Programm Amok. Oder wenn es einen Bitflip im Maschinenbefehl > gibt, ist das ploetzlich ein ganz anderer Befehl. Das ist leider korrekt. Fehlerkorrektur würde nur gegen Bitflips in Daten helfen. > Wie gesagt, ich kennne keinen Mikrocontroller, der das absichert. > (Heisst aber nicht, dass es das nicht gaebe). In Hardware gibt es den > Watchdog, mit dem man zumindest einen Totalabsturz des Programms > erkennen kann. Was bei sicherheitsrelevanten Systemen z.T. gemacht wird, > ist mehrere Prozessoren parallel zu betreiben, die sich dann gegenseitig > ueberwachen. Sehr aufwendig. Manche größeren µC haben inzwischen mehrere Kerne. Könnte man die nicht nutzen um durch mehrere Kerne, die parallel das gleiche abarbeiten Fehler zu vermeiden? So eine Lösung wäre zwar sicher noch nicht für die Luft- und Raumfahrttechnik zugelassen, aber im Consumerbreich würde das sicherlich schon reichen und ist besser als nichts. Der µC mit mehreren Kernen kostet dadurch auch nicht mehr, wenn es ohnehin die Version mit mehreren Kernen wird.
Nano schrieb: > Könnte man die nicht nutzen um durch mehrere Kerne, > die parallel das gleiche abarbeiten Fehler zu vermeiden? Wenn sich die beiden nicht einig sind, wer entscheidet dann über Recht und Unrecht? Und wie sorgst du dafür, dann nur mit den richtigen Daten weiter gearbeitet wird? Und was ist, wenn der Fehler im RAM liegt, so dass beide CPU Kerne die gleichen falschen Daten verwenden um ein falsches Ergebnis zu produzieren? > im Consumerbreich würde das sicherlich schon reichen Naja, ein zweiter CPU Kern ist noch keine Lösung.
Das 2 bit immer noch 2 undefinierte Zustände hat ist klar, darum ja die Fehlerbehandlung. Auch das 3 bit mehr Sicherheit bringen, 8bit sind sogar noch sicherer und 32bit erst.
Die Fehlerbehandlung ist halt meistens das was in einem Programm die Qualität ausmacht. Ich hatte mal eine Maschinen Steuerung gemacht, den gesamten Ablauf hatte ich in gut 30 Stunden zusammen. Nur damit hätte niemand arbeiten können, aber man konnte sehen ob wir in die richtige Richtung gehen. Erst die 10 Wochen absichern der Abläufe hat daraus ein Produkt gemacht!
Nicht mehr rekonstruierbar und eh irrelevant schrieb im Beitrag #7281559: > Da gibt es auch Standards für > https://de.wikipedia.org/wiki/Funktionale_Sicherheit IEC60730 schrieb: > Nano schrieb: >> Die Frage ist nun, wir das bei Consumergeräten so gemacht? > > https://www.microchip.com/en-us/solutions/functional-safety/iec-60730 Danke noch für die Links. Stefan F. schrieb: > Nano schrieb: >> Das Problem war, die Maschine war nicht richtig geschlossen und nach dem >> Einschalten lief das ganze Wasser nicht nur durch den Hahn zur Tasse, >> durch den es fließen sollte, sondern auch über den nicht richtig >> geschlossenen Schließdeckel. > > Lass mich raten: Es war eine Senseo. Von der kenne ich das. Habe leider auf den Hersteller nicht geachtet. Aber so eine quaderförmige Senseo Quadrante könnte passen.
Nano schrieb: >> Die lassen sich das natürlich bezahlen. Sollte klar sein. > > Dann zeig mir mal eine Spec eines Consumer µC mit Angaben zu > Wahrscheinlichkeiten von Bitkips durch natürliche Hintergrundstrahlung. > Du sagst, das steht drin, also zeig mal. Welchen Teil von "Die lassen sich das natürlich bezahlen. Sollte klar sein." hast du denn nicht verstanden?
Mein Gott, hier tummeln sich ja fast nur mehr Ahnungslose und Pensionisten mit Langeweile die wegen dem Tratsch da sind... Wenn der Hersteller 1e6 Geräte / Jahr verkauft, und in der 5-10 jährigen Lebensdauer 1000 verrückt spielen, dann ist der wegen der schlechten Mundpropaganda schnell weg. Gerade der Konsumerbereich ist da viel empfindlicher als die meisten anderen Märkte. Die produzieren nicht schlechte Qualität, sondern sehr genau kalkulierte Qualität. Jeder namhafte Hersteller der >20 Jahre am Markt ist, weiß genau welche Probleme in der Praxis wie oft auftreten. Und natürlich haben die eine Absicherung gegen abgestürzte/kaputte Mikrocontroller eingebaut. Das schreibt ja auch die EU Maschinenrichtlinie vor. Ohne Risikoanalyse und entschärfende Massnahmen kann man schon seit Jahren nichts mehr zulassen. Bitfehler wegen kosmischer Strahlung sind relativ häufig. Serverworkstations haben nicht ohne Grund ECC RAM. Die loggen solche Events mit. Ich kann mich erinnern, dass solche Fehler regelmässig (1-2/Monat) aufgetreten sind. Mikrocontroller sind da wahrscheinlich weniger anfällig, weil die einfach wenig Ram und relativ grosse Strukturbreiten haben(hatten). >> Die Frage sollte eher heißen, ob die Softwerker über ihren Tellerrand >> hinaus schauen >Das tun sie selten - schon weil ihnen die dazu nötigen Fähigkeiten >meistens gar nicht vermittelt worden sind oder sie es ohne ihre >Vorgesetzten nicht dürfen. Natürlich wissen die Softwerker in dem Bereich normalerweise was sie tun. Die Fähigkeiten werden ihnen von den älteren Kollegen vermittelt.
:
Bearbeitet durch User
Re D. schrieb: > Nano schrieb: >> Z.B. durch natürliche Hintergrundstrahlung. > > Dieses trollige Forum. Wenn die Strahlung in seiner Wohnung so hoch ist, > solltest du über einen Umzug nachdenken und der Waschmaschine danken. Informiere dich mal. Die "Höhe" bzw. Aktivität der Strahlung ist dafür gar nicht relevant, sondern nur, das sie da ist und die Teilchenstrahlung durch die Speicherzelle fliegt und da das Bit kippt. Normale Hintergrundstrahlung ist dafür ausreichend und kann auch nicht restlos verhindert werden. Eine höhere Aktivität steigert lediglich die Wahrscheinlichkeit, dass es innerhalb der Betriebszeit irgendwann auftritt.
Re D. schrieb: >> Z.B. durch natürliche Hintergrundstrahlung. > > Dieses trollige Forum. Wenn die Strahlung in seiner Wohnung so hoch ist, > solltest du über einen Umzug nachdenken und der Waschmaschine danken. Natürliche Strahlung (Radon) ist in bergigen Gegenden die zweithäufigste Ursache für Lungenkrebs... Meist reicht es, für Durchzug im Keller zu sorgen.
Peter D. schrieb: > Einen Bitflip habe ich noch nie bemerkt. Es gibt aber viele > Programmfehler, die so aussehen als ob. > Z.B. habe ich mal eine Reaktion erlebt, die lt. Programmablauf unmöglich > wäre. Die Analyse ergab, daß der Autor um RAM zu sparen, IO-Pins > mehrmals eingelesen hat. Da aber externe Ereignisse asynchron sind, kam > es dazu, daß verschiedene Pegel eingelesen wurden. Der Ablauf ging > jedoch davon aus, daß alle Signale im Zyklus konstant sind. > Nach Umstellung des Programms auf EVA funktionierte alles und es gab > keine undefinierten Zustände mehr. Die Eingänge werden zu Beginnn eines > Zyklus eingelesen und dann nur noch mit dieser Kopie gearbeitet. Das ist ein gutes Beispiel, bei dem es nötig sein kann, dass die Sensoren nur am Anfang einmal eingelesen werden und dann mit den Daten im Statuswort gearbeitet wird. > Die > kann nämlich nicht flippen. Doch, die Kopie kann flippen, und wenn sie über keine Fehlerkorrektur verfügt wird das weder erkannt noch korrigiert. Das ist genau der Punkt. Der Bitflip erfolgt in der Regelung durch natürliche Strahlung, also von außen.
Stefan F. schrieb: > Nano schrieb: >> Könnte man die nicht nutzen um durch mehrere Kerne, >> die parallel das gleiche abarbeiten Fehler zu vermeiden? > > Wenn sich die beiden nicht einig sind, wer entscheidet dann über Recht > und Unrecht? In der Regel nimmt man mindestens 3, besser 4 CPUs. Eine liegt dann falsch, die Mehrheit richtig und nach der Mehrheit wird orientiert. Das Space Shuttle hatte bspw. 4 Prozessoren. Das waren aber halt 4 eigenständige Prozessoren, keine 4 Kerne auf einem Die. > Und wie sorgst du dafür, dann nur mit den richtigen Daten > weiter gearbeitet wird? Und was ist, wenn der Fehler im RAM liegt, Falls das RAM geteilt wird, wäre hier eine Fehlerkorrektur ausreichend. >> im Consumerbreich würde das sicherlich schon reichen > > Naja, ein zweiter CPU Kern ist noch keine Lösung. Ein dritter schon.
Udo K. schrieb: > Bitfehler wegen kosmischer Strahlung sind relativ häufig. Es ist ein großer Unterschied, ob wir von 16GB DRAM in einem PC sprechen oder von 1kB SRAM in einem MC. Die SRAM Zellen sind im Vergleich riesig, da mußt Du schon direkt mit einem Röntgengerät drauf schießen.
MaWin schrieb: > Nano schrieb: >>> GELOGENE EINFÜGUNG VON MaWin >> >> Dann zeig mir mal eine Spec eines Consumer µC mit Angaben zu >> Wahrscheinlichkeiten von Bitkips durch natürliche Hintergrundstrahlung. >> Du sagst, das steht drin, also zeig mal. > > Welchen Teil von > "Die lassen sich das natürlich bezahlen. Sollte klar sein." > hast du denn nicht verstanden? 1. Stand das gar nicht oben. Das Orignal ist das hier: Beitrag "Re: Wird heutzutage auch im Komsumerbereich auf Bitflips geachtet und sicherer programmiert?" Da steht nichts von "die lassen sich das natürlich bezahlen. Meine Antwort darauf war das: Beitrag "Re: Wird heutzutage auch im Komsumerbereich auf Bitflips geachtet und sicherer programmiert?" und erst dann kamst du: Beitrag "Re: Wird heutzutage auch im Komsumerbereich auf Bitflips geachtet und sicherer programmiert?" und 2. Geht es um Consumer µC. Nicht um Mil µC für den Militär und Luft und Raumfahrtbedarf. Und jetzt liefere! Kannst du nicht. Dachte ich mir. Typischer MaWin Kommentar.
Peter D. schrieb: > Udo K. schrieb: >> Bitfehler wegen kosmischer Strahlung sind relativ häufig. > > Es ist ein großer Unterschied, ob wir von 16GB DRAM in einem PC sprechen > oder von 1kB SRAM in einem MC. > Die SRAM Zellen sind im Vergleich riesig, da mußt Du schon direkt mit > einem Röntgengerät drauf schießen. Es gibt heute µC die kosten 3 Cent pro Stück und die sind deswegen so billig, weil ihr Flächenbedarf dank kleiner Strukturbreite so gering ist. Die kleine Strukturbreite macht sie dann anfällig gegen Strahlung.
Nano schrieb: > Und jetzt liefere! > Kannst du nicht. Dachte ich mir. Typischer MaWin Kommentar. Du nervst. Frag doch einfach beim Hersteller nach. Die geben dir die Daten meist einfach so...
Udo K. schrieb: > Nano schrieb: >> Und jetzt liefere! >> Kannst du nicht. Dachte ich mir. Typischer MaWin Kommentar. > > Du nervst. Frag doch einfach beim Hersteller nach. Die geben dir die > Daten meist einfach so... Halte du dich bitte heraus. MaWin hat eine Behauptung aufgestellt, die er nicht untermauern kann.
Horst V. schrieb: > Und ob sich darum jemand kümmert! Die Geräte müssen vor der > Markteinführung einen Approbationsprozess durchlaufen. Und dabei wird > die Erfüllung der zutreffenden Sicherheitsnormen z.B. vom VDE (oder UL, > CCCC, ...) recht penibel überprüft. Dazu gehören auch entsprechende > Sicherheitskonzepte und deren Realisierung in Hard- und/oder Software. > Da steckt schon erheblich mehr Aufwand drin, als sich manch einer > vorstellt! Ich habe das jahrelang von der Entwicklerseite aus mitmachen > "dürfen". Das ist wirklich keine Spaß. ist der Beitrag Satire? Was soll der VDE bitte prüfen? Bei Consumer Geräten interessiert das keine Sau. Wenn da ein Bitflippt haste Pech gehabt. Da ich schon gesehen habe wie Sachen in der Medizintechnik aussehen, garantiere ich dir, dass es bei Consumergeräten eher noch schlimmer sein dürfte
Stefan F. schrieb: >> im Consumerbreich würde das sicherlich schon reichen > Naja, ein zweiter CPU Kern ist noch keine Lösung. Und das noch dazu in einem Bereich wo um jeden Cent gefeilscht wird:-) Von den Kosten so ein Konstrukt auch nur ansatzweise zu testen mal ganz abgesehen. Und bevor ich mir die eher unwahrscheinlichen (solange man sich nicht gerade jahrelang im Weltraum aufhalten will) gekippten Bits Gedanken machen würde, würde ich mit eher Gedanken darüber machen ob die vermeintliche Information von Sensor überhaupt stimmt. Von da dürften sehr sehr viel häufiger fehlerhafte Infos kommen als das der µC mal umkippt.
Nano schrieb: >>>> GELOGENE EINFÜGUNG VON MaWin Du bist ein Spinner. Lies den Text und finde deinen Fehler. Ich habe das gemeint, was ich geschrieben habe. Nicht das, was du dir gewünscht hast.
Es ist manchmal sinnvoll, etwas defensiv zu Programmieren, damit falks mal ein fall auftritt an den man nicht gedacht hat, das Programm wieder in einen wohldefinierten zustand findet. Aber sich um Bitflips bei CPU oder RAM zu sorgen ist nicht sinnvoll. Flippt mal der Program Counter, oder ein Funktionspointer, wer weiss was dann passiert? Und wer weiss was da der Compiler effektiv gemacht hat, und was für versteckte unmögliche Zustände es nach allen Optimierungen noch gibt? Selbst Rust hilft einem da nicht mehr weiter. Bitflips müssen HW Seitig verhindert werden. EEC RAM usw. Über mögliche Programmverhalten zu spekulieren, wenn die HW nicht tut was sie soll, ist schlicht nicht möglich. Was noch einigermassen machbar ist ist absichtlich welche verursachen, und sehen, ob was gefährliches passiert. Aber da erwischt man halt nur die wahrscheinlichsten szenarien, und oft kann man dann eh nichts dagegen machen. Bei PCs sollen Bitflips wohl häufiger sein, als man meinen sollte. Aber meistens passiert einfach nichts. Wird vielleicht mal ein Pixel rot, oder ein i zu j, aber nur selten passiert was richtig übles.
MaWin schrieb: > Nano schrieb: >>>>> GELOGENE EINFÜGUNG VON MaWin > > Du bist ein Spinner. > Lies den Text und finde deinen Fehler. > Ich habe das gemeint, was ich geschrieben habe. Nicht das, was du dir > gewünscht hast. Schwurbel woanders. Der Kontext war schon immer Conumser µC, den ganzen Thread über und du kannst keine Spec mit normalen Consumer µC, die das können, liefern. Gegen Strahlung gehärtete Spezialhochpreis CPUs war nie das Thema. Es geht um Waschmaschinen und Kaffeekocher, da verbaust du keine $$$$$ CPUs, auch dann nicht, wenn du dich durch Bitflips gegen normale Hintergrundstrahlung absichern willst. Da kannst du höchstens versuchen, das Problem mit Software zu abzumildern, aber das sagte ich bereits. Nano schrieb > Dann zeig mir mal eine Spec eines Consumer µC mit Angaben zu > Wahrscheinlichkeiten von Bitkips durch natürliche Hintergrundstrahlung. > Du sagst, das steht drin, also zeig mal.
Nano schrieb: > und du kannst keine Spec mit normalen Consumer µC, die das > können, liefern. Ja. Weil die etwas kosten und unter NDA stehen, du Spinner. Verstehst du das?
Udo K. schrieb: > Natürliche Strahlung (Radon) ist in bergigen Gegenden die zweithäufigste > Ursache für Lungenkrebs... Da sollte man schon den Abstand zur ersthäufigsten Ursache nennene (Rauchen) der dürfte so bei 1:1000 liegen. Und dann sollte man auch noch klar machen, das ein langzeitaufenthalt in schlecht belüfteten Räuzmen nötig ist um sich vom Edelgas Radon Lungenkrebs zu holen. Und auf die lange liste weiterer karzinogener Stoffe hinweisen.
Ürülék schrieb: >> Natürliche Strahlung (Radon) ist in bergigen Gegenden die zweithäufigste >> Ursache für Lungenkrebs... > > Da sollte man schon den Abstand zur ersthäufigsten Ursache nennene > (Rauchen) der dürfte so bei 1:1000 liegen. Und dann sollte man auch noch > klar machen, das ein langzeitaufenthalt in schlecht belüfteten Räuzmen > nötig ist um sich vom Edelgas Radon Lungenkrebs zu holen. > Und auf die lange liste weiterer karzinogener Stoffe hinweisen. Woher hast du die Zahlen? Die sind um einen Faktor 100 daneben. Radon verursacht ca. 25% der jährlichen Strahlenbelastung. Der Anteil an den Lungenkrebstoten liegt Europaweit bei knapp 10%. In Gegenden mit Granit ist der Anteil deutlich höher als diese Durchschnittswerte. Moderne Einfamilienhäuser mit dichtem Keller sind da problematisch. Hier etwa: https://medonline.at/174043/2016/400-lungenkarzinome-durch-radon/
:
Bearbeitet durch User
Nano schrieb: > Es gibt heute µC die kosten 3 Cent pro Stück und die sind deswegen so > billig, weil ihr Flächenbedarf dank kleiner Strukturbreite so gering > ist. > Die kleine Strukturbreite macht sie dann anfällig gegen Strahlung. Hast Du dafür auch Belege? SRAM kann man überhaupt nicht vergleichen mit DRAM. Ich hab mal einem AT89C2051 >10s die VCC kurzgeschlossen, der SRAM war noch komplett erhalten. Ich wollte über den SRAM eine Kaltstart/Warmstart Erkennung programmieren, da der AT89C2051 keine Bits zur Erkennung der Resetquelle hat. Was aber kippen kann, ist Flash/EEPROM, die ersten Atmel AVRs waren dafür berüchtigt. Die kippen aber nicht durch Strahlung, sondern unausgereiftes Power-On Reset.
Udo K. schrieb: > Radon verursacht ca. 25% der jährlichen Strahlenbelastung. Der Anteil an > den Lungenkrebstoten liegt Europaweit bei knapp 10%. > In Gegenden mit Granit ist der Anteil deutlich höher als diese > Durchschnittswerte. Moderne Einfamilienhäuser mit dichtem Keller sind da > problematisch. Danke für den link, der ist ja sehr auf Wohnungen im Alpenland fokussiert. Also für Österreich stehen da 3600 Lungenkrebsfälle und davon ca. 400 Radon. Das scheint mir das Tabakrauchen völlig zu ignorieren, dem doch die überwiegenden Fälle von Lungenkrebs zugeschrieben werden?. Oder gibt es jetzt krebsfreies Rauchen? https://medonline.at/174043/2016/400-lungenkarzinome-durch-radon/ In .de dagegen gilt Rauchen als Hauptursachen dann Job. Radon wird garnicht erwähnt (obwohl es Radonbelastung (hauptsachlich im Grenzgebiet zu Tschechien) gibt). https://www.geothermie.de/fileadmin/_processed_/9/0/csm_Radonbelastung_82c5b73ff1.gif https://www.krebsgesellschaft.de/onko-internetportal/basis-informationen-krebs/krebsarten/definition/ursachen-und-risikofaktoren.html
Heinzelmännle schrieb: > In .de dagegen gilt Rauchen als Hauptursachen dann Job. Radon wird > garnicht erwähnt (obwohl es Radonbelastung (hauptsachlich im Grenzgebiet > zu Tschechien) gibt). Rauchen ist auch in Ö die Hauptursache, in D sind es im Schnitt nur halb so viele Lungenkrebstote / 1000 Einwohner auf Grund von Radon (ca. 2000 gegenüber 400 gesamt). Siehe hier: https://www.deutsche-apotheker-zeitung.de/daz-az/2005/daz-50-2005/uid-15134 Gruss, Udo
:
Bearbeitet durch User
DPA schrieb: > Wird vielleicht mal ein Pixel rot, > oder ein i zu j, aber nur selten passiert was richtig übles. Für Banken ist das doch sicher ein kritisches Thema. Da darf ja nicht einfach Geld im Nirvana verschwinden.
Die Frage ist sinnlos, da der "Consumerbereich" nicht von einem Programmierer bedient wird, der immer das Selbe tut! Zudem - was will man denn gegen einen Bitflip tun? Prüfsumme? Und was wenn da der Bitflip ist? Oder in einem Pointer? Oder im Interrupt-Register? Oder in einem anderen Register des Controllers, das ihn initialisiert? Oder im Flash? Natürlich wird hier und da mehr oder weniger Aufwand getrieben, Daten robust zu halten, aber alles hat Grenzen. Deine Kaffeemaschine ist ausgelaufen, weil die Dichtung nicht schließen konnte (Kaffeesatz, Pad nicht zentriert) oder sowas, nicht weil ein Bit geflippt ist. Was ein Blödsinn.
Stefan F. schrieb: > DPA schrieb: >> Wird vielleicht mal ein Pixel rot, >> oder ein i zu j, aber nur selten passiert was richtig übles. > > Für Banken ist das doch sicher ein kritisches Thema. Da darf ja nicht > einfach Geld im Nirvana verschwinden. Wenn du plötzlich zu viel geld hast, werden die das schon merken. Aber wenn du plötzlich zuwenig hast, musst du halt hoffen, dass sie kulant sind. Theoretisch gäbe es so zeugs wie PaxOS: https://en.m.wikipedia.org/wiki/Paxos_(computer_science) Aber ich glaube nicht, dass das in der Praxis angewendet wird. Die werden sich schon an alle möglichen Regulationen halten, zugriffe X fach absichern, zeugs abschotten, etc. Ein paar plausibilitätschecks gibt es sicher auch. Aber bitflipps werden vermut nicht komplett verhindert, sondern höchstens nachträglich irgendwann erkannt, wenn die Bilanz mal nicht mehr aufgeht, oder plötzlich eine Billionentransaktion gewesen wäre. Am Ende wird die Software auch in Banken einfach zusammengekauft werden, zertifiziert für bla bla, und es wird der selbe scheiss wie überall sonst auch gemacht werden. Aber naja, vermutlich werden die schon EEC Memory nutzen, dann wird das sicher nicht ganz so oft passieren.
Ich würde jetzt nicht von Blödsinn sprechen sondern von Abwägen der Risiken und Aufwände. Tatsächliches Szenario: Kaffeevollautomat schaltet sich nachts ein und lässt das Mahlwerk laufen bis es zum Brand kommt. So passiert. Ursache war ein Fehler in der MCU. Insofern macht es schon Sinn sich als Hersteller über mögliche Gefahren durch Fehleranalysen Gedanken zu machen und Nutzen Aufwand Kosten / Risikobereitschaft / Produkthaftung gegeneinander abzuwägen. Sicher wird man nicht jedes Bit absichern, aber z.B. eine Laufzeitkontrolle ist nicht sehr komplex und machbar.
R9D9 schrieb: > Kaffeevollautomat schaltet sich nachts ein und lässt das Mahlwerk laufen > bis es zum Brand kommt. So passiert. Ursache war ein Fehler in der MCU. Und das konnte der Sachverständige an dem verbrannten Plastikklumpen herausfinden? > z.B. eine Laufzeitkontrolle ist nicht sehr komplex und machbar. Und die läuft dann auch auf dem fehlerhaften µC?
:
Bearbeitet durch Moderator
Das Beispiel ist schlecht gewählt. Bei einer Waschmaschine ist "Tür offen" ein wesentliches Sicherheitsmerkmal und muss wie ein Not-Aus behandelt (also kontinuierlich geprüft) werden. Stell' dir vor, der gelangweilte Steppke findet die Tür-auf Taste und greift im Schleudergang in die Trommel...
Peter D. schrieb: > Nano schrieb: >> Es gibt heute µC die kosten 3 Cent pro Stück und die sind deswegen so >> billig, weil ihr Flächenbedarf dank kleiner Strukturbreite so gering >> ist. >> Die kleine Strukturbreite macht sie dann anfällig gegen Strahlung. > > Hast Du dafür auch Belege? Beleg für den Preis: https://www.youtube.com/watch?v=VYhAGnsnO7w Der Rest ergibt sich aus Logik, denn auch China kocht nur mit Wasser. Die Energiekosten sind gegenüber den USA mit 0,091 Dollar nur geringfügig niedriger. https://www.globalpetrolprices.com/electricity_prices/ Die Arbeitskräfte sind zwar günstiger, aber in einer hochautomatisierten Fabrik fallen die bei den Stückzahlen nicht ins Gewicht. Ein Teil der Kosten besteht bei westlichen µC noch aus Geistiges Eigentum (Intellectual property (IP)), da muss China natürlich nichts zahlen, wenn die ein eigenes Chipdesign haben, wie in diesem Fall. Diese Kosten kann man somit rausrechnen. Aber wenn man den Preis auf 3 Cent drücken und dabei noch Gewinn machen will, während das eigene CPU Design erst einmal Akzeptanz aufbauen muss, dann kann man den Preis nur noch durch eine kostengünstigere Fertigung drücken und das geht dann halt nur noch durch einen Die Shrink, möglichst kleine Strukturbreiten und somit einen geringen Chipflächenbedarf, denn das Silizium kostet und je mehr µC man auf einen Waver bei gleich gutem Yield (Ausbeute) drauf bekommt, desto günstiger kann man die anbieten. Und das mit der Anfälligkeit bei kleineren Strukturbreiten ist allgemein bekannt. Moderne CPUs werden in der Weltraumfahrt aus diesem Grund gemieden. > SRAM kann man überhaupt nicht vergleichen mit DRAM. Der 1st Level Cache im 486 besteht nicht aus DRAM. Das ist ein ganz normaler aus Transistoren aufgebauter Speicher, wie es auch bei SRAM der Fall ist: https://de.wikipedia.org/wiki/Static_random-access_memory#/media/Datei:6t-SRAM-cell.png Und aus dem weiter oben verlinkten NASA Paper bezüglich dem 486er kannst du somit belegt ableiten, dass SRAM anfällig gegenüber Strahlung ist.
Mokli schrieb: > Zudem - was will > man denn gegen einen Bitflip tun? Prüfsumme? Und was wenn da der Bitflip > ist? Nicht einfach nur eine Prüfsumme, sondern Fehlererkennung und Fehlerkorrektur. Siehe hier, da ist ein Beispiel: https://de.wikipedia.org/wiki/Hamming-Abstand#Anwendungsbeispiel > Oder in einem Pointer? Oder im Interrupt-Register? Oder in einem > anderen Register des Controllers, das ihn initialisiert? In dem Fall hast du verloren. Da brauchst du dann mindestens 3 CPU Kerne, die das gleiche rechnen und durch Mehrheitsentscheid die CPU mit der fehlerhaften Berechnung ausklammern und gegebenenfalls die falsch rechnende CPU neu starten, falls die sich im Code verrannt hat. Mit 4 CPU Kernen verbesserst du dann die Robustheit gegen Fehler. > Natürlich wird hier und da mehr oder weniger Aufwand getrieben, Daten > robust zu halten, aber alles hat Grenzen. Deine Kaffeemaschine ist > ausgelaufen, weil die Dichtung nicht schließen konnte (Kaffeesatz, Pad > nicht zentriert) oder sowas, nicht weil ein Bit geflippt ist. Was ein > Blödsinn. Das mit der Kaffeemaschine ist ein mögliches Beispiel zur Veranschaulichung und ob da tatsächlich ein Bit geflippt ist, weiß ich nicht, das habe ich auch nicht behauptet, dass es so war, aber man kann es nicht ausschließen. Denn überlege doch mal. Wenn einen Sensor hast, der dir den Zustand ob Deckel geschlossen oder nicht geschlossen an den µC sendet und der das in einem Statusbit speichert und dann, nachdem du den Knopf "Kaffee machen" gedrückt hast, der µC dann das Statusbit überprüft, dann muss er sich darauf verlassen können, dass es korrekt ist. Sollte davor aber ein Bitflip stattgefunden haben, dann läuft das Wasser eben an der falsche Stelle raus.
DPA schrieb: > Stefan F. schrieb: >> DPA schrieb: >>> Wird vielleicht mal ein Pixel rot, >>> oder ein i zu j, aber nur selten passiert was richtig übles. >> >> Für Banken ist das doch sicher ein kritisches Thema. Da darf ja nicht >> einfach Geld im Nirvana verschwinden. > > ... Die > werden sich schon an alle möglichen Regulationen halten, zugriffe X fach > absichern, zeugs abschotten, etc. Ein paar plausibilitätschecks gibt es > sicher auch. Aber bitflipps werden vermut nicht komplett verhindert, > sondern höchstens nachträglich irgendwann erkannt, wenn die Bilanz mal > nicht mehr aufgeht, oder plötzlich eine Billionentransaktion gewesen > wäre. >.. > Aber naja, vermutlich werden die schon EEC Memory nutzen, dann wird das > sicher nicht ganz so oft passieren. Davon kann man ausgehen, dass die ECC RAM nutzen. Damit wird ein Großteil der möglichen Risiken, fehlerhafte Daten und fehlerhafter Code, der im RAM liegt, erkannt und gegebenenfalls korrigiert. Kann er nicht korrigiert werden, dann ist die Transaktion nicht atomic. Bleiben also noch die Register in den CPUs und deren Cache ein Risiko. Keine Ahnung, ob CPUs in ihrem Cache heutzutage auch ECC nutzen. Da helfen dann wirklich nur mehrere CPU Kerne.
Markus F. schrieb: > Das Beispiel ist schlecht gewählt. > > Bei einer Waschmaschine ist "Tür offen" ein wesentliches > Sicherheitsmerkmal und muss wie ein Not-Aus behandelt (also > kontinuierlich geprüft) werden. Stell' dir vor, der gelangweilte Steppke > findet die Tür-auf Taste und greift im Schleudergang in die Trommel... Du hast natürlich recht. Wer bessere Beispiele oder sogar reale Ereignisse hat, kann die aber gerne nennen.
Nano schrieb: ... > In dem Fall hast du verloren. Da brauchst du dann mindestens 3 CPU > Kerne, die das gleiche rechnen und durch Mehrheitsentscheid die CPU mit > der fehlerhaften Berechnung ausklammern und gegebenenfalls die falsch > rechnende CPU neu starten, falls die sich im Code verrannt hat. > > Mit 4 CPU Kernen verbesserst du dann die Robustheit gegen Fehler. > ... und auch das muss nicht unbedingt reichen. Ich habe (vor Jahrzehnten) an einem Satelliten-Projekt mitgearbeitet, dessen Rechnermodul aus 8 Z80-CPU-Platinen bestand, von denen sich immer zwei gegenseitig überwacht (mit Reset, wenn Diskrepanz) haben. Hat nicht viel genutzt. Nach ein paar Tagen ist der RAM langsam aber sicher nach und nach an Latch-Ups gestorben. Mehrere Jahre Entwicklungsarbeit für die Katz.
Nano:
> aber man kann es nicht ausschließen.
Der Standardspruch, wenn Leute weitere Fördergelder brauchen - kann man
so gut wie immer anbringen.
Man muß die Sache mal in Relation sehen. Dass in deinem Statuswort
durch Hintergrundstrahlung zum unpassenden Zeitpunkt ein Bit kippt ist
um viele Größenordnungen unwahrscheinlicher als dass du morgen, aus was
für Gründen auch immer, stirbst. Deine Fehlerkorrektur für dieses
Statuswort wäre dann vergleichbar mit etwas wie "Dann esse ich eben
morgen keinen Fisch - dann ersticke ich zumindest nicht an Fischgräten".
Glaub mir, dein Leben wird deutlich lebenswerter, wenn du dir darum
keine Sorgen machst ;-)
In Kaffemaschinen hat man schon gemerkt, daß Bitflips viel zu selten auftreten. Daher hat man für die Lebensdauerverkürzung Kondensatoren vorgesehen.
Markus F. schrieb: > Bei einer Waschmaschine ist "Tür offen" ein wesentliches > Sicherheitsmerkmal und muss wie ein Not-Aus behandelt (also > kontinuierlich geprüft) werden. Stell' dir vor, der gelangweilte Steppke > findet die Tür-auf Taste und greift im Schleudergang in die Trommel... Da ergibt die Gefahrenanalyse aber auch sehr schnell, dass man sowas in Hardware lösen muss. Die meisten Waschmaschinen haben an der Tür einen Kontakt, der die komplette Netzversorgung unterbricht. Auch in der Kaffeemaschine gibt es neben dem NTC für die Regelung einen elektromechanischen Übertemperaturabschalter ("Thermosicherung"), der die Stromzufuhr kappt.
Darf ich mal eine einfach Frage stellen? Wer arbeitet hier ueberhaubt als Programmierer im Consumerbereich? Gibt hier irgendjemanden der etwas programmiert das man bei Aldi oder von mir aus auch Mediamarkt kaufen kann? Ich vermute mal das sind sowieso nicht sehr viele. Da muss man sich also vermutlich keine weiteren Gedanken machen oder man sollte die Diskussion in Chinesisch fuehren. Olaf
olaf schrieb: > Wer arbeitet hier ueberhaubt als Programmierer im Consumerbereich? Meine Programme laufen im Hintergrund der Aldi Webseite (und nicht nur dort). Wenn du eine SIM Karte von Telefonica, Vodafone oder einer der zahlreichen Marken von MobileOne (=Telekom) aktivierst, benutzt du auch meine Software. Um Bitflips machen wir uns keine Gedanken, aber wir führen zahlreiche automatisierte und manuelle Checks durch, um nicht nur Hardwarefehler sondern auch Softwarefehler, Hacker-Angriffe und Betrugsversuche zu erkennen.
olaf schrieb: > Wer arbeitet hier ueberhaubt als Programmierer im Consumerbereich? > Gibt hier irgendjemanden der etwas programmiert das man bei Aldi > oder von mir aus auch Mediamarkt kaufen kann? Das ist aber eine recht einfältige Definition von "Consumer". Consumer ist alles was nicht Medizintechnik, Luftfahrt/Space, Military oder "Einzelstück Forschung" ist. Also auch Automotive. Da kannst von mir Firmware im Daimler, BMW und Audi finden.
Automotive ist eben kein Consumer, sondern Automotive. Dort hast Du AEC-Q, ASPICE und ASIL -- alles Dinge, die Consumerprojekte nicht kennen. Wer Automotive-SW schreibt, der arbeitet nach einem standardisierten (und vom Kunden auditierten) Entwicklungsprozess und prüft seinen Code nach dem V-Modell mit Tools wie Tessy, Polyspace oder Cantata. Sowas ist bei Consumerprodukten optional und fällt schnell dem Rotstift zum Opfer.
Lothar M. schrieb: > R9D9 schrieb: >> Kaffeevollautomat... > Und das konnte der Sachverständige an dem verbrannten Plastikklumpen > herausfinden? Soviel ich weiß haben die Rauchmelder angeschlagen und der Besitzer konnte schnell reagieren. >> z.B. eine Laufzeitkontrolle ist nicht sehr komplex und machbar. > Und die läuft dann auch auf dem fehlerhaften µC? Laufzeitkontrolle steuert einen externen Watchdogbaustein. Unterbricht die Versorgung zu Wärmeerzeugern und Motoren. Kein Hexenwerk. Ich behaupte allerdings nicht, dass dass überall gemacht wird. War zumindest an einem Produkt beteiligt, das so ein Mechanismus implementiert hatte. War allerdings hochpreisige Konsumer Ware und man hat Wert auf eine Risikoanalyse gelegt.
Beitrag #7283364 wurde von einem Moderator gelöscht.
Soul E. schrieb: > Automotive ist eben kein Consumer, sondern Automotive Aha. Und Kaffeemaschinen sind auch kein Consumer, sondern Brühgerätebranche.
Soul E. schrieb: > Automotive ist eben kein Consumer, sondern Automotive. Dort hast Du > AEC-Q, ASPICE und ASIL -- alles Dinge, die Consumerprojekte nicht > kennen. Nope, weil Automotive ist mehr als nur Steuergeräte. Und für Steuergeräte wurde ASPICE, ASIL und Co gemacht. Aber ein Autoradio ist nicht sicherheitsrelevant, wie viele anderen Komponenten im Auto auch. Beispielsweise Navi, Rearseatentertainment, car-Audio, Innenraumleuchten, Fensterheber, Kühlboxen, Sitzheizung, AirCon, ... halt alles was zu (Car-)Entertainment gehört. Und das wird immer mehr als weniger.
R9D9 schrieb: > Kaffeevollautomat schaltet sich nachts ein und > lässt das Mahlwerk laufen bis es zum Brand kommt. So passiert. Ursache > war ein Fehler in der MCU. Source: Trust me, bro. Wurde denn das Gamma-Photon, dass den Bitflip verursacht hat, noch rechtzeitig verhaftet?
> Und Kaffeemaschinen sind auch kein Consumer, sondern Brühgerätebranche.
Noe..Kaffemaschinen sind eindeutig Consumer. Toaster auch. Also wer
programmiert so ein Zeug?
Okay, ich kenne immerhin einen der seine Finger am Thermomix hat.
Aber klar ist ja wohl es wird nicht sehr viele geben die sowas machen.
BTW: Die Kaffeemaschine auf der Arbeit wuerde ich eher als
Industrieprodukt ansehen. Also mit WLAN, Bezahlkiste, Wasseranschluss
usw. Aber die ist auch so extrem kacke programmiert das ich mal hoffe
der Programmier ist nicht von hier. :)
Olaf
olaf schrieb: > BTW: Die Kaffeemaschine auf der Arbeit wuerde ich eher als > Industrieprodukt ansehen. Also mit WLAN, Bezahlkiste, Wasseranschluss > usw. Naja, Wlan ist eher ein Indiz für Kinderkram als Industrie. Die nimmt robuste Schnittstellen wie Profibus oder Profinet. Ein Multimeter oder eine Lötstation wird auch nicht zu "Industrie" weil es WLAN hat. Die richtige IP-Schutzklasse und Langlebigkeit ist da wichtiger als interconnectivity was nicht drinsteckt kann auch nicht "kaputt gehen".
Ich wundere mich über diesen Thread. Als ob jemand in der Entwicklung für die Waschmaschine von Whirlpool auch nur auf die Idee kommen würde sich um Hintergrundstrahlung zu sorgen... Eugenio Tarconi schrieb: > Soul E. schrieb: >> Automotive ist eben kein Consumer, sondern Automotive. Dort hast Du >> AEC-Q, ASPICE und ASIL -- alles Dinge, die Consumerprojekte nicht >> kennen. > > Nope, weil Automotive ist mehr als nur Steuergeräte. Und für > Steuergeräte wurde ASPICE, ASIL und Co gemacht. Aber ein Autoradio ist > nicht sicherheitsrelevant, wie viele anderen Komponenten im Auto auch. Trotzdem werden auch beim Autoradio zumindest ziemlich harte Belastungstests wie z.B. viele Temperaturzyklen in den Grenzbereichen (+80°C bis -40°C oder so) gefahren, Rütteltests und dergleichen. Auch da wird AEC usw. verbaut. Rütteltests bei der Waschmaschine von Whirlpool vielleicht noch, aber auch nicht für eine Lebensdauer von 10 Jahren und ganz sicher nicht diese Temperaturtests. Und die Rütteltests entfallen bei der Kaffemaschine sicherlich auch.
olaf schrieb: > Noe..Kaffemaschinen sind eindeutig Consumer. Toaster auch. Also Toaster sind für mich ganz eindeutig Brotrösterbranche. Niemals Consumer. > Aber klar ist ja wohl es wird nicht sehr viele geben die sowas machen. Genau. Das programmiert sich alles von selbst. > Aber die ist auch so extrem kacke programmiert das ich mal hoffe > der Programmier ist nicht von hier. :) Das ist leider nicht lustig, sondern rassistisch. Denke mal darüber nach.
foobar schrieb: > Nano: >> aber man kann es nicht ausschließen. > > Der Standardspruch, wenn Leute weitere Fördergelder brauchen - kann man > so gut wie immer anbringen. > > Man muß die Sache mal in Relation sehen. Dass in deinem Statuswort > durch Hintergrundstrahlung zum unpassenden Zeitpunkt ein Bit kippt ist > um viele Größenordnungen unwahrscheinlicher als dass du morgen, aus was > für Gründen auch immer, stirbst. Deine Fehlerkorrektur für dieses > Statuswort wäre dann vergleichbar mit etwas wie "Dann esse ich eben > morgen keinen Fisch - dann ersticke ich zumindest nicht an Fischgräten". > Glaub mir, dein Leben wird deutlich lebenswerter, wenn du dir darum > keine Sorgen machst ;-) Das mag schon sein. Aber so manches Consumergerät wird in Mio Stückzahlen gefertigt. Und irgendeinen Kunden kann es dann schon geben, den es dann trifft.
Nano schrieb: > Das mag schon sein. Aber so manches Consumergerät wird in Mio > Stückzahlen gefertigt. Und irgendeinen Kunden kann es dann schon geben, > den es dann trifft. Consumergeräte sind ausgelegt auf eine Lebensdauer von 24 Monaten. In dieser Zeit soll die Elektronik nicht verrecken und die SW soll nicht durch Bugs auf sich aufmerksam machen. Der genaue Ausfallzeitpunkt ist normalverteilt, Du hast also eine Gausskurve, deren steiler Anstieg irgendwann nach der Garantiezeit beginnt. Es gibt aber immer ein paar Frühausfälle, die während der nominellen Lebensdauer auftreten Du kannst das Produkt robuster machen. Bauteile mit mehr Reserven verwenden, mehr SW-Tests machen, die Produktion strenger kontrollieren. Das erhöht die Herstellkosten und reduziert den Profit. Du kannst das Produkt auch billiger machen und Ausfälle in Kauf nehmen. Wenn das Ding kaputt geht, bekommt der Kunde ein neues und freut sich über die kulante Abwicklung. Das erhöht ebenfalls die Herstellkosten, aber vielleicht nicht so sehr wie der klassische Ansatz weiter oben. Um das profitable Optimum zu ermitteln, gibt es Controller. Nicht Mikro-, sondern Finanzcontroller. Die rechnen Dir genau aus, welche Qualität Du produzieren musst, um den Gewinn zu maximieren. Die Journaille schwätzt von "geplanter Obsoleszenz", eigentlich ist es aber nur das Ergebnis eines Optimierungsprozesses. So billig wie möglich, so gut wie nötig. Das gilt für Softwareentwicklung genauso wie für die Hardware. Bei Automotive hast Du acht Jahre Lebensdauer. Bei Luftfahrt 20 Jahre. Das wirkt sich auf die Arbeitsweise aus.
Angehängte Dateien:
-
bitkipper.jpg
190 KB
Soul E. schrieb: > Um das profitable Optimum zu ermitteln, gibt es Controller. Nicht > Mikro-, sondern Finanzcontroller. Haben die auch ab und zu Bitkipper?
Soul E. schrieb: > Bei Automotive hast Du acht Jahre Lebensdauer. Bei Luftfahrt 20 Jahre. > Das wirkt sich auf die Arbeitsweise aus. Bei Automotive und Luftfahrt hat man Todesfälle, wenn man gewisse Sicherheiten und Maßnahmen weglässt.
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.