Startseite > Automotive > Infotainment > Der Allround-Gigabit-Link fürs Auto

Übertragung von verschlüsselten HD-Videoströmen

Der Allround-Gigabit-Link fürs Auto

6. Juli 2012, 10:39 Uhr | Von Roland Neumann und Michael Riedel

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Daten intelligent schützen

Ein besonderes Augenmerk wurde bei der Entwicklung auf den Schutz der Daten speziell für sicherheitsrelevante Anwendungen gelegt. APIX2 erfüllt damit heute bereits schon wesentliche Voraussetzungen für eine ASIL-konforme Übertragung nach ISO 26262.

Die dazu von Inova entwickelte und fest in die Bausteine integrierte AShell2 ist ein vollständig in Hardware implementiertes Kommunikationsprotokoll, das eine zuverlässige Datenübertragung zwischen zwei AShell2-Instanzen gewährleistet.

Applikationsdaten werden durch die AShell2 auf der Basis eines geeigneten CRC (Cyclic Redundancy Check) vor Fehlern während der Übertragung auf dem seriellen Übertragungskanal geschützt. Der Empfänger kann durch den CRC Übertragungsfehler erkennen und im Falle eines Fehlers mit Hilfe eines Protokolls (ARQ; Automatic Repeat Request) die Wiederholung der fehlerbehafteten Daten durch den Sender erzwingen.

In der Praxis ist potentiell jedes serielle Übertragungssystem mit Fehlern beim Transport der Bits vom Eingang des Sendebausteins zum Ausgang des Empfängerbausteins konfrontiert. Ursache sind äußere physikalische Einwirkungen der Umgebung, egal ob dadurch Bits im Übertragungskanal verfälscht werden oder die Rückgewinnung der zeitlichen Dauer der Bits (Re-Timing) am seriellen Eingang des Empfängerbausteins so stark beeinflusst wird, dass falsche Bit-Werte rekonstruiert werden. Da für die meisten Datenströme vieler Applikationen jedoch eine fehlerfreie Übertragung erwünscht bzw. erforderlich ist, müssen geeignete Maßnahmen ergriffen werden, um Fehler zu vermeiden, zu erkennen bzw. zu beheben. Enthalten die Applikationsdaten bereits inhärente Redundanz, kann das beispielsweise durch Bewertung der Plausibilität der im Empfänger extrahierten Daten erfolgen. Oder den Applikationsdaten wird im Sender Redundanz hinzugefügt, d.h., die Daten werden um zusätzliche Informationen ergänzt, welche die Fehlererkennung und u.U. auch deren Korrektur ermöglichen.

Diese Verfahren erhöhen allerdings die Komplexität der Sender und Empfänger, erzeugen zusätzliche Daten (Overhead) und beeinträchtigen somit die Nutzung der seriellen Übertragungskapazität durch die tatsächlichen Nutzdaten der Applikation. Man benötigt deshalb für eine sinnvolle technische Lösung ein gutes Modell für die Statistik der zu erwartenden Übertragungsfehler und ein gutes Verständnis dafür, welche Restwahrscheinlichkeit für Fehler in den Nutzdaten durch die Applikation toleriert werden kann. Es ist meist sehr schwierig, diese fundamentalen Parameter bei der Entwicklung eines Übertragungssystems so zu definieren, dass sie für die Praxis relevant und belastbar sind, insbesondere, wenn Sende- und Empfangsbaustein möglichst für viele Applikationen attraktiv sein sollen. APIX2 verwendet einige der oben genannten Methoden zur Erkennung und Korrektur von Fehlern, implementiert darüber hinaus aber auch die AShell2-Protokollschicht für die unspezifischen Daten einer Applikation, die dem oben beschriebenen Dilemma Rechnung tragen soll: Die Daten werden permanent nur um solche Informationen erweitert, die eine Fehlererkennung mit sehr hoher Wahrscheinlichkeit ermöglichen – im detektierten Fehlerfall wird ein Protokoll zwischen Sender und Empfänger aktiv, das so lange aufrecht erhalten wird, bis die Daten hundertprozentig fehlerfrei empfangen wurden. Solange die Übertragung fehlerfrei ist, erzeugt dieses Protokoll nahezu keinen zusätzlichen Overhead.

Daten, die eine Applikation vom Sender zum Empfänger fehlerfrei seriell übertragen möchte, werden wie oben beschrieben durch die AShell2 geschützt. Quelle und Senke dieser Daten sind Bausteine (z.B. MCU) der gemeinsamen Baugruppe, die diese Daten jeweils über SPI-Schnittstellen mit den APIX2-Bausteinen austauschen. Falls das Datensicherungskonzept einer Applikation auch diesen Übertragungsweg auf der Baugruppe vor unerkannten Fehlern schützen möchte, implementiert der APIX2-Baustein an seinen SPI-Schnittstellen Kontrollsummen (CRC) über die transferierten Daten, die von der Applikation ausgelesen und mit den von ihr ebenfalls berechneten Werten verglichen werden können.

Für einen menschlichen Betrachter enthalten die Informationen der Pixel von Bilddaten meist große Redundanz – einzelne, zufällig auftretende und zufällig im Frame verteilte Bit-Fehler sind meist völlig unsichtbar. Die Informationen jedoch, die das Bildformat beschreiben – in der Regel HSYNC, VSYNC, DE – haben große Relevanz, und viele Displays reagieren mit sichtbaren Störungen, wenn diese Signale auch nur kurzzeitig fehlerhaft sind. Deshalb schützt APIX2 diese Informationen besonders und überträgt sie fehlerfrei.

Die Bilddaten dagegen werden nicht mit diesem hohen Aufwand geschützt, um die zur Verfügung stehende serielle Übertragungsrate nicht durch unnötigen Overhead zu belegen.

Manche Applikationen benötigen jedoch auch Informationen über Fehler in den Videodaten, entweder, um fehlerbehaftete – oder auch nur zu stark fehlerbehaftete – Frames zu verwerfen oder nur, um über ein Kriterium zu verfügen, mit dem die Qualität der seriellen Datenübertragung permanent und zuverlässig beurteilt werden kann. APIX2 implementiert dafür einen CRC über jede horizontale Bildzeile und überträgt diese an den Empfänger. Dieser zeigt wahlweise erkannte Übertragungsfehler an seinem Status-Pin an oder leitet den CRC an die Senke der Videodaten weiter, so dass dadurch auch der Pfad beispielsweise bis zu einem Frame-Buffer überwachbar ist.

Das verwendete CRC-Polynom erkennt Burst-Fehler bis zu 32 Bits mit einer Hamming-Distanz von vier bzw. sechs für Frames mit bis zu 1.364 24-bit-Pixeln bzw. 1.818 18-bit-Pixeln pro Zeile. Dies bedeutet, dass bis zu vier bzw. sechs beliebig verteilte Fehler zu 100 Prozent erkannt werden. Ein CRC-4-Schutz, wie er häufig verwendet wird, hat selbst bei optimaler Wahl des CRC-4-Polynoms nur eine Hamming-Distanz von eins, d.h., er erkennt nur Einzel-Bit-Fehler zu 100 Prozent, obwohl er bei 16 bit breiten Kameradaten einen Overhead von 25 Prozent generiert.