Considerações para uso em conformidade à NR-12

Controladores Lógicos Programáveis são soluções robustas, flexíveis e modulares, utilizadas para otimizar sistemas de automação por meio de abstrações lógicas, eliminando diversos comutadores físicos, reduzindo o espaço ocupado em painéis de comando e aprimorando elementos de informação e diagnóstico, por meio de indicadores visuais, sonoros e/ou textuais, quando associados a IHMs (interfaces homem-máquina) e sistemas supervisórios. Contudo, para aplicações relativas à segurança, a fim de adequar máquinas e/ou equipamentos com sistemas de controle de média e alta complexidade aos requisitos da NR-12, novos desafios podem ser adicionados, em razão da necessidade de consideração sobre falhas sistemática¹, critérios de confiabilidade que CLPs convencionais não atendem e de uma abordagem lógica de raciocínio para a programação, sob uma perspectiva diferente daquela normalmente desenvolvida.

A Norma Regulamentadora nº 12 – Segurança no trabalho em máquinas e equipamentos (NR-12) determina, como uma medida de proteção possível, a implementação de sistemas de segurança. Quando esses sistemas compreendem o comando da máquina, as chamadas “partes de sistemas de comando relacionadas à segurança” (SRP/CS, do inglês “safety-related parts of control system”), devem ser compostos por dispositivos interligados adequadamente integrados ao sistema de comando, mantidos sob monitoramento automático (dependendo de risco associado), considerando as características técnicas da máquina e do processo de trabalho, conforme medidas e alternativas técnicas existentes – a exemplo das normas que tratam das partes do sistema de comando relacionado à segurança – a fim de atingir o nível mínimo necessário de segurança, para proteger pessoas nas zonas de perigo.

CLPs de segurança são controladores lógicos programáveis com características especiais de funcionamento (tais como redundância, diversidade e autoteste) que executam instruções e funções específicas de programação (como lógica combinacional e/ou sequencial, temporização e contagem) que, através de blocos padronizados e um programa de aplicação relacionado à segurança (SRASW²) validado, monitoram elementos geradores de sinais (entradas) e comandam elementos de controle da potência de movimentos perigosos (saídas) em vários tipos de máquinas ou processos. O programa de aplicação instalado, partindo da premissa de que não sofre “desgaste”, deve considerar condições previstas, assegurando sua eficácia e reduzindo ao mínimo razoavelmente previsível a possibilidade de erros provenientes de falhas sistemáticas, evitando a perda das funções relativas à segurança e não permitindo alterações inadvertidas dos blocos de função de segurança específicos.

Arquitetura básica:

Consideremos o seguinte:

A NR-12 não estabelece requisitos específicos para software de aplicação relacionado à segurança (SRASW – Safety-related application software) para a redução de risco, apesar de mencionar, no Anexo IV – Glossário, na definição de “Categoria”, que a integração de componentes relacionados à segurança dos sistemas de controle inclui aspectos de software, direcionando essa aplicação específica à ABNT NBR ISO 13849-1:2019, atualmente publicada;
A norma ABNT NBR 14153:2022 reconhece que o comportamento atingido pelas SRP/CS, em relação à resistência às possíveis falhas, pode depender, dentre vários fatores, da qualidade e exatidão do software, além da necessidade de validação por ensaios (testes) para comprovação das categorias especificadas, mas não determina requisitos para sua aplicação;
Ambas as normas ABNT NBR 14153 e ABNT NBR ISO 13849-1 concordam que o conceito de “defeito³” (aleatório, por desgaste) não se aplica em elementos que consistam apenas em software. Neste tipo de medida de redução de riscos, se aplicam apenas os requisitos para evitar falhas sistemáticas durante o ciclo de vida do software relacionado à segurança;
Erros de programação, projeto ou implementação afetam diretamente a segurança!
Usabilidade e testabilidade são essenciais!

Falhas sistemáticas são falhas determinísticas, que ocorrem repetidamente sob as mesmas condições, relacionadas a uma determinada causa e que somente podem ser eliminadas por modificações de projeto, processos de fabricação, procedimentos operacionais, documentação ou outros fatores relevantes. Medidas para controlar falhas sistemáticas podem incluir princípios fundamentais e devidamente comprovados de segurança, monitoramento da sequência do programa da aplicação, de módulos e blocos funcionais, de sub-rotinas ou comandos lógicos, bem como do processo de comunicação de dados. Já as medidas para evitar essas falhas incluem diversas opções voltadas para seleção, dimensionamento, montagem e manutenção de dispositivos e componentes, inspeção e testes para evidenciar a efetividade das soluções na aplicação.

Há uma nota na norma técnica ABNT NBR ISO 13849-1, informando que componentes eletrônicos complexos (incluindo CLPs “convencionais”) não atendem requisitos para comprovação como componentes “bem testados” (na edição brasileira, o termo em inglês “well-tried” é traduzido como “devidamente comprovado”). Em contrapartida, os controladores definidos como “CLPs de segurança” são projetados, fabricados e testados conforme normas relevantes em relação à segurança funcional, possuem processamento redundante, arquitetura em diversidade e teste automáticos do próprio sistema, apresentam dados relacionados à segurança (como “probabilidade média de falha perigosa por hora – PFHD⁴; e “cobertura de diagnóstico média – DCavg⁵", por exemplo) e permitem uma avaliação apropriada de subsistemas de geração de sinais e de comando de movimentos perigosos por blocos de função previamente validados e por lógica de programação de usuário que seja planejada, modelada, codificada e validada por processo que considere sobretudo a prevenção de falhas e defeitos que possam ser introduzidos durante o desenvolvimento do software.

Para tal, a norma estabelece o "Modelo V" para gerenciamento de ciclo de vida do software, com o objetivo principal de ter um software legível, compreensível, testável e de fácil manutenção.

Ao considerar critérios de estruturação e codificação do software de aplicação, é importante levar em consideração, relacionando às habilidades de programação para aplicações de segurança, uma vez que se pretende mitigar falhas sistemáticas:

organizar os blocos de programação de forma a serem fáceis de comissionar, testar e solucionar problemas;
utilizar métodos de programação defensiva, como verificações de integridade de dados e de plausibilidade (ex. verificações por intervalo), que estejam disponíveis na camada da aplicação;
estruturar a arquitetura de modo a permitir a fácil identificação dos estágios (subsistemas) de “Entrada” => “Processamento” => “Saída”, nesta orientação;
preferir o uso de blocos pré-validados⁶ e de forma adequada, de acordo com as necessidades e exigências da arquitetura (categoria), correspondente a uma SRP/CS de entrada (por exemplo, “botão de emergência”, “dispositivo bimanual”, “ESPEs”, etc.) ou saída (tais como “monitoramento de dispositivos externos”/EDM, também chamado pelo termo em inglês “feedback loop monitoring”, “monitoramento de válvula”, entre outros) e às condições da aplicação (como operadores lógicos, contadores, temporizadores e registradores tipo “flip-flop RS”, a depender da disponibilidade);
limitar os módulos e blocos de programação em função da extensão (tamanho) do código e dos parâmetros de entrada e saída, sendo devidamente comentados sempre que possível e adequado;
selecionar medidas de diagnóstico de acordo com as considerações e os modos das falhas previsíveis;
evitar retenções ou contornos (“bypasses” lógicos) nos ramos da programação – se necessário, preferir recursos "orientados a zero", flip-flops RS, por exemplo;
ter cuidado com abstração (simplificação/otimização) demais – manter a programação limpa, porém compreensível e, quando necessário, comentada;
usar de recursos de salvamento de blocos de codificação como bloco de função de usuário (biblioteca de usuário), para prover reusabilidade, sempre que um bloco que codificação (grupo) puder ter uso posterior.

Diversas linguagens de programação padronizadas podem ser utilizadas para implementação de software relacionado à segurança, agrupadas em dois tipos principais:

Linguagem de Variabilidade Limitada (LVL, do inglês “Limited Variability Language”), a exemplo do Diagrama de Blocos Funcionais – FBD (muito comuns em controladores compactos de segurança), do Ladder, do Grafcet/SFC e dos Operandos Lógicos Booleanos; e
Linguagem de Variabilidade Total (FLV, do inglês “Full Variability Language”), como Lista de Instruções, Texto Estruturado, Linguagem de Controle Estruturado, Pascal, C, C++, C# e Assembler.

A depender da linguagem selecionada, dos tipos de dados, dos arranjos estruturais, configuração dos blocos e da capacidade de realização automática de testes e detecção de falhas de toda a estrutura do software, diferentes níveis de desempenho (PL) podem ser atendidos ou limitados neste objeto.

Conforme a tecnologia de conectividade avança e controladores, estações remotas e dispositivos de campo são integrados a redes corporativas e à Internet, o ambiente de tecnologia de operações (do inglês “operational technology”, ou a sigla OT) pode se tornar vulnerável a agentes de ataque que procuram por pontos frágeis para entrada em instalações industriais, sendo que a ocorrência de ataques cibernéticos “bem-sucedidos” ou até invasões locais por tentativa de sabotagem podem levar a sérias consequências – como interrupção de operações críticas e comprometimento da segurança de pessoas.

Para prevenir tais situações, é urgente que os profissionais envolvidos com especificação técnica, configuração e programação de CLPs de segurança estejam aptos e capacitados em práticas de programação segura, façam controle e versionamento dos códigos de programação e de firmware, utilizem de autenticação de acessos, redes de comunicação mais seguras, sistemas de IPS (do inglês “intrusion prevention system”), firewalls industriais e medidas de defesa em profundidade, entre outras medidas de segurança cibernética em ambientes “OT”.

Em resumo, aplicações de software relacionado à segurança podem ser tratadas de maneira distinta para atendimento à conformidade com a NR-12. Para isso, é necessário que haja uma equivalência entre os elementos de hardware e a respectiva codificação lógica; a programação deve ser modular e estruturada, e diversos atributos qualitativos e boas práticas de programação defensiva devem ser considerados para o cumprimento dos requisitos de segurança de máquinas previstos na regulamentação. Não apenas conhecimentos apropriados sobre lógica de programação e ferramentas de desenvolvimento validadas, como também base consolidada sobre os requisitos normativos são essenciais para uma aplicação proficiente e segura.

1 Conforme ABNT NBR ISO 13849-1:2019, são “falhas relacionadas de forma determinística a uma determinada causa”, em muitas situações incluem o erro humano, e que somente podem ser eliminadas por modificação do projeto, processo, procedimento, documentação ou outro fator relevante. (voltar)

2 A norma técnica ABNT NBR ISO 13849-1:2019 considera e estabelece requisitos para alguns tipos de software relacionado à segurança, por exemplo: Software embarcado (SRESW), como firmwares e sistemas operacionais; de aplicação (SRASW), como lógicas de controle e avaliação de funções de segurança; e de parametrização, como configuração da área de monitoramento de um scanner. (voltar)

3 A norma técnica ABNT NBR ISO 12100:2013 define e diferencia falha (como uma “incapacidade” – na edição brasileira, “termination of the ability” foi traduzido como “incapacidade”, mas “perda da capacidade” também poderia ser uma tradução válida – de um elemento de executar sua função requerida, sendo um evento) e defeito (como “estado de um determinado elemento caracterizado pela incapacidade de realizar uma função requerida (...)”, frequentemente como resultado de uma falha, mas que pode ocorrer inesperadamente, sem relação com uma falha prévia). (voltar)

4 Conforme Loren Stewart, CFSE (2019), trata-se da probabilidade de um sistema de falhar perigosamente dentro de um período de uma hora e não estar apto a realizar sua determinada função de segurança quando for requerida, e é baseada na taxa de falhas perigosas e dos meios automáticos de diagnóstico. Na aplicação da ABNT NBR ISO 13849-1:2019, o nível de desempenho (PL) de uma função de segurança é definido pela consideração dos valores de PFHD dos diversos subsistemas que compõem esta função. (voltar)

5 Definida pela ABNT NBR ISO 13849-1:2019 como “medida da efetividade do diagnóstico”, considerando a razão entre a taxa de falhas perigosas detectadas por meio de testes automáticos antes de uma possível perda de função de segurança (DD) pela taxa de falhas perigosas totais (DT). (voltar)

6 Blocos de função desenvolvidos e validados previamente pelo fabricante, disponibilizados por meio de bibliotecas. (voltar)

Referências

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). ABNT NBR ISO 12100: Segurança de máquinas - Princípios gerais de projeto - Apreciação e redução de riscos. 1ª. ed. Rio de Janeiro: [s.n.], 2013.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). ABNT NBR ISO 13849-1: Segurança de máquinas - Partes de sistemas de comando relacionadas à segurança - Parte 1: Princípios gerais de projeto. 1ª. ed. Rio de Janeiro: [s.n.], 2019.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). ABNT ISO/TR 22100-2: Segurança de máquinas - Relação com a ABNT NBR ISO 12100 - Parte 2: Como a ABNT NBR ISO 12100 se relaciona com a ABNT NBR ISO 13849-1. 1ª. ed. Rio de Janeiro: [s.n.], 2024.

BRASIL. Ministério do Trabalho e Emprego. Norma Regulamentadora nº 12: Segurança no Trabalho em Máquinas e Equipamentos, Brasília, 2024. Disponivel em: <https://www.gov.br/trabalho-e-emprego/pt-br/acesso-a-informacao/participacao-social/conselhos-e-orgaos-colegiados/comissao-tripartite-partitaria-permanente/normas-regulamentadora/normas-regulamentadoras-vigentes/nr-12-atualizada-2025.pdf>. Acesso em: 17 set. 2025.

FRANCHI, C. M.; CAMARGO, V. L. A. D. Controladores Lógicos Programáveis - Sistemas Discretos. 1ª. ed. São Paulo: Érica, 2008.

INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). IEC/TS 63074: Machine safety - Security aspects in connection with the functional safety of safety-related control system. 2ª. ed. Genebra: IEC Central Office, 2023.

MADSEN, T. CyberSecurity-Magazine.com. Secure PLC Programming, 01 jul. 2025. Disponivel em: <https://cybersecurity-magazine.com/secure-plc-programming/>. Acesso em: 27 jan. 2026.

POSTAL, C. UpGuard.com. Programmable Logic Controllers and Cybersecurity Risk, 01 dez. 2025. Disponivel em: <https://www.upguard.com/blog/plc-risk>. Acesso em: 27 jan. 2026.

STEWART, L. Exida.com. PFH (Probability of dangerous failure per hour), 2019. Disponivel em: <https://www.exida.com/blog/back-to-basics-17-pfh>. Acesso em: 19 dez. 2025.

TXONE NETWORKS. txOne.com/blog. The Ultimate Guide to PLC Cybersecurity, 19 abr. 2024. Disponivel em: <https://www.txone.com/blog/ultimate-guide-to-plc-cybersecurity/>. Acesso em: 27 jan. 2026.