Installierte Videokomponenten

Kommunikation

Aufgrund der verteilten Architektur ist eine Kommunikation zwischen den Komponenten erforderlich, um Zustandsinformationen auszutauschen und Steuerungsbefehle zu übermitteln.

Die Kommunikation erfolgt ausschließlich über IP-basierte, asynchrone Nachrichtenprotokolle. Diese lose Kopplung vermeidet direkte Abhängigkeiten zwischen den Komponenten und sorgt für eine hohe Robustheit, Zuverlässigkeit und Skalierbarkeit des Gesamtsystems.

Es gibt zwei wesentliche Mechanismen für die Kommunikation zwischen den Komponenten:

Kommunikation über AccVimaccConfig: Die Kommunikation über AccVimaccConfig ist ein Mechanismus, der von jedem Applikationsframework auf den Komponenten bereitgestellt wird. Das Applikationsframework jeder Komponente kommuniziert über IP-Verbindungen mit der AccVimaccConfig-Komponente und stellt sicher, dass die Video-Konfiguration der Applikation als Datenbasis immer verfügbar ist. Dadurch kann jede Videoapplikation die für sie relevanten Steuerungsbefehle abrufen und selbst Steuerungsbefehle und Zustandsinformationen bereitstellen. In der Regel erfolgt die logische Kontrollverbindung zwischen zwei Komponenten über AccVimaccConfig.
Kommunikation über direkte TCP/IP-Verbindungen: In einigen Fällen ist es erforderlich, dass eine Komponente eine direkte Steuerverbindung zu einer anderen Komponente aufbaut, insbesondere wenn geringe Latenzzeiten erforderlich sind. Jede Komponente verfügt über einen Steuerungskanal, der vom internen TCP-Server bereitgestellt wird. Über diesen Kanal kann eine Komponente eine direkte TCP/IP-Verbindung zur anderen Komponente herstellen und Steuerungsbefehle übermitteln oder Statusinformationen abfragen.

Log-Files der einzelnen Dienste werden automatisch unter C:\vimacc\log\<component name>_<hostname>_<date>.log gespeichert.

Folgende Komponenten werden installiert:

AccVimaccConfig

Diese Komponente ist der zentrale Datenbankdienst für die gesamte Konfiguration eines WinCC OA Video-Systems, dessen Steuerung und all seine Systemzustände. AccVimaccConfig kann die statischen Konfigurationsdaten aus einer lokalen Datenbank auslesen. Nach dem Einlesen der Daten werden diese allen Prozessen des WinCC OA Video-Systems zur Verfügung gestellt.

Alle Software-Komponenten eines WinCC OA Video-Systems kommunizieren mittels TCP/IP mit diesem zentralen Dienst, um die Systemkonfiguration und Systemzustände abzufragen, Zustände der eigenen Komponente im System zu veröffentlichen und auf Steuerungsbefehle zu reagieren.

Im Datenbestand eines WinCC OA Video-Systems, in der Config, werden also nicht nur statische Konfigurationsdaten, sondern auch dynamische Zustandsinformationen und sämtliche Steuerungsbefehle gespeichert. Diese dynamischen Informationen werden zur Laufzeit im Speicher gehalten und sind damit flüchtig. Beim Neustart werden diese globalen Konfigurationsdaten wieder durch alle WinCC OA Video Komponenten zusammengetragen.

Die AccVimaccConfig wird somit auch als Interprozesskommunikationsplattform für die WinCC OA Video Prozesse eingesetzt und realisiert dadurch die WinCC OA Video Kommandoschnittstelle.

Üblicherweise wird AccVimaccConfig auf einer zentralen Komponente im System, z.B. einem WinCC OA Server, betrieben. Zur Erhöhung der Ausfallsicherheit kann es allerdings auch auf einem weiteren Rechner im System, beispielsweise einem redundanten WinCC OA Server, betrieben werden. So kann der redundante Partner sofort übernehmen, sollte eine Komponente ausfallen. Dadurch wird ein störungsfreier Betrieb des Systems gewährleistet.

Anmerkung: Es dürfen maximal zwei AccVimaccConfig Prozesse in einem System laufen.

Redundanz

Im Fall eines Hot-Standby Systems, bestehend aus zwei laufenden AccVimaccConfig-Prozessen auf zwei verschiedenen Rechnern, kommunizieren alle Software-Komponenten des WinCC OA Video Systems mit beiden AccVimaccConfig-Prozessen über getrennte TCP/IP-Datenverbindungen.

In diesem Zusammenhang werden die anderen Komponenten als Config-Clients und die AccVimaccConfig als Config-Server bezeichnet.

Beide Config-Server etablieren zusätzlich untereinander eine weitere TCP/IP-Verbindung (Config-Bridge) worüber unter anderem der Zustand (MASTER oder BACKUP) der beiden Prozesse ausgehandelt wird.

Der Zustand der beiden Config-Server ist unabhängig von der Redundanz des übrigen WinCC OA Systems.

Ein Config-Server nimmt immer den Zustand MASTER ein, der andere den Zustand BACKUP. Nur der Config-Server der den Zustand MASTER eingenommen hat, sendet Zustandsänderungen an die Config-Clients oder beantwortet deren Anfragen. Die Config-Clients wiederum senden immer alle Anfragen und Zustandsänderungen an beide Config-Server.

Änderungen an der Config werden vom Config-Master unmittelbar gespeichert und dann an den Backup-Config-Server gesendet. Wird die Verbindung der Config-Bridge wiederhergestellt sendet der aktuelle Master-Config-Server den gesamten Config-Bestand an den Backup-Config-Server und bleibt Master.

Anmerkung: Die hier beschriebene TCP/IP-Verbindung zwischen den redundanten Serverrechnern (Config-Bridge) eines redundanten Systems ist als logische Verbindung zu verstehen. Damit im Falle eines Fehlers die Umschaltung auf den redundanten Partner ordnungsgemäß erfolgen kann, dürfen die beiden Server netzwerkseitig nicht redundant angebunden werden. Die beiden Server dürfen also nur mit einem Netzwerkkabel an die aktiven Netzwerkkomponenten angeschlossen werden.

Kopplung zum WinCC OA Server

Über einen WinCC OA Video Manager wird die Verbindung zwischen einem WinCC OA Server und WinCC OA Video hergestellt. Die Datenhoheit für alle Parametrierdaten der Videokomponenten liegt dabei ausnahmslos bei den zu WinCC OA Video zugehörigen Datenpunkten. Bei Neustart des API-Managers schickt dieser alle notwendigen Parametrierinformationen an alle Config-Server. Nach einer erfolgreichen Initialisierung werden nur noch Änderungen gesendet. Meldungen des WinCC OA Video Systems werden vom WinCC OA Video Manager auf Datenpunktelemente geschrieben.

AccVimaccConfigProxy

In komplexen und weit verzweigten Anlagen kann es zu einer hohen Kommunikationslast an den zentralen Managementservern kommen. Um weiterhin deren optimale Reaktionsfähigkeit zu gewährleisten, kann der Dienst AccVimaccConfigProxy verwendet werden. Dieser Dienst wird auf jedem vimacc-Rechner automatisch installiert und kann aktiviert werden, um die Interprozesskommunikation je Rechner zu bündeln und dadurch die gleichzeitigen Interprozessverbindungen zu den zentralen Servern zu reduzieren.

Anmerkung:

Der Dienst AccVimaccConfigProxy darf nicht innerhalb von Subknoten zum Einsatz kommen, falls die Anlage wie im Abschnitt AccVimaccConfigSlave beschrieben konfiguriert wird.

Um die Bündelung der Interprozesskommunikation zu aktivieren, müssen auf den entsprechenden vimacc-Rechnern Anpassungen an den folgenden Config-Dateien vorgenommen werden:

AccVimaccConfigProxy.conf

Auf Clients:

[ConfigServer]
Port=9360
ContentUpdateCompressLevel=1
[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Server1> 9370
Server2=<DNS-Name von Server2> 9370
AccVimaccConfig.conf

Auf Clients:

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name des Clients> 9360

Anmerkung: Änderungen an der Konfiguration werden erst nach Neustart der vimacc-Dienste übernommen.

AccVimaccConfigSlave

Ein verteiltes Video-System kann in unterschiedliche Segmente (Subknoten) aufgeteilt werden. Der AccVimaccConfigSlave-Dienst bündelt die für das Management notwendige Interprozesskommunikation und puffert diese lokal. Das ermöglicht im Fall eines Kommunikationsausfalles (z.B. bei Verbindungsverlust zu den zentralen Management-Servern), dass die Funktionsfähigkeit der jeweiligen Subknoten lokal weiterhin gegeben ist. So können beispielsweise Aufzeichnungs- oder Streamingknoten inklusive angebundenen vimacc-Arbeitsplätzen realisiert werden, die bei Netzwerkproblemen eigenständig arbeiten.

Solange die Verbindung zur Zentrale besteht, können alle WinCC OA Video-Komponenten am Subknoten verwendet werden.

Abbildung 1. Verbindung zwischen Subknoten und Zentrale hergestellt

Bei Verbindungsverlust zur Zentrale stehen am Subknoten durch den AccVimaccConfigSlave-Dienst weiterhin vimacc-Komponenten zum Aufzeichnen und Streamen, sowie die vimacc-Workstation zur Visualisierung und Bedienung, zur Verfügung.

Abbildung 2. Verbindung zwischen Subknoten und Zentrale unterbrochen

Die AccVimaccConfigSlave-Komponente kann entsprechend der vorgenommenen Konfiguration auf unterschiedliche Weise verwendet werden.

Anmerkung: Änderungen an der Konfiguration werden erst nach Neustart der vimacc-Dienste übernommen.

Subknoten

Um die Bündelung der Interprozesskommunikation zu aktivieren, müssen auf den entsprechenden vimacc-Rechnern Anpassungen an den folgenden Config-Dateien vorgenommen werden:

AccVimaccConfigSlave.conf

Auf Sub-Server:

[ConfigProxy]
RCLMode=2
RCLUseOnlyLocalLicense=false
[ConfigServer]
Port=9365
ClientConnectDelay=0
ContentUpdateCompressLevel=1

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Server1> 9370
Server2=<DNS-Name von Server2> 9370

AccVimaccConfig.conf

Auf Sub-Server & Sub-Client(s) (sofern vorhanden):

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Server1> 9365

Redundanter Subknoten

Wie zentrale Video-Server können auch die Subknoten mit einem redundanten Serverpaar versehen werden. Hierfür sind folgende Anpassungen notwendig:

AccVimaccConfigSlave.conf

Auf Sub-Server1:

[ConfigProxy]
RCLMode=2
RCLUseOnlyLocalLicense=false

[ConfigServer]
Port=9365
ClientConnectDelay=0
ContentUpdateCompressLevel=1

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Server1> 9370
Server2=<DNS-Name von Server2> 9370

[Bridge]
ServerPort=7001
ServerHost=<DNS-Name von Sub-Server2>
IAmServer=true -> Definition als TCP-Server

Auf Sub-Server2:

[ConfigProxy]
RCLMode=keep
RCLUseOnlyLocalLicense=false

[ConfigServer]
Port=9365
ContentUpdateCompressLevel=1

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Server1> 9370
Server2=<DNS-Name von Server2> 9370

[Bridge]
ServerPort=7001
ServerHost=<DNS-Name von Sub-Server1>
IAmServer=false -> Definition als TCP-Client

AccVimaccConfig.conf

Auf Sub-Server1, Sub-Server2:

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Sub-Server1> 9365
Server2=<DNS-Name von Sub-Server2> 9365

Sub-Client(s) (sofern vorhanden):

[ConfigClient]
ListenToAnnouncements=false
MulticastInterface=0.0.0.0
Server1=<DNS-Name von Sub-Server1> 9365
Server2=<DNS-Name von Sub-Server2> 9365
ServerType=proxy

Datenbank-Replikation

Damit der Sub-Knoten bei Kommunikationsausfall zu den zentralen Management-Servern auch nach Neustart mit dem letzten Stand der Konfigurationsdatenbank weiterarbeiten kann, muss die Konfigurationsdatenbank bei Änderung automatisch auf die abgesetzten Subknoten dupliziert werden. Diese Funktionalität ist in Kombination mit der AccVimaccConfigSlave-Komponente (sowohl im single als auch im redundanten Betrieb) zu bevorzugen. Hierfür kommt der auf allen vimacc-Hosts standardmäßig installierte Dienst AccVimaccRoot zum Einsatz.

Grundlage ist die Konfiguration gemäß "Subknoten“ bzw. "Redundanter Subknoten“. Ergänzend dazu sind folgende Änderungen vorzunehmen:

AccVimaccRoot.conf

Auf Sub-Server1 & Sub-Server2 (sofern vorhanden):

[DatabaseReplication]
Mode=auto
ServerList=<DNS-Name von Sub-Server1>, <DNS-Name von Sub-Server2>

AccVimaccConfigSlave.conf

Auf Sub-Server1 & Sub-Server2 (sofern vorhanden):

[ConfigProxy]
RCLMode=keepWithLocalDB

AccVimaccControlInterface

Diese Komponente stellt folgende Funktionen zur Verfügung:

Schnittstelle für ein übergeordnetes System zur Steuerung von vimacc
Übersetzung der empfangenen Steuerkommandos in vimacc Kommandos

AccVimaccDongle

Ist die Komponente zur Kommunikation mit den Lizenz- bzw. Verschlüsselungs-Dongles auf jedem Rechner eines WinCC OA Video Systems.

AccVimaccEventManager

Der AccVimaccEventManager ermöglicht es, Events und Zustandsänderungen innerhalb des Video-Systems zu verwalten und zu verarbeiten. Er stellt eine zentrale Schnittstelle für die Benachrichtigung und den Empfang von Ereignissen zwischen den Komponenten bereit.

Der Event-Manager erfasst und verteilt Ereignisse, die von verschiedenen Video-Komponenten erzeugt werden. Dies können beispielsweise Ereignisse wie das Hinzufügen oder Entfernen von Kameras, Änderungen im Aufnahmestatus, Alarmereignisse oder andere systemrelevante Ereignisse sein.

Durch den Einsatz des AccVimaccEventManager können die Video-Komponenten effizient und synchronisiert auf Ereignisse reagieren, um die Funktion und Leistung des Video-Systems sicherzustellen.

Der AccVimaccEventManager ist somit eine wichtige Komponente für die Kommunikation und Koordination innerhalb des WinCC OA Video Systems.

AccVimaccExport

Die Komponente AccVimaccExport dient dazu, Teile der auf den Streaming-Servern gespeicherten Inhalte auf dem lokalen Arbeitsplatz zu speichern.

Um diese Aufgabe durchzuführen, arbeitet AccVimaccExport im Verbund mit der Komponente AccVimaccServer. Die Steuerung erfolgt über Datenpunkte z.B. über das WinCC OA User Interface.

Beim Export von gespeicherten Inhalten in ein Verzeichnis werden die Daten zunächst von den Streaming-Servern abgerufen und auf die lokale Festplatte des Rechners kopiert, von dem der Export initiiert wurde.

Von der steuernden Komponente erhält AccVimaccExport über die Aufforderung, bestimmte Teile des aufgezeichneten Inhaltes zu exportieren. AccVimaccExport kommuniziert daraufhin mit dem Streaming-Server, um die angeforderten Streaming-Daten abzurufen und die Daten auf dem lokalen Rechner, oder einem Netzlaufwerk zu speichern. Die steuernde Komponente kann sich kontinuierlich über die Datenpunkte über den aktuellen Zustand informieren.

Die Wiedergabe der exportierten Streaming-Daten kann mit der WinCC OA Video Komponente AccVimaccVimaccWorkstation erfolgen.

AccVimaccFtpAlarmReceiver

Der AccVimaccFtpAlarmReceiver überwacht einen bestimmten FTP-Ordner und erwartet das Eintreffen von Alarmdateien. Diese Alarmdateien enthalten Informationen über bestimmte Ereignisse, die im Video-System aufgetreten sind, z. B. Bewegungserkennung, Eindringen in gesperrte Bereiche oder andere Arten von Sicherheitsalarmen.

Sobald der AccVimaccFtpAlarmReceiver eine neue Alarmdatei erkennt, liest er die darin enthaltenen Informationen aus und leitet sie an die entsprechenden Komponenten im Video-System weiter. Dies ermöglicht eine schnelle Reaktion auf sicherheitsrelevante Ereignisse und eine gezielte Behandlung von Alarmen.

Der AccVimaccFtpAlarmReceiver spielt eine wichtige Rolle in der Alarmverarbeitung des WinCC OA Video Systems und trägt zur effektiven Überwachung und Sicherheit des Systems bei.

AccVimaccHttpServer

Der HTTP-Server ermöglicht den Zugriff auf verschiedene Funktionen und Daten des Video-Systems über das HTTP-Protokoll.

Der AccVimaccHttpServer bietet eine RESTful-API (Representational State Transfer), über die externen Anwendungen oder Systeme auf das Video-System zugreifen können. Die API stellt verschiedene Endpunkte und Ressourcen bereit, über die Informationen abgerufen, Aktionen ausgeführt und Einstellungen konfiguriert werden können.

Externe Anwendungen können beispielsweise mithilfe des AccVimaccHttpServers auf Streams von Kameras zugreifen, Aufzeichnungen abrufen, Alarme abfragen, Konfigurationseinstellungen ändern oder Steuerungsbefehle an das Video-System senden.

Der AccVimaccHttpServer ermöglicht eine einfache Integration des Video-Systems in andere Anwendungen, Systeme oder Benutzeroberflächen, da die Kommunikation über das weit verbreitete HTTP-Protokoll erfolgt.

Durch den Einsatz des AccVimaccHttpServers können Entwickler flexibel auf das Video-System zugreifen und benutzerdefinierte Anwendungen oder Integrationen erstellen, um die Funktionalität des Video-Systems zu erweitern und an spezifische Anforderungen anzupassen.

AccVimaccInterface

Integriert die unterschiedlichen externen Geräte (z.B. Videoquellen) der verschiedenen Hersteller in ein WinCC OA Video System und sorgt dafür, dass innerhalb des Systems über normierte Schnittstellen auf all diese Geräte zugegriffen werden kann. AccVimaccInterface ist verantwortlich für:

Integration der Peripherie
Steuerung der Peripherie
Überwachung der Peripherie
Empfang der Streaming-Daten
gegebenenfalls die Ausgabe von Audiodaten (z.B. bei Durchsagen)
Weiterleitung der empfangenen Daten an die verschiedenen Empfänger
gegebenenfalls die Weiterleitung zwischen IP Unicast und IP Multicast-Verbindungen
Verschlüsselung (wenn aktiviert) der empfangenen Streaming-Daten
gegebenenfalls die Transformation der empfangenen Streaming-Daten
Verbindung zu den Streaming-Servern zum Aufzeichnen der Daten

Das AccVimaccInterface wird in der Regel als Streaming-Proxy betrieben, um den speziellen Anforderungen der Netzwerktopologie gerecht zu werden. Das bedeutet, dass Streaming-Daten nur einmal von der Datenquelle abgerufen werden, auch wenn diese von mehreren Empfängern gleichzeitig abgerufen werden.

Beispiel 1:

Diese Abbildung zeigt beispielhaft den gleichzeitigen Abruf der Streaming-Daten von Netzwerkkameras durch mehrere Arbeitsplätze und einen Streaming-Server.

Nach dem Empfang der Daten können diese danach immer über die WinCC OA Video Kontrollverbindung vom WinCC OA Video Interface angefordert werden und werden immer per RTP zum Empfänger übertragen.

Die Verfügbarkeit der konfigurierten Geräte wird vom AccVimaccInterface überwacht und in der AccVimaccConfig entsprechend abgespeichert, so dass andere WinCC OA Video Komponenten diesen Zustand auswerten und gegebenenfalls visuell darstellen können. AccVimaccInterface kann auf jedem Rechner des WinCC OA Video Systems betrieben werden. Die maximale Anzahl der zu integrierenden Kanäle skaliert mit der Anzahl von Instanzen des AccVimaccInterfaces die auf verschiedenen Rechnern installiert werden.

Beispiel 2:

Die folgende Abbildung zeigt ein Beispiel eines WinCC OA Video Systems, bei dem mehrere Arbeits- und Anzeigeplätze die Daten von Netzwerkkameras abrufen und parallel die Aufzeichnung der Videodaten auf einen Streaming-Server durchgeführt wird.

An diesem Szenario ist zu erkennen, dass die Videodaten einer Kamera nur einmalig vom AccVimaccInterface abgerufen werden und von dort an die Empfänger weitergeleitet werden. Die Empfänger sind hier gleichermaßen der AccVimaccServer und alle Instanzen von AccVimaccWorkstation und AccVimaccDisplay, sowie alle WinCC OA Arbeitsplätze, die das Bild der entsprechenden Kameras abrufen.

Redundante Aufzeichnung

Ein WinCC OA Video System kann so aufgebaut werden, dass es in der Lage ist, die Streaming-Daten der angeschlossenen Datenquellen redundant aufzuzeichnen. Dadurch wird bei Ausfällen von zentralen Komponenten eine kontinuierliche Aufzeichnung sichergestellt. Bei der Aufzeichnung von Streaming-Daten bestehen generell zwei Möglichkeiten:

beide WinCC OA Video Streaming-Server zeichnen immer alle Daten parallel auf
die Datenquellen werden gleichmäßig auf die Server verteilt(Load-Balancing).

Vollständige redundante Aufzeichnung

In diesem Fall werden die Video-Komponenten so konfiguriert, dass die Streaming-Daten der Datenquellen nur von einem AccVimaccInterface abgerufen und den redundanten AccVimaccServer-Instanzen zur Speicherung übergeben werden. Dadurch wird sichergestellt, dass im Normalbetrieb beide Server zu jedem Zeitpunkt die gleichen Daten speichern und die Daten von den Kameras nicht doppelt abgerufen werden müssen. Die folgende Abbildung zeigt ein Beispiel eines solchen WinCC OA Video Systems:

Die Instanzen von AccVimaccWorkstation und AccVimaccVimaccDisplay sowie alle WinCC OA Arbeitsplätze, die das Bild der entsprechenden Kameras darstellen, rufen die Daten immer von dem aktiven AccVimaccInterface (Server PC #1) ab. Das redundante AccVimaccInterface (Server PC #2) arbeitet währenddessen im Hot-Standby Betrieb und wartet auf eine Redundanz-Umschaltung im Falle eines Fehlers.

Für den Fall, dass einer der beiden Server ausfällt, kommt es daher zu keiner Unterbrechung der Aufzeichnung. Der andere Server kann weiterhin Daten empfangen und aufzeichnen, Live-Verbindungen können nach wie vor aufgebaut werden und auch der Abruf von bereits aufgezeichneten Daten ist ohne Einschränkung möglich. Sobald der ausgefallene Server wieder in Betrieb genommen wird, werden die Aufzeichnungsverbindungen zu diesem Server automatisch wiederhergestellt und beide Server zeichnen wieder gleichzeitig auf. Die folgende Abbildung zeigt den Fall, dass der Server mit dem passiven AccVimaccInterface ausgefallen ist.

In diesem Fall ist keine Redundanz-Umschaltung erforderlich und die Instanzen von AccVimaccWorkstation und AccVimaccDisplay Fragen weiterhin die Daten vom Interface auf Server PC #1 ab.

Die folgende Abbildung stellt das WinCC OA Video System für den Fall dar, dass der redundante Server mit dem aktiven AccVimaccVimaccInterface ausgefallen ist.

Hier erkennt der verbleibende Server, dass eine Redundanz-Umschaltung durchgeführt werden muss und sorgt dafür, dass das vorher passive Interface die Streaming-Daten von den Datenquellen abruft und die Aufzeichnungsverbindungen zu dem AccVimaccVimaccServer hergestellt werden.

Die Instanzen von AccVimaccWorkstation und AccVimaccVimaccDisplay sowie alle WinCC OA Arbeitsplätze, die das Bild der entsprechenden Kameras darstellen, erkennen die Redundanz-Umschaltung auf den zweiten Server und rufen automatisch die Daten von dem nun aktiven AccVimaccVimaccInterface auf dem zweiten Server ab.

Load-Balancing

Die Komponenten AccVimaccInterface werden hierbei so konfiguriert, dass jedem Interface nur etwa die Hälfte der angeschlossen Datenquellen zugeordnet wird. Jedes Interface ruft dadurch nur die Streaming-Daten von der Hälfte der Datenquellen ab und übergibt diese dem jeweils zugeordneten AccVimaccVimaccServer zur Speicherung. Beide Server speichern also im Normalbetrieb nur etwa die Hälfte der Daten und die Streaming-Daten werden nur einmalig im Netzwerk übertragen.

Folgende Abbildung zeigt ein solches WinCC OA Video System.

Die Instanzen von AccVimaccDisplay sowie alle WinCC OA Arbeitsplätze, die das Bild der entsprechenden Kameras darstellen, rufen die Daten immer nur von dem Interface ab, das der angeforderten Datenquelle zugeordnet ist.

Fällt in diesem Szenario einer der Server (Server PC #1 oder Server PC #2) aus, so sorgt WinCC OA Video für eine Redundanzumschaltung auf den verbleibenden Server. Dem noch verbleibenden AccVimaccInterface wird automatisch auch die zweite Hälfte der Streaming-Quellen zugeordnet, so dass fortan alle Kameras auf nur einem Server aufgezeichnet werden.

Anmerkung: Für die Dauer des Ein-Server-Betriebes verringert sich dadurch die für den Ringspeicher zur Verfügung stehende Speicherkapazität.

Die folgende Abbildung zeigt das WinCC OA Video System für den Fall, dass einer der redundanten Server ausgefallen ist.

Live-Verbindungen die vorab über das AccVimaccInterface des nun ausgefallenen Servers (Server PC #2) aufgebaut wurden, werden nach der Redundanzumschaltung automatisch über den zweiten Server etabliert. Alle neuen Live-Verbindungen werden fortan nur noch über das AccVimaccInterface des verbleibenden Servers aufgebaut.

Für die Dauer des Ausfalls eines der beiden Server kann jedoch nicht auf die aufgezeichneten Daten der diesem Server zugeordneten Kameras zugegriffen werden, da der verbleibende Server diese Daten nicht gespeichert hat.

Ein kompletter Verlust der Daten wird durch die Erhöhung der Ausfallsicherheit auf Seiten des Speichersystems vermieden. Wird beispielsweise ein RAID-System (Redundant Array of Independent Disks) zur Datenspeicherung eingesetzt, so können durch die Verwendung eines geeigneten RAID-Levels (z.B. RAID 5) automatisch redundante Informationen erzeugt werden, damit beim Ausfall einzelner Komponenten das RAID als Ganzes weiterhin zur Verfügung steht.

Der Vorteil dieser Methode gegenüber der vollständigen redundanten Aufzeichnung liegt allerdings darin, dass bei gleicher Speicherkapazität ein doppelt so großer Ringspeicher realisiert werden kann, da jeder Server nur die Hälfte der anfallenden Daten aufzeichnen muss.

Failover-Redundancy

Bei der Failover-Redundancy werden vier Rechner (jeweils zwei Master-Slave-Rechnerpaare) für die Aufzeichnung definiert. Der Master des primären Rechnerpaares übernimmt die Aufzeichnung der Daten, alle anderen Rechner laufen im Hot-Standby-Betrieb. Erst wenn der Master ausfällt, übernimmt der Slave des primären Rechnerpaares die Aufzeichnung. Sollten sowohl Master als auch Slave ausfallen, wird auf das sekundäre Rechnerpaar umgeschaltet.

Die Rangordnung der Failover-Redundanz ist daher folgendermaßen:

Master Primär-Aufzeichnung > Slave Primär-Aufzeichnung > Master Sekundär-Aufzeichnung > Slave Sekundär-Aufzeichnung

Sobald ein Rechner wieder in den Normalbetrieb zurückkehrt, übernimmt diese wieder Aufzeichnung von Rechnern mit niedrigerem Rang.

Abbildung 3. Beispiel - Ausfall Recording1 -> Übernahme durch Recording2

Abbildung 4. Beispiel - Ausfall Recording1, Recording2+3 offline -> Übernahme durch Recording4

Abbildung 5. Beispiel - Recording1+2+3 offline, Normalbetrieb Recording2 -> Übernahme durch Recording2

Abbildung 6. Beispiel - Recording4 offline, Ausfall Recording3 -> Übernahme durch Recording1

AccVimaccInterfaceProxy

Der Hauptzweck des Interface-Proxy besteht darin, die Kommunikation zwischen den Clients und den Servern zu verwalten und sicherzustellen, dass die Anfragen und Daten korrekt übertragen werden.

Der AccVimaccInterfaceProxy agiert als zentraler Kontrollpunkt für den Zugriff auf die Video-Server. Er nimmt Anfragen von den Video-Clients entgegen, leitet sie an den entsprechenden Video-Server weiter und überwacht den Austausch von Daten zwischen den Clients und Servern.

Der AccVimaccInterfaceProxy spielt eine wichtige Rolle bei der Skalierbarkeit und Flexibilität des Video-Systems. Er ermöglicht die Verteilung der Last auf mehrere Video-Server und gewährleistet, dass die Anfragen effizient und zuverlässig bearbeitet werden. Darüber hinaus unterstützt der AccVimaccInterfaceProxy auch die Sicherheitsfunktionen des Systems, wie z.B. die Authentifizierung und Verschlüsselung der Kommunikation.

AccVimaccIpAlarmReceiver

Der AccVimaccIpAlarmReceiver ist für den Empfang und die Verarbeitung von IP-basierten Alarmmeldungen zuständig ist. Diese Alarmmeldungen können von verschiedenen Überwachungskameras oder anderen IP-fähigen Geräten generiert werden.

Der Alarmreceiver überwacht kontinuierlich den eingehenden Datenverkehr auf dem definierten IP-Port und erkennt eingehende Alarmnachrichten. Sobald eine Alarmnachricht erfasst wird, verarbeitet der Alarmreceiver diese weiter und leitet sie an die entsprechenden Komponenten des Videosystems weiter, z.B. an den Video-Manager oder den Control Manager.

Der AccVimaccIpAlarmReceiver spielt eine wichtige Rolle bei der Erfassung und Behandlung von Sicherheitsereignissen in einem Videoüberwachungssystem. Er ermöglicht die schnelle und effiziente Verarbeitung von Alarmmeldungen, um entsprechende Aktionen wie Benachrichtigungen, Aufzeichnungen oder das Auslösen von Ereignissen in der WinCC OA Umgebung auszulösen.

AccVimaccRoot

Ist die Kernkomponente auf jedem Rechner eines WinCC OA Video Systems und wird beim Hochfahren des Rechners gestartet. Diese Komponente ist für folgende Aufgaben verantwortlich:

Kontrolle aller WinCC OA Video Prozesse auf dem Rechner
Lizenzierung
Ablaufsteuerung

Abhängig von den installierten Komponenten werden alle weiteren WinCC OA Video Prozesse von AccVimaccRoot aktiviert und kontrolliert.

AccVimaccRTSPServer: Die Komponente AccVimaccRTSPServer realisiert ein RTSP-Interface (Real-Time Streaming Protocol), über das Videostreams von einem WinCC OA Video System abgerufen werden können; Der AccVimaccRTSPServer realisiert damit eine weitere Schnittstelle, über die ein WinCC OA Video System in ein übergeordnetes Video-Managementsystem integriert werden kann.; Dadurch ist es möglich, über eine standardisierte Schnittstelle die Streaming-Daten abzurufen, um sie z.B. direkt zur Anzeige zu bringen, oder sie einem weiteren System zur Video-Content-Analyse (VCA) zu übergeben.; Der AccVimaccRTSPServer unterstützt den Abruf der zur Verfügung stehenden Datenquellen für Livebilder Real-Time Streaming Protocol (RTSP).; Die Übermittlung der Streaming-Daten zum anfordernden Client erfolgt über das Real-Time Transport Protocol (RTP). Dabei können die RTP-Daten wahlweise über eine UDP/IP Verbindung, per unicast oder multicast oder getunnelt über die RTSP-TCP-Verbindung von einem Client angefordert werden; Werden die Live-Daten der angeschlossenen Streaming-Quellen (Netzwerk-Kameras etc.) angefordert, so kommuniziert der AccVimaccRTSPServer mit der Komponente AccVimaccInterface, um die entsprechenden Daten abzurufen.; Der AccVimaccRTSPServer dafür, dass die empfangenen Daten standard-konform in dem korrekten RTSP-Rahmenformat entsprechend der Streaming-Parameter an den Client übertragen werden.; AccVimaccRTSPServer unterstützt die Abfrage von Streaming-Daten, die im Format H.264 und MPEG-4 vorliegen.; AccVimaccRTSPServer unterstützt das RTSP-Protokoll entsprechend RFC 2326 /9/, einschließlich der Verschachtelung der Binärdaten, so dass die Daten auch über TCP/IP übertragen werden kann.; Die Eigenschaften der Multimediadatenströme werden vom AccVimaccRTSPServer in Form von sogenannten SDP-Dateien (Session Description Protocol) beschrieben, die gemäß RFC 4566 /10/ gebildet, inklusive der Dekodierungsparameter gemäß RFC 3984 (RTP Payload Format for H.264 Video /11/) und RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual Streams /12/).; Darüber hinaus unterstützt der AccVimaccRTSPServer die sogenannte "RTP header extension" für CCTV-Systeme gemäß der ONVIF Core Specification Version 2.0, so dass den verbundenen Clients immer stabile und genaue Zeitstempel (timestamps) für jeden einzelnen Frame bereitgestellt werden; AccVimaccRTSPServer ist ein Betriebssystemdienst, der keine eigene Benutzerschnittstelle bereitstellt, sondern seine Arbeit im Hintergrund ohne Benutzeraktionen verrichtet. Üblicherweise wird diese Komponente zusammen mit der Komponente AccVimaccServer auf den Serverrechnern des WinCC OA Video Systems betrieben.

AccVimaccServer

Die Komponente AccVimaccServer realisiert den Streaming-Server. Sie organisiert sämtliche Aufzeichnungen innerhalb eines WinCC OA Video Systems und stellt diese Aufzeichnungen für die Wiedergabe durch andere Komponenten zur Verfügung.

Der AccVimaccServer ist im Wesentlichen für die folgenden Aufgaben verantwortlich:

Aufzeichnung der Streaming-Daten in zentralen oder verteilten Archiven
Indizierung der Streaming-Daten
Bereitstellung der verschiedenen Aufzeichnungsmodi (Ringspeicher, Voralarmspeicher, Alarmspeicher, linearer Speicher)
Schützen von bestimmten Bereichen (sogenanntes Protecting), so dass diese durch den Ringspeicher nicht gelöscht werden

AccVimaccServer führt die Aufzeichnung der Streaming-Daten unabhängig von den verschiedenen Streaming-Quellen und Formaten durch. Er übernimmt die Streaming-Daten von einem oder mehreren AccVimaccInterface Instanzen und speichert die empfangenen Daten in den ihm zugeordneten Archiven. Er ist somit erst einmal frei von dem Wissen über Datenformate und speichert lediglich die ihm übergebenen Daten. Beim Abruf der aufgezeichneten Daten (z.B. von den Komponenten AccVimaccDisplay oder einem WinCC OA User Interface) werden entsprechend der Daten aus den Archiven ausgelesen und an die anfordernden Prozesse übergeben, die diese ihrerseits wieder vor der Ausgabe entsprechend dekodieren müssen.

Organisation der Mediadateien

AccVimaccServer speichert die empfangenen Streaming-Daten nicht in einer einzigen Datei pro Streaming-Quelle, sondern legt die Daten in Form von vielen einzelnen Dateien in einer bestimmte Verzeichnis- und Dateistruktur ab.

Die Mediadateien werden strukturiert, beginnend mit dem Media-Wurzel-Verzeichnis in der folgenden Verzeichnisstruktur abgelegt:

Media-Wurzel-Verzeichnis (<rootfilepath>)

Kontext-Verzeichnis (<context>)

Sessionverzeichnis (<session>)

Aufzeichnungskanal-Verzeichnis (<streamname>)

Jahresverzeichnis (<yyyy>)

Monatsverzeichnis (<mm>)

Tagesverzeichnis (<tt>)

Stundenverzeichnis (<hh>)

Anmerkung: Auf Stundenebene werden die Mediadaten in gleichlange Zeitbereiche zusammengefasst.

Der Dateiname der Mediadaten setzt sich folgendermaßen zusammen:

<rootfilepath>\

<context>\

<session>\

<streamname>\

<yyyy>\

<mm>\

<tt>\

<hh>\

<streamname>_<mm>.<audio|video>.<0...N>

Dabei werden die Verzeichnisnamen nach dem folgenden Schema vergeben:

<rootfilepath>: Die Definition erfolgt über die Bedienoberfläche

<context>: Die Definition erfolgt in der Datenbank

<session>: Die Definition erfolgt in der Datenbank

<streamname>: Ergibt sich aus dem Namen des Kameradatenpunktes und der Streamnummer (1-3) in folgender Form:

<Datenpunktname> für Stream 1 z.B. Camera_00345

<Datenpunktname>_<Streamnummer> für Stream 2 & 3 z.B. Camera_00345_2 (Stream_2) oder Camera_00345_3 (Stream 3)

<yyyy>\<mm>\<tt>\<hh>\<streamname>_<mm>: Ergibt sich aus der Textdarstellung (Jahr/Monat/Tag/Stunde/<streamname>_minute) der UTC-Zeitstempel der aufgezeichneten Streaming-Daten, die von der Komponente AccVimaccInterface von einer STreaming-Quelle weitergereicht bzw. erzeugt werden.

<audio|video>.<0...N>: Kennzeichnet die Sub-Streams eines Streams mit dem Type Video und einer Indizierung über eine Ziffer. Der Wert wird von der Komponente AccVimaccInterface festgelegt. Auf diese Weise wäre es beispielsweise möglich für einen Videokanal zwei Streams in unterschiedlichen Qualitäten für zwei verschiedene Aufläsungen (z.B. für PAL und CIF) aufzuzeichnen, die dann als *.video.0 und *video.1 abgespeichert werden würden.

Die Zuordnung zwischen den Streaming-Daten und der eigentlichen Mediadatei erfolgt immer über konkrete Zeitstempel.

Diese Zeitstempel werden in der sogenannten Index-Datenbank abgelegt. Für die Media-Daten eines Sub-Streams eines Aufzeichnungskanals existiert immer genau eine Index-Datenbank (sqllite3-Datenbank) die alle Indexinformationen sammelt.

Der Datename der Indexdatenbank wird nach dem folgenden Schema gebildet:

<rootfilepath>\

<context>\

<session>\

<streamname>\

<streamname>.idx\

<yyyymmtt>.idx

In der Indexdatenbank ist jeder Datenblock (bei Video GOP Group of Picutres) des Streams eingetragten mit der zugehörigen SDP-Datei (Session Description Protocol), dem zeitlichen INtervall (von-, bis-Zeitpunkte) in Form von Zeitstempeln und dem File-Pointer nebst Fileindex.

Jeder Zeitstempel ist dabei im UTC-Zeitformat kodiert und verweist über das Datum auf das zugehörige Verzeichnis. Der Fileindex dagegen referenziert einen einminütigen Abschnitt innerhalb des Streams. Der Stream selbst ist ein sogenannter ‚Elementary Stream‘ ohne Metainformationen.

Sind die Streams unverschlüsselt aufgezeichnet worden, kann man die mehrminütigen Abschnitte in einer Standard-Wiedergabesoftware (z.B. dem Video-LAN-Client vlc.exe) ansehen, in dem man die entsprechenden Dateien umbenennt (z.B. in *.h264). Dort werden sie korrekt wiedergegeben.

AccVimaccSystemMonitor

Überwacht das gesamte vimacc System (mit allen Rechnern, Prozessen, Lizenzen, usw.) um den Zustand des Systems zu ermitteln und in der Config bereitzustellen.

Prozessverteilung auf die Rechner eines Video OA Systems:

Hierbei wird davon ausgegangen, dass für die Integration der Peripheriegeräte (wie z.B. Netzwerkkameras) separate Interfacerechner betrieben werden. Sofern die Netzwerk- und CPU-Auslastung der Serverrechner dies zulässt, können die Komponenten eines WinCC OA Video Interfaces aber auch auf den Serverrechnern betrieben werden. Dies ist allerdings von verschiedenen Einflussgrößen abhängig, wie etwa der Anzahl der gleichzeitig zu übertragenen Streams, der Anzahl der gleichzeitig aufzuzeichnenden Streams, oder der geforderten Bildauflösung und Bildwiederholrate, und muss im Einzelfall entschieden werden.

Log-Dateien

Für die einzelnen Dienste werden täglich unter C:\vimacc\log\<component name>_<hostname>_<date>.log automatisch Log-Dateien angelegt.

Anmerkung: Alle Zeitstempel der vimacc-Dienste werden in UTC gespeichert.

Per Default werden diese Dateien für 30 Tage aufbewahrt. Diese Zeitspanne kann in der conf-Datei der jeweiligen Dienste über den Eintrag Logging/Days verändert werden.

Die Größe der Log-Dateien wird durch Ermittlung der Schreibrate über einen gewissen Zeitraum definiert. Zum Festlegen der Maximalgröße einer Logdatei stehen in der conf-Datei der Dienste folgende Einträge zur Verfügung:


Eintrag	Default	Beschreibung
CheckFileSize	10	Gibt an, ab welcher Größe (in Megabyte) der Prüfalgorithmus initialisiert wird.
BandwidthCheckInterval	15	Zeit in Minuten in der die verbrauchte Datenmenge gemessen wird und die mindestens vergeht bevor die nächste Prüfung erfolgt. Hinweis: Die verstrichene Zeit wird implizit beim Schreibvorgang ermittelt. Daher kann es vorkommen, dass bis zur nächsten Überprüfung auch mehr Zeit verstreicht, sofern keine oder wenig Daten geschrieben werden.
MaxLoggingBandwidth	500	Die Menge an neuen Daten in Kilobyte die maximal im Messzeitraum anfallen darf.

Anmerkung: Die Defaultwerte werden auch automatisch verwendet, wenn die Einträge auf 0 gesetzt werden.

Nachdem eine Log-Datei die vorgegebene Größe (z.B. 10 MB) erreicht hat, beginnt der festgelegte Messzeitraum (z.B. 15 Minuten). Für den jeweiligen Messzeitraum wird die gesamte in die Datei geschriebene Datenmenge aufsummiert. Nach Ablauf der Zeit wird geprüft, ob die verarbeitete Datenmenge die zugelassene Grenze (z.B. 500 KB) überschreitet. Ist dies der Fall, wird eine Fehlermeldung in die Log-Datei geschrieben und die Datei wird geschlossen. Zusätzlich wird auch bei jedem Schreibvorgang die laut Einstellungen maximal mögliche Tagesdatenmenge geprüft. Dieser Prüfalgorithmus wird für jede neue Log-Datei (nach jedem Tageswechsel) durchgeführt.

Beispiel:

[Logging]
CheckFileSize=10
BandwidthCheckInterval=15
MaxLoggingBandwidth=500

Im schlimmsten Fall würden mit den angegebenen Defaultwerten pro Dienst Log-Dateien folgender Größe erstellt werden:

10 MB + 0,499 MB x 24h x 4 (da alle 15 Minuten die Datenmenge gemessen wird) = ca. 58 MB

Mit der Default-Aufbewahrungszeit von 30 Tagen würde in diesem Fall für die Log-Datei eines Dienstes ca. 1.8 GB Speicherplatz benötigt werden.

AccVimaccCommander

Der AccVimaccCommander ist ein Administrationstool, um die Datenpunktebene sichtbar vom Videosystem sichtbar zu machen, damit lassen sich genauere Informationen über das Videosystems sammeln.

AccVimaccDisplay

AccVimaccDisplay ist zuständig für die Video-Ausgabe über Multikanal-Monitorausgaben und Großbildprojektionen.

Die Komponente wird auf einem Rechner betrieben, der über eine oder mehrere Grafikkarten eine Anzeige-Einheit treibt. Eine Anzeige-Einheit besteht z.B. aus Monitorkaskaden, Videoprojektionen, oder Großbildwänden mit Grafik-Controllern. Je nach Anzahl der geforderten gleichzeitig darzustellenden Videokanäle können ein oder mehrere Anzeigeplätze in einem WinCC OA Video System betrieben werden.

Diese Komponente stellt keine interaktive eigene Benutzerschnittstelle zur Verfügung, sondern wird ausschließlich durch die Steuerungsbefehle eines WinCC OA Video Systems bedient. Jeder AccVimaccDisplay wird dazu durch einen Datenpunkt im WinCC OA System repräsentiert, auf den Steuerbefehle geschrieben und auf dem Statusmeldungen empfangen werden können.

AccVimaccDisplay kann so vollständig über ein WinCC OA User Interface gesteuert werden, so dass alle Live-Aufschaltungen und Playback-Aufschaltungen auf den Videomonitoren einer Videowall inklusive der Kamerasteuerung (PTZ) und der Playback-Steuerung (PLAY, STOP, SETPOSITION, usw.) von einem WinCC OA User Interface durchgeführt werden können.

Pro AccVimaccDisplay-Instanz können 32 Videobilder angezeigt werden. Auf einem Rechner können mehrere AccVimaccDisplay-Instanzen betrieben werden.

Die Anzahl der gleichzeitig darstellbaren Videostreams skaliert mit der Anzahl der AccVimaccDisplay-Instanzen, die auf verschiedenen Rechnern verteilt ablaufen.

Beispiel:

Mit einem Anzeigeplatz-Rechner der High-End-CPU-Leistungsklasse (z.B. Intel Core i7) ist man in der Lage, 64 Videokanäle Live- bzw. Playback gleichzeitig in voller Videoquellenauflösung (4CIF) und mit voller Bildrate (25 fps) dekodieren und darstellen zu können (Stand Dezember 2011).

Für die gleichzeitige Anzeige von 128 4CIF-Videokanälen werden beispielsweise zwei Rechner der High-End CPU-Leistungsklasse benötigt.

Für die gleichzeitige Anzeige von 128 FullHD-Videokanälen benötigt man dagegen bereits zehn Rechner der High-End CPU-Leistungsklasse, weil ein Kanal in FullHD Auflösung den fünffachen Leistungsbedarf gegenüber einem 4CIF-Kanal hat.

AccVimaccExportPlayer

Der Video Export Player des Videomanagementsystem ist eine Stand-Alone-Software zur Wiedergabe exportierter Video-Dateien. Sie wird beim Export von aufgezeichneten Video-Dateien mit auf den Wechselmedien, wie DVD, USB-Stick etc., abgelegt und ermöglich damit die Wiedergabe der Daten auf jedem beliebigen PC.

Der Video Export Player stellt die folgenden Funktionen zur Verfügung:

Wiedergabe exportierter Video-Dateien von Wechselmedien.
Bei der gleichzeitigen Wiedergabe der aufgezeichneten Video-Dateien von mehreren Video-Quellen werden diese zeitlich synchron ausgegeben.
Auswahl von Kameras über Listendarstellungen.
Bildgenaue Navigation in aufgezeichnetem Videomaterial

Anmerkung: Damit die exportierten Videodaten nicht von unbefugten Personen wiedergegeben werden können diese verschlüsselt auf den Wechselmedien abgelegt werden.

AccVimaccWorkstation

Die Komponente AccVimaccWorkstation kann prinzipiell auf jedem Rechner des WinCC OA Video Systems und sogar außerhalb eines WinCC OA Video Systems betrieben werden. Sie kann beispielsweise beim Export von aufgezeichneten Streaming-Daten mit auf den Wechselmedien abgelegt werden und ermöglich damit die Wiedergabe der Daten auf jedem beliebigen PC.

AccVimaccWorkstation stellt die folgenden Funktionen zur Verfügung:

Wiedergabe exportierter Streaming-Daten von Wechselmedien
Bei der gleichzeitigen Wiedergabe der aufgezeichneten Streaming-Daten von mehreren Streaming-Quellen werden diese zeitlich synchron ausgegeben.
Die maximale Anzahl der gleichzeitig ausgegebenen Streams orientiert sich an der Leistungsfähigkeit des Arbeitsplatzrechners. Ein Arbeitsplatz-Rechner der High-End-CPU-Leistungsklasse (z.B. Intel Core i7) ist in der Lage, gleichzeitig 64 4CIF-Videokanäle (Live- oder Playback) in voller Videoquellenauflösung (4CIF) und mit voller Bildrate (25 fps) dekodieren und darstellen zu können.
Auswahl von Kameras über Listendarstellungen.
Bildgenaue Navigation in aufgezeichnetem Videomaterial