DCC-Übertragung, Fehlerbetrachtung

    Revision:
     0.01 2021-04-22 kw start

Inhalt

1. Einleitung

    In der Diskussion um Normung neuer Befehle, wie z.B. RCN128, DCC-A ist jeweils eine Betrachtung der nötigen Fehlerabsicherung nötig. Hierzu ist aber eine vorherige Betrachtung der möglichen Fehler und deren Erkennbarkeit durch die Empfangstechnik wichtig. Wegen der knappen Resource Bandbreite sollte der Codeaufwand für die Fehlerabsicherung möglichst minimal gehalten werden, zugleich aber hinreichend sicher sein.
    Da Modellbahn keine Technik ist, wo eine Störung extreme Auswirkungen hat (z.B. verglichen mit einer Leittechnik für Kraftwerke), liegt die Zielvorgabe sicherlich nicht bei 10-18, sondern man wird mit deutlich kleineren Dimensionen zufrieden sein können.

    Diese Seite enthält eine Zusammenstellung häufiger Fehlerquellen und deren mögliche Modellierung, es gibt Überlegungen wie verschiedene Empfangstechniken auf die Fehlererkennung wirken und was man zur Absicherung im Befehlscode vornehmen sollte.
    Erschwerend kommt hinzu, dass die einzelnen Bits eine variable Länge haben, Fehlerquellen wirken also unterschiedlich auf 0 und 1, fehlerkorrigierende Verfahren können damit kaum umgehen: die Länge einer 0 ist ungefähr die Länge zweier 1-Bits.

2. Fehlerquellen

    Betrachtet man die Fehlerquellen auf der Modellbahn, so hat man keineswegs mit normalen, rauschartigen statistischen Einflüssen zu tun, sondern die Fehler sind oft systematisch und klassischen Fehleranalysen nicht zugänglich.
  • Stromunterbrechungen
    Das ist in der Regel bedingt durch Probleme im Rad-Schiene-Kontakt oder durch Umschaltvorgänge (z.B. bei einer Kehrschleife). Stromunterbrechungen führen bei sehr kurzen Zeitdauern zu Verlängerungen der jeweiligen Bitphase (Pegel bleibt einfach erhalten), bei längeren Unterbrechungen zu einem Absinken der Spannung am Dekoder und zu einem Abbruch/Restart des DCC-Empfangs.

    Die Zeitdauer von Stromunterbrechungen ist schwer abschätzbar, aber zwei mögliche Quellen seien hier mal betrachtet:
    • Rad-Schiene-Kontakt:
      Angenommen, eine Rad fährt über ein Haar auf dem Gleis. Das Rad wird abheben und nach dem Haar wieder aufsetzen. Wie lang dauert dieser Vorgang?
      Hierzu eine einfache Beispielrechnung: Annahmen: Das Fahrzeug fährt 0,3m/s (=100km/h, 1:87). Raddurchmesser 11mm (Radumfang: 34.6mm), ein Haar mit 0.1mm Durchmesser auf der Schiene.
      Die Winkelgeschwindigkeit des Rades ergibt sich zu: 300mm/34.6mm = 8,7 U/s; skaliert mit 360° ergibt 3120°/s.
      Das Rad hebt ab, wenn cos(phi) = 5.4/5.5 ist. Damit berechnet sich phi = arccos(5.4/5.5) = 11°; d.h. das Rad ist für 22° in der Luft.
      Mit obiger Winkelgeschwindigkeit ergibt sich damit ein Drop von 7.05ms.
      Natürlich ist nicht nur ein Rad an der Stromübertragung beteiligt, aber die möglichen Unterbrechungen dürften sich durchaus in den ms-Bereich erstrecken.
    • Umschaltvorgänge:
      Übliche Relais haben Schaltdauern (break bis make) von ca. 400us bis etwa 1ms. (diese Daten stammen aus einer Testreihe an einem Kehrschleifenmodul.)
  • Kurzschlüsse
    Diese sind bedingt z.B. durch Berühren von Herzstücken oder Entgleisungen. Dabei dürften Radwinkel im Bereich von 5° bis 15° beteiligt sein. Analog zur obigen Betrachtung ergeben sich damit Drops im Bereich von 1ms bis 3ms.
  • systematische Fehler, korreliert
    Diese konnen entstehen z.B. durch unsaubere Boosterflanken. Allerdings dürften systematische Fehler zu einer derart hohen Bitfehlerrate führen, dass ein Betrieb kaum möglich ist und sich eine Fehlerbetrachtung erübrigt.
  • systematische Fehler, nicht korreliert Das können z.B. Störung durch andere Dekoder sein, deren Motorendstufe jeweils den Pegel am Gleis zusammenbrechen lassen. Die Folge sind sehr kurze (im Bereich weniger µs liegend) Spannungseinbrüche am Gleis.

3. Empfangstechniken

    Einen wesentlichen Einfluß auf die primäre Fehlerwahrscheinlichkeit hat die Empfangstechnik. Diese läßt sich grob in folgende Techniken untergliedern:
  • Flankentriggerung:
    Hier wird eine Flanke (als Interrupt) benutzt, um zusammen mit einem Zeitglied die Bitentscheidung zu treffen. Dieses Verfahren ist extrem anfällig für Störungen und nur bei stationären Dekoder verwendbar.
  • Flankenauswertung:
    Hier wird eine Flanke (oder werden beide Flanken) vermessen und daraus die Bitentscheidung getroffen. Das Verfahren sortiert sehr gut die obigen Fehler aus, weil durch die Fehler entweder ein Bit unzulässig verlängert oder verkürzt wird. Bei Auswertung beider Flanken wird zudem auch die 'schiefe' Rückkehr des Algorithmus auf eine korrekt Folge aus Halbbits erkannt.
  • Abtastung:
    Hier wird das Signal abgetastet, je nach Auflösung des Abtasters werden Störungen erkannt und eine DCC_Nachricht verworfen. Agiert der Abtaster in recht groben Raster, wird er zunehmend empfänglicher für Störungen. Auch bei Abtastung gibt es dann noch den Unterschied der einfach oder doppelten Flankenauswertung. Im Grenzfall sehr feiner Abtastauflösung ist die Abtastung ident zur Flankenauswertung.
    • Eine dichte Erfassung des Timings hilft, obige Fehler zuverlässig zu erkennen. Wenn man zudem beim Empfang die Möglichkeit zum Verwenden längerer 0-Bits ausklammert (sog. Zerostretching zur Unterstützung einer parallel fahrende analogen Lok), erhält man eine zusätzliche, gute Absicherung gegen die längeren Signalunterbrechungen aus Kontaktverlust oder Kurzschluß.

4. Absicherung durch Prüfcodes

    Ausgangssituation

    Als Absicherung sind verschiedene Techniken bekannt (XOR, Additonsverfahren, CRC mit verschiedenen Polynomen, FEC), insbesondere die Funktechnik hat hier wegen der häufigen Bitfehler bei der Übertragung viele Verfahren hervorgebracht. Allerdings fokusieren sich alle bekannten Untersuchungen i.d.R. auf deutlich längere Nachrichten, als sie hier bei DCC vorliegen.
    Bei sehr kurzen Nachrichten sind XOR und CRC gleichwertig, die Vorteile der CRC (kontinuierlicher Spread von eingesammelten Bitfehler über das gesamte Prüfsummenwort) kommt noch nicht zum tragen.
    Zudem werden üblicherwiese statisch gleichverteilte Fehler angenommen, die gemäß obigen Überlegungen hier nur partiell zutreffen.

    Bei DCC gibt es zudem die (historisch bedingte) Vorgabe des XOR am Nachrichtenende, aus Kompatibilitätgründen mit vorhandenen Boostern und Dekodern und wegen der Implementierbarkeit ist das auch für neue Nachrichten empfehlenswert. Allenfalls wäre eine Kombination von CRC + XOR oder ein generelles CRC bei bestimmten Anfangsbytes denkbar.

Theoretische Überlegungen

    Wesentlich ist die Fähigkeit eines Codes, false-positive zu vermeiden. Jeder Prüfcode leistet das für Einzelfehler, interessant wird es bei Mehrfachfehlern:
  • XOR liefert dann ein false-positive, wenn zwei Bits zugleich kippen. Betrachtet man das mal für 6 Bytes, haben wir 48 Bits. Weiters nehme ich mal p für die Bitfehlerwahrscheinlichkeit an. Die Wahrscheinlichkeit für einen Doppelfehler ist dann (x aus y ist der Binomialkoeffizient):

    (1-p)46 * p2 * (2 aus 48)

    wobei sich (2 aus 48) zu 48 * 47 / 2 = 1128 ergibt. Das gilt für bitweises, serielles XOR. Macht man ein byteweises XOR, kommt dieses false-positive nur zustande, wenn jeweils die gleiche Bitposition im Byte betroffen ist. D.h. statt 47 möglichen Partnerbits zu einem Einzelfehler gibt es dann nur noch 5. Die Chance für eine false-positive verringert sich dadurch mit dem Faktor 5/47.

    Wie skaliert das mit der Bitzahl: (1-p)^Bitzahl könnte man für kleine p in eine Reihe entwickeln, der erste Anteil ist linear: p*Bitzahl. Für sehr kleine p könnte man das auch noch vernachlässigen und würde p^2 * (2 aus Bitzahl) als dominanten Einfluß haben. D.h. die Versagenshäufigkeit eines XOR geht quadratisch mit der Bitzahl hoch, bei byteweisem XOR dann noch skaliert mit (B/8-1)/(B-1).
  • Zum Vergleich eine (theoretisch optimal angenommene) CRC. Hier wird der Bitfehler statisch perfekt auf die n-Prüfbits verschmiert. Die Chance für zwei identische 'Verschmiermuster' ist dann 1/(2^crc_length), bei einer 8-Bit CRC also 1/256. D.h. statt 5/48 habe ich 1/256 als Gewinn. (Das aber nur, wenn das 'Verschmieren' bereits voll greift, d.h. wenn die CRC dann schon eine nennenswerte Zahl an shift + divide gemacht hat. Das trifft bei kurzen Sequencen aber oft nicht zu).

    • Hier dargestellt: für verschiedene Ausgangswahrscheinlichkeiten p die Wahrscheinlichkeit für das Auftreten von unerkannten Doppelfehlern. Man sieht, dass bei großer Einzelfehlerwahrscheinlichkeit XOR mit zunehmender Länge anfällig für unerkannte Doppelfehler wird, bei größerer Länge ist CRC klar die bessere Wahl.

Implementierung

    Ein beachtenswerter Aspekt ist die Implementierbarkeit einer Prüftechnik bezogen auf die möglichen Zielplattformen (Dekoder) und das erforderliche Timing:
  • XOR ist auf allen gängigen System verfügbar. Als Dekoder werden häufig 8-bit Prozessoren eingesetzt, das Vorhandensein von Hardwaresupport für eine CRC Berechnung ist dort allgemein nicht anzunehmen. Erst mit neueren ARM-Generationen (Cortex M3, M33) kommt Hardware-CRC in die Zielplattformen.
    CRC läßt sich bitweise oder tabellengestützt wortweise berechnen. Eine sehr laufzeitoptimale Lösung geht über XOR und Tabellenzugriff, erfordert aber auch eine Tabelle der Länge 2n im Speicher.
  • Das Timing ist durchaus kritisch, weil der Dekoder zuerst entscheiden muß, ob eine Nachricht korrekt empfangen wurde und dann in sehr kurzem Zeitabstand die entsprechende Quittung via Railcom senden muß. Railcomantworten werden daher oft vorberechnet und nur noch bei Prüfsumme=ok freigegeben. Die Prüfsummenberechnung muß daher bereits in der Empfangsroutine möglich sein.

Literatur

    The Effectiveness of Checksums for Embedded Networks: Diese Arbeit vergleicht XOR, CRC, und ein paar andere Fehlerprüfverfahren, beurteilt dabei Bit- und Burst-Fehler, konzentriert sich aber vor allem auf längere Sequenzen als für DCC relevant. Diese Arbeit kommt zum Schluß, dass für Systeme Burstfehlern XOR eine durchaus gute Erkennung liefert, aber bei Systemen mit statistischen Einzelfehlern dann gegen CRC deutlich abfällt.

    Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks Auswahlkritieren und Vorschläge für gute CRC-Polynome besonders unter Berücksichtigung kurzer Datenwortlängen.

    Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations, RFC3385;
    Dieses Arbeit beschäftigt sich mit der Wahrscheinlichkeit unentdeckter Fehler in CRC Verfahren, wobei die Betrachtung sich auf sehr kleine Fehlerraten (kleiner 10-10 konzentriert.

5. Praktische Versuche / Messungen

    Testreihe bei Döhler und Haass
    Bei der Einführung von Railcom-QoS fanden im Hause Döhler und Haass Meßreihen statt, welche die Funktionsweise von QoS kontrollieren sollten. Dabei wurden im realen Betrieb (Testanlage) mit verschiedene Modellen, Spurweiten und Verschmutzungsgrade die Empfangsfehler geprüft.

    Ergebnisse:
  • Fehlerquelle 1: Die meisten Fehler waren sogenannte "Taktpausenfehler".
    (Zur Erläuterung: D&H kann auch SX; bei SX werden die Bits am Gleis jeweils durch eine sogenannte "Taktpause" (= kurzes "Cutout" mit 10µs Länge) getrennt. Diese darf nicht länger als 15µs werden, sonst wird der Empfang abgebrochen. Umgekehrt muss für SX zwischen jedem Bit eine Taktpause existieren.
    Für DCC ist solch eine Prüfung eigentlich "unnötig", aber da wir nur einen Code zur Datengewinnung haben, lesen wir natürlich auch DCC mit der für SX erforderlichen Genauigkeit ein. )
  • Fehlerquelle 2: Danach kamen Timingfehler in der ersten Bithälfte des DCC-Signals. Also weder eine "1" (um die 58µs) noch eine "0" (ab 100µs) erkannt.
  • Fehlerquelle 3: Anschließend kamen "Missmatch"-Fehler. Das bedeutet: die erste Bithälfte wurde als "halbe 1", die zweite Bithälfte wurde als "halbe 0" erkannt (oder umgekehrt).
    • An diesen drei Fehlerquellen kam kein einziges Paket "vorbei".
    Als vierte Fehlerquelle hatte man ungültiges Trennbit zwischen den Bytes vorgesehen, als fünfte Fehlerquelle die ungültige XOR-Prüfsumme und schließlich als sechste Fehlerquelle eine ungültige Paketlänge. Diese Fehler haben nie angeschlagen.
    Aufgrund dieser Ergebnisse wurde zunächst die Erkennungssicherheit des Dekoders angezweifelt (ob alles korrekt implementiert sei), da die Fehlerquellen vier bis sechs nie auftraten. Durch eine entsprechend manipulierte DCC-Gleissignalerzeugung konnte jedoch nachgewiesen werden, dass der Dekoder diese Fehlerquellen auch erkennen würde.

    Testreihe bei Tams Elektronik
    Desweiteren gab es aus gleichem Grund Untersuchungen bei der Fa. Tams Elektronik.

    Auch hier wurde eine Testlok auf eine Anlage mit verschiedenen 'bekannt schlechten' Abschnitten geschickt und die Fehleranzeige mittels QoS kontrolliert und auch mit dem realen Fahreindruck verglichen. Der Test umfasste vier Versuchsanordnungen:
  • 1. DCC-Auswertung mit beidseitiger Flankenauswertung, XOR-Prüfung aktiviert. (Regelbetrieb des Dekoders)
  • 2. DCC-Auswertung mit beidseitiger Flankenauswertung, XOR-Prüfung deaktiviert.
  • 3. DCC-Auswertung mit einseitiger Flankenauswertung, XOR-Prüfung aktiviert.
  • 4. DCC-Auswertung mit einseitiger Flankenauswertung, XOR-Prüfung deaktiviert.
    • Getestet wurde jeweils mit Strecken mit verschiedenen Verschmutzungen (was in einer Empfangsgüte (QoS) von 5% bis 100% resultierte).

    Ergebnisse:
  • Fall 1. (beide Flanken + XOR): Bis runter zu einer Empfangsgüte von 10% war eine Lok noch akzeptabel manuell kontrollierbar.
  • Fall 2. Kein Unterschied zu Fall 1. Die DCC-Nachrichten wurde jeweils bereits vor der XOR-Auswertung verworfen.
  • Fall 3. Unterhalb von Empfangsgüten von 25% kam es zu sporadischen Fehlfunktionen, Nachrichten wurden trotz XOR an die Auswertung weitergereicht.
  • Fall 4. Kaum vernünftiger Betrieb möglich.

6. 'Offizielle' Tests

    Es gibt leider bis jetzt noch keine offiziellen Testkriterien, weder bei der NMRA noch bei der Railcommunity.

    Die NMRA hat in den 90er Jahre auf sog. 'schlechten Anlagen' Probleme mit bestimmten Dekodern festgestellt. Bei einer Messung hat man nichtmonotone Flankenübergänge beim Booster und überlagerte Einkopplung als Ursache detektiert und dafür empirisch einen Testaufbau genieriert: der sogenannte 'Glitch-Booster' ist ein Booster mit besonders schlechter Flanke und den 'Noise-Injektor' der ein nicht näher begründete Rauschspannung auf das DCC-Signal einkoppelt. Die von diesem Testaufbau generierten künstlichen Störungen sind aber nirgends dokumentiert und doch zugleich Bestandteil des Konformitätstests.
    Die realen Probleme, die zu Bitfehlern führen könnten, decken diese Tests nur sehr bedingt ab. Untersuchungen mit diesem Aufbau sind also für einen praxisgerechten Übertragungstest unbrauchbar.

7. Zusammenfassung

    Die wesentlichen Störquellen bei DCC führen nicht zu statistischen Bitfehlern, sondern provozieren Timingfehler. Diese lassen sich durch geeignete Empfangsmethoden sehr gut erkennen, die Fehlerwahrscheinlichkeit sinkt damit sehr stark ab. Für eine nachgelagerte Prüfsumme ist im Vergleich CRC klar besser als XOR, aber bei kleinen Restwahrscheinlichkeiten liefert XOR eine hinreichend gute Fehlererkennung. Korrekte Timingauswertung und Beobachtung beider Flanken/Halbbits beim Empfang ist daher der Schlüssel zu einem sicheren und funktionalen Betrieb. Eine korrekte Timingauswertung wird auch bei kurzen DCC-Befehlen die Sicherheit signifikant erhöhen.

    Ein aussagekräftiger Test von der Dekodern, der reale Problemfälle wie Kontaktprobleme beim Rad-Schiene-Übergang nachbildet könnte ein fundierte Aussage über Notwendigkeit von Timingauswertungen und/oder zusätzlichen CRC liefern.