ONVIF w praktyce – jak standard ułatwia integrację systemów bezpieczeństwa

Na kartach katalogowych kamer i innych urządzeń bezpieczeństwa często widnieje informacja „obsługuje ONVIF”. Łatwo odczytać ją jako gwarancję pełnej kompatybilności z innymi systemami. W rzeczywistości o zakresie integracji decydują profil ONVIF, wersja firmware’u oraz sposób, w jaki standard zaimplementowano po obu stronach połączenia. W dalszej części wyjaśniam, jaka jest rola ONVIF w pozyskiwaniu obrazu, co oznaczają poszczególne profile i kiedy integrację trzeba uzupełnić przez API producenta. Pokazuję też problemy, które najczęściej wychodzą podczas testów, oraz konsekwencje zakończenia obsługi Profile S w 2027 roku.

Jak wyglądał świat przed ONVIF

Przed upowszechnieniem ONVIF integrator musiał znać właściwy adres URL dla konkretnego producenta, modelu, kanału i rodzaju strumienia. Zmieniała się ścieżka, nazwy parametrów, a czasem również sposób przekazywania danych uwierzytelniających.

Pozostałością po tym sposobie pracy są publiczne katalogi, takie jak iSpy Camera Connection Database. Zawierają dziesiątki ścieżek RTSP i HTTP dla różnych urządzeń. Integrator wybierał z listy prawdopodobny wariant i sprawdzał go na fizycznej kamerze.

Skąd wzięła się nazwa ONVIF

Nazwa ONVIF to skrót od Open Network Video Interface Forum, czyli otwartego forum na rzecz standaryzacji interfejsu sieciowych produktów wideo. Organizację powołały w 2008 roku Axis Communications, Bosch i Sony — trzej producenci, którzy postanowili wspólnie ujednolicić sposób komunikacji między urządzeniami IP i uniezależnić integratorów od rozwiązań pojedynczych marek. Z czasem zakres prac forum wykroczył poza sam obraz, obejmując również kontrolę dostępu.

ONVIF nie przesyła obrazu

ONVIF bywa nazywany protokołem transmisji obrazu, ale jest to skrót myślowy. Standard opisuje wykrywanie urządzenia, odczyt jego możliwości, konfigurację mediów i sposób uzyskania informacji potrzebnych do uruchomienia transmisji.

Operacja GetStreamUri zwraca adres URI używany później do rozpoczęcia sesji RTSP. Obraz płynie przez RTP, a RTCP przekazuje informacje kontrolne o transmisji. Szczegóły opisują ONVIF Media Service Specification i ONVIF Streaming Specification.

Poszczególne elementy mają w tym procesie różne zadania:

• ONVIF pozwala pozyskać informacje i sterować ustandaryzowanymi funkcjami urządzenia;
• RTSP służy do zestawienia i kontroli sesji;
• RTP/RTCP odpowiada za transmisję mediów i informacje kontrolne;
• Kodek określa sposób kompresji obrazu (np. H.264, H.265).

Jak przebiega integracja urządzenia przez ONVIF

Klient najpierw wykrywa urządzenie i sprawdza udostępniane usługi. Po uwierzytelnieniu odczytuje profile mediów, pobiera URI strumienia i uruchamia odbiór obrazu. Jeżeli obie strony obsługują odpowiednie funkcje, tą samą drogą można integrować zdarzenia, wejścia i wyjścia, audio oraz sterowanie PTZ.

Automatyczne wykrywanie często zatrzymuje się na granicy segmentu sieci, ponieważ WS-Discovery korzysta z multicastu. W takim przypadku podanie adresu usługi urządzenia ręcznie może wystarczyć do zestawienia połączenia.

ONVIF to nie tylko kamery

Profil ONVIF określa zestaw funkcji wspólnych dla urządzenia i klienta. Profile dotyczą transmisji i zapisu obrazu, analityki oraz kontroli dostępu.

Aktualny zakres publikuje ONVIF na stronie Profiles. Urządzenie zgodne z jednym profilem nie musi obsługiwać pozostałych ani wszystkich funkcji opcjonalnych.

„Obsługuje ONVIF” nie zawsze oznacza oficjalną zgodność

Najwięcej nieporozumień powoduje słowo „zgodność”. W materiałach marketingowych określenia „ONVIF”, „ONVIF compatible” i „ONVIF conformant” bywają używane zamiennie. Tymczasem opisują różne sytuacje:

• techniczną implementację publicznej specyfikacji;
• oficjalnie zadeklarowaną zgodność konkretnego produktu i wersji firmware’u;
• rzeczywistą interoperacyjność funkcji wymaganych w danym projekcie.

Członkostwo producenta w organizacji nie obejmuje automatycznie całej jego oferty. W bazie ONVIF Conformant Products trzeba sprawdzić dokładny model, profil i wersję firmware’u. Testy wykonuje producent, a część funkcji profilu jest opcjonalna. Zasady procesu opisuje Conformance FAQ.

W efekcie podgląd obrazu może działać prawidłowo, podczas gdy zdarzenia, audio zwrotne, PTZ albo metadane analityczne pozostają niedostępne.

ONVIF czy API producenta?

ONVIF daje wspólny zakres funkcji dla wielu marek, więc nie trzeba utrzymywać osobnej integracji podstawowych operacji dla każdego producenta. Standard zwykle nie obejmuje jednak wszystkich możliwości urządzenia. Zaawansowana analityka, diagnostyka i najnowsze funkcje często są dostępne wyłącznie przez API albo SDK producenta.

W integracjach GEMOS najpierw wykorzystujemy funkcje dostępne przez ONVIF, a brakujące uzupełniamy przez interfejs producenta. Po aktualizacji firmware’u ponownie testujemy część zależną od API, ponieważ to ona jest najbardziej podatna na zmiany.

Najczęstsze problemy w praktyce

W naszych testach najwięcej czasu zajmują różnice między urządzeniami i konfiguracją sieci. Powtarzają się zwłaszcza:

• blokowanie discovery przez segmentację sieci;
• błędny czas urządzenia powodujący problemy z uwierzytelnianiem;
• konieczność osobnego włączenia ONVIF lub utworzenia dedykowanego użytkownika;
• niezgodny kodek, profil mediów, rozdzielczość albo transport UDP/TCP;
• niepełna obsługa zdarzeń, PTZ, audio lub metadanych;
• regresje po aktualizacji firmware’u.

Deklaracja zgodności nie zastępuje testu konkretnego modelu w docelowej sieci. Sam podgląd obrazu to za mało, jeżeli projekt wymaga także zdarzeń, PTZ, audio lub metadanych.

Co sprawdzić przed wdrożeniem

Przed wyborem urządzenia trzeba:

• wskazać wymagany profil i konkretne funkcje;
• sprawdzić model oraz firmware w oficjalnej bazie ONVIF;
• przetestować zdarzenia, PTZ, audio i metadane, jeżeli są wymagane;
• powtórzyć test po restarcie i planowanej aktualizacji firmware’u;
• zapisać sprawdzone wersje oprogramowania w dokumentacji projektu.

Tak pracujemy przy integracjach GEMOS: zaczynamy od funkcji dostępnych w standardzie, a następnie identyfikujemy te, które wymagają API producenta. W dokumentacji zapisujemy także wersje firmware’u i zakres testów do powtórzenia po aktualizacji.

Co z tego wynika?

ONVIF rozwiązuje konkretny problem: pozwala urządzeniom różnych producentów udostępniać podstawowe funkcje w uzgodniony sposób. Nadal trzeba sprawdzić konkretny model i firmware. Gdy potrzebna funkcja wykracza poza profil ONVIF, integrację uzupełnia się przez API producenta.

Jeżeli planujesz połączenie kamer, kontroli dostępu lub analityki z GEMOS, skontaktuj się z zespołem ela-compil. Sprawdzimy urządzenia, wymagane funkcje i zakres testów przed wdrożeniem.

FAQ

• Czy ONVIF przesyła obraz z kamery?Nie bezpośrednio. ONVIF pomaga uzyskać parametry i adres strumienia, który jest następnie obsługiwany przez RTSP/RTP.
• Czy Profile S przestanie działać 31 marca 2027 roku?Nie. Kończy się możliwość deklarowania nowych produktów i nowych wersji firmware'u jako zgodnych z Profile S, a nie działanie istniejących urządzeń.
• Czy każda kamera oznaczona jako „ONVIF” będzie współpracowała z GEMOS?Nie można tego zagwarantować na podstawie samego oznaczenia. Przed wdrożeniem sprawdzamy model i firmware w bazie ONVIF Conformant Products, a następnie testujemy funkcje wymagane w projekcie.
• Kiedy warto wykorzystać API producenta?Gdy projekt wymaga funkcji niedostępnych w standardzie, na przykład specjalistycznej analityki, konfiguracji lub rozbudowanej diagnostyki.

ONVIF® jest zastrzeżonym znakiem towarowym należącym do ONVIF, Inc. Ewentualne wykorzystanie logo ONVIF wymaga zachowania ONVIF Brand Standards oraz odpowiedniego uprawnienia lub zgody właściciela znaku.