Aprenda a estruturar uma matriz funcional de controle de acesso com IDs, fluxos, leitores, APB, eventos, integrações, emergência e critérios rastreáveis de projeto e teste.
Confira!
A matriz funcional de controle de acesso é um documento de engenharia que transforma cada porta, catraca, portão, cancela ou ponto controlado em um conjunto rastreável de requisitos físicos, lógicos e operacionais. Em vez de informar apenas “há controle de acesso neste local”, a matriz define de onde para onde ocorre a passagem, quais sentidos são controlados, quais leitores e sensores são necessários, quais regras se aplicam, quais eventos devem ser gerados, como o ponto se comporta em emergência e quais sistemas precisam ser integrados.
Ela é especialmente útil porque o desenho arquitetônico mostra onde está o ponto, enquanto a matriz explica como ele deve funcionar. A ABNT NBR IEC 60839-11-2 orienta que o planejamento identifique áreas controladas, equipamentos de reconhecimento, classificação dos pontos, conexões entre componentes, níveis de acesso, operação sob falhas, interfaces e requisitos de emergência. Uma matriz funcional bem estruturada reúne essas decisões em uma camada de rastreabilidade que pode ser utilizada no projeto, na contratação, no Design Review, na configuração e no comissionamento.
O que é uma matriz funcional de controle de acesso
A matriz funcional é a tabela mestre que relaciona cada ponto de acesso a seus requisitos. Ela funciona como ponte entre análise de risco, plantas, diagramas, especificações, quantitativos, software e testes.
Um ponto pode ser fisicamente simples — uma porta com uma leitora e uma fechadura — e ainda assim possuir comportamento complexo: autenticação em um sentido, saída livre no outro, anti-passback, horário, contato de porta, porta mantida aberta, liberação por incêndio, correlação com câmera e autonomia offline.
Sem uma matriz, essas regras tendem a ficar dispersas em memoriais, comentários de planta, reuniões e configurações do integrador. Isso reduz rastreabilidade e torna difícil provar se a solução ofertada e instalada realmente atende ao projeto.
Por que a planta não é suficiente
Uma planta indica localização e, em muitos casos, símbolos de leitor, contato, botoeira e trava. Ela não é o melhor meio para registrar dezenas de atributos funcionais por ponto.
Se todas as regras forem colocadas graficamente, a planta fica carregada e difícil de revisar. Se forem retiradas sem criar outro documento, a informação simplesmente desaparece. A matriz resolve essa lacuna ao manter o desenho limpo e a função explícita.
O artigo Como funciona uma porta controlada explica a cadeia física de leitor, ACU, relé, trava, REX e sensor. A matriz funcional usa essa cadeia como unidade de especificação.
Matriz funcional não é a mesma coisa que matriz de acesso de usuários
É comum chamar diferentes documentos de “matriz de acesso”. Eles não devem ser confundidos.
A matriz funcional de pontos descreve o comportamento técnico de portas e barreiras. A matriz de direitos de acesso relaciona perfis de usuários, grupos, áreas e horários. Ambas podem existir no mesmo projeto, mas respondem a perguntas diferentes.
| Documento | Pergunta principal | Exemplo |
| Matriz funcional | como este ponto funciona? | PA-014 tem leitor entrada/saída, APB hard e integração VMS |
| Matriz de direitos | quem pode entrar onde e quando? | manutenção acessa sala técnica em horário autorizado |
| Lista de I/O | quais sinais físicos existem? | DPS, REX, tamper, AC fail |
| Matriz de causa e efeito | o que acontece quando ocorre um evento? | incêndio → liberar portas definidas |
| Quantitativo | quanto precisa ser contratado? | 42 leitores, 21 pontos controlados |
A separação evita transformar uma única planilha em documento impossível de manter.
A unidade básica: o ID do ponto de acesso
Cada ponto precisa de um identificador único e persistente. O mesmo ID deve aparecer na planta, matriz, diagrama, quantitativo, lista de I/O, programação, teste e As Built sempre que possível.
Um padrão pode ser simples, como PA-001, PA-002 e assim por diante, ou incorporar setor/pavimento quando isso realmente facilita gestão. O essencial é evitar que a mesma porta seja chamada de “P12”, “porta TI”, “AC-07” e “door 003” em documentos diferentes sem uma tabela de correspondência.
O ID deve representar o ponto, não o equipamento
O ponto de acesso é mais estável do que o modelo de leitor ou a controladora. Equipamentos podem mudar entre projeto básico e executivo; a função da porta permanece. Por isso, a identificação deve nascer da arquitetura física e funcional.
Campos essenciais da matriz funcional
Uma matriz madura pode crescer conforme a complexidade do sistema. O conjunto mínimo depende do projeto, mas alguns campos são recorrentes.
| Campo | O que registra | Por que importa |
| ID | identificador do ponto | rastreabilidade entre documentos |
| Pavimento/área | localização macro | filtragem e coordenação |
| Local/ponto | descrição física | entendimento operacional |
| Tipo | porta, catraca, portão etc. | define família de requisitos |
| Área de origem | de onde vem o fluxo | lógica de zonas |
| Área de destino | para onde vai | autorização e APB |
| Sentido controlado | entrada, saída ou ambos | define reconhecimento |
| Leitores | quantidade e posição funcional | autenticação e presença |
| REX | modo de solicitação de saída | operação e emergência |
| Sensor de porta | monitoramento da barreira | porta forçada/aberta |
| Travamento | comportamento funcional | segurança e life safety |
| APB | sim/não e modalidade | coerência de presença |
| Eventos/alarmes | condições a anunciar | operação da central |
| Integração VMS | ação de vídeo | correlação operacional |
| Emergência/incêndio | comportamento definido | segurança da vida |
| Observações | exceções controladas | contexto adicional |
Origem, destino e sentido: a base da lógica
Uma porta separa duas áreas. Registrar apenas o nome da porta perde informação importante. A matriz deve dizer qual é a área de origem e qual é a área de destino de cada sentido controlado.
Isso permite compreender transições de segurança. Uma porta entre corredor público e área administrativa tem função diferente de uma porta entre área administrativa e data hall, ainda que ambas utilizem leitores semelhantes.
A informação também sustenta anti-passback, porque presença é uma relação entre credencial e zona.
Como registrar leitores de entrada e saída
A matriz deve mostrar se existe reconhecimento em um sentido ou nos dois. “2 leitores” é menos informativo do que “leitor de entrada + leitor de saída”.
A decisão interfere em:
- autenticação;
- anti-passback;
- presença;
- fluxo;
- cabeamento;
- capacidade de controladoras;
- licenciamento;
- operação offline;
- comissionamento.
Um REX não substitui automaticamente leitor de saída para fins de identificação individual. Se o sistema precisa saber quem saiu, a matriz precisa exigir mecanismo capaz de produzir essa informação.
Como registrar a regra de autenticação
O campo pode indicar o requisito funcional sem amarrar o produto. Exemplos incluem cartão, credencial móvel, PIN, biometria ou MFA.
Em projeto competitivo, é preferível descrever a função e o nível de segurança necessário a fixar uma marca ou modelo. O artigo sobre graus de segurança segundo a IEC 60839 ajuda a relacionar risco e nível de proteção.
APB precisa estar associado ao ponto e à zona
A expressão “o sistema terá anti-passback” é insuficiente. A matriz deve dizer onde a função é aplicada e qual modalidade é esperada.
Campos úteis incluem:
- APB: sim/não;
- modo: soft ou hard;
- escopo: local ou global;
- lógica: por área ou temporizada;
- zona de origem/destino;
- comportamento em falha;
- política de reset;
- exceções autorizadas.
Essa granularidade transforma uma feature de software em requisito testável.
Eventos e alarmes por ponto
A ABNT NBR IEC 60839-11-1 relaciona anúncio, visualização, alerta e registro a diferentes condições do EACS. A matriz funcional pode traduzir a necessidade operacional por ponto.
Eventos típicos incluem:
- acesso autorizado;
- acesso negado;
- porta forçada;
- porta mantida aberta;
- mudança manual de estado;
- leitor desconectado;
- tamper;
- falha de alimentação;
- bateria baixa;
- falha de comunicação;
- violação de APB;
- condição de coação, quando aplicável.
Nem todo evento precisa ter a mesma prioridade ou gerar alarme para operador. A matriz pode separar o que apenas é registrado do que exige tratamento imediato.
Integração com VMS na matriz
Uma coluna “Integração VMS: sim” ainda é pouco específica. O projeto pode registrar a ação esperada: abrir câmera associada, gerar bookmark, criar alarme, apresentar vídeo ao operador ou correlacionar gravação ao evento.
A integração deve ter semântica operacional. Se a porta forçada é crítica, a matriz pode dizer qual câmera contextualiza o ponto e qual evento deve aparecer na central. Isso cria uma ponte direta para o futuro artigo de integração entre controle de acesso e VMS.
Emergência e incêndio: comportamento por ponto
O comportamento durante emergência precisa estar documentado por ponto ou grupo claramente definido. A ABNT NBR IEC 60839-11-2 orienta que o EACS não impeça saída livre concedida por sistemas de emergência e exige que requisitos de incêndio e saída segura sejam considerados no projeto.
A matriz pode classificar cada ponto como:
- sem interface direta com incêndio;
- liberação conforme causa e efeito;
- manutenção de condição com saída mecânica independente;
- integração específica definida pelo projeto de incêndio;
- ponto pertencente a eclusa com lógica especial de emergência.
Não se deve assumir que “alarme de incêndio = todas as portas destravadas”. O comportamento depende da estratégia de segurança da edificação e precisa ser coordenado entre disciplinas.
Matriz funcional x matriz de causa e efeito
A matriz funcional diz que a porta possui determinada relação com incêndio, VMS ou intrusão. A matriz de causa e efeito descreve a sequência completa do evento.
Separar os documentos é especialmente útil quando uma mesma causa afeta muitas portas e outros subsistemas.
Matriz funcional x lista de I/O
A matriz descreve função; a lista de I/O descreve sinais físicos. Um único ponto pode demandar diversas entradas e saídas: contato de porta, REX, tamper, relé de trava, retorno de fonte, comando de barreira e outros.
O artigo Entradas supervisionadas em controle de acesso aprofunda NO, NC, EOL e tamper. Na matriz, basta indicar o requisito funcional; o detalhe elétrico pode permanecer na lista de I/O e no diagrama típico.
Como transformar a matriz em quantitativo
A matriz é uma fonte de dados para quantitativos, mas não deve ser confundida com BOM. O número de pontos, leitores, sensores e funções permite derivar capacidade mínima do sistema.
Para controladoras, módulos I/O, fontes e gabinetes, uma contratação orientada por desempenho pode evitar fixar uma quantidade física baseada em um único fabricante. O projeto informa quantos pontos e sinais precisam ser atendidos, reserva técnica, segregação e critérios de disponibilidade; a proponente apresenta a composição de hardware que cumpre esses requisitos.
Essa abordagem reduz direcionamento e permite comparar arquiteturas centralizadas e distribuídas.
Exemplo de matriz funcional simplificada
| ID | Local | Origem → destino | Leitura | APB | Eventos | VMS | Incêndio |
| PA-001 | entrada administrativa | externo → recepção | entrada | não | negado, porta forçada | câmera contextual | conforme estratégia |
| PA-012 | área técnica | circulação → sala técnica | entrada e saída | hard/global | negado, APB, porta forçada | alarme + vídeo | causa e efeito |
| PA-021 | área crítica | técnica → crítica | MFA entrada/saída | hard/global | todos críticos | correlação obrigatória | lógica específica |
O exemplo não é um template universal. A matriz real deve refletir risco, fluxo, arquitetura e disciplina da organização.
Como construir a matriz a partir do levantamento
Em brownfield, a primeira versão deve nascer do levantamento físico e documental. Cada porta é identificada, fotografada e confrontada com fluxo, ferragens, infraestrutura, dispositivos existentes e documentação disponível.
Depois, o processo pode seguir:
- identificar o ponto e suas áreas de origem/destino;
- classificar criticidade e requisito de segurança;
- definir sentido controlado;
- definir método de reconhecimento;
- definir sensor, REX e travamento;
- definir regras funcionais;
- definir eventos e integrações;
- definir emergência;
- vincular ao desenho e quantitativo;
- criar critérios de teste.
A matriz evolui junto com o projeto, não deve ser produzida apenas no final.
Como usar a matriz em projeto básico e executivo
Quando cada ponto precisa ser transformado em requisitos verificáveis, a matriz funcional deve nascer junto com o projeto e permanecer vinculada às plantas, especificações e quantitativos.
No projeto básico, ela caracteriza o desempenho esperado e sustenta contratação. No executivo, ganha detalhamento de dispositivos, endereçamento, I/O, controladoras, interfaces e parâmetros específicos da solução selecionada.
A diferença de maturidade deve ser controlada. O executivo pode detalhar a arquitetura, mas não pode reduzir silenciosamente requisitos definidos no básico. Qualquer mudança precisa ser tratada como decisão de engenharia e refletida nos documentos correspondentes.
Como usar a matriz para analisar propostas técnicas
Quando o edital ou processo de procurement exige aderência funcional, a matriz ajuda a transformar promessas comerciais em itens verificáveis. A proponente pode ser obrigada a demonstrar como sua solução atende cada requisito.
Isso é particularmente útil para:
- capacidade de leitores e portas;
- APB global;
- operação offline;
- eventos e alarmes;
- integração VMS;
- supervisão;
- emergência;
- redundância;
- escalabilidade.
A análise deixa de comparar apenas datasheets e passa a verificar arquitetura contra requisitos.
Design Review da matriz funcional
Uma matriz bem construída permite revisar se projeto executivo, proposta e arquitetura preservam as funções previstas em cada ponto.
O Design Review precisa verificar consistência entre matriz e demais documentos. Um ponto com leitor de saída na matriz precisa aparecer na planta, no quantitativo, na capacidade de controladoras e no diagrama. Uma função APB global precisa ser suportada pela arquitetura de comunicação. Uma integração de incêndio precisa aparecer na causa e efeito.
Checagens importantes incluem:
- IDs únicos e sem duplicidade;
- origem/destino coerentes;
- sentidos compatíveis com fluxo;
- dispositivos compatíveis com função;
- grau de segurança refletido nos requisitos;
- interfaces representadas;
- quantitativos derivados corretamente;
- nenhuma regra crítica apenas em observação textual;
- compatibilidade entre básico e executivo.
Controle de versão e mudanças
A matriz funcional é documento controlado. Alterar uma porta pode afetar planta, I/O, quantitativo, software, VMS, incêndio e plano de testes.
Por isso, mudanças precisam ter revisão, motivo e rastreabilidade. Em projetos maiores, a matriz pode se tornar uma fonte central para gestão de requisitos. O artigo sobre Gestão de Interfaces em Projetos de Engenharia é uma referência transversal útil para tratar dependências entre disciplinas.
Como transformar a matriz em plano de comissionamento
Cada linha pode originar um conjunto de testes. O comissionamento deixa de trabalhar com um checklist genérico e passa a verificar o comportamento específico de cada ponto.
Para PA-012, por exemplo, o procedimento pode testar autenticação válida, acesso negado, entrada, saída, APB, porta forçada, porta mantida aberta, evento VMS, falha de comunicação e condição de incêndio aplicável.
A rastreabilidade ideal é:
requisito → linha da matriz → documento executivo → teste → evidência → aceite.
A ABNT NBR IEC 60839-11-2 reforça esse princípio ao definir o comissionamento como verificação de que o sistema instalado atende ao projeto e ao exigir coerência entre instalação real e documentação As Built.
Matriz no As Built e na operação
Após implantação, a matriz deve refletir a condição instalada. Ela se torna referência para manutenção, expansão, investigação e mudanças de configuração.
Uma matriz desatualizada perde rapidamente valor. Se uma porta foi convertida de saída livre para leitura bidirecional, a alteração precisa ser refletida no As Built e nas regras do sistema.
Erros recorrentes
Os problemas mais comuns são:
- matriz criada apenas como lista de portas;
- IDs diferentes em cada documento;
- ausência de origem e destino;
- APB definido genericamente para todo o sistema;
- VMS marcado como “sim” sem ação funcional;
- incêndio tratado como “libera tudo”;
- hardware específico misturado a requisito funcional sem necessidade;
- quantitativo que não deriva da matriz;
- alterações de campo não incorporadas;
- testes sem vínculo com cada linha.
Uma matriz útil precisa ser suficientemente objetiva para ser auditável e suficientemente funcional para orientar arquitetura.
Considerações finais
A matriz funcional é um dos documentos mais eficientes para transformar controle de acesso em engenharia verificável. Ela conecta risco, fluxo, porta, autenticação, APB, eventos, VMS, incêndio, infraestrutura, quantitativos e testes usando uma identificação única por ponto.
Seu maior valor não está na planilha em si, mas na rastreabilidade que cria. Quando a mesma linha orienta projeto, proposta técnica, executivo, configuração e comissionamento, decisões deixam de ficar dispersas e o aceite passa a ter critério objetivo. Em sistemas complexos, essa matriz funciona como uma verdadeira espinha dorsal da disciplina de controle de acesso.
Durante a implantação, a Engenharia do Proprietário pode usar a matriz como baseline para acompanhar mudanças, interfaces, evidências e aceite técnico.
Referências técnicas
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 60839-11-1:2019 — Sistemas de segurança eletrônica e alarme — Parte 11-1: Sistemas eletrônicos de controle de acesso — Requisitos do sistema e dos componentes. Rio de Janeiro: ABNT, 2019. Disponível em: https://webstore.iec.ch/en/publication/11873
[2] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 60839-11-2:2019 — Sistemas de segurança eletrônica e alarme — Parte 11-2: Sistemas eletrônicos de controle de acesso — Diretrizes de aplicação. Rio de Janeiro: ABNT, 2019. Disponível em: https://webstore.iec.ch/en/publication/26292
Perguntas frequentes
É o documento que relaciona cada ponto de acesso a seus requisitos físicos, lógicos e operacionais, como fluxo, leitores, APB, eventos, integrações e comportamento em emergência.
Não. A matriz funcional descreve como cada porta ou barreira funciona; a matriz de direitos relaciona perfis de usuários a áreas, horários e permissões.
Normalmente ID, localização, tipo de ponto, origem, destino, sentido, leitores, REX, sensor, travamento, APB, eventos, VMS, emergência/incêndio e observações.
Para manter rastreabilidade entre planta, matriz, diagrama, quantitativo, I/O, configuração, teste e As Built.
No projeto básico, não necessariamente. Ela deve priorizar função e desempenho. O executivo pode detalhar equipamentos compatíveis com os requisitos definidos.
Cada linha pode gerar cenários de teste específicos, vinculando requisito, ponto físico, evento esperado e evidência de aceite.
Sim, quando existe interface. O comportamento deve ser definido por ponto ou grupo, em coordenação com a matriz de causa e efeito e a estratégia de segurança contra incêndio.
Materiais técnicos complementares
Soluções relacionadas
Serviços relacionados
- Projeto de Controle de Acesso
- Design Review em Projetos de Engenharia
- Engenharia do Proprietário (Owner’s Engineering)
- Comissionamento de Engenharia
Conteúdos principais sobre o tema
- Sistema de Controle de Acesso: tipos, tecnologias, normas e projeto
- Anti-passback em controle de acesso
- Entradas supervisionadas em controle de acesso
