<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <journal-title-group>
        <journal-title>F. Petitcolas, R. Anderson and M. Kuhn, “Information Hiding - A
Survey”, Proceedings of the IEEE, special issue on protection of
multimedia content</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Neue Ansätze und Methoden für die Fehlermodellierung und -behandlung bei automobilen Videodatenübertragungsstrecken</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Jan Bauer</string-name>
          <email>jan.j.bauer@daimler.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Andreas Hudak</string-name>
          <email>andreas.hudak@stz-es.com</email>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Karlheinz Blankenbach</string-name>
          <email>karlheinz.blankenbach@hs-pforzheim.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Frank Langner</string-name>
          <email>jan.j.bauer@daimler.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Chihao Xu</string-name>
          <email>chihao.xu@lme.uni-saarland.de</email>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Mirko Conrad</string-name>
          <email>mirko.conrad@samoconsult.de</email>
          <email>mirko.conrad@samoconsult.de https://orcid.org/0000-0003-3221-6503</email>
          <xref ref-type="aff" rid="aff4">4</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Matthäus Vogelmann</string-name>
          <email>matthaeus.vogelmann@hs-pforzheim.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Daimler AG</institution>
          ,
          <addr-line>Stuttgart</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Hochschule Pforzheim</institution>
          ,
          <addr-line>Pforzheim</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>STZ Electronic Systems GmbH</institution>
          ,
          <addr-line>Mühlacker</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>Universität des Saarlandes</institution>
          ,
          <addr-line>Saarbrücken</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff4">
          <label>4</label>
          <institution>samoconsult GmbH</institution>
          ,
          <addr-line>Berlin</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2017</year>
      </pub-date>
      <volume>87</volume>
      <issue>7</issue>
      <fpage>30</fpage>
      <lpage>36</lpage>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Keywords — Camera Monitor Systems (CMS), Video Data
Transmission, Fault Model, Functional Safety, ISO 26262</p>
    </sec>
    <sec id="sec-2">
      <title>I. EINLEITUNG</title>
      <p>In modernen Fahrzeugen werden Videodaten oft
zwischen mehreren Kameras, Bildprozessoren und Displays
übertragen. Die gesteigerte Anzahl der Komponenten mit
einer notwendigen Partizipation an der
Videodatenübertragung ist auf der Kameraseite durch die
Verbreitung von videobasierten Assistenzsystemen und auf
der Displayseite durch den gesteigerten Bedarf, diese
Informationen adäquat dem Fahrer und Passagieren
darzustellen, begründet. Wird ein Kamerabild auf einem
Display dargestellt, kann es durch die Darstellung von
fahrrelevanten Informationen zu Anforderungen bezüglich
der funktionalen Sicherheit kommen.</p>
      <p>Teil-, hoch- oder vollautomatisierte Fahrzeuge beziehen
einen nicht unerheblichen Teil der Information über ihre
Umgebung von bildgebenden Aufnahmeverfahren. Werden
die dort anfallenden Videodaten im Fahrzeug übertragen,
müssen zur Gewährleistung der Funktionssicherheit
ebenfalls Maßnahmen ergriffen werden.</p>
      <p>Darüber hinaus werden Videodaten zu Empfängern
außerhalb des Fahrzeugs übertragen, wie z.B. für
automatisierte Parkvorgänge. Auch hier kann bspw. die
Verknüpfung der Bildinformation mit einer eventuellen
Entscheidung für die Fahrzeugbewegung sicherheitsrelevant
sein.</p>
      <p>Im Rahmen einer Bestandsaufnahme wurden von den
Autoren mehr als 20 Use-Cases mit Videoübertragung
(Video Use-Cases) identifiziert, die potentiell funktional
abgesichert werden müssen.</p>
      <p>Die Videoübertragung ist ein Spezialfall der
Datenübertragung. Die Videoübertragung unterscheidet sich
dabei, in der hohen Bandbreite in eine Übertragungsrichtung
und die in den meisten Fällen verbindungslose Übermittlung
(d.h. es findet kein expliziter Aufbau einer
Kommunikationsbeziehung vor dem Datenaustausch statt) in einem
sogenannten Pixel-Stream.</p>
      <p>Die übertragenen Videodaten werden dann entweder (RD)
über eine Anzeige in ortsaufgelöste Lichtinformation
umgesetzt und als Bild von einem Betrachter
wahrgenommen, oder (RP) von einem Videoprozessor mit
einem Algorithmus weiterverarbeitet, um entsprechende
Merkmale der Umgebung wie z.B. Verkehrszeichen zu
erkennen. Der Fall (RP) geht dabei über die Funktionalität
herkömmlicher Kamera-Monitor-Systeme (Camera Monitor
Systems, CMS [13]) hinaus.</p>
      <p>Im Fall (RD) kann zur Verbesserung der
Benutzererfahrung (User-Experience) eine Bildverbesserung
beispielsweise unter Nutzung von Farbraumkonvertierungen
oder durch eine Überlagerung mit zusätzlichen Inhalten
erfolgen. Weiter werden die Eigenschaften der visuellen
Wahrnehmung genutzt, um z.B. durch Kompression der
Videodaten die Effizienz der Übertragung zu optimieren.
Verfahren für die Absicherung müssen in diesem Fall
entsprechend robust gegenüber den (validen) Änderungen
der Bildverbesserung, Überlagerung und Kompression sein.
Gleichzeitig müssen ungültige Änderungen wie z.B.
einfrieren des Bilds erkannt werden. Sowohl bei (RD) als
auch bei (RP) muss die Integrität der Daten und die
verzögerungsfreie Übertragung sichergestellt werden.</p>
      <p>Viele der derzeit bekannten bzw. verwendeten
Mechanismen zur Absicherung der Datenübertragung bei
Fehlern und Ausfällen sind für die allgemeine
Datenübertragung ausgelegt und betrachten den Sonderfall
der Videoübertragung nicht im benötigten Umfang. Hieraus
ergeben sich potentielle Lücken bei der Gewährleistung der
Funktionssicherheit [12] bei vielen state-of-the-art als auch
bei zukünftigen Video Use-Cases. Beispielsweise gibt es nur
beschränkte Mechanismen, um festzustellen ob Videodaten
korrekt übertragen und durch das Display in die
entsprechende Lichtinformation umgesetzt wurden.</p>
      <p>Im vorliegenden Paper wird ein Konzept vorgestellt, dass
eine funktionale Absicherung von Videoübertragungen von
der Quelle (nach Erzeugung der Pixel) bis zur Umwandlung
der Pixel in optische Information (RD) bzw. zum Empfänger
(RP) ermöglicht. Dabei werden bekannte Verfahren zur
Absicherung der Qualität bei Videoübertragungen für die
Nutzung innerhalb der funktionalen Sicherheit betrachtet und
mit neuen Verfahren kombiniert, um eine möglichst
holistische Absicherung der Videoübertragungskette zu
erreichen.</p>
      <p>II. ABLEITUNG EINES FEHLERMODELLS FÜR DIE
ÜBERTRAGUNG VON VIDEODATEN</p>
      <p>Voraussetzung für die systematische Absicherung eines
technischen Systems, bspw. eines Systems zur
Videodatenübertragung, ist die Kenntnis der möglichen
Ausfallarten (failure modes), die in diesem System auftreten
können, also die Definition eines geeigneten Fehlermodells
(fault model).</p>
      <p>Für die klassische Datenübertragung kann ein solches
Fehlermodell aus der Funktionssicherheitsnorm ISO 26262
[12] abgeleitet werden.</p>
      <p>Um eine hohe Fehleraufdeckung zu gewährleisten,
müssen die folgenden Ausfallarten berücksichtigt werden:
• Informationsverfälschung (corruption of information)
• Informationsverlust (loss of information)
• fehlerhafte Informationsabfolge (incorrect sequence
of information)
• Informationswiederholung (repetition of information)
•
•
•
•</p>
    </sec>
    <sec id="sec-3">
      <title>Hinzufügen von Information (insertion of infor</title>
      <p>mation)
• Informationsverzögerung (delay of information)</p>
    </sec>
    <sec id="sec-4">
      <title>Maskeradefehler oder fehlerhafte Adressierung</title>
      <p>(masquerade or incorrect addressing of information)
Nichtempfang oder nichtintendierter Empfang von
Informationen (asymmetric information sent from a
sender to multiple receivers, information from a
sender received by only a subset of the receivers)</p>
    </sec>
    <sec id="sec-5">
      <title>Verhinderung des Zugriffs auf einen</title>
      <p>Kommunikationskanal (blocking access to a
communication channel)</p>
      <p>Anhand eines derartigen Fehlermodells kann die
Wirksamkeit von Sicherheitsmechanismen zur
Fehlererkennung bzw. -vermeidung systematisch analysiert
werden. Da den Autoren ein angepasstes Fehlermodell für
den Spezialfall der Übertragung von Videodaten nicht
bekannt ist soll ein solches nachfolgend erarbeitet werden.</p>
      <p>Hierfür wird das in Fig. 1 illustrierte generische Modell
einer Videodatenübertragungsstrecke zugrunde gelegt. Eine
Videoübertragungsstrecke besteht aus einem Sender (Sender,
S), einem Übertragungskanal (Transmission, T) und einem
Empfänger (Receiver, R). Dabei können S, T und R aus
mehreren Teilen bestehen.</p>
      <p>Im Falle eines Rückfahrkamera- (Rear View Camera)
Systems werden die aus den eigentlichen Pixeldaten und
zugehörigen Metadaten bestehenden Videodaten (I) bspw.
durch eine Rückfahrkamera erzeugt und von dieser über
einen ungesicherten (sog. grauen) Kanal digital an den
Empfänger (I'') bspw. ein Monitor in der Mittelkonsole
übertragen (Fig. 1). Die Übertragung T: I→I'' kann dabei
drahtgebunden als auch drahtlos erfolgen.</p>
      <p>Eine zusätzliche Herausforderung ergibt sich dadurch,
dass sich optional innerhalb des ungesicherten
Übertragungskanals weitere Elektronikkomponenten, genannt
Modifier (M) befinden können, die die zu übertragenden
Videodaten auf bestimmte Art und Weise verändern können
(I*).</p>
      <p>In dem in Fig. 1 dargestellten Rear View Camera System
könnte eine zwischengeschaltete Head Unit bspw. die
Bildhelligkeit oder den Kontrast optimieren, ein Kamerabild
skalieren, es in ein größeres Gesamtbild einbetten oder
augmentieren.</p>
      <p>(S) Sender
❑ Rear View Camera
(M) Modifier
❑ Head Unit
(R) Receiver
❑ Center Console Display
I1, I2, I3, I4, …</p>
      <p>I’x = F(Ix)</p>
      <p>I*x = F(I’x)</p>
      <p>I”x = F(I*x)</p>
      <p>I”1, I”2, I”3, I”4, …
Pixel data
Meta data</p>
      <p>Zulässige Bildtransformationen sollen dabei durch die
Sicherheitsmechanismen toleriert werden. Unzulässige
Bildtransformationen, die bspw. dazu führen, dass der
Nutzer die relevanten Bildinformationen nicht mehr
erkennen kann, sollen dagegen erkannt werden.</p>
      <p>Voraussetzung für die Entwicklung und vor allem die
Bewertung von Mechanismen für die Absicherung der
Videodatenübertragung ist die Aufstellung eines geeigneten
Fehlermodells für eine Videodatenübertragung.</p>
      <p>Prinzipiell können zunächst einmal die gleichen
Ausfallarten wie bei der klassischen Datenübertragung
auftreten, d.h. das Fehlermodell für die
Videodatenübertragung muss daher mindestens die o.g.
Ausfallarten berücksichtigen:</p>
    </sec>
    <sec id="sec-6">
      <title>FM01: Bildverfälschung</title>
    </sec>
    <sec id="sec-7">
      <title>FM02: Bildverlust</title>
    </sec>
    <sec id="sec-8">
      <title>FM03: fehlerhafte Bildabfolge</title>
    </sec>
    <sec id="sec-9">
      <title>FM04: Bildwiederholung</title>
    </sec>
    <sec id="sec-10">
      <title>FM05: Hinzufügen von Bildern</title>
    </sec>
    <sec id="sec-11">
      <title>FM06: Bildverzögerung</title>
      <p>FM07: Maskeradefehler oder fehlerhafte Adressierung
FM08: Nichtempfang oder nichtintendierter Empfang
von Bilden</p>
    </sec>
    <sec id="sec-12">
      <title>FM09: Verhinderung des Zugriffs auf eine Bild</title>
      <p>übertragungsstrecke</p>
      <p>Darüber hinaus wurden weitere videospezifische
Ausfallarten identifiziert, die ebenfalls berücksichtigt werden
müssen. Hierzu gehören z.B.:</p>
    </sec>
    <sec id="sec-13">
      <title>FM10: eingefrorenes Bild (frozen image)</title>
      <p>FM11: fehlerhafter Bildausschnitt /
Vergrößerungsfaktor (erroneous field of view / zoom factor)
FM12: fehlerhafte Bildgröße (erroneous image size)
FM13: fehlerhafte Metadaten (erroneous meta data)
FM14: fehlerhafte Bilddarstellung (erroneous image
display)
FM15: Verlust notwendiger Bildinformation (loss of
essential image information)
FM16: fehlerhafte Bildtransformation (unintended
image transformation)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•</p>
      <sec id="sec-13-1">
        <title>A. Absicherung des Übertragungskanals (T)</title>
        <p>Für Videoübertragungen können prinzipiell verschiedene
physikalische Übertragungsverfahren und
Übertragungsmedien verwendet werden. Heutige Verfahren für die
Videoübertragung im Fahrzeug verwenden vornehmlich
elektrische drahtgebundene Verfahren, daher soll sich an
dieser Stelle auf die elektrischen drahtgebundenen
Verfahren fokussiert werden. Heutige Mechanismen zur
Absicherung der physikalischen Übertragungsschicht haben
das Ziel, die Qualität der Videoübertagung sicherzustellen,
d.h. Ausfälle und Störungen zu erkennen und / oder zu
vermeiden.</p>
        <p>Dazu zählt die Erkennung von Fehlern der
physikalischen Verbindung (Line Fault Detection) mit den
Möglichkeiten:
• erhöhter Leitungswiderstand zwischen Sender und</p>
        <p>Empfänger
• fehlerhafter Leitungsabschluss</p>
        <p>Besteht eine physikalische Verbindung, kann bspw. über
die Aussendung eines Testsignals vom Sender zum
Empfänger, den dortigen Empfang und die Rückmeldung an
den Sender die logische Verbindung beidseitig überprüft
werden. Der Zustand der logischen Verbindung wird in
vielen automotive Übertragungssystemen mit einem
LinkLock signalisiert.</p>
        <p>Die Übertragung der Videodaten über einen
Übertragungskanal kann durch Error-Detection Codes (EDC),
bspw. die Verwendung eines Cyclic Redundancy Checks
(CRC), abgesichert werden. Auf diese Weise können
eventuelle elektro-magnetische Störungen auf der
Videoübertragungsstrecke erkannt werden. Die Verwendung von
Error-Correction Codes (ECC) erlaubt eine Forward Error
Correction (FEC), also eine automatische Korrektur
bestimmter Übertragungsfehler.</p>
        <p>Neben der Möglichkeit, Fehler zu erkennen bzw. zu
korrigieren, können aus den genannten Verfahren die
aktuelle Anzahl der Übertragungsfehler aus der
CRCAuswertung (FCRC) bzw. Anzahl der Fehlerkorrekturen
(CFEC) abgeleitet werden und als Messgröße für die Qualität
der physikalischen Verbindung QTP verwendet werden. Diese
Qualitätsbewertung der physikalischen Verbindung QTP kann
durch Messung der physikalischen Empfangseigenschaften
wie bspw. der vertikalen, horizontalen Augenöffnung (A, B)
erweitert werden.</p>
        <p>Darüber hinaus verwenden heutige
Videoübertragungsstrecken Ausgleichsfilter auf Frequenzbasis (Equalizer) zum
Ausgleich der frequenzabhängigen Dämpfung auf der
Übertragungsstrecke. Der Abstand der aktuellen zur
maximal möglichen Aussteuerung dieser Filter über die
Frequenz ∆D(f) kann als weiterer Parameter für die
Qualitätsbewertung der Übertragungsstrecke genutzt werden.</p>
        <p>Wird ein zu definierender Schwellwert für die Qualität
der Übertragungsstrecke QTP unterschritten, können dann
entsprechende Fehlerbehandlungsmechanismen aktiviert</p>
      </sec>
    </sec>
    <sec id="sec-14">
      <title>III. SICHERHEITSMECHANISMEN</title>
      <p>Um die o.g. Fehlermöglichkeiten zu erkennen bzw. zu
behandeln, wurden von den Autoren bekannte
Sicherheitsmechanismen für die einzelnen Bestandteile der
Videodatenübertragung zusammengetragen und potentielle Lücken
identifiziert.</p>
      <p>Diese Vorgehensweise wird in den folgenden
Unterabschnitten anhand der Beispiele Absicherung des
Übertragungskanals T auf physikalischer Ebene
(Unterabschnitt A) und Absicherung des Empfängers R in Form
eines Displays (Unterabschnitt B) beschrieben. Darüber
hinaus werden komponentenübergreifende (systemweite)
Absicherungsverfahren mittels Hashing und Watermarking
beschrieben (Unterabschnitte C, D).
werden. Mögliche Fehlerbehandlungsmechanismen sind
bspw. die präventive Abschaltung von betroffenen
Funktionen (PD) oder eine abgestufte Funktionsreduktion
(Graceful Degradation, GD). Eine Graceful Degradation
kann bspw. durch eine auf der Qualitätsbewertung QTP
basierende Anpassung des Bandbreitenbedarfs per Reduktion
der Auflösung oder Bildwiederholrate erfolgen.</p>
      <p>Ziele der weiteren Arbeiten zur Absicherung der
physikalischen Übertragung sind zum einen die Definition
geeigneter Funktionen zur Qualitätsbewertung auf Basis der
einzelnen Qualitätsparameter</p>
      <p>QTP = f ( ∆D, CFEC, FCRC, A, B, … )
und zum anderen die Entwicklung entsprechender Methoden
zur abgestuften Funktionsreduktion PD, GD auf Basis dieser
Qualitätsbewertung QTP</p>
      <p>PD = f ( QTP )</p>
      <p>GD = f ( QTP )</p>
      <sec id="sec-14-1">
        <title>B. Absicherung des Empfängers (R)</title>
        <p>Um im Falle einer Videoübertragung eine Ende-zu-Ende
Absicherung zu erreichen, muss auch die Umwandlung der
digitalen Pixelinformationen in sichtbares Licht durch das
Display überprüft werden.</p>
        <p>Sollen aufgetretene Bildfehler oder -degradationen nicht
nur erkannt, sondern auch in deren Ursache bestimmt werden
können, ist neben der optischen Ausgabe auch die
Signalverarbeitungskette innerhalb des Display-Moduls zu
überwachen. Somit kann die Absicherung des Displays
anhand zweier, sich ergänzender Ansätze angestrebt werden:
•
•</p>
      </sec>
    </sec>
    <sec id="sec-15">
      <title>Optoelektronischer Ansatz: optoelektronische</title>
      <p>Erfassung der Emission des Displays</p>
      <sec id="sec-15-1">
        <title>Elektrischer Ansatz: Messung von elektrischen</title>
        <p>Größen (bspw. Stromverbrauch) und Überwachung
der Daten-Signale im Display-Modul</p>
        <p>Optoelektronische Methoden basieren auf der Erfassung
des dargestellten Bildes mittels eines optischen Systems und
dessen Vergleich mit den empfangenen Bilddaten oder
Metadaten der Bildgenerierung in der Kamera. Ultimativ
sollte die Lichtinformation der einzelnen Pixel erfasst
werden. Hierfür ist es erforderlich, die zeitliche Intensität
sowie die Ortskoordinaten der von den Pixeln ausgesendeten
Lichtstrahlen und somit ein zweidimensionales Lichtfeld
I(x,y,t) zu erfassen. Ziel ist es hierbei, die Bildintegrität und
die Erkennbarkeit des Bildinhaltes zu ermitteln.</p>
        <p>Naheliegend ist die Erfassung der optischen Ausgabe
mittels einer vor dem Display angebrachten Kamera,
wodurch ein hoher Grad der Fehlererkennung erreicht wird.
Diese kann jedoch aus bautechnischen Gründen nicht in allen
Fällen eingesetzt werden und der erforderliche
Auswerteund Analyseaufwand ist hoch.</p>
        <p>
          Eine abgewandelte Methode ist die Erfassung der
optischen Ausgabe mittels eines auf das Displayglas
aufgebrachten Wedge-Lightguide [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ]. Dieser Lichtleiter kann
in Form einer dünnen, semitransparenten Folie einen Teil der
Intensität der Lichtstrahlen zu einem optoelektrischen Sensor
weiterleiten, ohne dass deren Ortsinformation verloren geht.
Anstatt einer Kamera können dort auch niedrigauflösende
Sensoren als Kompromiss zwischen
Signalverarbeitungsleistung und Informationsgehalt eingesetzt
werden. Bei der Verwendung eines (semi-)transparenten
OLED kann ein Wedge-Lightguide oder eine Kamera auch
hinter dem Panel verbaut werden (Fig. 2).
        </p>
        <p>
          Diese beiden Methoden können prinzipiell einem
Displaymodul hinzugefügt werden, während eine Erfassung
der optischen Ausgabe mittels Fotosensoren in jedem Pixel
des Displays [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ] bereits bei der Herstellung des
elektrooptischen Wandler (z.B. LCD) integriert werden muss.
Dieser Ansatz rechnet sich nur bei höchsten Stückzahlen.
        </p>
        <p>Ein modernes, hochauflösendes Aktiv-Matrix-Display
besteht neben dem eigentlichen elektro-optischen Wandler
(Display Glass) aus einer Vielzahl von Mikroprozessoren
und Halbleitern (Panel Electronics). Natürlich setzt eine
fehlerfreie optische Ausgabe eine ebenso funktionierende
Elektronik voraus; im Umkehrschluss können auftretende
Fehlfunktionen der Elektronik anhand einer fehlerhaften
optischen Ausgabe erkannt werden. Ziel der in der
Panelelektronik umzusetzenden Sicherheitsmechanismen ist
die Erkennung von Fehlerfällen wie z.B. ein nicht
kompatibles Eingangssignal oder ein gestörter Bildaufbau.</p>
        <p>
          Die elektrischen Ansätze zur Überwachung des Displays
werden anhand des Blockschaltbildes in Fig. 3 diskutiert. Im
Wesentlichen sind in der Panelelektronik folgende
Komponenten enthalten:
Der Timing Controller (TCON, z.B. [
          <xref ref-type="bibr" rid="ref1">1</xref>
          ]) formatiert
den Input-Bilddatenstrom in Signale (z.B. [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ]) für
Zeilen- (row driver) und Spaltentreiber (column
driver) um.
        </p>
        <p>
          Die Zeilentreiber steuern eine Zeile nach der anderen
an, während die Spaltentreiber (z.B. [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ]) die
zugehörigen Graustufen-Daten einspielen.
        </p>
        <p>Der Gamma- und VCOM-Buffer stellt
LCDspezifische Spannungen zur Verfügung.</p>
        <p>Das LCD-Backlight stellt die Lichtquelle des LCDs
dar.</p>
        <p>Naheliegende Ansätze zur Fehlererkennung und -analyse
sind die Spannungs-, Strom-, Leistungs- und
SignalÜberwachungen aller oben aufgeführten
PanelelektronikKomponenten.</p>
        <p>Bei einem OLED-Display ist der Stromverbrauch
maßgeblich durch die Graustufen der Pixel bestimmt. Somit
stellt der Abgleich zwischen Stromverbrauch und
Graustufen-Histogramm eine erste und einfache Überwachung bei
OLEDs dar. Mit erweiterten Methoden im Zeitbereich und
Referenzmessungen ist dies auch bei LCDs möglich. Es ist
offensichtlich, dass in beiden Fällen bei keiner oder nur sehr
geringer Leistungsaufnahme kein Bild dargestellt wird.</p>
        <p>Die digitalen Signale am Eingang und im Panel können
bezüglich ihrer Frequenz, Dauer, Austastlücken etc., d.h. des
korrekten Timings, überwacht werden
(TimingÜberwachung der digitalen Signale). Bei Abwesenheit oder
falschem Timing wird typischerweise kein oder nur ein
gestörtes Bild visualisiert. Eine weitere, klassische Methode
ist die Nutzung von Error-Detection Codes, bspw. die
Kontrolle des CRC über die Bilddaten.</p>
        <p>
          Aufwändigere Überwachungsmethoden basieren auf der
Analyse darzustellender Bildinhalte (geliefert über die
Metadaten) und deren Vergleich mit den Daten im
Bilddatenstrom. Ein Telltale-Monitoring durch z.B. Abgleich
einer Höchstgeschwindigkeitsinformation (darzustellender
Bildinhalt) mit dem dargestellten Verkehrszeichens (Daten
im Bilddatenstrom) ist Stand der Technik [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ].
        </p>
        <p>In Summe existiert displayseitig eine Vielzahl von
Mechanismen zur Fehlererkennung mit unterschiedlicher
Effektivität und sehr unterschiedlichen Kostenindikationen.</p>
        <p>Viele fehlerhafte Darstellungen auf einem Display sind
vom Betrachter problemlos als solche zu identifizieren
(perceived faults), z.B. der Nichtempfang von Bildern
(FM08) oder bestimmte Bildstörungen. Kritischer sind kaum
zu erkennende Fehler wie falsche Graustufen-Spannungen,
die wichtige Bildinhalte quasi „unsichtbar“ werden lassen
oder eine Bildverzögerung (FM06). Die einzusetzenden
Fehlererkennungsmechanismen sollten daher auf diese
Fehlerarten fokussieren.</p>
        <p>Als möglicher Fehlerbehandlungsmechanismus, bspw.
bei fortwährenden CRC-Fehlern, kommt die präventive
Abschaltung des LCD-Backlights PD (sicherer Zustand ‚keine
Bilddarstellung‘ bzw. ‚Anzeige eines (dunklen)
Ersatzbildes‘) in Frage.</p>
        <p>Anwendungsabhängig kann jedoch auch hier die Anzeige
eines degradierten Bildes (Graceful Degradation) GD bei
erkannten Störungen (z.B. digitale Blockartefakte) oder
Degradationen (z.B. Rauschen) gefordert sein (sicherer
Zustand ‚Anzeige eines degradierten Bildes‘) ggf. in
Kombination mit einer geeigneten Indikation für den
Betrachter, dass der Bildinhalt fehlerbehaftet ist. Als Beispiel
kann der Video Use-Case ‚Überwachung des Fahrzeugs
durch einen Remote-Operator‘ dienen; hierbei erscheint ein
degradiertes Bild nützlicher als das vollständige Unterbinden
des Informationsflusses.</p>
        <p>C. Komponentenübergreifende Absicherung: Hashing</p>
        <p>Moderne Autos zeigen dem Fahrer hochqualitative
Videodaten an. Anpassungen an die Umgebung und
Augmentieren mit Hilfslinien und Symbolen unterstützen
den Fahrer zusätzlich in der Durchführung seiner
Fahraufgaben. Dafür kann das originale Kamerabild
verschiedene Verarbeitungsschritte durchlaufen. Diese
Bearbeitungsschritte sind i.d.R. nicht gemäß eines definierten
Automotive Safety Integrity Level (ASIL) gemäß ISO 26262
abgesichert, sondern zumindest in Teilen auf QM-Level
realisiert.</p>
        <p>Ein videoübertragendes System muss in einem solchen
Fall gewährleisten, dass das originale und bearbeitete Bild
von Betrachter gleich bzw. ähnlich wahrgenommen werden
und für die Durchführung der Fahraufgabe notwendige
Bildinformationen nicht verloren gehen.</p>
        <p>
          Eine weit verbreitete Methode für einen solchen
Bildvergleich ist die Scale-Invariant Feature Transform
(SIFT) [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ]. Dieses und ähnliche Bildabsicherungsverfahren
basieren auf Features wie z.B. den sogenannten Harris
Corners. Ein direkter Einsatz für die Absicherung eines
Modifiers ist jedoch nicht zielführend, da diese speziellen
Verfahren mit dem Hintergrund der Objekterkennung
entwickelt wurden und nicht die ‚Identität‘ eines Bildes
berücksichtigen. Dennoch können manche Aspekte dieser
Algorithmen für unsere Anwendung herangezogen werden
[
          <xref ref-type="bibr" rid="ref1">1</xref>
          ].
        </p>
        <p>Eine probate Methode, die Datenintegrität einer
Bildübertragung mit Bildverarbeitung (vgl. Fig. 1) zu
gewährleisten, ist es, mit einer Hash-Funktion h ein beschreibendes
Label des Bildes I, das am Anfang der Übertragungsstrecke
steht, zu erzeugen.</p>
        <p>h : I → E</p>
        <p>Der Output der Hash-Funktion E enthält die
beschreibenden Eigenschaften des Bildes. E benötigt nur einen
Bruchteil der Datenmenge von I und kann entweder in den
Austastlücken der Pixeldaten oder als Bestandteil der
Metadaten geleitet werden. Am Ende der
Übertragungsstrecke ist das Bild I'', das aufgrund der möglichen
Bildbearbeitung pixelweise stark vom Originalbild I
abweichen kann. Das bearbeitete Bild I'' hat dann den
HashWert von E''.</p>
        <p>h : I'' → E''</p>
        <p>Die Herausforderung ist es nun, ein Verfahren zu
entwickeln, das die Unterscheidung zwischen gewünschten und
fehlerhaft veränderten Bildern (inhaltlich anders) ermöglicht.
Der Kern der Technologie liegt im Entwurf einer speziellen
Hashfunktion und einer Matching-Funktion, die eine hohe
und robuste Diskriminanz aufweisen.</p>
        <p>Wichtig ist es zudem, dass E ohne nennenswerte Latenz
erzeugt wird, damit das Verfahren für sicherheitsrelevante
Anwendungen eingesetzt werden kann. Das gleiche gilt auch
für E'': Dieses muss unmittelbar nach dem Empfang des
Bildes I'' erzeugt werden. Auch die Matching-Funktion von
E und E'' soll schnell ein Ergebnis liefern, ob die Videodaten
ungewünscht verändert oder fehlerhaft übertragen worden
sind. Die Algorithmen sollen nach Möglichkeit am Anfang
und am Ende der Übertragungsstrecke eingesetzt werden, so
dass eine hohe Integrität der Videodaten erreicht werden
kann.
D. Komponentenübergreifende Absicherung: Watermarking</p>
        <p>Neben den bereits betrachteten, primär einer
Komponente des Übertragungsmodells für Videodaten zuordenbaren
Fehlererkennungs- und Fehlerbehandlungsmechanismen
können weitere, systemübergreifende Mechanismen
erforderlich sein. Als Vertreter dieser Kategorie sollen hier die
Absicherung sicherheitsrelevanter Inhalte mittels
Wasserzeichen und die Absicherung der zeitlichen
Synchronität betrachtet werden.</p>
        <p>Je nach Video Use-Case kann ein erzeugter Videoinhalt
sicherheitsrelevant sein. Derartige Inhalte werden im
Rahmen des sicherheitsgerichteten Entwicklungsprozesses
gemäß ISO 26262 definiert. Je nach Anwendungsfall gelten
für diesen Inhalt besondere Anforderungen bezüglich der
Anzeige, bspw. kann es vorkommen, dass ein eingefrorener
sicherheitsrelevanter Inhalt IS nicht angezeigt werden darf.
Wird im Fahrzeug ein solcher sicherheitsrelevanter
Videoinhalt IS erzeugt, kann dieser Videoinhalt zur
Absicherung mit einer entsprechenden Markierung
(Wasserzeichen, W) versehen werden. Jedes Display das
potentiell den Videoinhalt IS anzeigen könnte, muss eine
Methode zur Detektion von des Videoinhalts IS
implementieren um eine fehlerhafte Anzeige zu verhindern.</p>
        <p>Eine probate Methode dafür ist das Hinzufügen von
Informationen zu den Bilddaten in Form eines sichtbaren /
unsichtbaren, robusten / fragilen Wasserzeichens W. Ein
Beispiel für eine robuste, unsichtbare Methode des
Wasserzeichens ist in [14] zu finden. Zusätzlich kann
optional ein zufälliger Wert K (z.B. geheimer oder
öffentlicher Schlüssel) verwendet werden. Durch das
Hinzufügen des Wasserzeichens W und dem Zufallswert K
wird die ursprüngliche Bildinformation IS verändert [11]:</p>
        <p>Der Erkennungsprozess kann dann über den folgenden
Zusammenhang erfolgen [11]:</p>
        <p>Ziel ist es nun geeignete Methoden für das Hinzufügen
der Markierung, mit entsprechender Robustheit gegenüber
Veränderungen, sowie entsprechende Methoden zur
Erkennung der Wasserzeichen zu finden. Darüber hinaus
können fragile Wasserzeichen dazu verwendet werden, um
festzustellen ob eine Änderung an den Videodaten
vorgenommen wurde. Auch hier ist es wichtig das
Hinzufügen, Erkennen (und Entfernen) der Markierung ohne
nennenswerte Verzögerung durchzuführen.</p>
        <p>Ein weiteres Kriterium für die Absicherung der
Videodaten ist die Bewertung des zeitlichen Versatzes ∆tI zwischen
dem Originalbild I und dem empfangenen Bild I'' (vgl. Fig.
1).</p>
        <p>Eine Realisierungsmöglichkeit dafür besteht in der
Kombination einer gemeinsamen Zeitbasis zwischen Sender
S und Empfänger R und einem im Bild oder den Metadaten
enthaltenen Zeitstempel. Die zeitliche Synchronisierung
könnte bspw. über einen zusätzlichen bidirektionalen
Kommunikationskanal, unter Verwendung von
Laufzeitunterschieden, erreicht werden. Der Zeitstempel könnte im
Sender als Teil der Markierung, z.B. als Modulation des
Zufallswertes K, erfolgen.</p>
        <p>Ziel ist es hier entsprechende
Synchronisierungsmechanismen für die automobile Videoübertragung zu
definieren und entsprechend robuste Lösungen für
Einbringung in die Markierung und die entsprechende
Erkennung zu finden.</p>
        <p>IV. SICHERHEITSKONZEPT AUF SYSTEMEBENE</p>
        <p>Systemabhängig muss die Umsetzung der einzelnen
komponentenbezogenen und übergreifenden
Absicherungsmechanismen auf Systemebene geeignet kombiniert und
orchestriert werden.</p>
        <p>Die pauschale Übertragung bekannter
Maßnahmenkombinationen aus der herkömmlichen Datenübertragung
wie bspw. der Ende-zu-Ende-Absicherung (End-to-end
Protection, E2E), welche die Mechanismen Checksumme auf
Applikationsebene, Botschaftszähler, Timeoutüberwachung
und Senderkennung miteinander kombiniert, auf die hier
betrachtete Videodatenübertragung ist jedoch nicht
zielführend, da diese z.B. nicht tolerant in Bezug auf die
zulässigen Bildtransformationen sind.</p>
        <p>Eine systemabhängige Auswahl der Mechanismen muss
dabei abhängig vom Automotive Safety Integrity Level
(ASIL) des betrachteten Sicherheitsziels sowie der Definition
des sicheren Zustands erfolgen.</p>
        <p>Anwendungsabhängig können dabei typischerweise
folgende sicheren Zustände unterschieden werden:
•
•
•
•</p>
      </sec>
    </sec>
    <sec id="sec-16">
      <title>SZ01: keine Bilddarstellung</title>
      <p>SZ02: Anzeige eines Ersatzbildes (z.B. schwarzer
Bildschirm oder Fehlermeldung)
SZ03: Anzeige eines Bildes, das vom Betrachter als
eindeutig fehlerhaft erkannt wird
SZ04: Anzeige eines degradierten Bildes (z.B. Bild
mit geringerer Auflösung oder Frequenz)</p>
      <p>Kann im Fehlerfall auf die Videodatenübertragung
verzichtet werden (Fail Silent oder Fail Safe), bspw. bei einem
elektronischen Seitenspiegel, kann über
Fehlererkennungsmechanismen eine Fehlfunktion detektiert und das Display
oder die Funktion deaktiviert werden (SZ01) bzw. ein
Ersatzbild angezeigt werden (SZ02).</p>
      <p>Besteht eine Verfügbarkeitsanforderung an die
Videodatenübertragung (Fail Operational), muss dagegen
auch im Fehlerfall ein hinreichend geignetes Bild angezeigt
werden. Dies kann über eine Degradierung der
Videoübertragung (SZ04) oder durch den Wechsel auf eine
redundante Komponente erfolgen.</p>
      <p>Viele der in III. definierten
Fehlererkennungsmechanismen können so implementiert werden, dass sie
Kenngrößen für einen systeminternen Test
(Built-In-SelfTest, BIST) liefern. Unterschreitet eine Kenngröße oder eine
Kenngrößenkombination einen Schwellwert, kann eine
Fehlerbehandlung bzw. der Übergang in einen sicheren
Zustand (ggf. auch vor Fahrtantritt) getriggert werden.</p>
      <p>Zur systemweiten Orchestrierung der
Sicherheitsmechanismen wird vorgeschlagen, die Kenngrößen der
verschiedenen Fehlererkennungsmechanismen in einer
dezidierten Safety Unit (SAF) zusammenzufassen. Damit
ergibt sich das in Fig. 4 veranschaulichte generische Modell
einer Sicherheitsarchitektur zur Absicherung der
Videodatenübertragung.
(S) Sender</p>
      <p>(R) Receiver
(SAF) Safety Unit</p>
      <p>Die SAF muss dabei nicht als einzelne, separate
Komponente ausgeführt sein, sondern kann bspw. in einer
der anderen Systemkomponenten verortet sein oder über
mehre Systemkomponenten (bspw. S und R) verteilt sein.
Ebenso kann ein lokaler Datenaustausch zwischen S, T, M
und R erforderlich sein, um übergreifende
Sicherheitsmechanismen zu realisieren (bspw. ein
Kommunikationskanal zwischen S und R zur zeitlichen Synchronisation).</p>
    </sec>
    <sec id="sec-17">
      <title>V. ZUSAMMENFASSUNG UND AUSBLICK</title>
      <p>Ausgehend vom Stand der Technik bei der Absicherung
der allgemeinen Datenübertragung wurde von den Autoren
ein generisches Modell der Videodatenübertragung und ein
Fehlermodell für eine solche Übertragung vorgeschlagen.
Die Modelle umfassen dabei die Veränderung von Bilddaten
durch eine modifizierende Komponente innerhalb der
Übertra-gungsstrecke.</p>
      <p>Danach wurden vorhandene Sicherheitsmechanismen für
einzelne Komponenten des Übertragungsmodells sowie
komponentenübergreifende Sicherheitsmechanismen
identifiziert und zusammengetragen. Dabei identifizierte Lücken
wurden herausgearbeitet und es wurde damit begonnen, diese
zu schließen.
Die identifizierten Sicherheitsmechanismen SM sollen im
weiteren Projektverlauf systematisch auf die identifizierten
Ausfallarten FM abgebildet werden, um einen Baukasten für
die Absicherung der verschiedenen
Videodatenübertragungen im Fahrzeug bereit zu stellen (Fig. 5). Hierzu gehört
auch eine Abschätzung der Diagnosegüte (Diagnostic
Coverage, DC) der einzelnen Mechanismen. Für
Ausfallarten, für die der Baukasten bisher nur wenige oder keine
Sicherheitsmechanismen enthält, sollen gezielt weitere
Mechanismen entwickelt werden.</p>
      <p>Im Rahmen der Anwendung auf ein konkretes System
werden dann zunächst a) die relevanten Fehlermodi
identifiziert und b) für diese eine geeignete Kombination von
Sicherheitsmechanismen aus dem Baukasten ausgewählt.
Danach ist c) die generische Sicherheitsarchitektur geeignet
zu instantiieren und d) die Sicherheitsmechanismen sind den
einzelnen Komponenten der instantiierten
Sicherheitsarchitektur zuzuordnen und dort zu implementieren.
3</p>
      <p>Vehicles
-</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>E.</given-names>
            <surname>Rublee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>V.</given-names>
            <surname>Rabaud</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Konolige</surname>
          </string-name>
          and G. Bradski, “
          <article-title>ORB: and efficient alternative to SIFT or SURF”</article-title>
          ,
          <source>IEEE Int. Conf. on Computer Vision</source>
          ,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>D. G.</given-names>
            <surname>Lowe</surname>
          </string-name>
          , “
          <article-title>Distinctive Image Features from Scale-Invariant Keypoints”</article-title>
          ,
          <source>Int. Journal of Computer Vision</source>
          , Vol.
          <volume>50</volume>
          , No.
          <volume>2</volume>
          ,
          <issue>2004</issue>
          , pp.
          <fpage>91</fpage>
          -
          <lpage>110</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>T.-J. Kim</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          <string-name>
            <surname>Baek</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Chun</surname>
            ,
            <given-names>K.-H.</given-names>
          </string-name>
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>J.-I.</given-names>
          </string-name>
          <string-name>
            <surname>Hwang</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          <string-name>
            <surname>Kwon</surname>
            ,
            <given-names>Y.-H.</given-names>
          </string-name>
          <string-name>
            <surname>Kim</surname>
            , H.-S. Park,
            <given-names>Y.</given-names>
          </string-name>
          <string-name>
            <surname>Shin</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Ryu</surname>
            ,
            <given-names>J.-Y.</given-names>
          </string-name>
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          <string-name>
            <surname>Hwang</surname>
          </string-name>
          , G. Kim, “
          <article-title>A timing controller embedded driver IC with 3.24-Gbps eDP interface for chip-on-glass TFT-LCD applications”</article-title>
          ,
          <source>J SOC INF DISPLAY</source>
          , Vol.
          <volume>24</volume>
          , pp.
          <fpage>299</fpage>
          -
          <lpage>306</lpage>
          ,
          <year>2016</year>
          , doi: 10.1002/jsid.446
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>D.</given-names>
            <surname>Lee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Lee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D. H.</given-names>
            <surname>Baek</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Pae</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Lim</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Y. M.</given-names>
            <surname>Choi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Y. H.</given-names>
            <surname>Lee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.I.</given-names>
            <surname>Lee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Lee</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Nah</surname>
          </string-name>
          and G. Hwang, “
          <article-title>A 1.4-Gbps intra-panel interface with low-power and low-EMI schemes for Tablet PC applications”</article-title>
          ,
          <source>J SOC INF DISPLAY</source>
          , Vol.
          <volume>20</volume>
          , pp.
          <fpage>661</fpage>
          -
          <lpage>668</lpage>
          ,
          <year>2012</year>
          , doi:10.1002/jsid.134
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Ryu</surname>
          </string-name>
          , S.-Y.,
          <string-name>
            <surname>Baek</surname>
          </string-name>
          , D.-H.,
          <string-name>
            <surname>Lim</surname>
          </string-name>
          , H.-W., Han, S.
          <article-title>-</article-title>
          K.,
          <string-name>
            <surname>Ryu</surname>
          </string-name>
          , K.-H.,
          <string-name>
            <surname>Park</surname>
          </string-name>
          , K.-H.,
          <string-name>
            <surname>Park</surname>
          </string-name>
          , J.-Y.,
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>J.-M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kim</surname>
            ,
            <given-names>T-J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lee</surname>
          </string-name>
          , J.-Y., and
          <string-name>
            <surname>Kim</surname>
          </string-name>
          , G.-N.,
          <article-title>“A 13-bit universal column driver for various displays of OLED and LCD”</article-title>
          ,
          <source>J SOC INF DISPLAY</source>
          , Vol.
          <volume>24</volume>
          , pp.
          <fpage>277</fpage>
          -
          <lpage>285</lpage>
          ,
          <year>2016</year>
          , doi: 10.1002/jsid.437
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>M.</given-names>
            <surname>Wittmeir</surname>
          </string-name>
          , “
          <article-title>Image Analysis to Support Functional Safety for Automotive Displays”</article-title>
          ,
          <source>Proceedings of electronic displays Conference</source>
          , WEKA, Munich,
          <year>2018</year>
          , ISBN 978-3-
          <fpage>645</fpage>
          -50169-9
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Boual</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Large</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Buckingham</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Travis</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Munford</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , “
          <article-title>Wedge Displays as Cameras”</article-title>
          ,
          <source>SID Symposium Digest of Technical Papers</source>
          , Vol.
          <volume>37</volume>
          , pp.
          <fpage>1999</fpage>
          -
          <lpage>2002</lpage>
          ,
          <year>2006</year>
          , doi:10.
          <year>1889</year>
          /1.2433445
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>T.</given-names>
            <surname>Nishibe</surname>
          </string-name>
          and
          <string-name>
            <given-names>H.</given-names>
            <surname>Nakamura</surname>
          </string-name>
          , “
          <article-title>Value-added integration of functions for silicon-on-glass (SOG) based on LTPS technologies”</article-title>
          ,
          <source>J SOC INF DISPLAY</source>
          , Vol.
          <volume>15</volume>
          , pp.
          <fpage>151</fpage>
          -
          <lpage>156</lpage>
          ,
          <year>2007</year>
          , doi:10.
          <year>1889</year>
          /1.2709736
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>