Bandbreitenmanagement bei GigE Vision

GigE Vision Kameras können während der Bildübertragung einen großen Teil der verfügbaren Übertragungskapazität beanspruchen. Für einen stabilen Betrieb darf die Bandbreite des Netzwerks jedoch nicht vollständig für Bilddaten eingeplant werden, da ausreichend Reserve für weitere Kommunikation verbleiben muss.

Dieses Kapitel erläutert zunächst die Grundlagen der Bildübertragung und beschreibt anschließend Möglichkeiten zum Bandbreitenmanagement für einzelne und mehrere Kameras. Darüber hinaus werden Hinweise zur Auslegung des Netzwerks und zu den Anforderungen an die beteiligten Netzwerkkomponenten gegeben.

Grundlagen der Bildübertragung

Die Datenmenge eines Kamerabildes ist in der Regel größer als die Nutzlast, die mit einem einzelnen Ethernet-Frame übertragen werden kann, sodass die Daten in kleinere Einheiten zerlegt werden müssen. Bei GigE Vision erfolgt die Aufteilung der Bilddaten gemäß dem GigE Vision Stream Protocol (GVSP) in einzelne GVSP-Pakete, die über UDP/IP jeweils in einem Ethernet-Frame übertragen werden. Die zulässige Paketgröße wird durch die kleinste Maximum Transmission Unit (MTU) entlang des gesamten Übertragungspfads begrenzt. Maßgeblich ist dabei, welche Ethernet-Frame-Größe die beteiligten Netzwerkkomponenten tatsächlich unterstützen und wie sie konfiguriert sind. Jedes GVSP-Paket transportiert einen Teil der Bilddaten (Payload) und zusätzliche Protokollinformationen. Anhand dieser Informationen kann die Applikation die Pakete eindeutig zuordnen, in die richtige Reihenfolge bringen und daraus das vollständige Kamerabild rekonstruieren.

Um möglichst hohe Bildraten sowie geringe Reaktions- und Übertragungszeiten zu erreichen, sendet eine Kamera die Pakete eines Bildes standardmäßig unmittelbar hintereinander. In kabelgebundenen Ethernet-Netzen ist der Mindestabstand zwischen zwei Ethernet-Frames durch das im Standard festgelegte Inter-Frame Gap (IFG) von 96 Bitzeiten bzw. 12 Bytezeiten definiert. Gebräuchlich ist auch der allgemeinere Begriff Inter-Packet Gap (IPG), der im Folgenden verwendet wird. Der tatsächliche Abstand zwischen einzelnen Paketen kann größer ausfallen, das standardisierte IPG wird jedoch nie unterschritten.

Zusätzlich zur reinen Übertragungszeit bestimmen die Kameraeinstellungen wie Belichtungszeit und Trigger-Strategie sowie die modellabhängigen Leistungsgrenzen von Sensor und Hardware den zeitlichen Abstand zwischen zwei aufeinanderfolgenden Bildern.

Einzelkamerabetrieb

Der zuvor beschriebene, dicht gepackte Datenstrom kann während der Bildübertragung die gesamte verfügbare Bandbreite des Übertragungspfads beanspruchen. Übersteigt die anfallende Datenrate die Übertragungs- oder Verarbeitungskapazität, können Pakete verloren gehen. Neben der Bildübertragung muss das Netzwerk jedoch noch weitere Kommunikation bewältigen, um die ordnungsgemäße Funktion nach dem GigE Vision Standard sicherzustellen:

• GVCP (GigE Vision Control Protocol): Über diesen Steuerkanal konfiguriert und überwacht die Applikation die Kamera. Dies geschieht über lesende und schreibende Registerzugriffe sowie zyklische Heartbeat-Kommunikation. Werden die Rückmeldungen des Steuerkanals durch Bilddaten so lange verzögert, dass ein Timeout auftritt, kann dies zu Kommunikationsfehlern bis hin zum Verbindungsverlust führen.
• Resend-Mechanismus: Jedes GVSP-Paket ist über eine Block-ID (Nummer des Bildblocks) und eine Packet-ID (fortlaufende Paketnummer) eindeutig gekennzeichnet. Anhand dieser IDs erkennt die Applikation eine Lücke im Datenstrom. Unterstützt die Kamera den Resend-Mechanismus und ist er in der Applikation aktiviert, fordert diese das fehlende Paket über GVCP gezielt erneut an. Die Kamera wiederholt daraufhin die Übertragung, sofern die Daten in ihrem internen Puffer noch verfügbar sind. Dieser Vorgang belastet die Leitung zusätzlich, da die erneut übertragenen Pakete zum ohnehin laufenden Datenstrom hinzukommen. Dadurch kann sich die Zeit bis zur vollständigen Übertragung des betroffenen Bildes verlängern.

Bei der Systemauslegung muss daher grundsätzlich eine ausreichende Bandbreitenreserve einkalkuliert werden. Ist die Leitungskapazität bereits durch Bilddaten ausgelastet, können GVCP-Antworten und Resend-Pakete nicht mehr rechtzeitig übertragen werden. Jede Nachforderung erhöht die Last zusätzlich und kann dadurch weitere Paketverluste verursachen. Im ungünstigen Fall können nicht rechtzeitig übertragene Resend-Pakete zu unvollständigen Bildern und verzögerte GVCP-Antworten zum Verlust der Verbindung führen. Für einen stabilen Betrieb müssen sowohl eine ausreichende Bandbreitenreserve als auch die Verarbeitungskapazität der beteiligten Netzwerkkomponenten berücksichtigt werden. Hierfür gibt es im Wesentlichen zwei Ansätze:

• Reduzierung der Bildrate: Eine Verringerung der Bildrate vergrößert die Pausen zwischen den Bildübertragungen und schafft dadurch Bandbreitenreserve für GVCP-Antworten und Resend-Pakete. Da die Pakete eines einzelnen Bildes weiterhin unmittelbar hintereinander übertragen werden, bleiben dessen Übertragungszeit und damit der netzwerkbedingte Anteil an der Reaktionszeit so gering wie möglich. Die Bildrate sollte so gewählt werden, dass die Übertragung eines Bildes einschließlich möglicher zusätzlicher Kommunikation abgeschlossen werden kann, bevor die Übertragung des nächsten Bildes beginnt.
  Je nach Betriebsart erfolgt die Begrenzung der Bildrate entweder direkt in der Kamerakonfiguration, beispielsweise durch Limitierung der AcquisitionFrameRate, oder extern über eine angepasste Trigger-Strategie, beispielsweise durch eine reduzierte Trigger-Frequenz der SPS.
• Einfügen eines Packet Delays: Zur Reduzierung der kurzfristigen Paketlast stellt der GigE Vision Standard mit dem Kameraregister GevSCPD (Stream Channel Packet Delay) eine weitere Möglichkeit bereit. Über dieses Register wird zusätzlich zum standardmäßigen IPG eine definierte Wartezeit zwischen allen aufeinanderfolgenden Paketen des GVSP-Datenstroms eingefügt. Dadurch entstehen kontinuierlich kleine Lücken im Datenstrom und die Übertragungszeit des Bildes verlängert sich. Die übertragene Datenmenge bleibt dabei unverändert, die freie Übertragungskapazität verteilt sich jedoch gleichmäßig über die Bildübertragung statt in einem Block zwischen den Bildern.
  Dieser Mechanismus reduziert die kurzfristige Belastung der Hardwarekomponenten im Netzwerk, beispielsweise der Switches und des Netzwerkadapters, sowie der CPU des IPCs. Da die Daten zeitlich gestreckt übertragen werden, müssen die Netzwerkkomponenten pro Zeitintervall weniger Pakete verarbeiten und die CPU weniger Datenkopiervorgänge ausführen. Dadurch sinkt die kurzfristige Paket- und CPU-Last und damit das Risiko eines Überlaufens der Puffer.
  Über den TcCOM-Parameter MinPacketDelay kann der Wert für GevSCPD direkt vorgegeben werden. Die Angabe erfolgt in gerätespezifischen Hardware-Ticks. Da die Berechnung eines geeigneten Wertes aufwendig ist, unterstützen viele Kameras das Feature DeviceLinkThroughputLimit. Hierüber kann die maximal zulässige Datenrate direkt vorgegeben werden, beispielsweise in Bytes pro Sekunde oder herstellerspezifisch als relativer Prozentwert. Die Kamerafirmware berechnet aus der vorgegebenen Datenrate den erforderlichen Packet Delay und setzt den entsprechenden GevSCPD Wert automatisch.

Empfehlungen und Hinweise

Vor einer Begrenzung der Bildrate oder dem Einfügen eines Packet Delays sollte die größtmögliche Paketgröße verwendet werden, die von allen Komponenten entlang des Übertragungspfads unterstützt wird. Durch die Verwendung von Jumbo Frames steigt der Anteil der Bildnutzdaten pro Ethernet-Frame, während die Anzahl der zu übertragenden Pakete und der Protokoll-Overhead sinken. Voraussetzungen und Konfiguration sind im Kapitel Jumbo Frames beschrieben.

Die beiden zuvor beschriebenen Ansätze erfüllen unterschiedliche Aufgaben. Eine Reduzierung der Bildrate schafft Übertragungskapazität zwischen den Bildern, während ein Packet Delay die Übertragung zeitlich streckt und dadurch die kurzfristige Paketlast senkt.

Steht eine möglichst geringe Übertragungs- und Reaktionszeit im Vordergrund, sollte die Bildrate so begrenzt werden, dass ausreichende Pausen zwischen den Bildübertragungen entstehen. Da die Pakete eines Bildes weiterhin unmittelbar hintereinander übertragen werden, bleibt die kurzfristige Spitzenlast während der Bildübertragung jedoch unverändert hoch. Soll dagegen die Spitzenlast von Netzwerkkomponenten und CPU reduziert werden, kann der Datenstrom durch einen Packet Delay zeitlich gestreckt werden. Da sich dadurch die Übertragungszeit des Bildes verlängert, sollte der Packet Delay nur so groß wie erforderlich gewählt werden.

In beiden Fällen kann sich die maximal dauerhaft übertragbare Bildrate verringern, bei der Bildratenreduzierung unmittelbar, beim Packet Delay als Folge der längeren Übertragungszeit. Die Ansätze können bei Bedarf miteinander kombiniert werden.

Die gewählten Einstellungen sollten unter den maximal zu erwartenden Betriebsbedingungen überprüft werden. Dabei ist sicherzustellen, dass die für Bilddaten vorgesehene Datenrate unterhalb der stabil nutzbaren Datenrate des Übertragungspfads liegt, ausreichend Reserve für zusätzliche Kommunikation verbleibt und keine Paketverluste oder Timeouts auftreten.

Mehrkamerabetrieb

Werden mehrere Kameras über einen Switch an einem Netzwerkport des IPCs betrieben, teilen sie sich einen gemeinsamen Übertragungspfad. Für einen stabilen Betrieb darf die Summe der mittleren Datenraten aller Kameras dessen Übertragungskapazität nicht überschreiten. Maßgeblich ist der am stärksten ausgelastete Abschnitt, in der Regel die Verbindung zwischen dem Switch und dem Netzwerkport des IPCs. Wie beim Einzelkamerabetrieb muss zusätzlich ausreichend Reserve für die GVCP-Kommunikation und Resend-Pakete verbleiben. Übersteigt die erforderliche Gesamtdatenrate dieses Limit, muss die Bilddatenmenge reduziert werden, beispielsweise durch eine geringere Bildrate oder das Setzen einer Region of Interest.

Über diese Bandbreitenbilanz hinaus sind im Mehrkamerabetrieb die kurzfristige Spitzenlast und die Verarbeitungskapazität der beteiligten Komponenten entscheidend. Senden mehrere Kameras gleichzeitig, können Pakete verloren gehen, obwohl die mittlere Gesamtdatenrate innerhalb des zulässigen Bereichs liegt.

Rechenbeispiel: Drei Kameras an einem 1-Gbit/s-Port

Die mittlere Bilddatenrate einer Kamera kann überschlägig wie folgt berechnet werden:

Bilddatenrate [Byte/s] = Auflösung [Pixel] × Bytes pro Pixel × Bildrate [fps]

Für die gesamte Netzwerklast kommt noch der Protokoll-Overhead hinzu, der in dieser vereinfachten Berechnung nicht berücksichtigt wird.

Für eine Kamera mit einer Auflösung von 1920 × 1200 Pixel, dem Pixelformat Mono8 mit 1 Byte pro Pixel und einer Bildrate von 30 fps ergibt sich:

1920 × 1200 × 1 Byte × 30 fps = 69,12 MB/s

Für drei identische Kameras beträgt die gesamte Bilddatenrate:

3 × 69,12 MB/s = 207,36 MB/s

Eine Netzwerkverbindung mit 1 Gbit/s besitzt eine Bruttodatenrate von 125 MB/s. Aufgrund des Protokoll-Overheads und der erforderlichen Reserve für GVCP-Kommunikation und Resend-Pakete steht diese Datenrate nicht vollständig für Bilddaten zur Verfügung. Für dieses Beispiel wird eine stabil nutzbare Bilddatenrate von etwa 110 bis 115 MB/s angenommen. Der tatsächlich nutzbare Wert hängt von weiteren Faktoren ab, beispielsweise von der Paketgröße, den eingesetzten Netzwerkkomponenten und deren Konfiguration. Er muss daher unter den tatsächlichen Betriebsbedingungen überprüft werden.

Die erforderliche Bildnutzdatenrate von 207,36 MB/s überschreitet diesen Planungswert deutlich. Der Betrieb mit den gewählten Einstellungen ist über den gemeinsamen 1-Gbit/s-Port daher nicht möglich. Eine mögliche Gegenmaßnahme ist die Reduzierung der Bildrate auf 15 fps:

3 × 1920 × 1200 × 1 Byte × 15 fps = 103,68 MB/s

Damit liegt die mittlere Bilddatenrate rechnerisch unterhalb des für dieses Beispiel angenommenen Planungswerts. Ein stabiler Betrieb ist damit jedoch nicht sichergestellt, da insbesondere das gleichzeitige Senden mehrerer Kameras kurzfristige Überlastungen verursachen kann.

Kurzfristige Spitzenlast

Auch wenn die mittlere Gesamtdatenrate innerhalb der stabil nutzbaren Datenrate des gemeinsamen Übertragungspfads liegt, können kurzfristige Überlastungen auftreten. Dies ist insbesondere der Fall, wenn mehrere Kameras gleichzeitig mit der Übertragung ihrer Bilddaten beginnen.

Sind beispielsweise drei Kameras jeweils über eine 1-Gbit/s-Verbindung an einen Switch angeschlossen, können am Switch kurzzeitig Daten mit einer Gesamtrate von bis zu 3 Gbit/s eintreffen. Über die gemeinsame 1-Gbit/s-Verbindung zum IPC kann jedoch nur ein Teil davon unmittelbar weitergeleitet werden. Die überschüssigen Pakete müssen zunächst im Switch zwischengespeichert werden. Reicht dessen Verarbeitungs- oder Pufferkapazität für die Dauer der gleichzeitigen Übertragung nicht aus, werden Pakete verworfen und fehlen anschließend im Datenstrom.

Neben der mittleren Bandbreitenbilanz müssen daher die kurzfristige Spitzenlast, die Pufferkapazität des Switches und die Verarbeitungskapazität des Gesamtsystems berücksichtigt werden.

Maßnahmen zur Reduzierung der Spitzenlast

Um kurzfristige Überlastungen am Switch zu vermeiden, müssen die Datenströme der Kameras zeitlich entzerrt werden. Hierbei kann zwischen kameraseitigen und prozessseitigen Maßnahmen unterschieden werden:

• Begrenzung des Datenstroms: Das im Abschnitt Einzelkamerabetrieb beschriebene Packet Delay streckt die Bildübertragung jeder Kamera zeitlich. Dadurch treffen pro Zeitintervall weniger Pakete am Switch ein, sodass dieser die Datenströme kontinuierlicher über die gemeinsame Verbindung zum IPC weiterleiten kann. Die Datenströme können sich weiterhin zeitlich überlagern, die kurzfristige Paketlast und das Ausmaß möglicher Rückstaus werden jedoch reduziert. Voraussetzung bleibt, dass die Verarbeitungs- und Pufferkapazität des Switches für die verbleibende Last ausreicht.
• Zeitliche Trennung der Bildübertragungen: Wenn der Prozess ausreichende zeitliche Freiräume bietet, können die Kameras nacheinander getriggert werden. Dadurch beginnen auch die Bildübertragungen zeitlich versetzt und die Datenströme überlagern sich am Switch nicht oder nur in geringem Umfang. Dies kann den erforderlichen Packet Delay reduzieren oder dessen Einsatz vollständig vermeiden.
  Der zeitliche Abstand sollte so gewählt werden, dass die Übertragung des vorherigen Bildes abgeschlossen ist, bevor die nächste Kamera mit der Übertragung beginnt. Zusätzlich sollte eine angemessene Sicherheitsreserve eingeplant werden, die mögliche Schwankungen der Übertragungszeit und zusätzliche Kommunikation berücksichtigt.
  Muss aus Prozessgründen synchron getriggert werden, bieten einige Kameramodelle ein FrameTransmissionDelay. Die Kameras werden dabei gleichzeitig getriggert, beginnen die Übertragung jedoch zeitversetzt. Es handelt sich nur um eine einmalige Verzögerung des Übertragungsbeginns, die Pakete werden anschließend weiterhin unmittelbar hintereinander gesendet. Vermieden wird dadurch ausschließlich die Überlagerung der Datenströme, während sich die Bereitstellung der Bilddaten der nachgelagerten Kameras entsprechend verzögert.
• Anpassung der Netzwerkinfrastruktur: Reicht die verfügbare Übertragungskapazität für die erforderliche Gesamtdatenrate nicht aus oder lässt sich die kurzfristige Spitzenlast nicht zuverlässig beherrschen, muss die Netzwerkinfrastruktur angepasst werden. Mögliche Maßnahmen sind ein Switch mit ausreichender Verarbeitungsleistung und ausreichend großen Paketpuffern, eine schnellere Verbindung zwischen Switch und IPC oder die Verteilung der Kameras auf mehrere Netzwerkports. Größere Paketpuffer können kurzfristige Überlastungen auffangen, gleichen eine dauerhafte Überschreitung der Übertragungskapazität jedoch nicht aus. Die erzeugte Datenmenge bleibt durch diese Maßnahmen unverändert. Je nach Maßnahme wird die Pufferreserve vergrößert, die verfügbare Übertragungs- oder Verarbeitungskapazität erhöht oder die Last auf mehrere Übertragungspfade verteilt.

Für einen stabilen Mehrkamerabetrieb müssen sowohl die Bandbreitenbilanz als auch die kurzfristige Spitzenlast berücksichtigt werden. Die beschriebenen Verfahren können bei Bedarf kombiniert werden. Die gewählte Systemauslegung sollte unter den maximal zu erwartenden Betriebsbedingungen auf Paketverluste und Timeouts geprüft werden.