Ich habe inzwischen zweimal einen Crash in der Elektronik des Funk-UhrzeitDatum-Moduls in meinem Auto erlebt.
Bei eingeschalteter Zündung und in der Tiefgarage funktioniert der Funk grundsätzlich nicht.
Ich hatte das Auto in der Tiefgarage mit korrekten Daten abgestellt. Zwei Tage später waren Uhrzeit+Datum komplett verstellt und der Tageskilometerzähler stand auf 0. Das Funksymbol war nun abgeschaltet.
Heute habe ich das Auto zum Einkaufen mitten auf einem großen Parkplatz abgestellt. Danach waren Uhrzeit+Datum per Funk wieder korrekt eingestellt. Das Funksymbol war wieder sichtbar. Der ursprüngliche Wert des Tageskilometerzählers blieb natürlich verloren.
Vor ungefähr 10 Jahren hatte ich schon mal solch ein Ereignis.
Ich kann mir das nur durch Digital-Crash wegen metastabiler Zustände erklären.
Nein. Das sind zu 99,9% einfach nur Softwarefehler.
Unabhängig davon, muss man sich seit der Erkundung der Quantenmechanik - also vor der Ausbreitung der Elektronik - durchaus darüber im Klaren sein, dass der ganze Kram sowieso nur /wahrscheinlich/ funktioniert. Das ist einfach eine /Auslegungssache./
Mache ich die magnetischen Domänen auf der Festplatte so groß, dass sie mit einer Wahrscheinlichkeit von 10^-5 oder 10^-6 in unter typischen Bedingungen thermodynamisch instabil sind? Drücke ich die effektive Blockfehlerrate durch hinzufügen von redundanten Informationen (ECC) auf
10^-15 oder 10^-16? Kann ich unkorrigierbare Fehler mit 10^-20 nicht erkennen oder noch weniger?
Welche Fehlerrate akzeptiere ich bei der Speicherung von Ladung in DRAM-Zellen? Wie hoch lege ich die Tunnelbarriere aus? Reduziere ich den Kalium-Gehalt im Package, damit weniger Fehler durch K-40 Strahlung entstehen? Nutze ich auch da Fehlerkorrektur (ECC) oder mache ich ein PAL-Feld draus? Ähnliches gilt für die Floating-Gates von EProms und Flash-RAM/SSD.
Auf welche Fehlerrate lege ich die Signalpegel und Symbolraten auf dem SATA-Port, dem PCI-Bus oder einer anderen Übertragungstrecke aus? Welche Fehlerkorrekturmechanismen sehe ich vor? FEC? Fehlererkennung mit Datenpuffer und Retry?
Das kann man jetzt beliebig weiter spinnen bis runter auf jeden der Mrd. Transistoren in den Chips.
Metastabilität ist da nur eine kleine Facette, die auch nicht an beliebigen Stellen auftreten kann, oder zumindest nur auf irrelevant kleinen Zeitspannen. So ist z.B. der intermediäre Zustand einer SRAM-Zelle instabil und würde sofort in einen der digitalen Zustände zerfallen. Die gespeicherte Information ist dann natürlich weg und durch Zufall (Rauschen) ersetzt.
Am Ende ist es wie bei Schrödingers Katze. Ob es geklappt hat oder nicht, erfahre ich erst hinterher. Und in wie weit ich eine Abweichung von erwarteten Ergebnis bemerke, steht nochmal auf einem anderen Blatt. Und falls ja, ist auch noch nicht gesagt, ob ich den Vorgang wiederholen kann. Das setzt eine Redundanz voraus.
Alles in allem dominieren Softwarefehler aber die makroskopischen Fehlerraten bei weitem. Hier sorgen z.B. Race-Conditions dafür dass Ergebnisse nicht mehr deterministisch sind. Ich habe noch keinen Quellcode eines größeren Softwareprojektes gesehen, der nicht nach eingehender statischer Analyse Race-Conditions enthält. Wenn die Software gut ist, mag die Fehlerwahrscheinlichkeit dadurch so gering sein, dass es in diesem Universum wahrscheinlich nicht auftritt, aber sie sind zumindest latent vorhanden. Durch Änderungen an äußeren Rahmenbedingungen wie z.B. Virtualisierung oder einfach schnellere Hardware können sich solchen Wahrscheinlichkeiten aber um etliche Zehnerpotenzen verschieben. Dadurch kann auch nach langer Zeit so eine Leiche aus dem Keller hochkommen. Ich hatte mal einen Fall, wo eine Softwarekomponente eines Hochverfügbarkeits-Systems über 20 Jahre störungsfrei gelaufen ist. Und dann hat man durch Umstellung eines Unternehmensprozesses das Zugriffsmuster geändert, und der Fehler (nachweislich Data-Race) lies sich mit nahezu 100% binnen Millisekunden reproduzieren. Es wurden binär exakt dieselben Daten wie früher übertragen. Es war gar nicht so einfach, um den elementaren Fehler in der Software, deren Quellcode nach der Zeit verloren gegangen war, herumzuprogrammieren. Einer Nachteil sehr zuverlässiger Systeme ist, dass sich im Fehlerfall keiner mehr damit auskennt.
Ein anderes typisches Szenario für Softwarefehler sind State-Machines, die sich bei bestimmten Statusübergängen einfach falsch verhalten. Das sind ganz klassische, deterministische Fehler. Der Verlust des Tageskilometerzählers riecht schwer nach einem solchen Fehler. Man hat den Fall einer inkorrekten Uhrzeit einfach nicht bedacht.
Auch Softwarequalität ist natürlich Auslegungssache. Man kann Fehler zwar nicht ausschließen, aber durch Maßnahmen durchaus reduzieren. Nur ist es uns das Wert? Der Trend geht gerade im Bereich von Consumerware eher dahin, dass Software, wenn sie mit mäßigen Abstürzen läuft, fertig ist. Und in einem halben Jahr interessiert es den Hersteller auch nicht mehr, weil längst das Nachfolgeprodukt auf dem Markt ist.
Hier würde ich sogar noch einen drauf setzen: In der Realität erfährt man in einigermaßen vielen Fällen, wenn etwas schiefgegangen ist. Nicht in jedem Fall, denn in ebenfalls einigermaßen vielen Fällen wird Fehlermechanismus A durch eine Kombination weiterer Variablen (tatsächliche Daten, weitere Fehlermechanismen, pures Glück und so weiter) maskiert, so daß er in der Anwendung nicht wirksam wird.
Und wenn er mal bemerkt wird, dann kann man in der Regel hinterher nicht mehr ermitteln, WELCHER Fehlermechanismus denn da gerade verantwortlich gewesen ist. Um das zu ermitteln, muß man den Fehler bewusst provozieren und an den richigen Stellen schauen. Haken an der Sache: Versuche mal einen Fehlermechanismus bewusst zu provozieren, den Du nicht kennst...
[noch mehr richtiges über Software und Race Conditions gsnippt]
Und wenn man so will, ist die von Helmut angesprochene Metastabilität auch nix anderes als eine Race Condition, nur diesmal in Hardware. In getakteten Systemen in der Regel ein ungünstiges Zeitverhältnis zwischen Takt- und Datenflanke. Und genau wie die Race Conditions in Software nur schwer zu diagnostizieren. Im Unterschied zur Softwarevariante aber tatsächlich sehr selten - und dann auch regelmäßig ziemlich unerwartet ;-)
Es handelt sich um einen Funkmodul in einem Oberklasse-Audi (im Hauptinstrument). Kosten des Moduls für den Kunden etwa 50 EUR.
Ich glaube eher nicht, daß dieses Modul überhaupt Software enthält. Jedenfalls keine, die der Hersteller in jedes Modul einprogrammiert.
Ich hatte Software als Fehlerquelle ausgeschlossen, da der Fehler im Abstand von etwa 10 Jahren in der Tiefgarage nur zweimal vorkam. Wobei komplett konstante Verhältnisse in jeder Hinsicht vorlagen!
Das Funkmodul ist optional! Dieses hat mit dem Tageskilometerzähler nichts zu tun.
Software im weiteren Sinn kann natürlich nicht als Fehlerquelle absolut ausgeschlossen werden.
Selbst wenn das Funkmodul softwarefrei sein sollte, so ist es das Hauptinstrument mit dem Tageskilometerzähler ziemlich sicher nicht. Selbst wenn mich in einem Oberklassefahrzeug wundern würde, wenn ein Funkuhrmodul die einzige Zeitquelle wäre: Empfangsbedingungen in Tiefgaragen sind notorisch schlecht. Daß da unterschiedliche Quellen unterschiedliche (oder garkeine) Daten liefern, würde ich eher als Regelfall denn als Ausnahme ansehen. Ganz abgesehen von der eher philosophischen Frage, aus welchem Grund irgendein Instrument auf irgendwelche fehlenden oder fehlerhaften Daten ÜBERHAUPT reagieren sollte, wenn die Karre doch abgestellt ist. Es sei denn, der Fehler wäre während des Betriebes in der Tiefgarage aufgetreten, was leider nicht ohne weiteres aus den vorliegenden Informationen ersichtlich ist.
Genauso wenig, wie ersichtlich ist, welche Rolle das Funkmodul da überhaupt spielen sollte, wenn es nicht mit dem Tageskilometerzähler kommuniziert.
Aus dem Bauch heraus halte ich semi-externe Einflüsse (elektronisch probierende Langfinger, auf Batteriekontakte urinierende Marder, was auch immer) für wahrscheinlichere Ursachen.
Richtig, aber das Hauptinstrument wird nicht das Funkmodul sabotieren. Solche Konzept-Annahmen sind unsinnig. Das Funkmodul wird technisch-logisch außer Spannungsversorgung gar keinen Eingang haben, sondern nur an seinem Ausgang Uhrzeit+Datum bereitstellen und eventuell seinen Status.
Ich schrieb, daß in der Tiefgarage kein Empfang möglich ist.
Eben. Das Modul wird bei eingeschaltetem Funksymbol nachts ein- oder zweimal pauschal versuchen, Kontakt zu DCF77 aufzunehmen. Wenn das drei Nächte lang nicht gelingt, wird das Funksymbol abgeschaltet (Quarzbetrieb). Bei abgeschaltetem Funksymbol wird das Modul _sofort_ nach Abstellen des Autos versuchen, Kontakt zu DCF77 herzustellen.
Natürlich ist der Fehler während des Abgestelltzustands in der Tiefgarage aufgetreten. Ich schrieb oben, daß ich zwei Tage nach dem Abstellen den Fehler sofort sah. Direkt vor dem Abstellen seien alle Daten in Ordnung gewesen.
Warum sollte das _optionale_ Funkmodul kommunizieren? Technisch-logisch ist, daß das Hauptinstrument der große Manager ist. Das muß wissen, ob es Daten vom Funkmodul oder von der Quarzuhr liest.
Ich dachte spontan, als ich den Fehler sah: "Hat da jemand einen Hochenergieimpuls geschossen?" Die Batterie wurde vor wenigen Monaten gewechselt. Der Motor springt in 0,5..1 s an, nach mehreren Tagen Standzeit. Die Batteriekontakte müssen folglich makellos sein.
Da hab' ich wohl mehr (und gleichzeitig weniger) gelesen als tatsächlich geschrieben war. Ich vermutete, Du wärest der Ansicht gewesen, das Funkuhrmodul wäre ursächlich verantwortlich für die Verwirrung und die verstellte Zeit nicht nur ein Symptom. Auch nach Jahrzehnten im Usenet braucht das verstehende Lesen manchmal Nachhilfe ;-)
Abgesehen davon: Wie genau die Kommunikation zwischen Funkuhrmodul und Hauptinstrument gestaltet ist, entzieht sich wohl unserer Kenntnis. Im Prinzip gibt es ja nur zwei Möglichkeiten: a) Das Hauptmodul fragt aktiv "Wie spät ist es gerade?", oder b) Das Funkmodul blökt ungefragt in die Gegend "Es ist gerade der 17. Februar 2021 9:23 Uhr". Was das Hauptmodul dann wiederum mit der Information macht, ist dann eine zweite Frage, was aber beides nicht direkt für die Beantwortung deiner eigentlichen Frage, ob Metastabilität hier eine Rolle spielen könnte, hilfreich ist.
Die Kontakte selber können sicher gut sein, worauf ich hinauswollte: Transienten sowohl positiver als auch negativer Polarität sind grundsätzlich in der Lage, real erhältliche Digitalschaltungen in Zustände zu bringen, die eigentlich nicht vorgesehen sind. Ob das jetzt Spannungseinbrüche (oder -spitzen) sind, weil es (kurzfristig und reversibel) Leckstrompfade gibt, oder weil jemand 'nen Schraubenschlüssel auf die Bateriekontakte geworfen hat, oder warum auch sonst, ist dann für die Auswirkungen fast egal. Es wäre durchaus auch denkbar, daß hier nicht die dicke Starterbatterie betroffen ist, sondern möglicherweise eine Stützbatterie in Funkmodul oder Hauptinstrument, ähnlich der BIOS-Batterie in Computern.
Und wenn ich den Erzählungen meines Nachbarn (KFZ-Mechaniker...) Glauben schenken kann, dann gibt es gerade in Oberlasselimousinen namhafter deutscher Premiumhersteller die absurdesten Funktionsstörungen, wenn die Informationsbröckchen aus verschiedenen Steuerteilen, die auf den ersten Blick garnix mit der fraglichen Funktion zu tun haben, nicht zusammenpassen. So Dinge der Art, daß in manchen Modelljahren bei Hersteller X die Zentralverrigelung der Hecklappe nicht geht, wenn die Steuerteile der hinteren Leuchten unterschiedliche Gesamtkilometerstände gespeichert haben. Oder so ähnlich, jedenfalls ziehen sich solche abstrusen Zusammenhänge durch das gesamte deutsche Premiumsegment.
Insofern finde ich es überhaupt nicht verwunderlich, daß augenscheinlich vollkommen separate Daten wie der Tageskilometerstand flöten gehen, wenn zwei Zeitquellen unterschiedliche Werte liefern. Daß soetwas Zweifel an der Gründlichkeit der Entwicklung sät, ist ein andere Sache.
Um das Ganze nochmal zusammenzufassen: Metastabilität als Ursache würde ich erst dann überhaupt in Erwägung ziehen, wenn alle anderen Möglichkeiten ausgeschlossen sind, weil sie einfach erheblich wahrscheinlicher sind. Und auch die Aussage "das hat doch garnix damit zu tun" taugt augenscheinlich nicht dazu, unerwartete Zustände in anderen Teilsystemen als Ursache auszuschließen, sondern liefert vielmehr eher eine Steilvorlage für die Annahme, daß die beobachtete Merkwürdigkeit ihren Ursprung in Softwarefehlern hat.
Angenommen, das Funkmodul würde uninitialisiert ein Datum zurückliefern, das mer oder weniger weit in der Vergangenheit liegt. Das ist nicht unüblich, zahlreiche GPS-Module beispielsweise handhaben bei einem Neustart den 1024-Wochen-Rollover im GPS-Epochendatum derart, daß sie annehmen, das aktuelle Datum sei in einem 1024-Wochen-Fenster seit einem bestimmten fixen Datum (oftmals Compile-Datum der aktuellen Firmware) anzusiedeln. Entsprechend alte Module liefern also heute nach einem Neustart ein Datum irgendwann in den 90gern des vergangenen Jahrtausends. Bei einem entsprechend alten DCF-Modul müsste man damit rechnen, daß das angezeigte Datum im vergangenen Jahrhundert liegt. Immerhin zeigt der Tageskilometerzähler eine Null, und nicht irgendeinen anderen absurden Wert. Mich würden in einem solchen Fall auch negative Zahlen nicht wirklich wundern, also hat da zumindest ein bischen Plausibilitätsprüfung stattgefunden...
Mit dem Impuls hast du vielleicht gar nicht so verkehrt gedacht...
Vielleicht war ein Auto mit Funkanlage (CB-Funker mit Brenner, Amateurfunkstation, BOS-Funk ... etc.) in der Tiefgarage und hat mit hochfrequenter Power irgendetwas an deinem Fahrzeug durch unmittelbare Nähe bewirkt, was sonst im Normalfalle nicht passiert.
Eine Anekdote aus meiner Erinnerung hier mal am Rande: Vor vielen Jahren war mal in einer Zeitschrift zu lesen, dass ein Autobesitzer (Neuwagen) ein ärgerliches Problem hatte. Sonntags nach der Predigt wollte sein Auto, vor der Kirche geparkt, nicht mehr anspringen, oder es lies sich nicht mehr öffnen. Als der Pannenhelfer eintraf, lief die Karre wieder. Auch die nächsten Tage war alles in Ordnung. ...bis zum nächsten Sonntag nach der Kirche. ...verflucht! :-D
Wieder Fehlersuche... und xx Minuten später lief das Auto plötzlich wieder. Durch Zufall ist die Lösung des Problems irgendwie bekannt geworden.
In der Nähe der Kirche wohnte ein Funkamateur, der Sonntag vormittags immer den aktuellen Rundspruch verlesen/gesendet hat. Da war der Sender der Funkstation über längere Zeit mit höherer Leistung ununterbrochen in Betrieb, und das genau zu dem Zeitpunkt, wo der kirchliche Neuwagenbesitzer dort wegfahren wollte. Die Aussendungen der technisch einwandfrei funktionierenden Funkstelle hatte (WIMRE) die Deaktivierung der Wegfahrsperre oder das Öffnen des Wagens über Funkschlüssel verhindert.
Es gab/gibt wohl Automarken, die für solche Schaltvorgänge billigste Funktechnik im relativ unsicheren Frequenzbereich um 433MHz nutzen. Unsicher deshalb, weil dieser Bereich innerhalb des 70cm Amateurfunk- bandes (430-440MHz) liegt. Der Amateurfunk ist in dem Bereich Primärnutzer mit Vorrecht, so dass es dort für andere Anwendungen zu Störungen kommen kann.
Mit an Sicherheit ist da Software drin. Wie sollte es denn sonst über den Bus ansprechbar sein? Und eine klassische ZF baut heute auch keiner mehr. Das ist üblicherweise alles Software Defined Radio.
Wer sagt, dass Softwarefehler jeden Tag auftreten müssen.Die Zeiten, wo sich Software deterministisch verhalten hat, sind schon sehr lange vorbei. Das ist allenfalls noch chaotisch deterministisch, also Schmetterlingseffekt. Und wie ich dargelegt habe, ist selbst das nicht zu 100% gesichert.
Ach! Alle Sensoren im Auto haben den Bus immer exakt mit denselben Daten versorgt? Die Temperatur war immer gleich? Die Uhrzeit war immer gleich? Die empfangenen Funksignale waren immer gleich? Alle Alle Quarze der einzelnen Komponenten liefen immer auf exakt derselben Frequenz?
Die hängen alle am selben Bus. Die Uhrzeit steuert alle zusammen. Zappelt sie, glaubt der Tageskilometerzähler als Folgefehler an einen Tageswechsel.
In der Tat. Ich würde darauf tippen, dass der Fall "Tiefgarage, kein Empfang" einfach nicht sauber getestet ist. Mglw. hat er auch doch noch ein wenig Empfang gehabt, und den Fehler nicht erkannt (die Ursache) und den Müll den er empfangen hat, als (falsche) Uhrzeit interpretiert. Auch Prüfsummen können falsch positiv sein, üblicherweise selten, aber das würde ja passen.
Innerhalb des Hauptinstruments gibt es keinen CAN-Bus, jedenfalls nicht mit dem Funkmodul. Das Funkmodul ist folglich kein CAN-Gerät. Ohne Funkmodul oder ohne Empfang werden die Daten von einer Quarzuhr bezogen.
Du willst also 'pro Tag' oder 'pro Dekade' nahelegen. Ich sagte nichts von 'jeden Tag'. Aber häufiger als pro Dekade sollte ein Ereignis schon vorkommen, um Software als Verursacher als wahrscheinlich(er) anzusehen.
Ich meine damit das Umfeld des Autos. Denn das Auto war ja abgestellt! Neben Uhr+Datum und Einbruchalarm dürfte da nichts in Betrieb sein. Funkempfang gibt es nicht in der Tiefgarage, wie ich mehrfach schrieb.
Der Tageskilometerzähler ist vollkommen unabhängig vom Funkmodul, der ja optional ist (schrieb ich). Und er hat nichts mit einem Tageswechsel zu tun, obwohl er Tageskilometerzähler heißt. Er addiert bis zu 9999 km auf, über einen beliebigen Zeitraum hinweg.
Das Funkmodul im Hauptinstrument dürfte kein CAN-Gerät sein. Der CAN-Bus ist für bis zu 500 m gemacht und arbeitet mit Differenzsignal.
Das ist ziemlich weit hergeholt. Mein Auto steht seit 2012 in dieser Tiefgarage. Empfang gab es niemals! Die Tiefgarage hat halbmeterdicken Stahlbeton - sie ist abgeschirmt. Empfang fehlt sogar oft außerhalb von Gebäuden, wenn das Auto sich in geringer Entfernung zu einem Gebäude befindet - man braucht eine weite, offene Fläche.
Ich hab hier einen billigen DCF77 Wecker im Bad an einer offenbar grenzwertigen Stelle. Manchmal zeigt er eine falsche Uhrzeit an... 10 oder 15 Minuten Offset, manchmal auch ein paar Stunden. Am nächsten Tag ist es dann wieder ok. Ein bauähnliches Gerät zeigt an dieser Stelle das gleiche Verhalten.
Was war ich froh, dass mein grosser Audi damals eine simple analoge Uhr hatte. So richtig mit Zeigern, die funktionierte auch in Tiefgaragen :-)
Mindestens wird es Firmware enthalten. Pott wie Deckel.
Das heisst nichts, Zulieferer koennen genauso Fehler machen.
Wie kommen die Daten von der Quarzuhr oder in Deinem Fall bei Empfang vom Modul an die Stelle, die diese Daten beziehen moechte?
Warum das denn? Denk mal zurueck an den Y2K ehler. Der konnte nur einmal in 100 Jahren vorkommen, tat das dann auch und hat Schaden angerichtet.
formatting link
Zitat "Millions of unusable German bank cards had to be replaced"
Da waere ich mir bei modernen Autos nicht so sicher. Ein Nachbar hatte im Anflug uebermaessiger Vorsichtigkeit vor dem Urlaub die Batterie seines Porsche abgeklemmt. Danach wollte der Porsche nicht mehr. Der Abschleppdienst musste anruecken. Viele hundert Dollars spaeter lief er wieder und die Werkstatt erklaerte dem Nachbarn, sowas nie mehr zu tun.
"Beliebig" ist in der modernen Fahrzeugelektronik ein haariges Wort ...
Nun schriebst Du aber, dass die Urhzeit wetergegeben wird. Ueber welchen Bus geschieht das?
Manchmal tauchen Software-Probleme nur ganz selten auf. Laut Murphy's Gesetz immer kurz vor Weihnachten oder Freitag abends.
Beispiel Tiefgarage: Es kurze sporadische Bursts von Funkempfang geben. Ich wohne sehr weit von unserem Zeitzeichensender entfernt. Bei uns ist es WWVB auf 60kHz, er ist aehnlich Eurem DCF77. Unsere Funkuhren synchronisieren wegen ansonsten schwachem Signal nur weit nach Mitternacht, also dann, wenn Du mit hoher Sicherheit nicht mehr im Auto bist, sondern im Bett.
Falls das dann sehr fehlerbehaftete dekodierte Signal suboptimal ausgewertet wird, kann es ganz seltene Faelle von Fehlverhalten geben. Die Zeitanzeige loeschen sollten Funkuhren nicht, das zeugt von einem nicht sehr gelungenen Design und Audi waere anzuraten, den Zulieferer mal in den Burggraben zu tunken. Im Mittelater hat sowas geholfen :-)
Für meine Uhr gilt das ebenfalls. Die Daten kommen bei Empfang vom Funkmodul, andernfalls vom Quarzmodul.
Ich glaube nicht, daß da Software drin ist, die überhaupt einprogrammiert werden muß. Da wird ein Schaltwerk enthalten sein.
Weder Quarzmodul noch Funkmodul im Hauptinstrument sind ein CAN-Gerät. Es könnte da eine serielle Schnittstelle mit nur 1 oder 2 Bit geben, z.B. I²C.
Warum sollte man eine Entfernung von ein paar cm mittels eines Feldbusses überbrücken?
Das ist nicht vergleichbar und kein Programmierfehler. Es wurde ja das Jahr absichtlich nur 2-stellig gespeichert. Manchmal auch jetzt, nach dem Jahr 2000.
Ich hatte zwei Mal einen Daten-Crash zu krummen Zeiten und krummer Differenzdauer. Das paßt nicht.
Das war bei meinem Auto auch kürzlich so. Nach Wiederherstellung der Spannung funktionierte das Auto einwandfrei. Ich mußte nur wieder die Diebstahlschutz-PIN in die Navigation+Radio+TV eingeben.
Es ist aber tatsächlich so. Ich fahre dieses Auto seit 2005.
Sicher nicht über einen Feldbus. Halt über eine geeignete, elektrisch leitende Verbindung innerhalb des Hauptinstruments.
Letzteres bei mir nie.
Funkstörungen (CB) wurden hier schon von jemandem beschrieben (Kirchenparkplatz). Auch bei DCF77 wird ein- oder zweimal nachts synchronisiert.
Ein Crash der Daten in der Anzeige alle 10 Jahre stört mich überhaupt nicht. Bei ständigem Funkempfang passiert das ohnehin nicht, sondern nur in der abgeschirmten Tiefgarage.
Kenne nur die Geschichte eines britischen Funkers, welcher gerade einen heftigen Nachbrenner im Auto installiert hatte. Auf einer Probefahrt dann Druck aufs Mikro, da gab es einen Riesenknall und die stärkste Ohrfeige aller Zeiten...
Bei mehr als 10W oder so erlischt die allgemeine Betriebserlaubnis für moderne Autos.
Ich kenne einen, der hatte einen historischen BMW 730-D genau für den Zweck. Von Glühkerze und Licht abgesehen lief da nix mit Strom. Nicht mal Zündfunken.
Aber im Kofferraum! LKW-Akkus für 48V und 1000 Watt out auf 144 MHz. Motorola homebrew. Der konnte in Berlin im Schlangenbader Tunnel die Beleuchtung töggeln.
Ein Schaltwerk kann aber keine Daten generieren oder gar uebertragen :-)
Die Bus-Architektur ist egal, auf jedem Bus kann es zu Fehlern kommen. Meist auf dem Modul, welches die Daten generiert.
Z.B. wegen Standardisierung. KFZ-Hersteller haben so hohe Stueckzahlen, dass die Kosten fuer einen an wenigen Stellen zu aufwendigen Bus nicht ins Gewicht fallen. Die anteiligen Kosten etwa fuer sonst unterschiedliche Steckverbinder (BOM Complexity) koennen hoeher sein. Das wird dort bis auf den letzten roten Heller durchgeklingelt.
Ja, und nun koennte es sein, dass in Deinem Audi etwas nur bei einer ganz bestimmten Konstellation bei Signalaufall ausrastet, die so gut wie nie vorkommt. Aber eben nur "so gut wie".
Wenn Du die Software nicht im Source Code untersucht hast, weisst Du das nicht.
Dann ist Dein Audi schonmal besser als der Porsche des Nachbarn. Da ging mehr als Diebstahlschutz und Jux-Elektronik nicht mehr.
Nun schriebst Du aber, Zitat "... und der Tageskilometerzähler stand auf 0".
Egal ob CAN oder was anderes, es ist ein Bus erforderlich und darauf (oder davor) kann es Fehlverhalten geben, und gibt es in Deinem Auto offenbar.
Ahem ... Zitat aus Deinem ersten Post "Ich habe inzwischen zweimal einen Crash in der Elektronik des Funk-UhrzeitDatum-Moduls in meinem Auto erlebt". Ich halte es fuer unwahrscheinlich, dass das ein Hardware-Problem ist. Nicht unmoeglich, aber unwahrscheinlich. Schliesslich ist ein Audi gusseiserne deutsche Wertarbeit :-)
[...]
Ja, wenn es nur den Tageskilometerzaehler oder anderes nicht "mission-critical" betrifft, wuerde mich das auch nicht gross jucken.
Merkwürdig. Ich habe die gleiche Konstellation. Was vorkommt ist, dass die Uhrzeit exakt 2 Stunden daneben angezeigt wird. Seltener eine. Aber was mit Minuten hatte ich noch nie.
(Einmal war ich verwirrt, als ich 26 Uhr 72 sah, aber da war gerade auf Temperatur/Luftfeuchte. Offenbar dusche ich zu warm.)
Ich hatte nach 11/11/2022 nun am 10.3.2023 erneut genau solch einen elektronischen Crash. (Im damaligen Thread wurde auch starker Funk (aus einem KFZ) als Möglichkeit erachtet.) Die Funkuhr hat sich dann außerhalb der Tiefgarage erneut wieder korrekt eingestellt.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.