Guia técnico sobre eclusas e mantraps em controle de acesso: intertravamento, singularização, sensores, lógica de estados, emergência, falhas e comissionamento.
Confira!
Uma eclusa de segurança em controle de acesso utiliza duas barreiras sequenciais e uma área intermediária para controlar a progressão do usuário. Em aplicações chamadas de mantrap, a lógica pode acrescentar verificação de presença, singularização e autenticação complementar. O elemento central não é a quantidade de portas, mas a sequência funcional que define quando cada uma pode ser liberada.
A engenharia precisa conhecer estado das portas, presença, autenticação, direção, tempos, exceções e sinais externos. Uma solução baseada apenas em temporização pode perder a referência do estado físico. Por isso, sensores, controladora, dispositivos de travamento, interfaces de emergência e registro de eventos devem fazer parte de uma única especificação.
Em áreas críticas, a eclusa pode elevar o nível de controle entre zonas, mas também aumenta a complexidade operacional. O projeto deve equilibrar proteção, capacidade de fluxo, acessibilidade, tratamento de exceções e segurança da vida.
O que é intertravamento
Intertravamento é a regra que condiciona a liberação de uma barreira ao estado de outra. Na configuração básica, a segunda porta só pode ser liberada depois que a primeira estiver fechada e as condições adicionais tiverem sido atendidas.
A ABNT NBR IEC 60839 aplicada ao controle de acesso fornece a base funcional para estados, interfaces, registro e supervisão do sistema eletrônico de controle de acesso.
| Elemento | Função | Informação necessária |
| Porta 1 | Entrada no volume intermediário | Aberta, fechada, condição de travamento |
| Porta 2 | Saída do volume intermediário | Aberta, fechada, condição de travamento |
| Leitores | Identificação/autenticação | Credencial e resultado da decisão |
| Sensores | Estado e presença | Ocupação e condições anormais |
| Controladora | Sequência e registro | I/O, regras, temporizações e eventos |
| Operação | Tratamento de exceções | Comandos autorizados e auditoria |
Eclusa e mantrap
Os termos aparecem como equivalentes em muitos projetos, mas a especificação deve dizer exatamente qual função é requerida. Uma eclusa pode apenas impedir abertura simultânea. Uma aplicação de maior restrição pode verificar uma pessoa por ciclo, exigir novo fator de autenticação e condicionar a progressão a mais de um estado.
O nome comercial da solução não define automaticamente sensores, lógica ou nível de proteção. Esses elementos precisam estar nos documentos do projeto e no plano de testes.
Intertravamento e anti-passback tratam problemas diferentes
A distinção é relevante para especificação e testes. Uma eclusa pode estar fisicamente intertravada e ainda permitir incoerência no estado lógico de presença se a credencial for utilizada fora da sequência prevista. Da mesma forma, um anti-passback bem configurado não garante que duas portas físicas não sejam abertas simultaneamente.
Quando os dois mecanismos são combinados, o projeto precisa definir qual informação prevalece em situações divergentes. Uma saída por rota de emergência pode alterar o estado físico sem produzir leitura de credencial; uma intervenção de operador pode liberar a porta sem alterar automaticamente a presença lógica. Essas condições precisam ter procedimento de reconciliação e registro.
O intertravamento se apoia no estado físico das barreiras. O anti-passback trabalha com o estado lógico da credencial e com a coerência entre entrada e saída.
Uma arquitetura pode utilizar os dois mecanismos. A primeira porta pode exigir estado lógico válido; a segunda pode depender do fechamento confirmado da primeira e de uma validação adicional.
A sequência deve ser documentada
O fluxo normal pode ser descrito como: sistema disponível; autenticação inicial; liberação da primeira porta; entrada; confirmação de fechamento; validação interna; liberação da segunda porta; saída; retorno ao estado inicial.
Também precisam existir respostas para estados fora do fluxo normal: porta não fechou, presença permaneceu por tempo excessivo, validação foi negada, usuário desistiu, sensor ficou indisponível, energia foi interrompida ou operador realizou comando manual.
| Estado | Condição de entrada | Próxima ação possível |
| Disponível | Ambas as portas em condição definida | Aguardar autorização |
| Entrada liberada | Credencial aceita | Confirmar entrada |
| Área ocupada | Presença confirmada | Fechar primeira porta |
| Validação | Primeira porta confirmada | Aplicar regras adicionais |
| Saída liberada | Regras atendidas | Confirmar saída |
| Exceção | Condição divergente | Procedimento controlado |
Singularização
Singularização significa verificar que o ciclo está compatível com a passagem prevista de uma pessoa. Esse objetivo pode exigir sensores volumétricos, barreiras ópticas ou outras tecnologias adequadas ao ambiente.
Bagagens, mochilas, carrinhos, equipamentos e características físicas dos usuários podem influenciar a detecção. Por isso, o critério precisa ser validado no ambiente real e com a população esperada.
O projeto também deve definir o tratamento de uma detecção divergente. O sistema pode interromper a progressão, registrar evento e solicitar atendimento, mas a resposta deve estar prevista e ser compreensível para o operador.
Autenticação adicional
Em áreas de maior criticidade, a segunda etapa pode exigir biometria, PIN ou outra credencial. O objetivo é reduzir a dependência de um único fator e confirmar que a pessoa que entrou no volume intermediário é compatível com a autorização.
Essa etapa aumenta o tempo de ciclo e pode criar exceções. O dimensionamento deve considerar taxa de chegada, tempo de autenticação e capacidade de atendimento quando o fluxo não se conclui normalmente.
Capacidade de fluxo e dimensionamento operacional
Uma eclusa introduz uma sequência obrigatória entre autenticação, movimento das portas, confirmação de presença e liberação da etapa seguinte. Isso significa que sua capacidade não pode ser estimada apenas pelo tempo de abertura de uma porta. O ciclo completo precisa considerar aproximação, leitura da credencial, decisão, abertura, entrada, fechamento confirmado, eventual autenticação adicional, liberação da segunda porta e saída.
Em períodos de pico, pequenas variações se acumulam. Se uma validação biométrica acrescenta alguns segundos ou se uma porta demora a confirmar o fechamento, a fila pode crescer rapidamente. O projeto deve avaliar taxa de chegada, tempo médio de ciclo, percentual de exceções e espaço disponível para espera. Quando uma única eclusa não atende ao fluxo previsto, a solução pode exigir canais paralelos, separação por perfil ou outro desenho de acesso.
A capacidade também é afetada por usuários com bagagem, pessoas com mobilidade reduzida, visitantes que precisam de orientação e procedimentos de inspeção. Esses casos não devem ser tratados como eventos raros se fazem parte da população real do empreendimento.
| Variável | Efeito sobre o ciclo | Decisão de projeto |
|---|---|---|
| Tempo de autenticação | Pode aumentar a ocupação da eclusa | Definir tecnologia e regra compatíveis com o fluxo |
| Tempo mecânico das portas | Limita a taxa de processamento | Verificar desempenho no conjunto instalado |
| Exceções | Interrompem a sequência normal | Prever atendimento sem bloquear todo o acesso |
| Bagagem e equipamentos | Podem afetar sensores de singularização | Validar cenários representativos |
| Pico de chegada | Forma filas | Dimensionar número de canais e área de espera |
Acessibilidade e passagem assistida
A arquitetura precisa prever usuários que não conseguem utilizar o ciclo padrão com a mesma velocidade ou geometria. Largura útil, esforço de abertura, comandos, tempo de permanência, circulação de cadeira de rodas e passagem com acompanhante devem ser avaliados conforme a aplicação e os requisitos de acessibilidade do empreendimento.
Uma rota acessível paralela não deve se transformar em bypass sem controle. Quando a passagem assistida utiliza outra porta, essa porta precisa ter regras, registros e comportamento de emergência coerentes com o restante do sistema. O mesmo vale para transporte autorizado de volumes que não passam pela eclusa principal.
O procedimento operacional deve indicar quem autoriza a passagem assistida, como o evento é registrado e como o sistema mantém a coerência de presença. Isso evita que a exceção operacional enfraqueça a política de segurança.
A eclusa deve ser dimensionada a partir do risco, do fluxo e das exceções reais do empreendimento.
Portas e dispositivos de travamento
A escolha do atuador precisa ser coerente com a porta e com a filosofia de operação. O artigo sobre fechaduras para controle de acesso detalha as tecnologias mais comuns.
Em uma eclusa, o sistema não deve confundir comando de travamento com confirmação de estado. O sensor da porta e, quando necessário, o monitoramento do dispositivo de travamento fornecem evidências distintas.
A lógica de fail-safe x fail-secure deve resultar da análise do acesso e das condições de saída, sem aplicação automática de uma regra única.
Emergência e causa e efeito
O comportamento em emergência precisa ser definido por evento e direção de fuga. A resposta de uma porta que participa de rota de saída pode ser diferente daquela de uma barreira interna que não interfere na evacuação. Por isso, a matriz deve relacionar origem do comando, portas afetadas, prioridade, estado esperado, forma de reset e evidência de registro.
Também é necessário evitar dependência exclusiva do software central quando uma função precisa ocorrer mesmo com indisponibilidade de rede ou servidor. Interfaces locais, alimentação de reserva e dispositivos de liberação devem ser avaliados dentro da arquitetura, e o SAT deve simular as condições previstas em vez de limitar-se à operação normal.
A função de intertravamento precisa ser compatibilizada com as condições de emergência. A integração entre controle de acesso e incêndio mostra por que a liberação deve ser definida em matriz de causa e efeito.
Eventos como sinal do sistema de incêndio, acionamento local, falta de energia e comando autorizado devem ter respostas documentadas. A prioridade entre esses comandos precisa estar clara.
Tratamento de exceções
O usuário pode desistir, ter uma validação negada ou precisar de atendimento. O projeto deve definir como retornar ao estado inicial sem criar sequência ambígua.
Interfone e vídeo podem apoiar o operador. A integração entre controle de acesso e VMS permite associar eventos a câmeras e melhorar o contexto operacional.
Comandos manuais precisam ser limitados por perfil e registrados. A existência de override não deve transformar qualquer exceção em liberação informal.
Falhas e modo degradado
A indisponibilidade de sensor, rede, servidor ou alimentação precisa resultar em estado conhecido. A resposta pode variar conforme o risco e a arquitetura, mas deve estar documentada.
A controladora de acesso precisa possuir entradas, saídas, memória e capacidade lógica compatíveis com a sequência requerida.
Após uma reinicialização, o sistema deve reconstruir o estado usando informações físicas. Assumir uma condição apenas porque o software reiniciou pode levar a uma transição incorreta.
Operação assistida, interfone e vídeo
Mesmo em uma arquitetura automatizada, determinadas condições exigem intervenção humana. Uma validação negada, um objeto detectado, uma porta que não confirmou fechamento ou um usuário que precisa de orientação são situações previsíveis. O projeto deve definir quais informações o operador recebe e quais comandos pode executar.
Interfone e vídeo fornecem contexto para tratar essas ocorrências. A câmera deve permitir observar a área relevante sem substituir os sensores funcionais. O operador precisa identificar a condição, comunicar-se com o usuário e, quando autorizado, executar um comando que fique registrado com data, hora e identidade do operador.
A operação não deve depender de alternância manual entre várias interfaces sem correlação. Quando o sistema de acesso e o VMS trocam eventos, um alarme pode apresentar automaticamente a câmera associada, reduzindo tempo de resposta e facilitando investigação posterior.
Aplicações em áreas críticas e proteção por camadas
Data centers, laboratórios, centros de operação, salas de infraestrutura, áreas de pesquisa e ambientes com ativos críticos podem usar eclusas como transição entre zonas de segurança. Nesses casos, a solução deve fazer parte de uma arquitetura por camadas, com requisitos crescentes conforme a criticidade.
Uma credencial aceita no perímetro geral não precisa ser suficiente para concluir o ciclo da eclusa. O projeto pode exigir segundo fator, presença de acompanhante, janela de horário mais restrita ou autorização específica. Essas regras precisam ser administráveis e auditáveis para não depender de exceções informais.
Também é necessário avaliar continuidade. Uma indisponibilidade da eclusa pode bloquear a única rota operacional para uma área essencial. O projeto deve definir modo degradado, contingência de manutenção e procedimento de acesso autorizado sem eliminar a rastreabilidade.
Eclusa veicular e dupla barreira
O conceito de intertravamento pode ser aplicado a veículos por meio de duas cancelas, dois portões ou combinação de barreiras. O espaço intermediário precisa acomodar o maior veículo previsto e possuir sensores capazes de confirmar sua posição antes de qualquer movimento da segunda barreira.
A lógica pode combinar identificação por placa, tag, credencial do condutor e validação da portaria. Em aplicações logísticas, podem existir ainda regras de agendamento, carga, doca e transportadora. A segunda barreira só deve liberar quando o conjunto de condições previsto tiver sido atendido.
O risco mecânico é diferente do acesso de pedestres. Comprimento do veículo, reboques, distância entre eixos e manobras precisam ser considerados no posicionamento de sensores e barreiras. O projeto de controle de acesso veicular deve servir de base para esse caso.
Intertravamento, autenticação, sensores, emergência e operação precisam ser especificados como uma arquitetura única.
Como especificar uma eclusa
A especificação deve descrever função, sequência, sensores, autenticação, exceções, falhas e critérios de aceite. A contratação de “uma eclusa completa” sem esses elementos transfere decisões de projeto para a etapa de instalação.
Requisitos úteis incluem:
- número e tipo de barreiras;
- direção de fluxo;
- autenticação em cada etapa;
- necessidade de singularização;
- sensores de porta e presença;
- lógica de intertravamento;
- tempos máximos;
- alarmes e registros;
- integração com VMS e interfone;
- comportamento em falta de energia e comunicação;
- interfaces de emergência;
- modo de manutenção e comandos autorizados;
- requisitos de acessibilidade;
- FAT, SAT e documentação.
| Requisito | Critério de projeto | Evidência de aceite |
| Intertravamento | Segunda porta depende dos estados definidos | Teste de sequência |
| Presença | Área intermediária possui detecção compatível | Teste em campo |
| Exceções | Estados anormais têm procedimento | Casos de teste |
| Emergência | Causa e efeito documentada | Simulação funcional |
| Auditoria | Comandos e eventos possuem registro | Verificação de logs |
| Recuperação | Retorno após falha reconstrói estado | Ensaio de recuperação |
Contratação, submittals e documentação
A contratação deve separar claramente fornecimento de barreiras e fechaduras, controladoras, sensores, software, infraestrutura, integração, programação, testes, treinamento e documentação. A expressão “eclusa completa” não é suficiente para definir responsabilidades ou permitir comparação técnica entre propostas.
Antes da implantação, o fornecedor deve apresentar documentos de submissão compatíveis com o projeto: arquitetura, sequência funcional, lista de I/O, interfaces, alimentação, desenho das portas, matriz de causa e efeito, descrição dos modos de operação e plano de testes. Esses documentos permitem validar o comportamento antes de ele ser materializado em campo.
Na entrega, a documentação deve refletir o estado implantado. As Built, backups, parâmetros, matriz funcional, lista de dispositivos, procedimentos de contingência, registros de FAT/SAT e pendências encerradas compõem a evidência necessária para manutenção e futuras alterações.
| Entregável | Finalidade |
|---|---|
| Sequência funcional | Definir estados e transições esperadas |
| Lista de I/O | Rastrear sensores, comandos e retornos |
| Matriz de causa e efeito | Definir emergência e prioridades |
| Plano de testes | Transformar requisitos em verificações |
| As Built | Registrar a solução efetivamente instalada |
| Backup e parâmetros | Apoiar recuperação e manutenção |
O aceite deve comprovar a sequência funcional, as falhas previstas e a recuperação do sistema.
FAT, SAT e comissionamento
O plano de testes deve derivar diretamente da sequência funcional e da matriz de causa e efeito. Cada transição relevante precisa ter condição inicial, ação aplicada, resultado esperado e evidência. Isso inclui não apenas autenticação válida, mas também tentativas de abertura simultânea, porta que não fecha, presença além do tempo permitido, falha de sensor, perda de comunicação e recuperação após reinicialização.
No FAT, quando aplicável, a equipe pode validar controladora, I/O, regras, alarmes e integrações antes da mobilização definitiva. No SAT, a verificação precisa ocorrer com as portas, fechaduras, sensores, alimentação e rede instalados, porque geometria, alinhamento e tempos reais influenciam o resultado.
O aceite deve registrar evidências, pendências e retestes. Uma simples demonstração de que a porta abre com uma credencial não comprova a função de uma eclusa. O objetivo é demonstrar que a sequência se mantém coerente diante de estados normais, exceções e falhas.
O FAT deve verificar a sequência funcional antes da implantação quando a arquitetura permitir. O SAT comprova o comportamento no ambiente real, com portas, sensores, rede, alimentação e integrações definitivas.
O comissionamento conforme a IEC 60839 deve confrontar requisito e resultado. Fluxo normal, exceções, falhas e recuperação precisam estar no plano de testes.
Operação e manutenção
A operação precisa distinguir eventos que exigem resposta imediata daqueles que representam condição de manutenção. Porta aberta por tempo excessivo, sensor incoerente, falha de travamento, override e presença não compatível com o ciclo devem possuir mensagens compreensíveis e procedimento associado.
A manutenção preventiva deve verificar alinhamento mecânico, fechaduras, sensores, dispositivos de emergência, fontes, baterias, interfaces e comunicação. O histórico de eventos também é uma fonte de diagnóstico: recorrência de tempo excedido ou de falha de fechamento pode indicar problema físico, parametrização inadequada ou processo incompatível com a realidade operacional.
Alterações posteriores precisam ser controladas. Troca de sensor, atualização de firmware, substituição de controladora ou mudança em regras de autenticação podem modificar a sequência. Quando isso ocorre, os testes afetados devem ser repetidos e a documentação As Built atualizada.
A equipe deve compreender alarmes, estados e procedimentos de atendimento. Sensores, fechaduras, portas, alimentação e lógica precisam ser verificados periodicamente.
Alterações de firmware, software, dispositivos ou política de acesso podem modificar o comportamento da sequência. Mudanças relevantes devem passar por controle e revalidação.
Arquitetura de sensores, I/O e supervisão
A lógica de uma eclusa só é confiável quando o sistema distingue comando, estado físico e condição de falha. Por isso, a engenharia deve mapear cada entrada e saída antes da programação. Contato de porta, retorno da fechadura, sensor de presença, botão de emergência, interfone, singularização e comando de liberação representam evidências diferentes.
O contato magnético informa se a folha está aberta ou fechada, mas não comprova sozinho que o mecanismo de travamento está efetivamente engatado. Da mesma forma, o comando enviado ao relé não prova que a porta respondeu. Quando a criticidade exigir, o projeto deve prever retornos independentes e entradas supervisionadas capazes de identificar falha ou violação do circuito.
A lista de I/O deve nascer da sequência funcional. Cada transição precisa registrar quais sinais habilitam a mudança de estado e quais bloqueiam o avanço. Isso evita programações baseadas apenas em temporização, nas quais o sistema presume que uma ação aconteceu porque um tempo transcorreu.
| Sinal | O que comprova | Uso na lógica | Falha a tratar |
|---|---|---|---|
| Contato da porta | Posição física | Intertravamento | Aberta além do tempo |
| Retorno da fechadura | Condição do travamento | Confirmar segurança | Comando sem retorno |
| Sensor de presença | Ocupação | Controlar sequência | Presença indefinida |
| Autenticador | Resultado da identidade | Autorizar progressão | Indisponibilidade |
| Emergência | Condição prioritária | Aplicar causa e efeito | Perda do sinal |
| Comando do operador | Intervenção autorizada | Tratar exceção | Uso sem auditoria |
Essa matriz também ajuda o comissionamento: o teste deixa de verificar apenas o resultado final e passa a confirmar se cada transição ocorreu porque a condição correta foi percebida pelo sistema.
Precedência de comandos e conflitos de estado
Uma eclusa recebe comandos de origens diferentes: autorização normal, intervenção do operador, manutenção, emergência, falha de energia e integrações externas. O projeto precisa definir qual comando prevalece quando dois eventos ocorrem simultaneamente ou em sequência próxima.
Sem regra de precedência, a programação pode produzir estados contraditórios. Um operador pode tentar liberar uma porta ao mesmo tempo em que uma condição prioritária exige outro comportamento; uma rotina de manutenção pode manter um sensor inibido enquanto a lógica normal continua ativa; uma reinicialização pode ocorrer com uma pessoa dentro do volume intermediário.
A matriz de causa e efeito deve registrar ação esperada e prioridade. Comandos relacionados à segurança da vida precisam permanecer independentes de uma rotina administrativa. Já intervenções manuais devem ser restritas por perfil, exigir justificativa quando aplicável e gerar registro auditável.
Também é necessário definir a recuperação. Depois que uma condição prioritária deixa de existir, o sistema não deve simplesmente retornar ao estado anterior sem verificar a realidade física. A lógica precisa reconstruir o estado a partir dos sensores e, quando necessário, exigir intervenção do operador antes de voltar ao modo normal.
Energia, autonomia e continuidade de operação
Intertravamento envolve dispositivos eletromecânicos, sensores, controladoras, leitores e comunicação. Uma falha de alimentação pode afetar cada componente de forma diferente. Por isso, a filosofia de continuidade precisa ser definida por função e não apenas por uma autonomia genérica de bateria.
O dimensionamento deve considerar consumo em repouso, correntes de acionamento, simultaneidade, carregadores, baterias, perdas em cabos e comportamento dos dispositivos quando a tensão cai. Em uma arquitetura distribuída, pode existir alimentação local para portas e alimentação separada para controladoras e rede; a indisponibilidade de um elo não deve gerar estado imprevisível.
O projeto precisa responder o que ocorre na perda da rede elétrica, no esgotamento da bateria, na falha da fonte local e na perda da infraestrutura de comunicação. A resposta pode variar conforme risco e função da porta, mas deve ser explícita e testável.
Em áreas críticas, continuidade também envolve manutenção. Se a troca de uma fonte ou controladora exige retirar toda a eclusa de operação, deve existir procedimento de contingência que preserve controle e rastreabilidade. O modo degradado precisa ser planejado antes da falha.
Arquitetura de rede, cibersegurança e administração
Quando controladoras, leitores inteligentes, VMS, interfone ou software de supervisão utilizam rede IP, a eclusa passa a depender também da arquitetura de cibersegurança. Segmentação de rede, autenticação administrativa, atualização de firmware, sincronismo de tempo e proteção das interfaces de integração influenciam diretamente disponibilidade e confiabilidade dos eventos.
As funções críticas de intertravamento devem permanecer no nível mais local possível quando a arquitetura permitir. Isso reduz dependência do servidor central e evita que uma perda de comunicação transforme uma função física imediata em operação indeterminada. O software central continua relevante para administração, auditoria e supervisão, mas a sequência básica deve manter comportamento conhecido em contingência.
Credenciais administrativas precisam ser individualizadas e comandos remotos devem produzir trilha de auditoria. Alterações de regras, tempos, perfis de operador ou firmware são mudanças funcionais: qualquer uma delas pode modificar a sequência anteriormente aceita e deve ser submetida a controle de mudança e reteste proporcional.
Integrações com VMS, interfone e outros sistemas devem utilizar interfaces documentadas. Dependências ocultas, acesso direto a banco de dados ou contas compartilhadas aumentam o risco de manutenção e dificultam comprovar o comportamento depois de uma atualização.
Rastreabilidade entre requisito, lógica e teste
A forma mais robusta de controlar a complexidade é manter rastreabilidade entre o requisito de segurança, a lógica implementada e o caso de teste correspondente. Se o requisito afirma que a segunda porta não pode ser liberada enquanto a primeira estiver aberta, deve existir uma regra identificável na documentação e um ensaio que force exatamente essa condição.
O mesmo raciocínio vale para singularização, timeout, perda de sensor, autenticação adicional, emergência e override. Cada requisito funcional deve possuir uma evidência objetiva de aceite. Essa disciplina reduz discussões subjetivas no final da obra e facilita futuras alterações.
| Requisito | Implementação esperada | Teste | Evidência |
|---|---|---|---|
| Impedir abertura simultânea | Intertravamento local | Comandar porta 2 com porta 1 aberta | Bloqueio + log |
| Detectar ocupação excessiva | Sensor + temporização | Manter presença além do limite | Alarme + registro |
| Tratar perda de sensor | Modo degradado definido | Simular circuito indisponível | Estado conhecido |
| Priorizar emergência | Matriz de causa e efeito | Acionar evento prioritário | Estado esperado das portas |
| Auditar override | Perfil + logging | Executar comando manual | Usuário, horário e motivo |
Essa rastreabilidade deve permanecer no As Built. O documento final precisa representar a lógica realmente implantada, e não apenas a intenção inicial do projeto.
Considerações finais
Eclusa e mantrap devem ser projetados como sistemas de estados e não como simples conjunto de duas portas. A qualidade depende da relação entre autenticação, sensores, intertravamento, exceções, emergência, operação e evidências de teste.
Quando a sequência é documentada desde o projeto, a solução pode ser comparada, implementada e aceita por desempenho, com menor dependência de configuração implícita do fornecedor.
Referências técnicas
[1] IEC. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. Disponível em: https://webstore.iec.ch/en/publication/3662
[2] IEC. IEC 60839-11-2:2014 — Alarm and electronic security systems — Part 11-2: Electronic access control systems — Application guidelines. Disponível em: https://webstore.iec.ch/en/publication/3663
[3] A3A ENGENHARIA. Controle de acesso e incêndio: liberação, emergência e matriz de causa e efeito. Disponível em: https://a3aengenharia.com.br/conteudo/artigos-tecnicos/controle-de-acesso-incendio-liberacao-emergencia-causa-efeito/
Perguntas frequentes
É um acesso com duas ou mais barreiras sequenciais cuja lógica condiciona a progressão aos estados físicos, à autenticação e às regras definidas no projeto.
Os termos são usados de forma próxima no mercado, mas o projeto deve especificar as funções. Aplicações de mantrap podem acrescentar singularização e autenticação adicional.
Não. Intertravamento usa o estado físico das barreiras; anti-passback usa o estado lógico da credencial. Os recursos podem ser combinados.
Depende da função. Para singularização ou confirmação de ocupação, sensores de presença são relevantes. O tipo deve ser escolhido e validado conforme ambiente e usuários.
O plano de testes deve verificar sequência normal, estados anormais, falhas, comandos autorizados, emergência, recuperação e registro de eventos contra os requisitos aprovados.
Materiais técnicos complementares
Serviços relacionados
- Projeto de Controle de Acesso: arquitetura, dispositivos, integração e especificação
- Projeto de Segurança Eletrônica Integrada: CFTV, acesso, intrusão e integração
