Systemplanung

Wahl der geeigneten CPU

Die gleichzeitige Verarbeitung, Dekodierung und ruckelfreie Darstellung von Videobildern mehrerer Kameras in hoher Qualität und Auflösung stellt sehr große Anforderungen an den Prozessor. Der verwendete Prozessor ist daher besonders ausschlaggebend für die Leistungsfähigkeit des Systems.

Grundsätzlich kann WinCC OA Video mit allen heute gängigen CPUs betrieben werden (von Intel Atom bis i7). Um optimale Ergebnisse erzielen zu können, sollte die verwendete CPU den Befehlssatz SSE2 unterstützen. Wenn viele Videostreams gleichzeitig dekodiert und dargestellt werden sollen, müssen High-End Prozessoren eingesetzt werden.

Beispiel

Mit einem System der folgenden Server-Konfiguration wurden im praktischen Einsatz bei 30-50% CPU-Auslastung 52 Kanäle mit 25fps@3Mbps aufgezeichnet:

• CPU: Intel Xeon E5620 4C/8T 2.40 GHz 12 MB
• Speicherausstattung: 8 GB
• Videomassenspeicher: 64 TByte, 400 Mbps Schreiben im Dauerbetrieb (Realtime-Traffic), <100 Mbps Lesen
• Netzwerk: Gigabit Ethernet
• Betriebsystem: Windows Server x64

Vergleichbare oder bessere High-End Prozessoren können ebenfalls verwendet werden. Beim Vergleich von Prozessoren dürfen nicht nur Typangaben oder Taktfrequenz herangezogen werden, sondern CPU-Benchmarks, bei denen die Prozessoren unter gleichen Lastszenarien miteinander verglichen werden.

Kalkulation des Arbeitsspeichers

Einer Grafikkarte können nur unkomprimierte Daten in Form von Farbinformationen pro Bildpunkt übergeben werden. Daher müssen die vom Sender komprimierten Daten nach Übertragung der digitalen Videodaten von einer Bildquelle zu einem Empfänger zunächst dekodiert werden.

Zur Berechnung des Arbeitsspeichers, der auf Seiten des Empfängers zur Verfügung stehen muss damit ein Videobild dargestellt werden kann, muss berücksichtigt werden wie die Videobilder auf Seiten des Senders digitalisiert wurden. Hierbei sind folgende Punkte wichtig:

Verwendetes Farbmodell

WinCC OA Video ist in der Lage, Videobilder nach den gängigen Standards M-JPEG, H.264 und MPEG-4 zu dekodieren. Alle diese Standards, die in den marktüblichen Video-Encodern eingesetzt werden, verwenden üblicherweise das sogenannte YUV 4:2:0 Farbmodell mit dem Unterformat YV12, bei dem zur Darstellung der Farbinformationen eines Pixels lediglich 12 Bits verwendet werden.

Im WinCC OA Video Video-Decoder muss genügend Arbeitsspeicher bereitgestellt werden, um die dekodierten Videobilder in Form ihrer YUV 4:2:0 Repräsentation speichern zu können. Liegen die YUV Daten im Video-Decoder bereit, so werden sie in den entsprechenden Speicher der Grafikkarte geschrieben, die daraufhin eine Konvertierung in den RGB-Farbraum vornimmt und jeden einzelnen Bildpunkt mit seinem entsprechenden Farbwert zur Anzeige bringt.

Unter Berücksichtigung der Bildauflösung (x*y Pixel) des kodierten Videobildes lässt sich der für alle Bildpunkte benötigte Speicher durch folgende Formel ausdrücken:

Nachdem nun bekannt ist, wie viel Speicher für die einzelnen Bildpunkte eines Videobildes bereitgestellt werden müssen, sind noch einige Implementierungsdetails des WinCC OA Video-Decoders zu berücksichtigen, um den tatsächlich benötigten Arbeitsspeicher berechnen zu können:

Speicherpools

WinCC OA Video verwendet mehrere Speicherpools. Der Prozess des Anlegens und Freigebens von benötigtem Speicherbereich wirkt sich sehr stark auf die Performance aus. Daher werden im WinCC OA Video Decoder mehrere Speicherpools mit festen Blockgrößen angelegt, aus dem der Video Decoder seinen Speicher beziehen kann. Hierbei werden für die gängigen Bildauflösungen (CIF, 4CIF, Half HD, Full HD, etc.) feste Blockgrößen definiert und der entsprechende Speicher einmalig angelegt.

Benötigt nun der Video-Decoder für ein Videobild eine bestimmte Speichergröße, so wird ihm nicht ein Speicher mit der exakten Größe, sondern stattdessen ein Speicherblock aus dem Speicherpool mit der nächst größeren Blockgröße zugewiesen. WinCC OA Video stellt für die gängigen Auflösungen je einen Speicherpool mit den folgenden Blockgrößen bereit:

Die Größe des zurückgegeben Speichers, in der ein Bild (ein Frame) intern gespeichert wird, soll an dieser Stelle durch die folgende Formel ausgedrückt werden:

GoP Länge

Bei der Videokomprimierung werden in der Regel aufeinanderfolgende Einzelbilder des Bilderstromes einer Kamera zu einer Gruppe von untereinander abhängigen Bildern zusammengefasst und diese Gruppen komprimiert und kodiert.

Diese Gruppen von untereinander kodierten, aufeinanderfolgenden Einzelbildern werden als Group Of Pictures (GoP) bezeichnet. Einige Bilder werden dabei als Referenzbilder kodiert (I-Frames), andere wiederum werden nur als Differenzbilder zu diesem Referenzbild kodiert (P-frames und B-frames). Die sogenannte GOP Länge (GoP size oder GoP length) gibt den Abstand zwischen zwei I-Frames an. Dieser Wert beeinflusst auch den auf Seiten des Empfängers benötigten Arbeitsspeicher.

Der Grund dafür ist, dass WinCC OA Video beim Playback (vorwärts und rückwärts) eines Videostreams eine bildgenaue Positionierung ermöglicht, selbst an den Positionen, an denen nur Differenzbilder vorliegen. Um diese Positionierung realisieren zu können, muss der Video-Decoder allerdings drei komplette GoPs im Speicher halten, was bedeutet, das für jedes dekodierte Frame aus den drei GoPs der Speicher bereitgestellt werden muss.

Übliche GoP Längen im CCTV Umfeld sind 25 bis 30 frames. Auf Grund der beschriebenen Zwischenspeicherung von mehreren GoPs begrenzt WinCC OA Video die GoP Länge auf 100 frames.

Der benötigte Speicher für einen Playbackkanal lässt sich also durch folgende Formel ausdrücken:

Im Falle der Darstellung eines Live-Videostreams wird dagegen maximal eine GOP im Speicher gehalten, daher wird hier weniger Arbeitsspeicher benötigt:

Zusammenfassung:

Der insgesamt benötigte Arbeitsspeicher für die gleichzeitige Darstellung von L Live-Kanälen und P Playbackkanälen bei einer festen Auflösung beträgt daher:

und ausgedrückt durch die bereits bekannten Formeln:

Die Vergrößerung der GoP Länge führt zwar zu einer Verringerung des benötigten Speichervolumens und einer Reduktion der benötigten Übertragsbandbreite, weil dadurch weniger Vollbilder übertragen werden müssen, allerdings führt sie auch zu einer deutlichen Vergrößerung des auf Seiten des Empfängers benötigten Arbeitsspeichers.

Die obige Formel ist nur anzuwenden wenn alle Videokameras die gleiche Auflösung verwenden. Werden verschiedene Auflösungen verwendet, so muss berücksichtigt werden, dass aus Gründen der Performance der Poolspeicher bewusst nicht wieder freigegeben wird. Das bedeutet, dass die obige Formel für alle verwendeten Auflösungen anzuwenden ist und der Gesamtspeicher sich aus der Summe aller Teilergebnisse ergibt:

Beispiel

Im folgenden Beispiel wird die gezeigte Berechnung durchgeführt. Folgende Werte werden angenommen:

• Es sollen auf Empfängerseite 48 Videokanäle parallel ausgegeben werden, wobei Live- und Playback-Kanäle beliebig verschaltet werden sollen.
• Auflösung der von den Videokameras gelieferten Bilder: 4CIF (704 × 576 Bildpunkte)
• Verwendete GoP Länge: 30

Daraus ergibt sich:

Im Worst Case werden ausschließlich Playback-Verbindungen verschaltet, woraus sich der benötigte Arbeitsspeicher berechnet zu:

Kalkulation des Datenvolumens für den Streaming-Server

Dieser Abschnitt beschreibt die Kalkulation des benötigten Datenvolumens für die Speicherung von Videodaten. Hierbei müssen folgende Punkte berücksichtigt werden:

• Soll eine Daueraufzeichnung oder eine ereignisgesteuerte Aufzeichnung erfolgen?
• Soll eine Aufzeichnung im Ring erfolgen, d.h. sollen alte Daten gelöscht werden, wenn die Speicherkapazität erreicht wurde?
• Über welchen Zeitraum soll aufgezeichnet werden.
• Bei einer Daueraufzeichnung: Wie viele Stunden sollen die Daten aufbewahrt werden? Wie viele Stunden Aufzeichnung pro Tag müssen pro Kamera angenommen werden?
• Bei einer ereignisgesteuerten Alarmaufzeichnung: Wie viele Stunden sollen die Daten aufbewahrt werden? Wie viele Stunden Aufzeichnung pro Tag müssen pro Kamera angenommen werden?
• Welche Bildqualität ist gefordert (CIF, 4CIF, Half-HD, Full-HD)?
• Welche Bildrate (fps) ist im Normalfall und im Alarmfall gefordert (5 fps, 10 fps, 25 fps)?
• Muss eine Ausfallzeit des Speichersystems toleriert werden? Wenn ja, für wie lange? Daraus ergibt sich, ob eine Zwischenspeicherung erfolgen muss, wodurch der Bedarf an benötigtem Arbeitsspeicher oder Zwischenspeicher anwächst.

Beispiel

An diesem Beispiel soll eine derartige Berechnung gezeigt werden. Folgende Randbedingungen werden dazu angenommen:

• Anzahl der Kameras: 35
• Die Videodaten sollen bis zu 96 Stunden (4 Tage) aufbewahrt werden. Dabei kann je Kamera von ca. 22 Stunden Videoaufzeichnung pro Tag ausgegangen werden.
• Die Videos der ereignisgesteuerte Alarmaufzeichnung sollen bis zu 336 Stunden (14 Tage) aufbewahrt werden. Dabei kann je Kamera von ca. 2 Stunden Videoaufzeichnung pro Tag ausgegangen werden.
• Geforderte Bildqualität: 4CIF (704 × 576 Pixel)
• Geforderte Bildrate: 4fps im Normalfall, 25 fps im Alarmfall.

Zur Berechnung des Datenvolumens müssen folgende Erfahrungswerte bezüglich Bildrate und Bildqualität herangezogen werden:

• 4CIF@4fps entspricht einer Datenrate von 250-440kbit/s je Kamera.
• 4CIF@25fps entspricht einer Datenrate von 1500-2700kbit/s je Kamera.

Zum Kalkulieren des geforderten Datenvolumen für die Aufzeichnung müssen die höchsten Datenraten angenommen werden. In diesem Fall bedeutet das, dass die digitale Daueraufzeichnung jeder Videokamera mit den gegebenen Randbedingungen pro Tag ein Datenvolumen von ca. 4,15 GByte produziert. Die Rechnung dazu:

Bei 35 Kameras und einer maximalen Datenaufbewahrungszeit von 4 Tagen ergibt sich ein Datenvolumen von 4,15 GByte * 4 * 35 = ca. 600 GByte.

Die digitale ereignisgesteuerte Alarmaufzeichnung jeder Videokamera produziert mit den gegebenen Randbedingungen pro Tag ein Datenvolumen von ca. 2,32 GByte.

Die Rechnung dazu:

Bei 35 Kameras und einer maximalen Datenaufbewahrungszeit von 14 Tagen ergibt sich ein Datenvolumen von ca. 1.136 GByte.

Damit ergibt sich ein gefordertes Datenvolumen für das Speichersystem dieses Beispiels von 1.136 GByte + 600 GByte = ca. 1,7 TByte.

Anforderungen an das verwendete Aufzeichnungssystem

Bei WinCC OA Video Systemen mit einer großen Anzahl von parallel aufzuzeichnenden Videostreams ist es wichtig, ein geeignetes Aufzeichnungssystem auf Grund der Leistungsanforderungen auszuwählen.

Wesentlichen Kenngrößen, die beachtet werden müssen:

• Summe der Schreib- und Lesevorgänge pro Sekunde (Input/Output operations Per Second = IOPS)
• mittlere Transferrate (in MBit/s)

Schreib- und Lesevorgänge pro Sekunde:

Die GOP Länge beeinflusst die Anforderungen an das Aufzeichnungssystem.

Zur Berechnung der Schreib- und Lesevorgänge bei der Aufzeichnung mittels des WinCC OA Video Streaming-Servers müssen folgende Werte zu Grunde gelegt werden:

Bei einem Schreibzugriff zum Speichern der Streaming-Daten müssen insgesamt drei Zugriffe berücksichtigt werden:

• 1 Schreibzugriff zum Schreiben der Binärdaten (also der GOP)
• 1 Schreibzugriff zum Schreiben der WinCC OA Video Indexdatenbank
• 1 Reserve

Unter Berücksichtigung der GOP Länge und der Bildwiederholrate ergibt sich daraus die Anzahl der Zugriffe pro Kanal:

Dementsprechend ergibt sich bei 100 Kanälen, einer GOP-Länge von 5 frames und einer Bildrate von 5 fps:

und bei einer Bildrate von 25 fps:

Bei einem Lesezugriff kann die gleiche Anzahl an Zugriffen angenommen werden, d.h. es ergibt sich hier die folgende Formel:

Dementsprechend ergibt sich auch hier bei 100 Kanälen, einer GOP-Länge von 5 frames und einer Bildrate von 5 fps eine IO-Belastung von 300 IOPS.

Transferraten

Die IO Belastung des Netzwerkadapters der PC-Komponenten sollte ebenfalls während der Planungsphase eines WinCC OA Video Systems in Betracht gezogen werden. Hierbei sind folgende Werte für die Datenübertragung per RTP zu berücksichtigen:

• Bei PAL Auflösung und 5 fps müssen bei H.264 für einen Videostream in etwa 70 PPS (Packets per second) übertragen werden.
• Bei PAL Auflösung und 25 fps müssen bei H.264 für einen Videostream in etwa 350 PPS (Packets per second) übertragen werden.

Nicht funktionale Anforderungen (NFR)

Nicht funktionale Anforderungen legen fest, welche spezifischen Eigenschaften ein System haben soll. Dazu zählen unter anderem Anforderungen wie

• Zuverlässigkeit
• Bedienbarkeit
• Leistungsgrenzen der eingesetzten Hardware
• Verfügbarkeit
• Performance, etc.

Bei Videomanagementsystemen eine Vielzahl von Faktoren zu berücksichtigen, da auch bei moderner Hardware digitale Videoverarbeitung (Kodierung, Dekodierung, Ausgabe, Speicherung von Videodaten) bei hoher Qualität und Bildrate hohe Anforderungen stellt. Erfahrungsgemäß sind etwa folgende Richtgrößen anzunehmen:

• Ein Videostream mit einer dem PAL-Standard entsprechenden Auflösung von 756x576 Pixel (ca. 4CIF) und einer Bildübertragungsrate von 25 Bildern pro Sekunde, der im H.264-Format kodiert ist, beansprucht mit seinem Stream-Profile bis zu 3 Mbps Bandbreite.
• Bei Full-HD Streams (1920x1080 Pixel) kann man von der dreifachen Datenmenge, vom dreifachen Speicherbedarf und der bis zu fünffachen Leistungsanforderung ausgehen.

Anmerkung:Bei Reduzierung der Bildrate kann man die Reduzierung für Datenmengen, Speicherbedarf und Performancebelastungen näherungsweise linear rechnen.

Performance des Systems

Da ein WinCC OA Video System immer ein über ein Netzwerk verteiltes System darstellt, müssen zur Betrachtung der Performance Netzwerk- und PC-Komponenten betrachtet werden.

Netzwerk:

Videostreaming bedeutet eine erhöhte Anforderung an das Netzwerk. Ein Videostream wie oben spezifiziert beansprucht je nach Änderung des Bildinhaltes und Profile des Streams ca. 0.1 - 3 Mbps. Baut man ein System mit 100 Kameras entsprechend den obigen Kenndaten für einen Stream auf, muss im Worst-Case mit einer Datenrate von ca. 300 Mbps gerechnet werden.

Durch das Videostreaming kann es auf manchen Netzwerkknoten vorkommen, dass der Traffic anderer Anwendungen beeinflusst wird.

Je nach Anforderung kann WinCC OA Video die Streams per Unicast oder per Multicast übertragen. Die Anzahl der verschiedenen Quellen, die an den Arbeits- und Anzeigeplätzen angezeigt werden sollen, bestimmt dabei die Netzwerkauslegung.

Ein WinCC OA Video Empfänger (Client) kann angeben, ob die Daten per Multicast oder per Unicast empfangen werden sollen. So können z.B. Fernsehkanäle effizient per Multicast durch das Netzwerk verteilt werden, während CCTV-Kanäle per unicast zum Empfänger übertragen werden.

Je nach Anforderungen an die Betriebssicherheit kann es unter Umständen sinnvoll sein, ein Videonetzwerk unabhängig von einem Datennetzwerk zu betreiben. In der Regel reicht dann eine VLAN-Trennung (Trennung der Netzwerke auf einer Hardware) mit entsprechender Priorisierung zwischen den Netzklassen, um Querwirkungen zu vermeiden.

Festplatte:

Auf Rechnern die Videodaten verarbeiten fallen erhöhte IO-Belastungen an, die in der Regel aber kaum Auswirkungen auf fremde Anwendungen mit sich bringen.

Auf Streaming-Servern die aufzeichnen und wiedergeben werden die Massenspeicher erhöhten Belastungen ausgesetzt. Die Stream-Leistung eines Streaming-Servers hängt hauptsächlich vom Datendurchsatz des für die Videoaufzeichnung und Videowiedergabe verwendeten Massenspeichers ab. Dabei können mit RAID-Arrays höhere Streamleistungen erzielt werden als mit Standardfestplatten.

Die Stream-Leistung eines Servers kann durch den Einsatz von SSD Festplatten (Solid-State-Drive) erheblich gesteigert werden. Besonders sinnvoll erscheint der Einsatz von SSD Festplatten, wenn viele Videokanäle auf der Systemplatte eines Rechners aufgezeichnet werden sollen.

CPU:

Auf Rechnern auf denen Videos dekodiert werden wird die CPU stärker in Anspruch genommen. Die Dekodier-Leistungsgrenze moderner Prozessoren mit 8 Kernen liegt (Stand 2011) bei ca. 64 Videostreams bei voller Bildrate und Auflösung.

RAM:

Wenn mit einem Rechner bis zu 64 Videostreams gleichzeitig dekodiert und angezeigt werden sollen, ist auf eine gute RAM-Ausstattung (mindestens 8 GB, besser 16 GB) und auf qualitativ hochwertige Grafikkarten zu achten.

Der Speicherbedarf hängt davon ab, ob nur Live oder auch Playback angezeigt wird. Playback-Szenarien mit vielen Playback-Kanälen benötigen gegenüber Live-Szenarien mehr Speicher. Der Mehrbedarf hängt auch vom gewählten Intra-Frame-Abstand einer Interfame-Kodierung (z.B. MPEG2/4, H.264) ab. In der Regel müssen Rechner, die nur Live-Videos anzeigen mit weniger RAM bestückt werden, sprich bei 64 Live-Videostreams reichen z.B. 8 GByte RAM aus, um genug Speicher für andere Anwendungen zur Verfügung zu haben.

Der erhöhte Speicherbedarf für die Videodekodierung bedingt auch, dass größere Multikanal Szenarien (gleichzeitige Darstellungen mit mehr als 24 Videostreams) nur mit einem 64-bit Betriebssystem umzusetzen sind.

Bedienbarkeit

Solange die Leistungsgrenze eines Rechners nicht erreicht wird, bleibt die Bedienbarkeit gewährleistet. Es muss also vermieden werden, dass ein Rechner mit dem Videofeature an seine Leistungsgrenze stößt. Dazu muss wenn nötig die Anzahl der gleichzeitig dargestellten Videokanäle begrenzt werden. Die Videobildanzeige sollte nur auf Prozessoren mit mehr als einem Kern verwendet werden.

Prozessverteilung auf andere Rechner

Alle Dienste wie Video-Integration, Video-Aufzeichnung und Video-Ausgabe können bis zu einer Anzahl von 64 Videokanälen auf einem leistungsfähigen Rechner (z.B. i7 Prozessor mit 8 Kernen, 16 GByte RAM, NVIDIA-Grafikkarte) ablaufen.

Wenn die Leistungsfähigkeit eines Rechners nicht ausreicht, müssen die Prozesse verteilt werden. Dazu werden zunächst die Aufzeichnung und das Interface auf einem separaten Streaming-Server ausgelagert. Mit einem separat betriebenen Standard-Server kann man ca. 75 Videostreams (4CIF@25 fps) mit RAID Level 5 und 150 Streams mit RAID Level 0 aufzeichnen. Durch Multiplikation der Server kann man die Stream-Leistung eines Systems skalieren, sofern das Netzwerk entsprechend skaliert wird.

Eine vollständige Systemtrennung würde nur notwendig werden, wenn die Anforderungen des Videosystems an das Datennetzwerk zu hoch sind, so dass eine Integration auf einem Netzwerk nicht möglich erscheint. Bei modernen Netzwerken ist dieser Fall in der Regel nicht zu betrachten. Bei Bestandsnetzwerken muss dies im Einzelfall geprüft werden.