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ß...
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?
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.
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.
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...
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.
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_SicherheitIEC60730 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.
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.
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.
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/
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.
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
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?
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 ;-)
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.
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.
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.
