Przed zamówieniem kamery ANPR dla istniejącej szlabanu i platformy parkingowej należy sprawdzić pięć oddzielnych interfejsów: wideo, zdarzenia na tablicach rejestracyjnych pojazdów, uprawnienia dostępu, polecenia otwarcia i fizyczna informacja zwrotna. Obraz na żywo lub pomyślna odpowiedź API nie są dowodem na to, że zostanie dopuszczony właściwy pojazd, że powtórzone zdarzenie zostanie obsłużone jednorazowo, ani że szlaban faktycznie się otworzył.
Przydatnym produktem jest krótka umowa dotycząca interfejsu poparta przykładowymi komunikatami, dokładnymi wersjami sprzętu i oprogramowania oraz testem z udziałem świadka. Ten przewodnik pomaga integratorom systemów i nabywcom projektów przygotować umowę przed dostawą sprzętu. Jeśli najpierw potrzebujesz przeglądu urządzeń, których to dotyczy, zobacz nasze Przewodnik po komponentach systemu parkingowego LPR.
1. Oddziel pięć interfejsów w swojej ofercie
Poproś każdego dostawcę o wypełnienie poniższej matrycy dla proponowanej konfiguracji. Przypisz określoną firmę lub zespół do każdego zakresu odpowiedzialności; „system wspiera integrację” pozostawia zbyt wiele nierozwiązanych kwestii. Poniższe przykłady stanowią wymagania dotyczące zamówienia, a nie listę funkcji dostępnych w każdym aparacie.
| Interfejs | Dowody, o które należy poprosić | Odpowiedzialność do przypisania | Pytanie o akceptację |
|---|---|---|---|
| Wideo i obrazy | Obsługiwany interfejs strumienia lub obrazu, uwierzytelnianie, format i wymagania klienta. | Dostawca kamery i klient odbiorczy wideo. | Czy zamierzony klient może wyświetlić wymagany widok pasa ruchu i pobrać powiązany obraz? |
| Wydarzenia na płycie | Wersjonowana specyfikacja zdarzenia, rzeczywista, zredagowana próbka, definicje pól i zachowanie podczas dostarczania. | Dostawca kamer lub silników rozpoznających i integrator oprogramowania. | Czy aplikacja otrzymuje wynik tablicy z prawidłową zależnością pasa, czasu i zdarzenia? |
| Uprawnienia i listy | W przypadku podjęcia decyzji o dostępie; wypisz reguły odczytu/zapisu, okresy ważności, reguły dopasowywania i zachowanie synchronizacji. | Właściciel autorytatywnych danych uprawnień i komponentu je wymuszającego. | Czy uzupełnienia, wygaśnięcie i unieważnienie zmieniają dostęp zgodnie z ustaleniami? |
| Polecenie otwarcia | Udokumentowany interfejs API lub interfejs elektryczny, dozwolone polecenia, znaczenie odpowiedzi i wymagania sterownika. | Komponent decyzyjny, integrator i dostawca barier. | Czy jedna autoryzowana decyzja wydaje zamierzone polecenie na właściwy pas? |
| Fizyczne sprzężenie zwrotne | Udokumentowane, faktycznie dostępne sygnały pozycji, usterek lub przejścia, łącznie z ich źródłem i ograniczeniami. | Dostawca bariery lub czujnika i aplikacja odbiorcza. | Czy aplikacja może odróżnić żądanie od zaobserwowanego ruchu i pokazać nieznany stan, gdy nie jest dostępna informacja zwrotna? |
Trzymaj dwa ostatnie rzędy oddzielnie. Wyjście przekaźnikowe może przenosić żądanie otwarcia. Nie jest to samo w sobie pomiar położenia ramienia. Wskazanie otwarcia ramienia również nie potwierdza, że pojazd przejechał; potwierdzenie przejazdu wymaga własnego uzgodnionego dowodu, jeśli projekt tego wymaga.
2. Zdecyduj, który komponent może udzielić dostępu
Dwa wspólne rozwiązania umieszczają decyzję w różnych lokalizacjach. W układzie Edge-LED kamera lub lokalny kontroler sprawdza zapisaną listę uprawnień i żąda otwarcia. W przypadku rozwiązania sterowanego oprogramowaniem dane rozpoznawcze trafiają do aplikacji parkingowej, która ocenia wizytę lub pozwolenie i wysyła polecenie poprzez udokumentowaną ścieżkę kontroli.
Wybierz jawnie właściciela każdej decyzji o dostępie. Projekt hybrydowy może być odpowiedni, ale wymaga określonej zasady awaryjnej i powrotu do normalności. Należy unikać wydawania przez dwa niezależne komponenty normalnych poleceń otwarcia dla tego samego pojazdu bez uzgodnionej metody koordynacji.
Na przykład w przypadku płatnego wyjazdu stwierdzenie „tablica znajduje się na liście” może nie być pełnym warunkiem autoryzacji. Aplikacja parkingowa może wymagać oceny powiązanej sesji i stanu płatności. Zapytaj, gdzie podjęto tę decyzję i jak rejestrowane jest obejście operatora. Nie zakładaj, że lista dozwolonych kamer reprezentuje wszystkie reguły biznesowe.
Umieść w umowie zamierzone zachowanie w przypadku utraty odbiorcy zdarzenia lub usługi decyzyjnej: który komponent może nadal decydować, jakich danych używa i kto autoryzuje wyjątek. Jest to sprawdzenie zależności dla wybranych interfejsów, a nie powód do założenia, że każde urządzenie działa niezależnie w trybie offline.
3. Zamień nazwy protokołów w sprawdzalne oświadczenie o kompatybilności
„Obsługiwane RTSP”, „Zgodne z ONVIF”, „Dostępne API” i „Dostarczone SDK” odpowiadają na różne pytania. Działający podgląd wideo lub ogólna etykieta protokołu nie są wystarczającym dowodem na przepływ pracy z pełnym dostępem. Żądaj rzeczywistych usług, wiadomości i poleceń wdrażanych przez oprogramowanie odbierające.
ONVIF nie powinien być ograniczany do „tylko wideo”. Profil T obejmuje strumieniowe przesyłanie metadanych i obejmuje dodatkowe funkcje w określonych warunkach; Profil M dotyczy metadanych i zdarzeń analitycznych, w tym interfejsy istotne dla rozpoznawania tablic rejestracyjnych, jeżeli produkt obsługuje tę funkcję. Pozostaje jeszcze zweryfikowanie dokładnego urządzenia, klienta i wymaganych funkcji. Jeśli dostawca twierdzi, że jest zgodny z ONVIF, sprawdź model i wersję oprogramowania sprzętowego lub oprogramowania w pliku oficjalna baza danych produktów ONVIF.
W przypadku zastrzeżonego interfejsu API lub zestawu SDK uzyskaj użyteczną wersję dokumentacji i przykładową integrację, zanim potraktujesz interfejs jako dołączony. Potwierdź obsługiwany system operacyjny, środowisko wykonawcze i architekturę, metodę uwierzytelniania, subskrypcję zdarzeń lub konfigurację wywołania zwrotnego oraz osobę obsługującą łącznik w przypadku zmiany którejkolwiek ze stron.
Wyceń także prawo do korzystania z niego. Zapytaj, czy podany zakres obejmuje aplikację rozpoznającą, API zdarzeń, konektor i wymagane licencje na kanał lub urządzenie; czy aktywacja wymaga usługi zewnętrznej; i co się stanie po wygaśnięciu okresu próbnego lub wymianie sprzętu. Możliwość pobrania zestawu rozwojowego nie reguluje licencji produkcyjnej.
4. Przed napisaniem łącznika uzgodnij, co oznacza zdarzenie na płycie
Poproś o oryginalne zredagowane wydarzenie z proponowanej wersji, a nie tylko o zrzut ekranu nakładki z kamery. Widoczny ciąg tablic nie stanowi dowodu na to, że aplikacja otrzymała ten ciąg, wie, do którego pasa należy, ani czy może powiązać późniejsze aktualizacje z tą samą obserwacją.
Twój arkusz mapowania powinien odpowiedzieć na te pytania. Poniższe etykiety opisują informacje do omówienia, a nie uniwersalne nazwy pól API.
- Tożsamość: Czy istnieje stabilny identyfikator zdarzenia lub ścieżki? Jaki jest jego zakres i czas życia na różnych urządzeniach i po ponownym uruchomieniu? W jaki sposób powtarzające się dostawy i aktualizacje są powiązane z pierwotną obserwacją?
- Wynik płyty: Czy wartość jest rozpoznaniem pierwotnym, poprawionym wynikiem czy zgodnością z uprawnieniami? Co oznaczają puste wartości i dowolny wskaźnik pewności?
- Miejsce i czas: Które urządzenie i pas wygenerowały zdarzenie? Jaka strefa czasowa lub przesunięcie jest używane? Czy czas przechwycenia znacznika czasu to czas dostarczenia czy czas dostawy?
- Obrazy: Czy obraz jest osadzany, dołączany lub pobierany osobno? Jak długo jest on dostępny i co się stanie, jeśli odzyskanie się nie powiedzie?
- Cykl życia: Czy jeden pojazd może wygenerować pierwsze wykrycie, poprawiony wynik i zdarzenie odjazdu? Które wydarzenie kwalifikuje się do żądania decyzji o dostępie?
- Dostawa: Co potwierdza potwierdzenie? Jakie są reguły ponawiania prób, porządkowania, buforowania i ponownego łączenia?
Jeżeli nie ma stabilnego identyfikatora, należy zażądać od integratora zaproponowania i zademonstrowania metody korelacji. Sam tekst na tablicy jest słabym kluczem zdarzenia: ten sam pojazd może powrócić, mogą to zgłosić dwa pasy, a wynik rozpoznania może się zmienić. Każde okno czasowe lub reguła dopasowywania wymagają sprawdzenia w odniesieniu do rzeczywistego ruchu i udokumentowanego zachowania związanego ze zdarzeniami.
Oddziel zapisy historyczne od bieżących próśb o otwarcie
Zaprojektuj oprogramowanie odbiorcze tak, aby ponowne dostarczenie nie tworzyło kolejnego żądania otwarcia dla tej samej zaakceptowanej decyzji. Na tym polega idempotencja: powtórzona wiadomość nie powtarza wykonanej czynności. Potwierdzenie odbioru, zapis zdarzenia i zezwolenie pojazdowi na wjazd to osobne etapy; uzgodniona semantyka odpowiedzi powinna umożliwiać śledzenie błędów.
Zdarzenia buforowane wymagają szczególnej uwagi. Rozpoznawanie płyt Dokumentacja konfiguracji strumienia ostrzega, że ponawianie nieudanych prób webhooków może spowodować niezamierzone działanie bramy, gdy te webhooki kontrolują bramę. Lekcja zakupowa polega na ustaleniu sposobu przechowywania wydarzeń historycznych bez traktowania ich jako świeżego pozwolenia na otwarcie. Aby uniknąć tego problemu, nie należy bezkrytycznie odrzucać zapisów audytu.
Zdefiniuj aktualność sygnatury czasowej i kontroli tożsamości zdarzeń, sposób obsługi brakującego lub niewiarygodnego czasu oraz który komponent wymusza regułę. Dopuszczalny wiek jest decyzją projektową, a nie liczbą uniwersalną. Po ponownym podłączeniu pojazd może wymagać nowej obserwacji lub działania operatora, a nie ponownego odtwarzania polecenia.
5. Sprawdź ścieżkę poleceń i informację zwrotną, nie zgadując okablowania
Uzyskaj schemat połączeń dla rzeczywistego wyjścia kamery, modułu interfejsu i konfiguracja kontrolera bariery. Poproś odpowiedzialnego instalatora o sprawdzenie, czy sterownik oczekuje wejścia stykowego lub sygnału zasilania, czy dopuszczalne parametry elektryczne, zachowanie poleceń i wymagana izolacja. Złącze oznaczone „I/O” nie zapewnia kompatybilności elektrycznej. Nie kopiuj długości impulsów, wartości napięcia ani przypisań zacisków z innego modelu.
W przypadku kontroli sieci zapytaj, czy odpowiedź oznacza otrzymanie, zaakceptowanie lub fizycznie ukończenie. Następnie określ, w jaki sposób raportowany jest rzeczywisty stan, ile może mieć ten stan i co wyświetla aplikacja w przypadku utraty połączenia. Jeśli sprzęt nie wykazuje udokumentowanego sygnału zwrotnego położenia, zapisz to ograniczenie, zamiast rysować wskaźnik „brama otwarta” na podstawie potwierdzenia polecenia.
Zatwierdzone urządzenia zabezpieczające i logika sterowania szlabanu pozostają odpowiedzialne za bezpieczne poruszanie się. Wynik ANPR lub zgoda na wjazd wynikająca z reguł systemu nie jest detektorem przeszkód. Uruchomić interfejs, stosując procedury producenta i ustalenia dotyczące kontrolowanych testów w zakładzie; nie omijaj zabezpieczeń, aby przejść demonstrację.
6. Przed zatwierdzeniem zamówienia weź udział w teście interfejsu
Korzystaj z proponowanych modeli, wersji oprogramowania sprzętowego, aplikacji i złączy, mając aktywne uzgodnione licencje. Rozpocznij na kontrolowanym stanowisku lub torze demonstracyjnym, a następnie podczas uruchamiania potwierdź zachowanie zależne od miejsca. Zapisz zdarzenie, decyzję, polecenie i rzeczywistą informację zwrotną w odniesieniu do jednego odniesienia testowego. Zdefiniuj cele czasowe i reakcje na błędy przed demonstracją, zamiast wybierać próg pozytywny później.
| Testuj | Zachowanie wyrażające zgodę i demonstrowanie | Dowody do zachowania |
|---|---|---|
| Ważne pozwolenie | Świeża kwalifikująca się obserwacja skutkuje zamierzoną decyzją i jednym poleceniem dla prawidłowego pasa ruchu; Fizyczna informacja zwrotna jest oceniana osobno. | Zdarzenie wejściowe, wersja uprawnień, decyzja, polecenie i obserwowany stan kontrolera. |
| Odmowa, wygaśnięcie lub cofnięcie pozwolenia | Nie jest wymagane normalne automatyczne otwieranie; uzgodniona trasa operatora pozostaje dostępna. | Zmienione pozwolenie, wynik synchronizacji i wynikająca z niej decyzja. |
| Zduplikowane lub zmienione wydarzenie | Ponowna dostawa nie oznacza powtórzenia tej samej zaakceptowanej czynności. Skorygowany wynik podlega uzgodnionej zasadzie aktualizacji. | Powiązane tożsamości zdarzeń oraz liczba decyzji i poleceń. |
| Odbiornik niedostępny, następnie przywrócony | Ponowne próby, zaległości i odzyskiwanie są zgodne z umową; stare zapisy nie stają się po cichu nowymi prośbami o otwarcie. | Czasy oryginalne i dostawy, zapisy ponownych prób i zachowanie ponownego połączenia. |
| Ponowne uruchomienie komponentu | Po ponownym uruchomieniu uzgodnionych komponentów sprawdź trwałość uprawnień, ponowne połączenie i zachowanie podczas resetowania identyfikatora przed powtórzeniem ważnego testu i testu zduplikowanego zdarzenia. | Zrestartowane wersje, bieżący stan uprawnień, nowe tożsamości zdarzeń i wynikające z nich polecenia. |
| Polecenie przyjęte, ale brak ruchu | Aplikacja odróżnia potwierdzenie od stanu rzeczywistego i przywołuje ustaloną ścieżkę usterki lub pomocy. | Informacje zwrotne od kontrolera lub zatwierdzonego symulatora; brak wyłączonego urządzenia zabezpieczającego. |
| Zły pas lub niejednoznaczny kierunek | Zdarzenia nie mogą przypadkowo uruchomić sąsiedniej bariery; brakujący kierunek jest zgodny z wybraną regułą. | Mapowanie urządzeń/ścieżek oraz odbieranie dzienników i obserwacji fizycznych. |
| Awaria konta integracyjnego lub licencji | Widoczna jest utrata wymaganego zezwolenia lub licencji; obowiązuje uzgodniona procedura kontrolowanego działania. | Reakcja na błąd, alarm lub dziennik i odzyskiwanie po przywróceniu prawidłowego dostępu. |
| Obejście operatora | Działanie autoryzowanego operatora różni się od dostępu automatycznego i nie zakłóca następnej normalnej transakcji. | Odniesienie do operatora, powód, polecenie i późniejszy normalny test. |
Oznacz każdy wymagany wiersz jako wykazany, zakończony niepowodzeniem, wykluczony na mocy umowy lub nadal otwarty, wraz z właścicielem i terminem. Symulator może sprawdzić obsługę komunikatów; nie może poświadczyć fizycznego ruchu ani bezpieczeństwa. Jeśli sprzęt jest już zainstalowany i dany etap ulegnie awarii, użyj opcji Przewodnik diagnostyki usterek kamery LPR zorganizować badanie symptomów.
Co wysłać wraz z zapytaniem integracyjnym
Wyślij krótki brief, który pozwoli dostawcom ocenić rzeczywiste połączenie, zamiast odpowiadać na ogólne pytanie dotyczące zgodności:
- Modele kamer, barier i tablic kontrolnych; wersja sprzętu i oprogramowanie sprzętowe, jeśli są znane.
- Wersje oprogramowania parkingowego i złączy, miejsce wdrożenia, system operacyjny i kontakt w sprawie integracji.
- Prosty schemat pasa ruchu, mapa wejść/wyjść i komponent decydujący o dostępie.
- Wymagana próbka i pola zdarzenia, działania związane z zarządzaniem listą, ścieżka poleceń i rzeczywiste sygnały zwrotne.
- Ograniczenia sieciowe, wymagania dotyczące uwierzytelniania i zamierzone zachowanie, gdy zależność jest niedostępna.
- Matryca odpowiedzialności, przypadki testowe oraz dokumentacja, licencje i wsparcie zawarte w wycenie.
Aby zapytać o sprzęt SHUNJIE, skorzystaj z Strona kamery ANPR i dołącz ten brief do istniejących dokumentów interfejsu. Poproś o pisemne potwierdzenie dokładnego proponowanego modelu, wersji i zakresu integracji. Przydatna decyzja o zakupie opiera się na tych dowodach i uzgodnionych wynikach testów, a nie na ogólnej obietnicy, że sprzęt jest „łatwy do integracji”.
Wyróżniony obraz: koncepcyjny stół warsztatowy wygenerowany przez sztuczną inteligencję z ogólnym wyposażeniem. Nie jest to rzeczywista konfiguracja produktu SHUNJIE, układ okablowania ani ukończona integracja.
Wygenerowany przez sztuczną inteligencję koncepcyjny stół warsztatowy z ogólnym wyposażeniem. Nie jest to rzeczywista konfiguracja produktu SHUNJIE, układ okablowania ani ukończona integracja.
