Herzlich Willkommen beim beam-Verlag in Marburg, dem Fachverlag für anspruchsvolle Elektronik-Literatur.


Wir freuen uns, Sie auf unserem ePaper-Kiosk begrüßen zu können.

Aufrufe
vor 7 Jahren

4-2016

  • Text
  • Home
  • Photovoltaik
  • Gebaeudeautomation
  • Hausautomation
  • Licht
  • Lichttechnik
  • Tv
  • Elektroinstallation
  • Zutrittskontrolle
  • Videoueberwachung
  • Gebaeudetechnik
  • Haus
  • Elektronik
  • Sicherheit
  • Beispielsweise
  • Belektro
  • Licht
Zeitschrift für Elektro-, Gebäude- und Sicherheitstechnik, Smart Home

Videoüberwachung Bild

Videoüberwachung Bild 4: Ein per FPGA verarbeiteter Frame mit Überlagerung des Bewegungsvektor-Gitters (unten rechts) ständige Demonstration dieses Algorithmus´ findet sich auf einem der am Schluss genannten Weblinks. Die FPGA- Implementierung stellte die nächste Phase unserer Systementwicklung dar. Eine derartige Implementierung hat ihre spezifischen Herausforderungen, bedingt durch die Tatsache, dass der Video- Ein-/Ausgang und die Frame-Pufferung nun Teil des FPGA-basierten Designs sind. Auch erfordern die meist begrenzten System-Ressourcen und die erzielbare Performance oft gewisse Optimierungen im Design. Unter Berücksichtigung dieser Aspekte und anderer architektonischer Gegebenheiten haben wir unsere FPGAbasierte Implementierung in drei Teilschritten ausgeführt. Als erster Schritt wurde eine generische Echtzeit-Video- Pipeline im FPGA entwickelt, die den notwendigen Video-Input/Output und die Frame-Pufferung übernimmt. Dann, im nächsten Schritt, haben wir spezifische Hardware-Akzeleratoren für den Algorithmus entwickelt. Und als dritten Schritt der Entwicklung wurden diese Elemente integriert sowie die algorithmische Steuerung und der Datenfluss implementiert. Damit war das gesamte FPGA-basierte System- Design komplett. Nun ein näherer Blick auf jeden dieser Einzelschritte. Eine Echtzeit-Video- Pipeline ist der wichtigste Baustein jeder Applikation zur Videoverarbeitung auf FPGA-Plattformen. Eine derartige Pipeline verbirgt das komplexe Speicher-Management in Bezug auf den Video-Ein-/Ausgang und die Frame- Pufferung vor dem Benutzer und bietet eine einfache Schnittstelle zum Zugriff auf die zu verarbeitenden Videoframe-Daten. Obwohl es bereits mehrere fortschrittliche und kommerziell verfügbare Video- Pipelines gibt [3], haben wir uns in diesem Fall für den Bau einer kundenspezifischen Video-Pipeline entschieden. Diese Pipeline wurde auf der Basis des Xilinx EDK erstellt, mit kundenspezifischen Ports für Video Capture und Display, um die anfallenden Video- Ein/Ausgangsdaten zu verarbeiten. Die Pipeline lässt sich sehr einfach auch für andere Xilinx-FPGA-Familien konfigurieren. Der Video-Capture-Port decodiert die Daten des vom Video-A/D-Wandler kommenden Videostroms und puffert sie lokal. Anschließend werden sie an den Hauptspeicher übertragen, um daraus einen Videoframe zu erstellen. Ganz ähnlich codiert der Video- Display-Port die in einem lokalen Puffer vorliegenden Video-Frame-Daten und leitet sie an den Video-D/A-Wandler zur Anzeige weiter. Die Video-Ein-/ Ausgangs-Ports sind mit dem Hauptperipherie-Bus eines MicroBlaze-Host- Prozessors verbunden, der diesen Video-Datentransfer vom und zum Hauptspeicher bewerkstelligt. Die Video-Ports können Interrupts generieren, die den MicroBlaze-Prozessor darüber informieren, dass neue Daten am Video-Eingangs-Port anliegen oder vom Video-Ausgangs-Port angefordert werden. Die Video-Ports führen somit ein „Ping-Pong“-Buffer- Management aus, falls der MicroBlaze nicht in der Lage ist, einen Video-Port sofort zu bedienen, sodass kein Overflow oder Underrun des Puffers eintreten kann. Bild 2 zeigt den Interconnect zwischen den Video-Ports und dem MicroBlaze-Prozessor. Die Video-Ports sind so ausgelegt, dass sie die Zeilennummer des Videosignals, die Halbbild-Information im Falle von Zwischenzeilen-Videocodierung und andere Steuerdaten im Video- Ein-/Ausgangsstrom detektieren bzw. erzeugen. Diese Information wird über die Interrupt-Service-Routinen (ISR) der Video-Ports an den MicroBlaze weitergeleitet, nachdem genügend Video daten vom Video-Eingangs-Port gepuffert wurden, oder wenn sie vom Video-Display-Port angefordert werden. Diese Service-Routinen bewirken dann per DMA den Transfer der Videodaten zwischen den lokalen Speichern der Video-Ports und dem Hauptspeicher. Zusätzlich zu den Video-Port-ISRs gibt es eine Reihe von Video-Frame- Queue-Management-Funktionen, den wir als Video Frame Queue API bezeichnen. Dieses API (Application Programming Interface) interagiert mit den ISRs und der Benutzerapplikation und formt eine Warteschlange aus mehreren Capture- und Display- Frames zur Unterstützung von doppelter oder dreifacher Frame-Pufferung. Eine Benutzerapplikation, die auf dem MicroBlaze läuft, kann einfach mithilfe der Video-Frame-Queue- API-Funktionen einen Video-Capture- Frame annehmen oder einen Video- Display-Frame ausgeben. Bild 3 zeigt diese Funktionen und ihre gestaffelte Hierarchie. Der Einsatz des MicroBlaze als Host- Prozessor zur Verbindung der verschiedenen Systembausteine bietet mehrere Vorteile. So kann man einfach eine Vielzahl von externen Speichern (SRAM, SDRAM etc.) ansteuern, um die Frame-Daten der Video-Ports zu laden oder zu speichern. Ganz ähnlich kann man auch DMA-Controller im EDK zum Transfer von Videodaten zwischen den Video-Ports und dem Hauptspeicher einsetzen. Außerdem haben wir auf diese Weise auch spezielle Hardware-Akzeleratoren mit dem MicroBlaze-Prozessor verbunden. Die Video-Frame-Queue-API-Funktionen vervollständigen zusammen mit den Video-Port-ISRs und den Video- Ein-/Ausgangs-Ports den Aufbau der Pipeline zur Videoverarbeitung. Bild 4 zeigt einen mit dieser Pipeline im FPGA erfassten, verarbeiteten und anschließend angezeigten Video- Frame. Ebenfalls dargestellt ist eine Bild-im-Bild-Funktion mit einer ver- 8 Haus + Elektronik 4/2016

Videoüberwachung kleinerten Darstellung der berechneten Bewegungsvektoren. Ein Hardware- Beschleuniger erschien sinnvoll, denn in dem beschriebenen Algorithmus zur Bewegungs- Klassifizierung ist die zeitraubendste und rechenintensivste Ausgabe die Berechnung der Bewegungsvektoren. Die andere Systemfunktion – die Ausführung der eigentlichen Klassifizierung – involviert keine Verarbeitung auf der Pixel-Ebene und ist deshalb recht einfach zu erzielen. Mit diesem Gedanken beim System- Design haben wir einen geeigneten Hardware-Beschleuniger aufgebaut, der die Bewegungsvektoren berechnet. Wir haben den Akzelerator in RTL (Register Transfer Language) entwickelt, getestet und anschließend synthetisiert, unter Verwendung der Xilinx Vivado HLS und C/C++. Eine der Schlüsseleigenschaften des Vivado-generierten RTL-Codes ist sein weitgehend optimaler Aufbau. Vivado HLS synthetisiert Array-Zugriffe (unter anderem auf die in einem Array gespeicherten Pixeldaten) in den Speicher-Interfaces und generiert automatisch die erforderlichen Adressen per Code-Analyse. Ebenso werden vorberechnete Offsets und Konstanten analysiert, um sogenannte strided (schrittweise) Speicherzugriffe sehr schnell auszuführen. Diese entstehen durch den Datenzugriff auf mehrere Zeilen eines Bildes (wie bei einer 2D-Faltung). Zu den wichtigsten Erwägungen beim Entwurf eines Vivadobasierten Beschleunigers zählen die Parallelisierung der Berechnung der Bewegungsvektoren und die Maximierung des aus dem Hauptspeicher gelesenen Datenumfangs. Zu diesem Zweck setzen wir acht Block-RAMs ein, um die Video-Frame-Daten parallel zu laden und zu speichern. Der Hardware-Akzelerator kann vier Bewegungsvektoren parallel berechnen. Dazu verwendet er alle acht Block- RAMs. Die Datenpumpe vom Hauptspeicher in die Block-RAMs wird vom MicroBlaze per DMA gesteuert. Der per Vivado HLS generierte Hardware-Beschleuniger liefert eine Reihe automatisch erzeugter Handshake- Signale, die beim Start und Stopp des Hardware-Akzelerators gebraucht werden. Zu diesen Signalen zählen die Flags für “Start“, “Busy“, “Idle” und “Done”. Diese Flags werden über die GPIO-Pins an den MicroBlaze geleitet, um das Handshaking auszulösen. Bild 5 zeigt die Verbindungen zwischen dem Hardware-Akzelerator, den acht Block-RAMs und dem Haupt-Peripherie-Bus des MicroBlaze. Die Block- RAMs (SA1, TA1 bis SA4, TA4) sind jeweils 16 KB groß. Jedes Paar aus SA1, TA1 bis SA4, TA4 hält genügend viele Daten zur Berechnung einer vollständigen Zeile von Bewegungsvektoren. Somit gibt der Hardware-Beschleuniger am Ende seines Durchlaufs vier Zeilen von Bewegungsvektoren aus, die wieder in dieselben Speicherplätze der Block-RAMs geschrieben werden. Diese so berechneten Bewegungsvektoren werden anschließend vom MicroBlaze-Prozessor gelesen, der das Ergebnis in seinem Hauptspeicher als Gitterstruktur von Bewegungsvektoren ablegt. (Bild 4 zeigt einen Frame, der mit einem Gitter von Bewegungsvektoren überlagert ist, die in diesem Hardware-Beschleuniger berechnet wurden.) Der Hardware-Beschleuniger arbeitet mit 200 MHz. Die gesamte zur Berechnung der Bewegungsvektoren benötigte Zeit liegt unter 10 ms, einschließlich aller Daten-Transfers vom und zum Speicher. Algorithmus-Steuerung und Datenfluss einzubinden, war der letzte Schritt zur Vervollständigung des Systems. Die Integration dieser beiden Elemente erfolgte mit dem MicroBlaze Host-Prozessor und die Implementierung der Algorithmus-Steuerung und des Datenflusses in einer Anwender- Applikation mit C/C++ und dem Xilinx Software Development Kit (SDK). Die Implementierung der Algorithmus- Steuerung und des Datenflusses im Xilinx SDK erlaubt ein hohes Maß an Design-Flexibilität. Das liegt daran, dass man weitere Hardware-Beschleuniger auf dieselbe Weise entwickeln und integrieren kann, und dabei den notwendigen Steuer- und Datenfluss so modifiziert, dass man neue Hardware-Beschleuniger einsetzen kann. Das Ergebnis ist eine Art softwaregesteuertes und hardware-beschleunigtes System-Design, das so flexibel Bild 5: Vivado-HLS-basierter Hardware-Akzelerator und dessen Verbindungen agiert wie eine reine Software-Implementierung, und dabei eine ebenso hohe Performance bietet wie eine durchgehende Hardware-Implementierung. Der Steuer- und Datenfluss unseres Algorithmus´ zur Klassifizierung von Bewegungsabläufen in einer Menschenmenge beginnt mit der Erfassung eines Video-Frames über die Video-Frame-Queue-API-Funk tionen. Nachdem ein Frame erhalten wurde, transferiert die Nutzer-Applikation die Daten des aktuellen und des vorhergehenden Video-Frames an den Hardware-Akzelerator und löst die Berechnung der Bewegungsvektoren aus. Zu diesem Zeitpunkt berechnet das System die statistischen Eigenschaften des Bewegungsvektors und die Ergebnisse der Klassifizierung in Software. Das ist darin begründet, dass diese Schritte keine Verarbeitung auf der Pixel-Ebene involvieren und nur einen sehr geringen Overhead hinzufügen. Nach der Berechnung der Klassifizierungen werden die Ergebnisse und die Bewegungsvektoren mithilfe der On- Screen-Display-Funktionen auf dem Haus + Elektronik 4/2016 9

hf-praxis

PC & Industrie

© beam-Verlag Dipl.-Ing. Reinhard Birchel