<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Neue Ansätze und Methoden für die Fehlermodellierung und -behandlung bei automobilen Videodatenübertragungsstrecken</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Jan</forename><surname>Bauer</surname></persName>
							<email>jan.j.bauer@daimler.com</email>
							<affiliation key="aff0">
								<orgName type="institution">Daimler AG Stuttgart</orgName>
								<address>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Andreas</forename><surname>Hudak</surname></persName>
							<email>andreas.hudak@stz-es.com</email>
							<affiliation key="aff1">
								<orgName type="institution">STZ Electronic Systems GmbH Mühlacker</orgName>
								<address>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Karlheinz</forename><surname>Blankenbach</surname></persName>
							<email>karlheinz.blankenbach@hs-pforzheim.de</email>
							<affiliation key="aff2">
								<orgName type="institution">Hochschule Pforzheim Pforzheim</orgName>
								<address>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Frank</forename><surname>Langner</surname></persName>
							<affiliation key="aff3">
								<orgName type="institution">Daimler AG Stuttgart</orgName>
								<address>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Chihao</forename><surname>Xu</surname></persName>
							<email>chihao.xu@lme.uni-saarland.de</email>
							<affiliation key="aff4">
								<orgName type="institution">Universität des Saarlandes Saarbrücken</orgName>
								<address>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Mirko</forename><surname>Conrad</surname></persName>
							<email>mirko.conrad@samoconsult.de</email>
							<affiliation key="aff5">
								<orgName type="institution">samoconsult GmbH</orgName>
								<address>
									<settlement>Berlin</settlement>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Matthäus</forename><surname>Vogelmann</surname></persName>
							<email>matthaeus.vogelmann@hs-pforzheim.de</email>
							<affiliation key="aff6">
								<orgName type="institution">Hochschule Pforzheim Pforzheim</orgName>
								<address>
									<country key="DE">Germany</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Neue Ansätze und Methoden für die Fehlermodellierung und -behandlung bei automobilen Videodatenübertragungsstrecken</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">F12B00E12B7282167D177FBFC6F42B54</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T16:01+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Camera Monitor Systems (CMS)</term>
					<term>Video Data Transmission</term>
					<term>Fault Model</term>
					<term>Functional Safety</term>
					<term>ISO 26262</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Camera monitor systems and the associated digital transmission of video data are increasingly being used in safety-relevant automotive systems. To avoid safety-related malfunctioning behavior, these systems must be protected against faults and failures. This paper proposes a fault model for video data transmission and outlines possible safety mechanisms to detect and handle faults in video links</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Um eine hohe Fehleraufdeckung zu gewährleisten, müssen die folgenden Ausfallarten berücksichtigt werden:</p><p>• Informationsverfälschung (corruption of information)</p><p>• Informationsverlust (loss of information) • fehlerhafte Informationsabfolge (incorrect sequence of information) • Informationswiederholung (repetition of information)</p><p>• Hinzufügen von Information (insertion of information) 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. <ref type="figure">1</ref>). 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. <ref type="figure">1</ref> 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. 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></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>(S) Sender</head><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><formula xml:id="formula_0">• FM01: Bildverfälschung • FM02: Bildverlust • FM03: fehlerhafte Bildabfolge • FM04: Bildwiederholung • FM05:</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>A. Absicherung des Übertragungskanals (T)</head><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:    Eine probate Methode, die Datenintegrität einer Bildübertragung mit Bildverarbeitung (vgl. Fig. <ref type="figure">1</ref>) 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><formula xml:id="formula_1">• Verbindungsunterbrechung • Kurzschluss nach</formula></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>h : I → E</head><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 Hash-Wert von E''.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>h : I'' → E''</head><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.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>D. Komponentenübergreifende Absicherung: Watermarking</head><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.    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. <ref type="figure" target="#fig_8">5</ref>). 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.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head></head><label></label><figDesc>I. EINLEITUNG 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. 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. 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. 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. 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. 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. 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. 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. 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. II. ABLEITUNG EINES FEHLERMODELLS FÜR DIE ÜBERTRAGUNG VON VIDEODATEN 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). Für die klassische Datenübertragung kann ein solches Fehlermodell aus der Funktionssicherheitsnorm ISO 26262 [12] abgeleitet werden.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>1 ,Fig. 1 .</head><label>11</label><figDesc>Fig. 1. Modell der Videodatenübertragungsstrecke</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head></head><label></label><figDesc>Hinzufügen von Bildern • FM06: Bildverzögerung • FM07: Maskeradefehler oder fehlerhafte Adressierung • FM08: Nichtempfang oder nichtintendierter Empfang von Bilden • FM09: Verhinderung des Zugriffs auf eine Bildübertragungsstrecke Darüber hinaus wurden weitere videospezifische Ausfallarten identifiziert, die ebenfalls berücksichtigt werden müssen. Hierzu gehören z.B.: • FM10: eingefrorenes Bild (frozen image) • 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) III. SICHERHEITSMECHANISMEN 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. 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).</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head></head><label></label><figDesc>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 PD = f ( QTP ) GD = f ( QTP ) B. Absicherung des Empfängers (R) 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. 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: • Optoelektronischer Ansatz: optoelektronische Erfassung der Emission des Displays • Elektrischer Ansatz: Messung von elektrischen Größen (bspw. Stromverbrauch) und Überwachung der Daten-Signale im Display-Modul 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. 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. Eine abgewandelte Methode ist die Erfassung der optischen Ausgabe mittels eines auf das Displayglas aufgebrachten Wedge-Lightguide [7]. 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). 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 [8] bereits bei der Herstellung des elektrooptischen Wandler (z.B. LCD) integriert werden muss. Dieser Ansatz rechnet sich nur bei höchsten Stückzahlen. 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.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_4"><head>Fig. 2 .</head><label>2</label><figDesc>Fig. 2. Transparentes OLED mit der Möglichkeit zur optischen Überwachung des Displayinhaltes von der Panel-Rückseite 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: • Das Display Interface (De-Serializer) empfängt die darzustellenden Daten über eine serielle Schnittstelle (ähnlich HDMI) und wandelt diese typischerweise auf LVDS Signale für den Timing Controller um. • Der Timing Controller (TCON, z.B. [1]) formatiert den Input-Bilddatenstrom in Signale (z.B. [4]) für Zeilen-(row driver) und Spaltentreiber (column driver) um. • Die Zeilentreiber steuern eine Zeile nach der anderen an, während die Spaltentreiber (z.B. [5]) die zugehörigen Graustufen-Daten einspielen. • Der Gamma-und VCOM-Buffer stellt LCDspezifische Spannungen zur Verfügung. • Das LCD-Backlight stellt die Lichtquelle des LCDs dar. Naheliegende Ansätze zur Fehlererkennung und -analyse sind die Spannungs-, Strom-, Leistungs-und Signal-Überwachungen aller oben aufgeführten Panelelektronik-Komponenten. 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</figDesc><graphic coords="4,310.55,289.90,235.45,94.60" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_5"><head>Fig. 3 .</head><label>3</label><figDesc>Fig. 3. Typisches Blockschaltbild eines LCD-Displaymoduls 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. 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 [6]. In Summe existiert displayseitig eine Vielzahl von Mechanismen zur Fehlererkennung mit unterschiedlicher Effektivität und sehr unterschiedlichen Kostenindikationen. 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. 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. 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.</figDesc><graphic coords="5,52.55,92.15,228.95,122.05" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_6"><head></head><label></label><figDesc>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<ref type="bibr" target="#b12">[14]</ref> 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]: Der Erkennungsprozess kann dann über den folgenden Zusammenhang erfolgen [11]: 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. 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). 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. 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. IV. SICHERHEITSKONZEPT AUF SYSTEMEBENE Systemabhängig muss die Umsetzung der einzelnen komponentenbezogenen und übergreifenden Absicherungsmechanismen auf Systemebene geeignet kombiniert und orchestriert werden. 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. 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. Anwendungsabhängig können dabei typischerweise folgende sicheren Zustände unterschieden werden: • SZ01: keine Bilddarstellung • 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) 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). 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. Viele der in III. definierten Fehlererkennungsmechanismen können so implementiert werden, dass sie Kenngrößen für einen systeminternen Test (Built-In-Self-Test, 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. 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.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_7"><head>Fig. 4 .</head><label>4</label><figDesc>Fig. 4. Modell der SicherheitsarchitekturDie 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).</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_8"><head>Fig. 5 .</head><label>5</label><figDesc>Fig. 5. Vorgehensweise zur Auswahl geeigneter Sicherheitsmechanismen</figDesc><graphic coords="7,45.35,446.30,235.45,275.00" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_1"><head></head><label></label><figDesc>Eine Graceful Degradation kann bspw. durch eine auf der Qualitätsbewertung QTP basierende Anpassung des Bandbreitenbedarfs per Reduktion der Auflösung oder Bildwiederholrate erfolgen.</figDesc><table><row><cell>werden. Mögliche Fehlerbehandlungsmechanismen sind</cell></row><row><cell>bspw. die präventive Abschaltung von betroffenen</cell></row><row><cell>Funktionen (PD) oder eine abgestufte Funktionsreduktion</cell></row><row><cell>(Graceful Degradation, GD). Ziele der weiteren Arbeiten zur Absicherung der</cell></row><row><cell>physikalischen Übertragung sind zum einen die Definition</cell></row><row><cell>geeigneter Funktionen zur Qualitätsbewertung auf Basis der</cell></row><row><cell>einzelnen Qualitätsparameter</cell></row><row><cell>Masse</cell></row><row><cell>• Kurzschluss zur Versorgungsspannung (oder anderen</cell></row><row><cell>Spannungen)</cell></row><row><cell>• Kurzschluss zwischen den Übertragungsleitungen</cell></row><row><cell>• erhöhter Leitungswiderstand zwischen Sender und</cell></row><row><cell>Empfänger</cell></row><row><cell>• fehlerhafter Leitungsabschluss</cell></row><row><cell>Besteht eine physikalische Verbindung, kann bspw. über</cell></row><row><cell>die Aussendung eines Testsignals vom Sender zum</cell></row><row><cell>Empfänger, den dortigen Empfang und die Rückmeldung an</cell></row><row><cell>den Sender die logische Verbindung beidseitig überprüft</cell></row><row><cell>werden. Der Zustand der logischen Verbindung wird in</cell></row><row><cell>vielen automotive Übertragungssystemen mit einem Link-</cell></row><row><cell>Lock signalisiert.</cell></row><row><cell>Die Übertragung der Videodaten über einen Über-</cell></row><row><cell>tragungskanal kann durch Error-Detection Codes (EDC),</cell></row><row><cell>bspw. die Verwendung eines Cyclic Redundancy Checks</cell></row><row><cell>(CRC), abgesichert werden. Auf diese Weise können</cell></row><row><cell>eventuelle elektro-magnetische Störungen auf der Video-</cell></row><row><cell>übertragungsstrecke erkannt werden. Die Verwendung von</cell></row><row><cell>Error-Correction Codes (ECC) erlaubt eine Forward Error</cell></row><row><cell>Correction (FEC), also eine automatische Korrektur</cell></row><row><cell>bestimmter Übertragungsfehler.</cell></row><row><cell>Neben der Möglichkeit, Fehler zu erkennen bzw. zu</cell></row><row><cell>korrigieren, können aus den genannten Verfahren die</cell></row><row><cell>aktuelle Anzahl der Übertragungsfehler aus der CRC-</cell></row><row><cell>Auswertung (FCRC) bzw. Anzahl der Fehlerkorrekturen</cell></row><row><cell>(CFEC) abgeleitet werden und als Messgröße für die Qualität</cell></row><row><cell>der physikalischen Verbindung QTP verwendet werden. Diese</cell></row><row><cell>Qualitätsbewertung der physikalischen Verbindung QTP kann</cell></row><row><cell>durch Messung der physikalischen Empfangseigenschaften</cell></row><row><cell>wie bspw. der vertikalen, horizontalen Augenöffnung (A, B)</cell></row><row><cell>erweitert werden.</cell></row><row><cell>Darüber hinaus verwenden heutige Videoübertragungs-</cell></row><row><cell>strecken Ausgleichsfilter auf Frequenzbasis (Equalizer) zum</cell></row><row><cell>Ausgleich der frequenzabhängigen Dämpfung auf der</cell></row><row><cell>Übertragungsstrecke. Der Abstand der aktuellen zur</cell></row><row><cell>maximal möglichen Aussteuerung dieser Filter über die</cell></row><row><cell>Frequenz ∆D(f) kann als weiterer Parameter für die Quali-</cell></row><row><cell>tätsbewertung der Übertragungsstrecke genutzt werden.</cell></row><row><cell>Wird ein zu definierender Schwellwert für die Qualität</cell></row><row><cell>der Übertragungsstrecke QTP unterschritten, können dann</cell></row><row><cell>entsprechende Fehlerbehandlungsmechanismen aktiviert</cell></row></table></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" type="table" xml:id="tab_2"><head></head><label></label><figDesc>Als Vertreter dieser Kategorie sollen hier die 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.</figDesc><table><row><cell>Absicherung</cell><cell>sicherheitsrelevanter</cell><cell>Inhalte</cell><cell>mittels</cell></row><row><cell cols="4">Wasserzeichen und die Absicherung der zeitlichen</cell></row><row><cell cols="2">Synchronität betrachtet werden.</cell><cell></cell><cell></cell></row><row><cell cols="4">Je nach Video Use-Case kann ein erzeugter Videoinhalt</cell></row><row><cell cols="4">sicherheitsrelevant sein. Derartige Inhalte werden im</cell></row><row><cell cols="4">Rahmen des sicherheitsgerichteten Entwicklungsprozesses</cell></row><row><cell cols="2">gemäß ISO 26262 definiert.</cell><cell></cell><cell></cell></row></table></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" xml:id="foot_0">ASE 2019: 16th Workshop on Automotive Software Engineering @ SE19, Stuttgart, Germany</note>
		</body>
		<back>
			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">ORB: and efficient alternative to SIFT or SURF</title>
		<author>
			<persName><forename type="first">E</forename><surname>Rublee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">V</forename><surname>Rabaud</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Konolige</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Bradski</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">IEEE Int. Conf. on Computer Vision</title>
				<imprint>
			<date type="published" when="2011">2011</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Distinctive Image Features from Scale-Invariant Keypoints</title>
		<author>
			<persName><forename type="first">D</forename><forename type="middle">G</forename><surname>Lowe</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Int. Journal of Computer Vision</title>
		<imprint>
			<biblScope unit="volume">50</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page" from="91" to="110" />
			<date type="published" when="2004">2004</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">A timing controller embedded driver IC with 3.24-Gbps eDP interface for chip-on-glass TFT-LCD applications</title>
		<author>
			<persName><forename type="first">T.-J</forename><surname>Kim</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Baek</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Chun</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K.-H</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J.-I</forename><surname>Hwang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Kwon</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y.-H</forename><surname>Kim</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H.-S</forename><surname>Park</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><surname>Shin</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Ryu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J.-Y</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Hwang</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Kim</surname></persName>
		</author>
		<idno type="DOI">10.1002/jsid.446</idno>
	</analytic>
	<monogr>
		<title level="j">J SOC INF DISPLAY</title>
		<imprint>
			<biblScope unit="volume">24</biblScope>
			<biblScope unit="page" from="299" to="306" />
			<date type="published" when="2016">2016</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">A 1.4-Gbps intra-panel interface with low-power and low-EMI schemes for Tablet PC applications</title>
		<author>
			<persName><forename type="first">D</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D</forename><forename type="middle">H</forename><surname>Baek</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Pae</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Lim</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><forename type="middle">M</forename><surname>Choi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Y</forename><forename type="middle">H</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><forename type="middle">I</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K</forename><surname>Nah</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Hwang</surname></persName>
		</author>
		<idno type="DOI">10.1002/jsid.134</idno>
	</analytic>
	<monogr>
		<title level="j">J SOC INF DISPLAY</title>
		<imprint>
			<biblScope unit="volume">20</biblScope>
			<biblScope unit="page" from="661" to="668" />
			<date type="published" when="2012">2012</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">A 13-bit universal column driver for various displays of OLED and LCD</title>
		<author>
			<persName><forename type="first">S.-Y</forename><surname>Ryu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">D.-H</forename><surname>Baek</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H.-W</forename><surname>Lim</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S.-K</forename><surname>Han</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K.-H</forename><surname>Ryu</surname></persName>
		</author>
		<author>
			<persName><forename type="first">K.-H</forename><surname>Park</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J.-Y</forename><surname>Park</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J.-M</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T-J</forename><surname>Kim</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J.-Y</forename><surname>Lee</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G.-N</forename><surname>Kim</surname></persName>
		</author>
		<idno type="DOI">10.1002/jsid.437</idno>
	</analytic>
	<monogr>
		<title level="j">J SOC INF DISPLAY</title>
		<imprint>
			<biblScope unit="volume">24</biblScope>
			<biblScope unit="page" from="277" to="285" />
			<date type="published" when="2016">2016</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Image Analysis to Support Functional Safety for Automotive Displays</title>
		<author>
			<persName><forename type="first">M</forename><surname>Wittmeir</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of electronic displays Conference</title>
				<meeting>electronic displays Conference<address><addrLine>WEKA, Munich</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2018">2018</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<analytic>
		<title level="a" type="main">Wedge Displays as Cameras</title>
		<author>
			<persName><forename type="first">S</forename><surname>Boual</surname></persName>
		</author>
		<author>
			<persName><forename type="first">T</forename><surname>Large</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Buckingham</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Travis</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Munford</surname></persName>
		</author>
		<idno type="DOI">10.1889/1.2433445</idno>
	</analytic>
	<monogr>
		<title level="j">SID Symposium Digest of Technical Papers</title>
		<imprint>
			<biblScope unit="volume">37</biblScope>
			<biblScope unit="page" from="1999" to="2002" />
			<date type="published" when="2006">2006</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<analytic>
		<title level="a" type="main">Value-added integration of functions for silicon-on-glass (SOG) based on LTPS technologies</title>
		<author>
			<persName><forename type="first">T</forename><surname>Nishibe</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Nakamura</surname></persName>
		</author>
		<idno type="DOI">10.1889/1.2709736</idno>
	</analytic>
	<monogr>
		<title level="j">J SOC INF DISPLAY</title>
		<imprint>
			<biblScope unit="volume">15</biblScope>
			<biblScope unit="page" from="151" to="156" />
			<date type="published" when="2007">2007</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<monogr>
		<title level="m" type="main">A Mathematical Foundation for Watermarking</title>
		<author>
			<persName><forename type="first">N</forename><surname>Boston</surname></persName>
		</author>
		<ptr target="http://www.math.wisc.edu/~boston/bostonpreps.html" />
		<imprint/>
	</monogr>
	<note type="report_type">Preprint</note>
</biblStruct>

<biblStruct xml:id="b9">
	<analytic>
		<title level="a" type="main">Information hiding by coverings</title>
		<author>
			<persName><forename type="first">Fabien</forename><surname>Galand</surname></persName>
		</author>
		<author>
			<persName><forename type="first">Gregory</forename><surname>Kabatiansky</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Information Theory Workshop</title>
				<imprint>
			<publisher>IEEE</publisher>
			<date type="published" when="2003">2003. 2003</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b10">
	<analytic>
		<title level="a" type="main">Information Hiding -A Survey</title>
		<author>
			<persName><forename type="first">F</forename><surname>Petitcolas</surname></persName>
		</author>
		<author>
			<persName><forename type="first">R</forename><surname>Anderson</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Kuhn</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the IEEE, special issue on protection of multimedia content</title>
				<meeting>the IEEE, special issue on protection of multimedia content</meeting>
		<imprint>
			<date type="published" when="1999-07">July 1999</date>
			<biblScope unit="volume">87</biblScope>
			<biblScope unit="page" from="1062" to="1078" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b11">
	<monogr>
		<idno>ISO 16505</idno>
		<title level="m">Road Vehicles -Ergonomic and performance aspects of Camera Monitor Systems -Requirements and test procedures</title>
				<imprint>
			<publisher>International Standard</publisher>
			<date type="published" when="2015">2015. 2015</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b12">
	<analytic>
		<title level="a" type="main">A Robust Method for Frozen Frame Detection in Safety Relevant Video Streams Based on Digital Watermarking</title>
		<author>
			<persName><forename type="first">K</forename><surname>Witt</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Bauer</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Electronic Display Conference</title>
				<meeting><address><addrLine>Nuremberg</addrLine></address></meeting>
		<imprint>
			<date type="published" when="2017">2017</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b13">
	<analytic>
		<title level="a" type="main">Functional Safety of Camera Monitor Systems</title>
		<author>
			<persName><forename type="first">B</forename><surname>Kaiser</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Handbook of Camera Monitor Systems -The Automotive Mirror-Replacement Technology based on ISO 16505</title>
				<editor>
			<persName><forename type="first">A</forename><surname>Terzis</surname></persName>
		</editor>
		<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2016">2016</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
