Suchen

Modellbasiertes Design Videoverarbeitung schneller optimiert

| Autor / Redakteur: Dave Jackson, Bruce Tannenbaum* / Holger Heller

Leistungs- und Preisvorgaben sowie eng gesteckte Zeitrahmen einzuhalten, sind eine Herausforderung in der Entwicklung video- und bildverarbeitender Embedded-Systeme. Herkömmliche Ansätze wie die Programmierung von Hand sind zeitraubend, fehleranfällig und schwer optimierbar. Das modellbasierte Design bei Videoüberwachungssystemen spart Zeit und verringert die Fehlerrate.

Firmen zum Thema

( Archiv: Vogel Business Media )

Herkömmliche Ansätze beim Design video- und bildverarbeitender Embedded-Systeme stützen sich auf schriftlich niedergelegte Spezifikationen und die Programmierung von Hand. Schriftliche Spezifikationen lassen sich aber nur schwer über eine Reihe von Entwurfsiterationen hinweg verwalten und sind oft nicht eindeutig, was mehr Besprechungen zwischen System- und Implementierungsteams erfordert, und u.U. entsteht ein Produkt, das nicht mit der eigentlichen Spezifikation übereinstimmt.

Durch die manuelle Programmierung muss der Entwurf bei jedem Einzelschritt neu geschrieben, kompiliert, getestet und fehlerbereinigt werden. Jede Veränderung am Hardwareentwurf hat eine umfangreiche Neuprogrammierung zur Folge, die es oft einfacher macht, wieder ganz von vorne anzufangen.

Bildergalerie

Die modellbasierte Entwicklung ermöglicht einen hierarchischen Ansatz, in dem der Entwurf zu Anfang auf einer sehr abstrakten Ebene definiert wird, worauf nach und nach, je nach Erforderlichkeit, Blöcke hinzugefügt werden, die die funktionellen Details in immer größerer Tiefe darstellen. Die Entwickler können so rasch ein grafisches Modell aufbauen, das aus vorgefertigten Grundbausteinen und hoch entwickelten Algorithmen besteht und in das selbst geschriebener C-Code nur dann eingefügt wird, wenn sich dies als unbedingt notwendig erweist.

Das Modell entwickelt sich so zu einer ausführbaren Spezifikation, die der Entwickler schnell verändern kann und die sich leicht durch eine Simulation auf der Entwicklungshardware testen lässt, wobei die Ergebnisse unmittelbar angezeigt werden können. Weil dieses Modell unabhängig von einer bestimmten Target-Hardware entwickelt wird, kann es leicht auf eine andere Target-Plattform übertragen und in künftigen Systemen wiederverwendet werden.

Entwicklung eines Videoverarbeitungssystems

Das als Beispiel verwendete Videoüberwachungssystem wurde als Teil eines Sicherheitssystems entwickelt und muss deshalb große Datenmengen schnell verarbeiten. Es nutzt eine einfache Methode zur Bewegungsdetektion durch Vergleich aufeinander folgender Frames, die sich auf Festkommahardware implementieren lässt. Eine im Blickfeld der Kamera festgestellte Bewegung speichert die betroffenen Frames. Um festzustellen, wie viele Pixel sich in benachbarten Frames verändert haben, kommt die Methode der absoluten Differenzen zum Einsatz. Nur Frames, deren Unterschiede eine bestimmte, einstellbare Schwelle überschreiten, werden gespeichert. Auf diese Weise verringern sich die Anforderungen an die Speicherkapazität des Systems.

Der Systementwurf wurde in der Simulink-Umgebung von The MathWorks vorgenommen. Die Implementierung begann mit einem rohen Blockdiagramm, das im Verlauf des Entwicklungsprozesses immer detaillierter ausgearbeitet wurde. Das Modell wurde durch einfaches „Drag-and-Drop“ von Video- und Bildverarbeitungsblöcken aus dem neuen Video and Image Processing Blockset erweitert. Dieses Blockset enthält eine Auswahl von Grundelementen und Algorithmen, die sich zum Aufbau einer großen Bandbreite bildverarbeitender Embedded-Systeme eignen.

Die Betriebsparameter wurden durch einfache Auswahl verschiedener Optionen in einer Dialogbox verändert. Die Bandbreite des Videoeingangs wurde auf 8-Bit-Integer ohne Vorzeichen gesetzt, der Ausgang dagegen auf 32-Bit-Integer. Das Subsystem zur Bestimmung der Bewegungsenergie, in dem der absolute Differenzalgorithmus untergebracht ist, unterstützt sowohl Fest- als auch Fließkommadaten.

Framegrößenvergleich über Schwellenwert

Dieses Subsystem stellt fest, ob der Unterschied zwischen zwei Frames größer als der festgelegte Schwellenwert ist. Der Sample-and-Hold-Block hält dann Frames fest, deren Bewegung den Schwellenwert überschreitet und speist sie in den Global-Switch-Block ein. Ein zentraler Parameter in diesem Block erlaubt es, den Trigger auf die ansteigende oder abfallende Flanke einzustellen. Durch diesen Block ist es möglich, zwischen dem komprimierten Videostrom und dem Videostrom mit absoluten Differenzen hin- und herzuschalten und so einen eingehenderen Echtzeit-Test durchzuführen (Bild 1).

Der Motion Frame Counter zählt, wie viele der im komprimierten Strom vorhandenen Frames die Schwelle für eine mutmaßliche Bewegung überschritten haben. Hierbei wird Entwicklungszeit eingespart, indem jeder Block den Datentyp des jeweils vorhergehenden übernimmt. Die automatische Verwaltung der Datentypen sorgt dafür, dass der Datentyp eines Blocks automatisch verändert wird, wenn sich der Datentyp des vorangehenden Blocks ändert. Der Entwickler kann sich so ganz auf den Genauigkeitsgrad konzentrieren, während die Entwicklungsumgebung sich völlig selbstständig um die Details der zu Grunde liegenden Berechnungen kümmert.

An jedem Punkt des Entwicklungsprozesses lassen sich Simulationen durchführen, die die Leistung, die Ergebnisgenauigkeit und einige weitere Systemparameter feststellen. Durch einen Video-Viewer und Anzeigeblöcke ist es möglich, sich den Videostrom an jedem Ort im Modell in Echtzeit anzusehen. Außerdem lässt sich der Videodatenstrom live an ein anderes Ausgabegerät weitergeben.

Es lassen sich daher schnell Veränderungen durchführen, indem man Blöcke einfügt, herausnimmt oder bewegt oder indem man Parameter verändert und dann sofort die Auswirkungen dieser Maßnahmen begutachtet. Die Definition eines Systems mit Hilfe von Blöcken ist natürlich schneller als die Programmierung per Hand, der eigentliche Vorteil der modellbasierten Entwicklung liegt jedoch in der Möglichkeit, in jeder beliebigen Entwicklungsphase Simulationen durchführen und umgehend deren Ergebnisse auswerten zu können.

Kompilierung für spezifische Hardwareplattformen

Sobald das System in Form eines Modells definiert wurde, kann der Entwickler automatisch C-Code erzeugen und den Entwurf auf einem Embedded-System ausführen. Der Hardwareprototyp lässt sich sofort im Echtzeitbetrieb begutachten. In diesem Beispiel war das Target des Entwurfs ein auf hohen Durchsatz hin optimierter C6416-Festkomma-DSP von Texas Instruments in der Code-Composer-Studio-Umgebung. Die modellbasierte Entwicklung ermöglichte hier Algorithmentests, Parametertuning und einen schnellen „Proof of Concept“ auf dem DSP.

Der erste Schritt bei der Ansteuerung des TI-DSK-Boards bestand darin, die Treiber so zu verändern, dass das Modell optimal für TIs Echtzeit-Datenaustausch (Real Time Data Exchange, RTDX) vorbereitet war, der die bidirektionale Kommunikation zwischen dem Code Compiler Studio auf der Hostseite und der Targetanwendung ermöglicht. Der ‚Link for Code Composer Studio‘ (von The MathWorks) enthält Komponenten, die das DSK-Board unterstützen wie z.B. RTDX Input/Output, Codex, LEDs und Schalter. Der nächste Schritt war die Festsetzung der Targetoptionen wie etwa DSP/BIOS- und Compilereinstellungen (Bild 2).

Nun wurde mit Hilfe des Link for Code Composer Studio ein Datentransfer zwischen Simulink und dem Code Composer Studio eingerichtet. Das Link for Code Computer Studio erweitert MATLAB um eine Unterstützung für die Code-Composer-Studio-Umgebung. Daneben ermöglicht es aber auch das Laden, Ausführen und Stoppen von Projekten, das Einfügen von Debug-Points, die Datenmanipulation, Hardware-in-the-Loop-Simulationen und Ko-Simulationen und es verfügt über eine RTDX-Unterstützung. Während des gesamten Test- und Debuggingprozesses übernimmt die Anwendung die Kontrolle über das Code Composer Studio und ermöglicht den Echtzeit-Datenaustausch mit der laufenden Targetanwendung.

Echtzeit-Datenaustausch mit dem Target

Ein weiteres Produkt von The MathWorks, der Real-Time Workshop, wurde zur automatischen Generierung des Programmcodes aus dem Modell des Überwachungssystems und zum nachfolgenden ebenfalls automatischen Laden in Code Composer Studio eingesetzt. Das Code Composer Studio baut ein Echtzeit-Betriebssystem und einen Scheduler in das Programm ein, erzeugt das gesamte Projekt in der integrierten Entwicklungsumgebung, fügt den Compiler und Linker ein, lädt den Code herunter und betreibt das Target. Der von Simulink generierte C-Code zeichnet sich normalerweise durch hohe Leistung aus, Simulink enthält aber auch TI-Bibliotheken, mit deren Hilfe sich auf einfache Weise Assembler-Code erzeugen lässt, der dann für die jeweils verwendete Hardware optimiert ist.

Danach wurde mit Hilfe von Simulink automatisch ein Profil des auf dem DSP laufenden Programms erstellt. In diesem Fall zeigte das Profil, dass das gesamte System, inklusive DSP-Anwendung, RTDX-Datenübertragung und Scheduler, etwa 20% der Systemressourcen benötigte und der Bewegungserkennungsalgorithmus nur etwa 4%. Das sprach dafür, dass der Chip mit Leichtigkeit mehr als zehn Kameras versorgen kann, die mit dieser Anwendung laufen.

Um das System zu testen, sahen sich die Entwickler die komprimierten und unkomprimierten Videoströme nebeneinander in verschiedenen Fenstern an, um den Systembetrieb zu verifizieren. Dank Simulink und Code Composer Studio war es möglich, die Ausgabe der Embedded-Anwendung direkt und in Echtzeit mit der ursprünglichen Simulation zu vergleichen. Diskrepanzen zwischen dem Ausgangsmodell und der Hardwareimplementierung ließen sich so auf einfache Weise feststellen und beseitigen.

Aufbau und Test neuer Iterationen

Nachdem die erste Iteration fertiggestellt und getestet war, konnten die Entwickler den Entwurf verfeinern und die Parameter optimieren. Sie konnten z.B. den Schwellenwert für relevante Videoframes besser einstellen, indem sie mehr Testdaten verwendeten, die die erwarteten Realbedingungen simulierten. Um den entsprechenden Parameter anzupassen, gingen die Entwickler in das Blockset für den Bewegungsgrenzwert, sahen sich die Unterschiede zwischen den Frames an, änderten den Schwellenwert und sahen sich die Ergebnisse auf den Videomonitoren und in den Framezählern an. In nur wenigen Minuten konnten sie so einen Schwellenwert einstellen, bei dem das System durch einen vorbeigehenden Menschen ausgelöst wurde, nicht jedoch durch eine Katze. Der letzte Schritt bestand nun darin, den Code für das endgültige Target zu kompilieren, in diesem Fall ein DM642-DSP, der für den abschließenden Prototypen ausgewählt worden war.

Um eine solche Optimierung erfolgreich durchzuführen, hätte es mit Hilfe herkömmlicher Entwicklungsmethoden einer ganzen Reihe von Iterationen bedurft, bei denen immer wieder der Schwellenwert im Programmcode verändert worden wäre, eine Neukompilierung stattgefunden hätte und die Anwendung erneut ausgeführt worden wäre. Dank der modellbasierten Entwicklung ist es dagegen möglich, in nur wenigen Sekunden Iterationen an Parametern durchzuführen, die sich in Echtzeit manipulieren lassen. Für alle anderen Parameter werden lediglich Minuten benötigt. Dadurch lassen sich erheblich mehr Iterationen sinnvoll durchführen, wodurch das Endresultat wirklich als optimal bezeichnet werden kann und nicht nur als „ganz in Ordnung“.

*Dave Jackson ist Product Marketing Manager für Video & Signal Processing Applications; Bruce Tannenbaum ist Technical Marketing Manager für Image Processing Applications, bei The MathWorks, Natick, Massachusetts.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de (ID: 221034)