Systemy rozpoznawania tablic GeoVision — analiza w kamerze czy GV-ASManager?

Zacznę od tego, co powtarzam każdemu, kto dzwoni z pytaniem „która kamera do tablic”: to nie jest pytanie o kamerę. To pytanie o to, gdzie ma się odbywać porównanie numeru z bazą, kto tę bazę utrzymuje i co dokładnie ma się stać po odczycie. Pojedyncza brama do firmy i parking z rozliczaniem czasu postoju to dwie zupełnie różne instalacje, choć obie „rozpoznają tablice”.

A nazwy z tytułu? GV-LPR Center i GV-LPR Standalone wciąż wyskakują w wyszukiwarce i ludzie przychodzą z nimi jak z gotową specyfikacją. Nie traktowałbym ich jako opisu tego, co GeoVision ma dziś w ofercie. Nie zakładam też, że GV-VMS jest prostym następcą GV-LPR Center — nie znalazłem na to potwierdzenia. To, co dokumentacja pokazuje wprost, to kamery liczące OCR u siebie oraz zarządzanie LPR przez GV-ASManager. I na tym się skupię.

Od obrazu tablicy do otwartej bramy

Mechanika jest prosta: kamera zamienia obraz tablicy w ciąg znaków (OCR), a ten ciąg trafia do porównania z listą pojazdów. Cała reszta — czy brama się otworzy, czy pojazd wyląduje w ewidencji postoju, czy wskoczy alarm z listy poszukiwanych — to już decyzja systemu, nie samego odczytu.

I tu jest sedno doboru. Odczytany numer można sprawdzić w bazie siedzącej w kamerze albo wysłać do centrali. Oba warianty działają, ale nadają się do innych obiektów. Zanim więc w ogóle zaczniesz przeglądać karty produktów, odpowiedz sobie na pięć rzeczy:

• gdzie ma się odbywać analiza i porównanie numerów;
• czy potrzebna jest jedna wspólna baza dla kilku wjazdów;
• czy system ma liczyć czas postoju i obsługiwać parking;
• jak fizycznie zepniesz to z bramą lub szlabanem;
• jakie urządzenia, kanały i licencje obsługuje oprogramowanie, na które się decydujesz.

Ostatni punkt ludzie pomijają najczęściej. Potem okazuje się, że kamera jest, serwer jest, a moduł LPR w VMS tej kamery nie widzi.

Wariant pierwszy: kamera liczy wszystko u siebie

To scenariusz, który wdrażam najczęściej — jedna brama, jedna lista uprawnionych aut, żadnego serwera.

Przykładem urządzenia liczącego OCR na brzegu sieci jest GeoVision GV-LPR2812-DL. Według producenta ma wbudowany procesor rozpoznawania tablic oparty na deep learning i potrafi porównać numer z bazą lokalną, z GV-ASManager albo z GV-Cloud Access Control, a następnie wyzwolić otwarcie bramy lub szlabanu. Czyli na małym obiekcie można skończyć na samej kamerze.

Z tego, co podaje karta: Digital I/O (1 in / 1 out), zasilanie DC 12V albo PoE (IEEE 802.3af). Jedno wyjście w zupełności starcza do jednego napędu.

Tylko uwaga na to wyjście. Napis „1 out” w specyfikacji nie znaczy, że możesz je wpiąć bezpośrednio do dowolnego sterownika szlabanu. Widziałem instalacje, gdzie ktoś podłączył wyjście kamery wprost do automatyki bez sprawdzenia, co ona oczekuje na wejściu, i potem szukał winy w OCR. Zanim cokolwiek podepniesz, zajrzyj do dokumentacji napędu i sprawdź, czy nie trzeba między nimi postawić modułu przekaźnikowego — u GeoVision to GV-Relay V2. Moim zdaniem lepiej założyć, że będzie potrzebny, i cieszyć się, jeśli nie.

Jedno zastrzeżenie: GV-LPR2812-DL opisuję jako przykład techniczny, nie jako rekomendację zakupową CTR.pl. Dostępność tego modelu w sklepie nie została potwierdzona.

Wariant drugi: wspólna baza w GV-ASManager

Kiedy wjazdów jest kilka, albo ktoś chce rozliczać czas postoju, sama kamera przestaje wystarczać. Punktem odniesienia jest wtedy dokumentacja GeoVision GV-LPR: opisana tam funkcja porównuje odczytane tablice z bazą GV-ASManager i obsługuje między innymi czas postoju, zarządzanie parkingiem oraz listę pojazdów poszukiwanych.

Producent podaje obsługę do 255 jednostek — pod tym pojęciem kryją się GV-DSP LPR, brzegowe kamery GV-IP LPR oraz systemy GV-DVR/GV-VMS LPR. Osobno jest limit do 8 kanałów rozpoznawania, ale dotyczy on GV-DVR LPR i GV-VMS LPR. Nie przenoś tej ósemki na każdą kamerę ani na dowolną licencję VMS, bo to inne ograniczenie dla innego elementu.

Czego dokumentacja nie obiecuje, a klienci lubią zakładać? Nieograniczonej rozbudowy, natychmiastowej synchronizacji wszystkich list i tego, że każda kamera wysyła do centrali tylko metadane zamiast obrazu. Jeśli którakolwiek z tych rzeczy jest dla projektu istotna, potwierdź ją dla konkretnej konfiguracji, a nie dla „ekosystemu GeoVision”.

Co sprawdzam przed wyborem

Zacznij od opisu procesu, nie od listy urządzeń. Kilka punktów, przez które przechodzę przy każdym LPR:

1. Rola instalacji. Tylko identyfikacja auta, sterowanie wjazdem, czy też parking z czasem postoju? To od razu zawęża wybór między wariantem pierwszym a drugim.
2. Miejsce porównania numeru. Lokalna baza wystarcza do prostego scenariusza; GV-ASManager daje funkcje wspólnego zarządzania opisane wyżej.
3. Kadr pod tablice. Kamera do LPR ma patrzeć na pas wjazdu i nic więcej. Kamera ogólnego podglądu, która „przy okazji” ma czytać tablice, kończy się reklamacją.
4. Zgodność programowa. Kamera, VMS, licencja, moduł analityczny — wspólne logo nie oznacza, że wszystko ze sobą gada.
5. Interfejs do automatyki. Jak pisałem przy kamerze — parametr I/O to nie to samo co możliwość bezpośredniego podpięcia szlabanu.
6. Status produktu. Na kartach potrafi jednocześnie wisieć „Dostępny” i EOL. Dostępny na wyprzedaży to nie to samo co produkt, na którym zbudujesz instalację na lata.

Kamery do takiego zastosowania porównasz w kategorii kamery IP, a przy części serwerowej zajrzyj do oprogramowania IP — tam trzeba doczytać licencje i obsługiwane moduły, zanim policzysz kanały.

Przykład: wjazd na parking z ewidencją postoju

Klient chce, żeby kamera czytała tablice przy wjeździe, sprawdzała uprawnienia i otwierała bramę. Do tego chce wiedzieć, ile kto stał.

Sam odczyt załatwi analiza lokalna w kamerze. Ale ewidencja czasu postoju to już funkcja z obszaru GV-ASManager — i to on decyduje o tym, jak instalacja będzie wyglądać po stronie serwera. W praktyce oznacza to, że przed zamówieniem potwierdzam pięć rzeczy: zgodność kamery z używaną wersją systemu, wymagane licencje i limity kanałów, sposób wymiany danych między urządzeniami, elektryczną zgodność wyjścia z automatyką bramy i to, czy wchodzi GV-Relay V2.

Nie składaj zestawu na zasadzie „wszystko GeoVision, więc zadziała”. Ścieżkę od odczytu tablicy do otwarcia bramy sprawdzam odcinek po odcinku.

Czego dokumentacja nie potwierdza

Krótko, bo to ważne przy rozmowie z klientem, który naczytał się materiałów marketingowych.

Lokalne rozpoznawanie, praca z bazą i sterowanie wjazdem są potwierdzone dla GV-LPR2812-DL. Nie dla wszystkich kamer GeoVision.

Nie potwierdzono, że ekosystem GV-LPR rozpoznaje markę i kolor pojazdu, mierzy średnią prędkość albo obsługuje tysiące kamer. Jeśli takie funkcje są w projekcie, potrzebujesz dokumentu odnoszącego się do wybranego urządzenia i konfiguracji — inaczej nie wpisuj ich do oferty.

No i same nazwy GV-LPR Center i GV-LPR Standalone nie mówią nic o statusie produktu, następcy ani zgodności z aktualnym oprogramowaniem. Przy modernizacji starej instalacji trzeba spisać konkretne modele, licencje i interfejsy, które tam siedzą. Bez tego nie da się rzetelnie powiedzieć, co zostaje, a co idzie do wymiany.

Zanim złożysz zamówienie

Przygotuj opis wjazdu, sposób, w jaki ma być prowadzona baza pojazdów, i dane istniejącej automatyki. Z tym zestawem możesz przejrzeć kamery IP albo odezwać się do CTR — sprawdzimy dostępność, licencje i zgodność elementów planowanej instalacji.