LPR transforma imagens de placas em dados para pesquisa, controle de acesso e automação. Entenda captura, OCR, arquitetura, iluminação, integração, LGPD e comissionamento.
Confira!
LPR (License Plate Recognition), também chamado de ANPR em parte da literatura internacional, é uma tecnologia de reconhecimento automático de placas veiculares. O sistema captura a imagem do veículo, localiza a região da placa, interpreta seus caracteres e transforma o resultado em dado estruturado — por exemplo, uma sequência alfanumérica acompanhada de horário, câmera, imagem associada, nível de confiança e outros metadados. Esse dado pode ser pesquisado, comparado com listas, enviado ao VMS ou integrado a sistemas de controle de acesso, estacionamento, logística e segurança.
A leitura correta da placa não depende apenas do algoritmo OCR. O desempenho nasce de uma cadeia composta por geometria da câmera, tamanho da placa na imagem, velocidade do veículo, tempo de exposição, iluminação, foco, compressão, qualidade óptica, modelo de reconhecimento e regras de decisão. Uma câmera convencional pode produzir uma imagem visualmente agradável e ainda ser inadequada para LPR; inversamente, uma câmera configurada para reconhecer placas pode gerar uma cena menos “bonita” para o operador, mas tecnicamente superior para o algoritmo.
Em aplicações de controle de acesso, o LPR também não deve ser confundido com a decisão de autorização. Reconhecer “ABC1D23” é uma etapa. Decidir se esse veículo pode entrar, em qual horário, por qual acesso e associado a qual pessoa é função de outra camada. Em uma arquitetura bem definida, captura, reconhecimento, cadastro, regra de acesso, acionamento da barreira e geração de evidência são funções separadas, ainda que integradas.
Por isso, projetar LPR exige tratar a cadeia completa: captura → reconhecimento → validação → correlação → decisão → atuação → registro. O resultado precisa ser testado no ambiente real, sob as condições de velocidade, iluminação, placas e fluxo previstas para a operação.
Como funciona um sistema LPR
O funcionamento de um LPR pode variar conforme fabricante e arquitetura, mas a lógica geral começa pela captura de um quadro onde a placa possua qualidade e dimensão suficientes para análise. O software localiza a região provável da placa, normaliza ou prepara a imagem quando necessário, segmenta ou interpreta os caracteres e produz uma hipótese de leitura com algum nível de confiança.
Em algoritmos modernos, parte dessas etapas pode ser realizada por redes neurais ou pipelines de visão computacional que integram detecção e reconhecimento. O termo OCR continua útil para explicar a conversão da imagem em caracteres, mas não descreve sozinho toda a lógica de um sistema contemporâneo.
O resultado de reconhecimento normalmente é enriquecido por metadados. Além da sequência da placa, a aplicação pode associar país ou padrão de placa, horário, câmera, direção, faixa, recorte da placa, quadro de contexto e, em algumas soluções, atributos do veículo como classe, cor, marca ou modelo. O ONVIF Profile M é relevante nesse ecossistema porque padroniza interfaces de metadados e eventos para analytics, inclusive informações relacionadas a veículos e reconhecimento de placas quando suportadas pelos produtos conformes.
Depois do reconhecimento, o dado pode simplesmente ser armazenado para pesquisa ou pode acionar uma regra. Um estacionamento pode comparar a placa com lista de mensalistas; uma portaria pode consultar cadastro de veículos autorizados; um centro de segurança pode gerar alarme para uma lista de interesse; uma operação logística pode correlacionar a chegada do veículo com agendamento de doca.
A qualidade da decisão depende de não confundir “leitura” com “verdade absoluta”. Um LPR trabalha com probabilidade. Portanto, aplicações críticas precisam definir o que acontece quando a confiança é baixa, quando existem placas semelhantes, quando a leitura falha ou quando o veículo não consta no cadastro.
A arquitetura LPR vai além da câmera
Em LPR, reconhecer a placa e autorizar o acesso são funções distintas. Quando cadastro, regra de autorização, controladora e barreira não estão claramente integrados, uma leitura correta pode terminar em decisão incorreta ou em operação sem rastreabilidade.
Em implementações simples, o reconhecimento pode ocorrer na própria câmera. Em outras, o stream de vídeo é enviado a um servidor LPR, appliance ou serviço em nuvem. A escolha entre edge e server-side altera requisitos de processamento, banda, escalabilidade, latência, atualização e integração.
No processamento em borda, a câmera ou dispositivo próximo gera o metadado de placa e pode enviar apenas eventos relevantes ao VMS ou ao sistema de controle. Isso reduz dependência de processamento central e pode diminuir tráfego de analytics. Em contrapartida, capacidade computacional, modelos disponíveis e ciclo de atualização ficam vinculados ao edge device.
No processamento centralizado, um servidor recebe streams de várias câmeras e executa o reconhecimento. Essa arquitetura facilita centralização de modelos, gestão e expansão computacional, mas exige dimensionamento de CPU/GPU, quantidade de streams, licenciamento e rede. Soluções como o XProtect LPR utilizam servidores dedicados de reconhecimento e integram os eventos ao VMS.
Em controle de acesso veicular, a cadeia torna-se ainda mais rica. Uma arquitetura de referência pode envolver:
- câmera IP dedicada à captura e ao reconhecimento;
- mecanismo LPR em borda ou servidor;
- banco de dados com placa, veículo e vínculo com usuário;
- sistema de controle de acesso;
- controladora de campo;
- cancela ou portão;
- sensores de passagem e segurança;
- VMS para vídeo e evidência;
- API ou middleware para sincronização de cadastros;
- registro de evento e auditoria.
O projeto deve documentar qual sistema é a fonte da verdade de cada dado. O cadastro da pessoa pertence ao RH, ao sistema do condomínio ou ao controle de acesso? A placa é mantida em qual banco? Quem replica alterações? Qual sistema decide autorização? O VMS apenas registra ou também dispara regras? Essas perguntas evitam bancos divergentes e decisões inconsistentes.
O artigo sobre integração entre CFTV e controle de acesso aprofunda essa relação entre eventos, vídeo e operação.
A captura da placa é o primeiro requisito de desempenho
Se a placa não chega ao algoritmo com informação suficiente, nenhuma camada posterior recupera detalhe inexistente. Por isso, o projeto precisa partir da zona de captura: uma região espacial onde o veículo deve estar em posição adequada para que a placa seja lida.
A câmera precisa ser posicionada para que a placa ocupe dimensão útil na imagem durante tempo suficiente. Distância, altura, ângulo horizontal, ângulo vertical, largura da faixa e direção do veículo afetam diretamente o resultado. Quanto mais oblíqua a visão, maior a deformação projetiva e menor a quantidade efetiva de pixels distribuída sobre os caracteres.
O dimensionamento por densidade de pixels pode ajudar a compreender a geometria da cena, mas LPR é uma aplicação de análise por software e deve seguir também os requisitos do algoritmo utilizado. A IEC 62676-4:2025 distingue explicitamente requisitos de interpretação humana daqueles aplicáveis a analytics.
Isso significa que não existe um único valor universal de px/m que garanta LPR em qualquer produto. O projeto deve consultar a documentação da solução, validar tamanho de placa recomendado, resolução da região de interesse, velocidade admitida e faixa angular. Em sistemas críticos, uma prova de conceito ou teste de campo pode ser mais confiável que assumir parâmetros genéricos.
Também é necessário evitar o erro inverso: usar resolução excessiva sem necessidade. Alguns motores LPR trabalham melhor com streams e dimensões específicas; processar imagens muito maiores aumenta carga computacional e pode exigir redimensionamento interno. A resolução correta é a que entrega ao algoritmo o detalhe necessário dentro do envelope de operação.
Exposição, velocidade e movimento definem se os caracteres permanecem legíveis
Veículos se deslocam durante o tempo de exposição do sensor. Se o obturador permanecer aberto por tempo excessivo, a placa se move vários pixels no quadro e os caracteres ficam borrados. A câmera pode estar perfeitamente focada e ainda assim falhar.
Por isso, LPR frequentemente exige tempos de exposição mais curtos que os usados em videomonitoramento geral. Reduzir o tempo de exposição, porém, diminui a quantidade de luz captada. O projeto precisa compensar essa perda com sensor adequado, lente, iluminação e ganho controlado.
A velocidade crítica é aquela prevista na zona de leitura. Em uma cancela, o veículo pode aproximar-se lentamente; em uma via interna, pode passar a 30 ou 40 km/h; em rodovia, as condições são muito diferentes. A solução precisa ser especificada para esse cenário, e o comissionamento deve reproduzi-lo.
Frame rate também influencia quantos quadros úteis estão disponíveis durante a passagem. Entretanto, aumentar FPS sem controlar exposição não resolve motion blur. Um fluxo com muitos quadros borrados continua inadequado. A quantidade de frames deve ser analisada junto com velocidade, comprimento da zona útil e capacidade do motor de reconhecimento.
A configuração automática de exposição pode causar instabilidade. Ao anoitecer, a câmera pode aumentar tempo de exposição para clarear a cena e, sem limitação apropriada, degradar justamente a leitura de veículos em movimento. Em pontos LPR, parâmetros críticos devem ser controlados e documentados.
Iluminação e placas retrorrefletivas exigem tratamento específico
Placas veiculares possuem materiais e acabamentos que podem responder fortemente à iluminação frontal, especialmente no infravermelho. Isso é útil porque a placa pode se destacar do fundo, mas também cria risco de saturação. Se os caracteres ou o fundo estourarem para branco, o contraste necessário ao reconhecimento desaparece.
Faróis são outra fonte crítica de contraste. À noite, uma câmera voltada para a aproximação do veículo recebe duas fontes intensas próximas à placa. WDR, exposição, ganho e iluminação IR precisam ser configurados para preservar a região de interesse.
A posição do iluminador também importa. IR integrado ao eixo da câmera pode funcionar bem em determinadas geometrias, enquanto iluminação externa permite controlar melhor potência, ângulo e alcance. Reflexos em para-brisa, carroceria molhada, sinalização e superfícies metálicas podem interferir.
Câmeras dedicadas a LPR frequentemente utilizam perfis de imagem menos naturais, priorizando placa em vez da aparência global da cena. Isso reforça uma prática de projeto: quando a operação também precisa de contexto visual do veículo e ocupantes, pode ser adequado utilizar uma câmera de contexto separada ou combinar stream/evento LPR com outras câmeras no VMS.
O desempenho visual em CFTV ajuda a estruturar a análise de iluminação, exposição, WDR e movimento de forma mais ampla.
Precisão, confiança, falsos positivos e falsos negativos
Um LPR não deve ser especificado apenas com frases como “alta precisão”. É necessário definir como o desempenho será medido. As duas falhas mais importantes são o falso negativo — um veículo passa e a placa não é reconhecida corretamente — e o falso positivo ou falso match — o sistema interpreta uma placa como outra ou associa incorretamente o resultado a uma regra.
A métrica de acerto precisa ter denominador claro. “98% de precisão” pode significar coisas diferentes: placas detectadas, caracteres corretos, placas completamente corretas, leitura em condição ideal ou desempenho médio em um dataset do fabricante. No projeto, é preferível estabelecer um protocolo de teste: quantidade de passagens, distribuição de condições, placas distintas, sentidos, velocidades e critério de aprovação.
Nível de confiança deve ser tratado como variável operacional. Um threshold alto pode reduzir falsos matches e aumentar leituras rejeitadas; um threshold baixo pode elevar automação, mas aceitar interpretações mais incertas. O valor adequado depende do risco da aplicação.
Em uma garagem residencial, uma leitura incerta pode solicitar segunda tentativa ou intervenção do porteiro. Em uma aplicação de segurança pública, um alerta pode exigir validação humana antes de qualquer ação. Em uma portaria industrial, a placa pode ser apenas um dos fatores de autorização, junto com credencial do motorista, agendamento ou identificação do veículo.
O sistema também deve tratar caracteres ambíguos e padrões de placa. País, região e formato ajudam o algoritmo a restringir hipóteses. A documentação do XProtect LPR, por exemplo, utiliza módulos de país/região e match lists para configurar reconhecimento e correlação; essa é uma implementação específica, mas ilustra a importância de contexto no motor de decisão.
LPR aplicado a controle de acesso veicular
No controle de acesso, a placa funciona como identificador do veículo, mas não necessariamente como credencial única. Uma placa é visível publicamente, pode ser clonada, alterada ou reproduzida. Portanto, o nível de confiança atribuído ao LPR deve ser compatível com o risco do acesso.
Em ambientes de menor criticidade, a placa pode ser suficiente para automatizar entrada de veículos cadastrados, desde que existam mecanismos de auditoria e exceção. Em áreas críticas, pode ser combinada com credencial do usuário, biometria, cartão, autorização prévia ou validação pelo operador.
A integração ideal separa identificação de decisão. O LPR gera o identificador; o sistema de controle consulta regras; a controladora executa a abertura; sensores verificam passagem e segurança; o VMS preserva vídeo e evento. O artigo sobre controle de acesso em estacionamentos trata essa lógica operacional de forma mais ampla.
Sensores físicos continuam necessários. A câmera não deve substituir laço indutivo, sensor óptico ou dispositivo de segurança quando esses componentes são necessários para detectar presença e impedir fechamento da cancela sobre o veículo. LPR reconhece e informa; a automação de barreira precisa obedecer à lógica de segurança do equipamento.
Também deve existir comportamento definido para indisponibilidade. Se a câmera falhar, o acesso trava? Existe credencial alternativa? O operador pode liberar manualmente? A falha de integração é monitorada? O sistema trabalha offline? Essas regras precisam estar no projeto e no procedimento operacional.
Listas, eventos, VMS e pesquisa forense
Uma vez transformada em dado, a placa passa a ser pesquisável. O VMS ou plataforma LPR pode associar a leitura a listas de veículos autorizados, bloqueados, visitantes, fornecedores ou objetos de interesse. Um match pode gerar alarme, abrir uma barreira, iniciar gravação especial ou apresentar vídeo a um operador.
O valor operacional aumenta quando o evento mantém vínculo com evidência. Ao pesquisar uma placa, o operador deve conseguir acessar timestamp, câmera, recorte da placa, vídeo de contexto e informações correlatas. Isso reduz o tempo de investigação e preserva rastreabilidade.
A documentação atual do XProtect LPR demonstra esse modelo ao permitir eventos LPR, match lists, pesquisa e associação com vídeo. Em arquiteturas abertas, metadados e eventos podem ser compartilhados entre edge devices, analytics, VMS e outros sistemas por interfaces padronizadas quando os produtos implementam os perfis correspondentes.
Retenção de dados LPR merece política própria. Nem sempre o período necessário para armazenar vídeo é igual ao período necessário para manter metadados de placa. A organização deve definir finalidade, prazo, acesso, trilhas de auditoria e descarte.
A busca forense também exige sincronismo de horário. Câmeras, servidores LPR, VMS e controle de acesso devem utilizar referência temporal coerente. Uma divergência de segundos pode dificultar correlação entre placa reconhecida, abertura da cancela e gravação.
LPR e proteção de dados pessoais
Placas veiculares podem participar de operações de tratamento de dados pessoais quando, no contexto concreto, permitem identificar ou tornar identificável uma pessoa natural por associação com cadastros, histórico de acesso ou outros dados. Por isso, projetos LPR devem considerar a Lei Geral de Proteção de Dados e a governança da finalidade desde a concepção.
O ponto não é assumir que toda imagem de placa possui a mesma natureza em qualquer cenário, mas analisar o tratamento realizado. Um sistema que registra placa, nome do proprietário, horário de entrada, destino e histórico de presença possui capacidade de construir informação vinculada a indivíduos e requer controles compatíveis.
A base legal precisa ser definida pelo controlador conforme a finalidade e o contexto. O legítimo interesse é uma das hipóteses previstas para dados pessoais não sensíveis, mas não deve ser invocado automaticamente. A ANPD orienta a análise de finalidade, necessidade, legítima expectativa, balanceamento e salvaguardas. Outras bases legais podem ser mais adequadas conforme relação contratual, obrigação legal, proteção da vida, execução de políticas públicas ou demais hipóteses previstas na LGPD.
Princípios de necessidade e minimização afetam diretamente a engenharia: armazenar todos os eventos indefinidamente não é requisito técnico. A política deve especificar quais campos são mantidos, por quanto tempo, quem acessa, como ocorre pesquisa, quando há exportação e como os dados são eliminados.
Segurança também inclui controle de acesso lógico, autenticação, segregação de perfis, logs, criptografia quando aplicável, atualização de software e proteção das integrações. Uma API que sincroniza placas autorizadas merece o mesmo rigor que a câmera de campo.
Como projetar um ponto LPR
Geometria, exposição, iluminação, velocidade, motor de reconhecimento e integração precisam ser dimensionados em conjunto. O projeto transforma esses fatores em requisitos de campo verificáveis antes da implantação.
O projeto deve começar pelo requisito operacional e pela geometria da passagem. O primeiro levantamento identifica faixa, sentido, distância disponível, velocidade real, largura, iluminação existente, possibilidade de instalação, barreiras físicas, riscos de oclusão e condições diurna/noturna.
Em seguida é definida a zona de captura. O projetista determina onde o veículo deverá estar quando a placa possuir tamanho e ângulo compatíveis com o reconhecimento. Essa zona orienta posição, altura, distância focal, iluminação e eventuais sensores auxiliares.
Depois vem o dimensionamento do pipeline. É preciso decidir se o reconhecimento ocorre na borda ou servidor, como o resultado chega ao VMS, qual banco mantém cadastro, qual interface consulta autorização e quais ações podem ser executadas. Em controle de acesso, o diagrama de sequência é tão importante quanto a planta física.
Os requisitos devem incluir condições de exceção. Placa suja, ausência de placa, motocicleta, veículo muito próximo, fila, dois veículos simultâneos, retorno em ré, leitura duplicada, placa não cadastrada e falha de rede são casos previsíveis. O sistema precisa ter comportamento definido.
Uma matriz de projeto pode registrar:
| Dimensão | Requisito a definir |
| Geometria | posição, altura, ângulos, largura da faixa, zona de leitura |
| Movimento | velocidade de projeto e sentido |
| Imagem | foco, exposição, iluminação, tamanho útil da placa |
| Analytics | motor LPR, região/país, confiança, regras de retry |
| Integração | VMS, controle de acesso, API, banco e eventos |
| Atuação | cancela, portão, alarme, validação humana |
| Dados | campos, retenção, acesso, logs e exportação |
| Continuidade | falha da câmera, rede, servidor e sistema de acesso |
| Aceite | protocolo de passagens, condições e taxa de sucesso |
O projeto de CFTV IP e videomonitoramento deve integrar esses critérios ao restante do sistema de vídeo, enquanto o projeto de controle de acesso define a lógica de autorização e atuação.
Como testar e comissionar o LPR
Uma demonstração com poucas placas em condição favorável não comprova desempenho. O recebimento técnico deve testar passagens representativas, condições diurnas e noturnas, match lists, atuação, falhas e evidências de integração.
O comissionamento deve testar o desempenho do sistema completo, não apenas demonstrar algumas leituras bem-sucedidas. Antes do teste, câmera, foco, exposição, iluminação, região de interesse e parâmetros do motor precisam estar configurados conforme projeto.
O protocolo deve usar veículos e placas representativos. Quando possível, incluir diferentes formatos, cores, condições superficiais e trajetórias. As passagens devem ocorrer nas velocidades previstas, em ambos os sentidos quando aplicável e em condições diurnas/noturnas relevantes.
Cada passagem precisa produzir resultado verificável: placa esperada, placa reconhecida, confiança, timestamp e evidência associada. Isso permite calcular taxa de leitura completa e identificar padrão de erro. Se a aplicação depende de match list, a correlação e o alarme também devem ser testados.
Em controle de acesso, o teste continua após o OCR. Deve ser verificado se a placa consulta corretamente o cadastro, se a decisão de autorização é registrada, se a controladora recebe o comando, se a cancela abre, se sensores impedem fechamento indevido e se o evento fica associado ao vídeo.
Cenários de falha são obrigatórios em sistemas relevantes: perda de comunicação da câmera, indisponibilidade do servidor LPR, falha de API, cadastro desatualizado, perda do VMS e retorno de energia. O objetivo é saber como a operação se comporta fora da condição ideal.
A evidência de aceite deve registrar configuração final, amostra de eventos, resultados estatísticos, exceções, versões de software, licenças e pontos pendentes. Essa baseline permite distinguir degradação futura de problema de projeto ou implantação.
O que exigir na contratação de uma solução LPR
Uma contratação tecnicamente madura não pede apenas “câmeras com LPR”. O objeto precisa definir finalidade, cenário, integrações, responsabilidades e critérios de desempenho. A solução pode envolver projeto, fornecimento, instalação, configuração, desenvolvimento de integração, treinamento e operação assistida.
O documento de requisitos deve descrever quantidade e tipo de acessos, velocidade prevista, operação 24×7 ou restrita, condições ambientais, sistemas existentes e função do LPR. Deve indicar se a placa será apenas pesquisada, se participará de controle de acesso ou se acionará alarmes.
Entre os entregáveis de engenharia, são relevantes levantamento de campo, planta de pontos, memória de dimensionamento, diagrama de arquitetura, diagrama de sequência, tabela de integrações, especificação de câmeras e servidores, critérios de dados, matriz de responsabilidades, plano de testes e as built.
A integração precisa ser tratada contratualmente. Quem desenvolve API? Quem fornece documentação? Qual sistema é master do cadastro? O fornecedor deve demonstrar ambiente de teste? Como serão tratadas mudanças de versão? Como será validada interoperabilidade? Essas definições evitam que “integração incluída” se torne escopo indeterminado.
Também devem ser definidos critérios de medição e aceite. Percentual de passagens corretamente reconhecidas, condições de teste, disponibilidade da função, associação com vídeo, tempo de resposta, comportamento de falha e completude documental podem formar a baseline de recebimento.
Considerações finais
LPR é uma cadeia de engenharia que começa na cena e termina na decisão operacional. A câmera fornece a matéria-prima; o algoritmo transforma imagem em hipótese de placa; integrações correlacionam esse dado; sistemas de acesso ou segurança tomam decisões; dispositivos físicos atuam; e registros preservam evidência.
A confiabilidade depende de tratar cada elo explicitamente. Resolução sem geometria não basta. OCR sem controle de exposição não basta. Match list sem governança de cadastro não basta. Cancela sem sensores de segurança não basta. Evento sem vídeo e timestamp coerente limita auditoria.
Por isso, um bom projeto LPR define zona de captura, envelope de velocidade e iluminação, arquitetura de processamento, fonte de verdade dos cadastros, regras de decisão, retenção, contingência e método de aceite. Quando essas condições são documentadas e testadas, o reconhecimento de placas deixa de ser um recurso isolado da câmera e passa a funcionar como subsistema integrado de segurança e automação.
Referências técnicas
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 62676-1-1:2019 — Sistemas de videomonitoramento para uso em aplicações de segurança — Requisitos de sistema. Disponível em: [ABNT Catálogo](https://www.abntcatalogo.com.br/).
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-4:2025 — Video surveillance systems for use in security applications — Part 4: Application guidelines. Disponível em: [IEC Webstore](https://webstore.iec.ch/en/publication/83425).
[3] ONVIF. Profile M — Metadata and events for analytics applications. Disponível em: [ONVIF](https://www.onvif.org/profiles/profile-m/).
[4] MILESTONE SYSTEMS. XProtect LPR 2026 R1 — documentação de instalação, configuração e operação. Disponível em: [Milestone Documentation](https://doc.milestonesys.com/en-US/bundle/doc1040_2026r1/page/content/add-ons/add-on_lpr/lpr_installxprlpr.htm).
[5] BRASIL. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais (LGPD). Disponível em: [Planalto](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm).
[6] AUTORIDADE NACIONAL DE PROTEÇÃO DE DADOS. Guia Orientativo: Hipóteses Legais de Tratamento de Dados Pessoais — Legítimo Interesse. Disponível em: [ANPD](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia_orientativo_hipoteses_legais_tratamento_de_dados_pessoais_legitimo_interesse).
Perguntas frequentes
LPR é o reconhecimento automático de placas veiculares a partir de imagens. O sistema localiza a placa, interpreta os caracteres e gera um dado estruturado que pode ser pesquisado ou integrado a VMS, controle de acesso, estacionamento e outras aplicações.
Não exatamente. OCR é a etapa de interpretação dos caracteres. Um sistema LPR completo também envolve detecção/localização da placa, preparação da imagem, regras de confiança, metadados, correlação, eventos e integrações.
A câmera deve atender aos requisitos do motor LPR para tamanho da placa na imagem, ângulo, velocidade, exposição e iluminação. Não existe uma única resolução universal; o dimensionamento depende da geometria e da solução utilizada.
Não. Mais resolução pode ajudar a preservar detalhe, mas excesso de resolução não corrige motion blur, ângulo inadequado, foco ruim ou saturação por faróis e IR. Alguns motores também possuem requisitos específicos de stream.
Sim, desde que exista integração com o sistema de controle de acesso ou automação. A leitura da placa identifica o veículo; a autorização deve ser decidida por regras e cadastro, e a atuação da cancela precisa incluir dispositivos de segurança adequados.
O projeto deve definir um protocolo de teste com quantidade de passagens, velocidades, condições de iluminação e placas representativas. A medição deve distinguir leituras corretas, não leituras e leituras incorretas, além de testar match lists e integrações quando aplicáveis.
Podem envolver tratamento de dados pessoais quando, no contexto da operação, a placa é associada ou associável a uma pessoa natural, cadastro, histórico de acesso ou outros dados. A finalidade, base legal, retenção, acesso e medidas de segurança devem ser definidos pelo controlador.
Sim quando os produtos suportam as funções correspondentes. O Profile M padroniza metadados e eventos de analytics e prevê interfaces relacionadas a veículos e reconhecimento de placas, facilitando interoperabilidade entre dispositivos, serviços e clientes.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- LPR: aplicações e vantagens em sistemas de segurança eletrônica
- Controle de acesso em estacionamentos
- CFTV e controle de acesso: integração, VMS e critérios de projeto
- Metadados de Análise de Vídeo e ONVIF Profile M
Conteúdos técnicos correlatos
- Densidade de Pixels e Requisitos DORI em Sistemas de Videomonitoramento
- Desempenho Visual em CFTV
- VMS: software de gerenciamento de vídeo
- Busca Forense em Sistemas de Videomonitoramento
