IEC 62676-4:2025 Systemreaktionszeit als kritischer Faktor moderner Videoüberwachung

Die Veröffentlichung der IEC 62676-4:2025 im Oktober 2025 markiert einen fundamentalen Paradigmenwechsel in der Normierung von Videoüberwachungsanlagen (VSS) für Sicherheitsanwendungen. Während frühere Iterationen der Norm, insbesondere die Ausgabe von 2014 (IEC 62676-4:2014), ihren Schwerpunkt primär auf statische Bildqualität, Auflösungsparameter – das klassische DORI-Modell – und Installationsrichtlinien legten, rückt die Revision 2025 die temporale Integrität und die Systemreaktionszeit in den Fokus.

Die vorliegende Analyse untersucht erschöpfend die neuen Anforderungen an die Systemreaktionszeit. Die Norm IEC 62676-4:2025 postuliert unmissverständlich: Eine Videoüberwachungsanlage, die Informationen verzögert darstellt oder träge auf Bedienerbefehle reagiert, verliert ihre Eignung für sicherheitskritische Echtzeitanwendungen. Kernstück der neuen Anforderungen ist die Definition eines „optimalen Zeitfensters“ von 0 bis 0,2 Sekunden für die Systemreaktionszeit. Dieser Wert ist nicht willkürlich gewählt, sondern leitet sich direkt aus der psychophysikalischen Forschung zur Mensch-Computer-Interaktion (HCI) ab.

Der Bericht detailliert die technischen Herausforderungen, die sich aus diesen Anforderungen ergeben, von der Sensor-Latenz über die Netzwerkübertragung bis hin zur Rendering-Pipeline in der Leitstelle. Besonderes Augenmerk liegt auf der Umschaltung zwischen verschiedenen Aufzeichnungsmodi, periodisch vs. Alarm, der Hardware-Bereitschaft (Standby-Modi) und dem Ressourcenmanagement unter Hochlastbedingungen. Die Analyse zeigt, dass die Einhaltung der IEC 62676-4:2025 eine Abkehr von generischen IT-Komponenten hin zu spezialisierten, auf niedrige Systemreaktionszeiten optimierten Sicherheitsarchitekturen erfordert, wie sie beispielsweise in Hochsicherheitsbereichen (Casinos, Flughäfen) durch Hersteller wie Dallmeier implementiert werden.

Vor dem Einstieg in die technischen Details fassen wir die zentralen Punkte der IEC 62676-4:2025 zur Systemreaktionszeit zusammen:

• Die 0,2-Sekunden-Regel: Eine Systemreaktionszeit von unter 0,2 Sekunden gilt als das einzige Zeitfenster für eine „optimale“ Bedienung. Alles darüber wird vom menschlichen Gehirn als Verzögerung wahrgenommen.
• Verbot von „Deep Sleep“: Um die Systemreaktionszeit im Alarmfall minimal zu halten, verbietet die Norm faktisch Energiesparmodi für sicherheitskritische Komponenten (Kameras, HDDs, Monitore). Das System muss „Always On“ sein.
• Keine Blindzeiten: Beim Umschalten von Zeitraffer- auf Alarmaufzeichnung darf keine Lücke entstehen. Dies erzwingt den Einsatz von Pre-Alarm-Puffern im Arbeitsspeicher (RAM).
• UI-Priorisierung: Selbst, wenn das System unter Volllast steht, z.B. hunderte Alarme gleichzeitig anstehen, muss die Benutzeroberfläche sofort reagieren. Die Systemreaktionszeit der Quittierungstaste hat Vorrang vor der Videodarstellung.
• Feedback-Pflicht: Dauert eine Aktion länger als 0,5 Sekunden, muss das System dem Operator visuelles Feedback geben („Bitte warten…“). Ohne Feedback gilt das System ab 2 Sekunden Verzögerung als „inakzeptabel“.

1. Einführung: Die Systemreaktionszeit als Qualitätsmerkmal in der IEC 62676-4:2025

1.1 Der historische Kontext und die Evolution der Norm

Die Normenreihe IEC 62676 hat sich als globaler Standard für VSS etabliert. Die Vorgängerversion IEC 62676-4:2014 definierte Qualitätskriterien, die stark auf die räumliche Auflösung Pixel pro Meter fokussiert waren. Mit der Einführung der Version 2025, veröffentlicht am 9. Oktober 2025, reagiert das technische Komitee TC 79 der IEC auf die massive Digitalisierung und Vernetzung der Sicherheitstechnik.

In modernen IP-basierten Systemen ist die Systemreaktionszeit, oft als Latenz bezeichnet, zum kritischen Flaschenhals geworden. Während analoge Systeme das Bild nahezu lichtgeschwindigkeitsnah auf den Röhrenmonitor brachten, führen digitale Kodierung (H.264 / H.265), Paketierung, Routing, Pufferung und Dekodierung zu akkumulierten Verzögerungen. In komplexen Netzwerken können diese Verzögerungen Sekundenbruchteile bis hin zu mehreren Sekunden betragen, was die Systemreaktionszeit negativ beeinflusst.

Die IEC 62676-4:2025 stellt fest, dass eine hohe Bildauflösung wertlos ist, wenn das Bild den Operator zu spät erreicht, um eine Intervention einzuleiten. Die Norm erhebt die Systemreaktionszeit somit zu einem gleichwertigen Qualitätsmerkmal neben der Bildauflösung.

1.2 Die Kernforderung: Begrenzung und Determinismus

Das vom Nutzer bereitgestellte Lizenzmaterial zur IEC 62676-4:2025 definiert spezifische Szenarien, in denen die Systemreaktionszeiten begrenzt und auf einem „maximal akzeptablen und festgelegten Niveau“ gehalten werden müssen:

1. Alarm-to-Display Latenz: Die Systemreaktionszeit zwischen Auslösung und Anzeige.
2. Quittierungszeit: Systemreaktionszeit der Leitstelle auf Eingaben.
3. PTZ-Voreinstellung: Positionierzeit von Kameras.
4. Modus-Umschaltung: Zeit für den Wechsel von periodischer Aufzeichnung (Time Lapse) zu Alarmaufzeichnung (Realtime).
5. Operator-Reaktionszeit: Kognitive Belastungsgrenzen des Menschen, beeinflusst durch die Systemreaktionszeit.

Um diese Zeiten zu minimieren, fordert die Norm radikale Maßnahmen im Hardware-Design: Geräte müssen „ständig in Betrieb und im Standby-Modus“ sein. Das Konzept des „Deep Sleep“ oder „Cold Boot“ im Alarmfall wird für sicherheitskritische Komponenten faktisch untersagt, da es die Systemreaktionszeit drastisch verschlechtern würde.

2. Die Psycho-Physiologie der Systemreaktionszeit: Warum 0,2 Sekunden?

Die in der IEC 62676-4:2025 (Tabelle 2) definierte Grenze von 0,2 Sekunden für eine „optimale Reaktion“ basiert auf fundierten ergonomischen und neurologischen Erkenntnissen über die Wahrnehmung von Systemreaktionszeiten. Um die Härte dieser Anforderung zu verstehen, muss man die menschliche Wahrnehmungsschleife betrachten.

2.1 Die visuo-motorische Regelschleife (Closed-Loop Control)

Bei der Steuerung einer PTZ-Kamera zur Verfolgung eines Verdächtigen befindet sich der Operator in einem geschlossenen Regelkreis:

1. Wahrnehmung: Das Auge erfasst die Position des Ziels und des Fadenkreuzes auf dem Monitor.
2. Verarbeitung: Das Gehirn berechnet die Differenz und plant eine Korrekturbewegung.
3. Aktion: Die Hand bewegt den Joystick.
4. Systemantwort: Das System verarbeitet den Befehl, bewegt die Kamera, kodiert das neue Bild und zeigt es an (die effektive Systemreaktionszeit).

Die menschliche Reaktionszeit auf visuelle Reize liegt durchschnittlich bei etwa 200 bis 250 Millisekunden (0,2 – 0,25 s).

• Wenn die Systemreaktionszeit deutlich unterhalb dieser Schwelle liegt (< 0,2 s), empfindet das Gehirn die Reaktion als instantane Kausalität. Die Bewegung des Joysticks und die Bewegung des Bildes werden als ein einziges, synchrones Ereignis wahrgenommen. Das System wird „transparent“; der Operator steuert gefühlt direkt die Kamera, nicht einen Computer.
• Steigt die Systemreaktionszeit über 0,2 s, beginnt eine Entkopplung. Das Gehirn bemerkt die Diskrepanz.

2.2 Die Gefahren der Latenz: Pilot Induced Oscillation (PIO)

Im Bereich von 0,2 s bis 0,5 s („Verzögerung“) tritt ein gefährliches Phänomen auf, das aus der Luftfahrt als „Pilot Induced Oscillation“ bekannt ist.

Der Operator bewegt den Joystick, sieht aber aufgrund der schlechten Systemreaktionszeit keine sofortige Reaktion. Er nimmt instinktiv an, der Input sei zu schwach gewesen, und verstärkt den Ausschlag. Wenn das System dann verzögert (aber heftig) reagiert, schießt die Kamera über das Ziel hinaus. Der Operator korrigiert abrupt in die Gegenrichtung, wieder mit Verzögerung. Das System schwingt sich auf, eine präzise Verfolgung wird unmöglich.

Die IEC 62676-4:2025 trägt dem Rechnung, indem sie den Bereich 0,2 s – 0,5 s zwar als funktional, aber qualitativ mindert, „Verzögerung wird wahrgenommen und es wird versucht, sich anzupassen“, einstuft.

2.3 Die Kognitive Toleranzschwelle (2 Sekunden)

Ab 2 Sekunden bricht der interaktive Dialog zusammen. In der Computer-Mensch-Interaktion gilt eine Systemreaktionszeit von > 2 Sekunden ohne Feedback als Systemabbruch. Der Nutzer zweifelt, ob der Befehl überhaupt registriert wurde.

Daher schreibt die Norm zwingend vor:

• Bei 0,5 s bis 2 s: Feedbackpflicht („Bitte warten…“). Das System muss die Lücke überbrücken, indem es dem Operator signalisiert: „Ich arbeite daran.“
• Über 2 s: Inakzeptabel für direkte Steuerungen. Wenn eine Systemreaktionszeit länger braucht, muss es detaillierte Statusinformationen liefern, „Bildschirm verfügbar in xx Sekunden“, um den Operator nicht im Blindflug zu lassen.

3. Detaillierte Analyse der Systemreaktionszeit-Kategorien

Im Folgenden werden die fünf spezifischen Zeitintervalle analysiert, die laut IEC 62676-4:2025 begrenzt werden müssen. Wir betrachten die technischen Ursachen für schlechte Systemreaktionszeiten in diesen Bereichen und die notwendigen Lösungsarchitekturen.

3.1 Zeit zwischen Auslösung des Alarmzustands und Anzeige (Alarm-to-Display Latency)

Die Anforderung: Minimierung der Systemreaktionszeit vom physikalischen Ereignis (z.B. Türöffnung) bis zum sichtbaren Pop-up des Videobildes auf der Videowand oder dem Arbeitsplatzmonitor.

Technische Engpässe:

In einer typischen IP-VSS-Kette durchläuft ein Alarm viele Stationen, die die Systemreaktionszeit erhöhen:

1. Sensor-Debounce: Um Fehlalarme zu vermeiden, haben I/O-Eingänge oft eine Entprellzeit (z.B. 50-100 ms).
2. Polling vs. Interrupt: Viele ältere oder schlecht konfigurierte Video-Management-Systeme (VMS) fragen den Status von Kameras oder I/O-Modulen periodisch ab („Polling“). Ist das Polling-Intervall auf 1 Sekunde eingestellt, beträgt die durchschnittliche Systemreaktionszeit allein hier schon 500 ms.
3. Server-Verarbeitung: Der VMS-Server muss die Alarmregel verarbeiten („Wenn Eingang 1 aktiv, dann schalte Kamera 5 auf Monitor 2“). Dies dauert in Datenbanken oft nur Millisekunden, kann aber bei hoher Last steigen.
4. Client-Buffering: Der kritischste Punkt für die Systemreaktionszeit. Wenn der Client (Anzeigestation) den Befehl erhält, „Kamera 5“ anzuzeigen, muss er:
   • Den Stream anfordern (RTSP Setup).
   • Auf den nächsten I-Frame (Vollbild) warten, um die Dekodierung zu starten.
   • Einen Jitter-Buffer füllen, um Netzwerkschwankungen auszugleichen.

Lösungsstrategie für IEC-Konformität (< 0,2 s):

Um die optimale Systemreaktionszeit zu erreichen, sind radikale Architekturänderungen nötig:

• Push-Benachrichtigungen: Kameras müssen Alarme aktiv per Interrupt z.B. TCP-Push oder MQTT, an den Server senden, Polling ist unzulässig.
• Multicast-Pre-Subscription: In Hochsicherheitsleitstellen werden kritische Kameras oft permanent per Multicast an alle Clients gestreamt, aber im Hintergrund unsichtbar dekodiert. Bei Alarm wird lediglich der Layer der Grafikkarte von „Hidden“ auf „Visible“ geschaltet. Dies eliminiert die Zeit für Stream-Aufbau und I-Frame-Wartezeit vollständig („Instant Switch“) und drückt die Systemreaktionszeit gegen Null.
• Zero-Buffer Decoding: In LAN-Umgebungen mit hoher Bandbreite kann der Jitter-Buffer im Decoder minimiert werden.⁷

3.2 Umschaltzeit der Leitstelle zur Bestätigung des Empfangs (Ack Time)

Die Anforderung: Wenn der Operator den „Alarm Quittieren“-Knopf drückt, muss die Systemreaktionszeit minimal sein z.B. Verstummen des Summers, Änderung der Alarmfarbe in der Liste.

Implikation für die Software-Architektur:

Dies betrifft die Responsivität der Benutzeroberfläche (GUI). Ein häufiges Problem in schlecht programmierten VMS-Clients ist, dass der GUI-Thread, der Mausklicks verarbeitet, durch Hintergrundaufgaben wie das Rendern von 64 Videostreams blockiert wird, was die gefühlte Systemreaktionszeit ruiniert.

Die Norm fordert hier eine strikte Ressourcentrennung. Die Verarbeitung der Bedieneraktion muss die höchste Priorität im Thread-Scheduling des Betriebssystems haben. Selbst wenn die Videodarstellung aufgrund von CPU-Last stockt, muss der Quittierungsklick innerhalb von 0,2 s visuelles Feedback geben.

3.3 Voreinstellung der Bildaufnahmegeräte (PTZ-Presets)

Die Anforderung: Die Systemreaktionszeit bis eine PTZ-Kamera eine definierte Position eingenommen hat und ein fokussiertes Bild liefert.

Physik vs. Elektronik:

Hier unterscheidet die Norm implizit zwischen der Reaktion des Systems (Start der Bewegung) und der Ausführung (Dauer der Fahrt).

• Die Startzeit (initiale Systemreaktionszeit) muss < 0,2 s liegen.
• Die Fahrzeit ist physikalisch durch die Motorgeschwindigkeit begrenzt. Schnelle Dome-Kameras erreichen 400°/s bis 800°/s.
• Kritisch ist der Autofokus. Nach der schnellen Fahrt benötigt der Fokus oft 0,5 bis 1 Sekunde, um sich zu stabilisieren („Focus Hunting“). Während dieser Zeit ist das Bild unscharf und somit nutzlos.
• Hochleistungslösung: Moderne Systeme wie die in den Snippets erwähnten Dallmeier-Kameras nutzen oft prädiktiven Fokus oder Laser gestützte Messungen, um die Schärfe während der Fahrt anzupassen, sodass das Bild im Moment des Stillstands bereits scharf ist („Rapid Focus“).
• Alternative Panomera®: Multifokalsensor-Systeme umgehen dieses Problem vollständig. Da sie das gesamte Bild permanent aufzeichnen, gibt es keine mechanische Bewegung. Ein „virtueller PTZ-Schwenk“ ist rein digital und erfolgt innerhalb der Frame-Refresh-Rate des Monitors (< 0,016 s bei 60 Hz), was die IEC-Anforderung an die Systemreaktionszeit von < 0,2 s spielend erfüllt.

3.4 Umschalten vom periodischen Aufzeichnungsmodus in den Normalmodus (The French Clause)

Die Norm enthält den Passus: „temps mis par les matériels d’affichage pour démarrer ou pour passer du mode d’enregistrement périodique au mode normal, si un enregistrement périodique ist spécifiziert“, übersetzt: „Zeit, die die Anzeigegeräte benötigen, um zu starten oder um vom periodischen Aufzeichnungsmodus in den Normalmodus zu wechseln, falls eine periodische Aufzeichnung spezifiziert ist.“

Dies adressiert eine komplexe technische Hürde: Die Systemreaktionszeit beim Wechsel der Aufzeichnungsstrategie.

H4: Definition der Modi:

• Periodische Aufzeichnung (Time Lapse): Um Speicherplatz zu sparen, zeichnen Systeme im Ruhemodus oft nur mit geringer Bildrate auf z.B. 1 Bild pro Sekunde oder 1 Bild alle 5 Sekunden.
• Normalmodus (Alarm): Bei einem Ereignis soll sofort auf Echtzeit (25/30 fps oder 60 fps) mit hoher Bitrate umgeschaltet werden.

Das Problem der „GOP-Struktur“:

Videokompression (H.264/H.265) basiert auf „Group of Pictures“ (GOP). Ein Stream beginnt immer mit einem I-Frame (Intra-Frame, Vollbild), gefolgt von P-Frames (Differenzbildern). P-Frames können nicht ohne den vorherigen I-Frame dekodiert werden.

• Wenn eine Kamera im Periodischen Modus (1 fps) läuft, sendet sie vielleicht nur alle paar Sekunden einen neuen I-Frame.
• Tritt ein Alarm auf, muss der Encoder die laufende GOP abbrechen, einen neuen IDR-Frame (Instantaneous Decoder Refresh) generieren und auf 30 fps hochschalten.
• Viele Encoder benötigen für diesen „Reset“ Zeit bis zu 1-2 Sekunden, was die Systemreaktionszeit negativ beeinflusst. Zudem muss die Festplatte (HDD), die im Time-Lapse-Modus nur sporadisch schrieb, nun einen kontinuierlichen Datenstrom bewältigen.

Latenz-Risiko:

Genau in der Sekunde des Alarms, z.B. Einbruch, entsteht eine „Blindzeit“ durch eine zu lange Systemreaktionszeit bei der Umschaltung. Oder die ersten Sekunden des Alarmvideos sind noch im ruckeligen 1-fps-Format, bis der Encoder stabilisiert ist.

Lösung gemäß IEC 62676-4:2025:

Systeme müssen Pre-Alarm-Puffer im Arbeitsspeicher (RAM) verwenden.

• Die Kamera generiert intern immer den Hochgeschwindigkeits-Stream.
• Im Normalbetrieb werden davon nur Stichproben (1 fps) gespeichert.
• Gleichzeitig laufen die letzten 5-10 Sekunden des High-Speed-Streams kontinuierlich durch einen Ringpuffer im RAM.
• Bei Alarm wird dieser Puffer auf die Festplatte geschrieben (Flush).
• Ergebnis: Das aufgezeichnete Video beginnt bereits vor dem Alarm in voller Qualität und geht nahtlos weiter. Die effektive Systemreaktionszeit für die Aufzeichnung ist null oder sogar negativ (Retrospektive).¹⁵

3.5 Umschalten vom kontinuierlichen Modus in den Alarmaufzeichnungsmodus

Ähnlich wie beim periodischen Wechsel, betrifft dies oft die Qualität (Bitrate).

• Kontinuierlich: Hohe Kompression, niedrige Qualität (für Langzeitarchiv).
• Alarm: Verlustfreie oder gering komprimierte Qualität (für forensische Beweise).

Auch hier fordert die Norm, dass keine Bilder verloren gehen. Der Wechsel der Quantisierungsparameter im Encoder muss „On-the-fly“ erfolgen, ohne den Stream neu aufzubauen, um die Systemreaktionszeit nicht durch Schwarzbilder zu belasten. Dies erfordert hochentwickelte Encoder-Firmware, die über Standard-ONVIF-Profile oft hinausgeht und proprietäre Treiber erfordert.

3.6 Reaktionszeit des Bedieners und Informationsüberflutung

Die Norm schützt nicht nur das System, sondern auch den Menschen: „Das System darf nicht mehr Informationen generieren, als der Bediener tatsächlich verarbeiten kann.“

Kognitive Ergonomie:

Ein System, das 500 Alarme pro Sekunde mit 0,001 s Systemreaktionszeit auf den Schirm wirft, ist technisch perfekt, aber operativ nutzlos. Der Mensch wird zum „Flaschenhals“.

• Die Norm fordert implizit Alarm-Aggregation. Wenn eine Einbruchmeldeanlage auslöst und 50 Bewegungsmelder in einer Halle gleichzeitig feuern, darf das VSS nicht 50 einzelne Popup-Fenster öffnen. Es muss diese zu einem einzigen Ereignis, „Einbruch Zone Halle 1“, zusammenfassen.
• Priorisierung: Wenn der Operator gerade einen kritischen Alarm der Priorität 1 bearbeitet, müssen eingehende Alarme der Priorität 3, z.B. „Festplatte fast voll“, in eine Warteschlange geschoben werden, statt den Operator zu unterbrechen.

4. Betriebliche Anforderungen (Operational Requirements – OR)

Die IEC 62676-4 ist eine Anwendungsrichtlinie. Sie verlagert die Verantwortung für die Definition der genauen Werte in die Operational Requirements (OR). Der Planer muss festlegen, was für den spezifischen Anwendungsfall als „akzeptable Systemreaktionszeit“ gilt.

4.1 Definition basierend auf der Visualisierungsaufgabe

Die Tabelle 2 der Norm ist hierfür das zentrale Werkzeug. Die Anforderungen müssen an die Aufgabe gekoppelt sein:

Visualisierungsaufgabe	Kritikalität	Notwendige Systemreaktionszeit (IEC 62676-4:2025)	Beispiel-Technologie
Personenverfolgung (Live)	Extrem Hoch	Optimal (0 s – 0,2 s)	Low-Latency-Decoder, 60fps Kameras, Joystick-Direktsteuerung
Fahrzeugschleuse (Verifikation)	Hoch	Verzögert (0,2 s – 0,5 s)	Standard IP-Kamera, Software-Button zur Schrankenöffnung
Forensische Recherche (Playback)	Mittel	Erhebliche Verzögerung (0,5 s – 2 s)	Abruf von Archivmaterial von HDD (Spin-up Zeit zulässig mit „Bitte warten“)

Integration in das Pflichtenheft:

Ein generischer Satz wie „Das System muss schnell sein“ ist nach IEC 62676-4:2025 unzulässig. Der Text muss lauten: „Für PTZ-Steuerungen in Zone 1 (Perimeter) darf die Systemreaktionszeit zwischen Befehlsgabe und Bildreaktion gemäß IEC 62676-4:2025 Tabelle 2 den Wert von 0,2 Sekunden nicht überschreiten.“

5. Systemdesign für minimale Systemreaktionszeit: „Always On“ und Standby

Die Norm macht eine klare technische Vorgabe zur Erreichung der Ziele: „Um die Systemreaktionszeiten so weit wie möglich zu verkürzen, müssen Bildaufnahmegeräte, Kontrollbildschirme, Videorekorder usw. ständig in Betrieb und im Standby-Modus sein.“

5.1 Das Problem des „Cold Boot“

Moderne IT-Geräte sind auf Energiesparen getrimmt.

• Festplatten (HDD): Gehen oft nach 10-20 Minuten Inaktivität in den „Spin-Down“. Das Hochfahren („Spin-Up“) dauert 5-10 Sekunden, eine inakzeptable Systemreaktionszeit im Alarmfall.
• Monitore: Gehen in den „Deep Sleep“. Das Aufwachen nach Signalerkennung dauert oft 3-5 Sekunden (HDMI-Handshake).
• Kameras: Ein Neustart (Reboot) dauert bei komplexen AI-Kameras oft 60-90 Sekunden.

5.2 Der IEC-konforme „Hot Standby“

Für ein IEC-62676-4:2025-konformes System sind diese Verzögerungen inakzeptabel (> 2 s = Inakzeptabel).

Konsequenz für das Design:

1. Disable Sleep Modes: Alle Energiesparoptionen (OS-Level, BIOS-Level, Device-Level) müssen deaktiviert werden. Festplatten in Aufzeichnungsservern müssen 24/7 rotieren („Always Spin“), um die Systemreaktionszeit beim Schreibzugriff zu minimieren.
2. Monitor-Management: Monitore in Leitstellen dürfen nicht abgeschaltet werden, oder müssen spezielle „24/7 Industrial Standby“-Modi nutzen, die das Panel abdunkeln (Backlight off), aber die Signalelektronik aktiv halten, um ein Bild in < 0,5 s zu zeigen.
3. Netzwerk-Verbindungen: TCP-Sessions zwischen Kamera und Server sollten mittels „Keep-Alive“-Paketen offen gehalten werden („Heartbeat“), um den TCP-Handshake (3-Way-Handshake) im Alarmfall zu vermeiden und die Systemreaktionszeit beim Verbindungsaufbau zu eliminieren.

5.3 Konflikt mit Green-IT

Diese Anforderung steht im direkten Konflikt mit modernen Nachhaltigkeitszielen (Energieeffizienz). Die IEC 62676-4:2025 priorisiert hier jedoch eindeutig die Sicherheit (Safety/Security) vor der Energieeinsparung. In der Risikoanalyse muss dokumentiert werden, dass der erhöhte Energieverbrauch durch deaktivierten Standby eine notwendige Maßnahme zur Risikominderung (schnelle Systemreaktionszeit) ist.

6. Performance unter Last: Ressourcenallokation

Ein Schlüsselaspekt der Norm ist das Verhalten bei Überlast: „Wenn die Leistung aufgrund einer hohen Alarmrate… gering ist, müssen die grafischen Anzeigen immer ’normal‘ erscheinen, und das System muss in der Lage sein, mehr Ressourcen zuzuweisen.“

6.1 QoS auf Anwendungsebene

Das System muss über einen internen „Quality of Service“ (QoS) Manager verfügen, um die Systemreaktionszeit stabil zu halten.

• Szenario: Ein Server zeichnet 100 Kameras auf. Plötzlich kommen 20 Alarme gleichzeitig. Die CPU-Last steigt auf 100%.
• Traditionelles Verhalten: Das System wird träge, die Maus ruckelt, Videobilder frieren ein („Frame Drop“), die Systemreaktionszeit explodiert.
• IEC-konformes Verhalten: Das System erkennt die Lastspitze. Es priorisiert den Interaktions-Thread (Maus/Tastatur) und die Alarm-Darstellung. Dafür opfert es Ressourcen an unwichtiger Stelle:
  • Reduktion der Framerate bei der Aufzeichnung unkritischer Kameras.
  • Verschieben von Hintergrundaufgaben (Indizierung, Backup) auf später.
  • Reduktion der Auflösung von Live-Bildern, die nicht im Fokus sind, z.B. Thumbnail-Streams statt Main-Streams für die Übersichtswand.

6.2 Grafische Stabilität („Normal erscheinen“)

Die Norm fordert, dass die grafischen Anzeigen „immer normal“ erscheinen. Das bedeutet:

• Keine „Sanduhr“ (Cursor) bei kritischen Operationen.
• Keine „White Screens“ (Windows: „Keine Rückmeldung“).
• Menüs müssen sich öffnen, auch wenn der Inhalt (Video) noch lädt.

Dies erfordert eine asynchrone Programmierung der VMS-Client-Software, bei der die UI vollständig vom Daten-Backend entkoppelt ist, um dem Benutzer eine sofortige Systemreaktionszeit zu suggerieren.

7. Tabelle der Systemreaktionszeit (Analyse und Anwendung)

Die folgende Tabelle (basierend auf der Normvorlage) dient als Bewertungsmatrix für Abnahmetests (SAT – Site Acceptance Tests).

Systemreaktionszeit	Bewertung	Operator-Wahrnehmung & Systempflichten	Technische Implikation
0 s bis 0,2 s	Optimal	„Keine Verzögerung wahrnehmbar.“ Transparente Interaktion.	Erfordert Hardware-Decoding (GPU), Low-Latency Netzwerk (LAN/LWL), Interrupt-basierte I/O.
0,2 s bis 0,5 s	Verzögert	„Verzögerung wird wahrgenommen.“ Operator muss adaptieren (Vorhalten beim Steuern).	Akzeptabel für Standard-IP-Systeme. Grenzbereich für PTZ-Tracking schneller Objekte.
0,5 s bis 2 s	Erhebliche Verzögerung	Operator wird gestört. Pflicht: System muss „Bitte warten…“ anzeigen.	Typisch für WAN-Strecken oder Satellitenverbindungen. Ohne visuelles Feedback ist das System hier nicht normkonform.
> 2 s	Inakzeptabel	„Reagiert nicht mehr.“ System gilt als abgestürzt. Pflicht: Detaillierte Gründe/Countdown anzeigen.	Systemversagen für Echtzeitsicherheit. Nur zulässig für Archiv-Recherche („Cold Storage“).

7.1 Beispielanwendung: Dallmeier Panomera® im Casino-Kontext

Im Kontext des Lizenzgebers Dallmeier ist diese Tabelle von besonderer Relevanz. In Casinos wird „Sleight of Hand“ (Taschenspielertricks) in Sekundenbruchteilen durchgeführt. Eine Systemreaktionszeit von 0,3 Sekunden würde bedeuten, dass der Operator den Trick auf dem Monitor erst sieht, wenn er in der Realität schon vorbei ist.

Dallmeier setzt daher auf Technologien, die konsequent im Bereich < 0,2 s arbeiten:

• Verzicht auf komplexe Transcodierung im Live-Pfad.
• Direkter Zugriff auf unkomprimierte oder I-Frame-Only Streams für die Steuerung.
• Die Panomera®-Technologie erlaubt es mehreren Operatoren gleichzeitig, in der gleichen Szene zu zoomen, ohne sich gegenseitig die Kamera „wegzudrehen“ da es keine mechanische Bewegung gibt, wodurch die mechanische Latenz und Wartezeit auf Verfügbarkeit der Kamera komplett entfällt.

8. Fazit und Zusammenfassung

Die IEC 62676-4:2025 definiert Videoüberwachung neu: Weg von der reinen Pixelschlacht, hin zur Echtzeit-Performance und optimaler Systemreaktionszeit.

Für Planer und Errichter bedeutet dies:

1. Latenz-Budgetierung: Die Systemreaktionszeit muss genauso berechnet werden wie Speicherplatz oder Bandbreite. Jede Komponente (Kamera, Switch, Server, Client) hat ein „Zeit-Budget“.
2. Hardware-Auswahl: Komponenten müssen auf „Instant On“ und schnelle Modus-Wechsel geprüft werden. Consumer-Hardware mit aggressiven Stromsparmodi ist oft ungeeignet.
3. Netzwerk-Design: QoS ist Pflicht, um Alarmpakete zu priorisieren und die Systemreaktionszeit konstant zu halten.
4. Operator-Zentrierung: Das System muss so konfiguriert werden, dass es den Menschen nicht mit Daten flutet, sondern Informationen aggregiert und priorisiert darstellt.

Die Einhaltung der 0,2-Sekunden-Grenze für die optimale Systemreaktionszeit ist die „Königsdisziplin“ der Videoüberwachung. Sie trennt professionelle Sicherheitslösungen von einfacher Überwachungstechnik. Ein System, das diese Werte einhält, verschmilzt mit der Wahrnehmung des Operators und ermöglicht eine proaktive Gefahrenabwehr in Echtzeit.

9. Häufig gestellte Fragen (FAQs)

10. Disclaimer

Dieser Bericht dient ausschließlich Informationszwecken und stellt keine Rechtsberatung oder verbindliche technische Planungsvorgabe dar. Die Interpretation der Norm IEC 62676-4:2025 obliegt im Einzelfall den zertifizierten Prüfstellen und Sachverständigen. Für die Planung und Errichtung konkreter Sicherheitsanlagen sind stets die originalen Normentexte des VDE/IEC sowie die lokalen gesetzlichen Bestimmungen maßgeblich.

NUTZUNG | HAFTUNG
Trotz sorgfältiger Kontrolle übernehmen wir keine Gewähr für die Richtigkeit und Vollständigkeit der Inhalte.