ABNT NBR IEC 61511 1 Sistemas Instrumentados de Seguran A 1707398384

ABNT/CB-003
PROJETO ABNT NBR IEC 61511-1

FEV 2024
Segurança funcional — Sistemas instrumentados de segurança

para o setor da indústria de processo
Parte 1: Estrutura, definições, sistema, hardware e requisitos
de programação do aplicativo
Projeto em Consulta Nacional
APRESENTAÇÃO
1) Este Projeto foi elaborado pela Comissão de Estudo de Sistemas e Componentes para
Medição, Controle e Automação de Processos Industriais (CE-003:065.001) do Comitê
Brasileiro de Eletricidade (ABNT/CB-003), com número de Texto-Base 003:065.001-007/1,
nas reuniões de:
02.10.2023 20.11.2023
a) é previsto para ser idêntico à IEC 61511-1:2016 + AMD1:2017, Ed.2.1, que foi elaborada
pelo Technical Committee Industrial Process Measurement, Control and Automation
(IEC/TC 65);
b) não tem valor normativo.
2) Aqueles que tiverem conhecimento de qualquer direito de patente devem apresentar esta
informação em seus comentários, com documentação comprobatória.
3) Analista ABNT – Newton Ferraz.
© ABNT 2024
Todos os direitos reservados. Salvo disposição em contrário, nenhuma parte desta publicação pode ser modificada
ou utilizada de outra forma que altere seu conteúdo. Esta publicação não é um documento normativo e tem
apenas a incumbência de permitir uma consulta prévia ao assunto tratado. Não é autorizado postar na internet
ou intranet sem prévia permissão por escrito. A permissão pode ser solicitada aos meios de comunicação da ABNT.
NÃO TEM VALOR NORMATIVO

ABNT/CB-003
FEV 2024

Functional safety — Safety instrumented systems for the process industry sector
Part 1: Framework, definitions, system, hardware, and application
programming requirements
Prefácio Nacional
A Associação Brasileira de Normas Técnicas (ABNT) é o Foro Nacional de Normalização. As Normas

Brasileiras, cujo conteúdo é de responsabilidade dos Comitês Brasileiros (ABNT/CB), dos Organismos
de Normalização Setorial (ABNT/ONS) e das Comissões de Estudo Especiais (ABNT/CEE), são
elaboradas por Comissões de Estudo (CE), formadas pelas partes interessadas no tema objeto
da normalização.
Os Documentos Técnicos internacionais adotados são elaborados conforme as regras da

ABNT Diretiva 3.
A ABNT chama a atenção para que, apesar de ter sido solicitada manifestação sobre eventuais direitos
de patentes durante a Consulta Nacional, estes podem ocorrer e devem ser comunicados à ABNT
a qualquer momento (Lei nº 9.279, de 14 de maio de 1996).
Os Documentos Técnicos ABNT, assim como as Normas Internacionais (ISO e IEC), são voluntários
e não incluem requisitos contratuais, legais ou estatutários. Os Documentos Técnicos ABNT não
substituem Leis, Decretos ou Regulamentos, aos quais os usuários devem atender, tendo precedência
sobre qualquer Documento Técnico ABNT.
Ressalta-se que os Documentos Técnicos ABNT podem ser objeto de citação em Regulamentos
Técnicos. Nestes casos, os órgãos responsáveis pelos Regulamentos Técnicos podem determinar
as datas para exigência dos requisitos de quaisquer Documentos Técnicos ABNT.
A ABNT NBR IEC 61511-1 foi elaborada no Comitê Brasileiro de Eletricidade (ABNT/CB-003),
pela Comissão de Estudo de Sistemas e Componentes para Medição, Controle e Automação
de Processos Industriais (CE-003:065.001). O Projeto circulou em Consulta Nacional conforme
Edital nº XX, de XX.XX.XXXX a XX.XX.XXXX.
A ABNT NBR IEC 61511-1 é uma adoção idêntica, em conteúdo técnico, estrutura e redação,
à IEC 61511-1:2016 + AMD1:2017, Ed.2.1, que foi elaborada pelo Technical Committee Industrial
Process Measurement, Control and Automation (IEC/TC 65).

ABNT/CB-003
FEV 2024
O Escopo da ABNT NBR IEC 61511-1 em inglês é o seguinte:
Scope
This Part of ABNT NBR IEC 61511 gives requirements for the specification, design, installation,
operation, and maintenance of a safety instrumented system (SIS), so that it can be confidently entrusted
to achieve or maintain a safe state of the process. ABNT NBR IEC 61511-1 has been developed
as a process sector implementation of IEC 61508:2010.

ABNT/CB-003
FEV 2024
Introdução
Os sistemas instrumentados de segurança (SIS) têm sido utilizados há anos para realizar funções
instrumentadas de segurança (SIF) nas indústrias de processo. Se a instrumentação for efetivamente
utilizada para desempenhar as SIF, é essencial que esta instrumentação apresente determinados
padrões e níveis de desempenho mínimos.

A série IEC 61511 aborda a aplicação de SIS nas indústrias de processo. Para o desenvolvimento
da especificação dos SIS, também é necessária a avaliação de risco e perigos (H&RA – Hazard
& Risk Analysis) do processo. Outras contribuições de sistemas de segurança são consideradas
apenas quando estão relacionadas aos requisitos de desempenho para o SIS. O SIS inclui todos
os dispositivos necessários para executar cada SIF, desde o(s) sensor(es) até o(s) elemento(s) final(is).
A série IEC 61511 contém dois conceitos que são fundamentais para a sua aplicação: ciclo de vida
de segurança do SIS e nível de integridade de segurança (SIL).
A série IEC 61511 aborda a aplicação dos SIS, os quais são baseados na utilização de tecnologia
elétrica, eletrônica e eletrônica programável. Quando outras tecnologias são utilizadas para
o solucionador lógico, recomenda-se que os princípios básicos da série IEC 61511 sejam aplicados
para assegurar que os requisitos de segurança funcional sejam atendidos. A série IEC 61511 também
aborda a aplicação de sensores e elementos finais de SIS, independentemente da tecnologia utilizada.
A série IEC 61511 é específica para a indústria de processo dentro da estrutura da série IEC 61508.
A série IEC 61511 estabelece uma abordagem para as atividades do ciclo de vida da segurança
do SIS, de maneira a atingir princípios mínimos. Esta abordagem tem sido adotada para que seja
utilizada uma política racional e tecnicamente consistente.
Na maioria das vezes, é melhor garantir a segurança por meio de um projeto de processo inerentemente
mais seguro. Contudo, em alguns casos, isso não é possível ou não é prático. Se necessário, o projeto
pode ser combinado com outro sistema de proteção ou sistemas projetados para tratar quaisquer
riscos residuais identificados. Sistemas de proteção podem ser baseados em diferentes tecnologias
(química, mecânica, hidráulica, pneumática, elétrica, eletrônica e eletrônica programável). Para facilitar
esta abordagem, a série IEC 61511:
— requer que a H&RA identifique os requisitos de segurança como um todo;
— aborda a alocação de requisitos de segurança ao SIS;
— trabalha dentro de uma estrutura aplicável a todos os meios instrumentados para atingir
a segurança funcional;
— detalha o uso de certas atividades, como o gerenciamento da segurança, que sejam aplicáveis
à obtenção da segurança funcional.
A série IEC 61511 sobre SIS para a indústria de processos:
— aborda todas as fases do ciclo de vida de segurança do SIS, desde a concepção inicial, projeto,
implementação, operação e manutenção até o descomissionamento;
— permite que padrões industriais de processos específicos de cada país, existentes ou novos,
sejam harmonizados com a série IEC 61511.
A série IEC 61511 tem o propósito de elevar o nível de consistência dentro da indústria
de processo (por exemplo, pelos princípios que a norteiam, terminologia, informação). Isto deve
proporcionar ambos os benefícios de segurança e econômicos. A Figura 1 mostra a estrutura geral
da série IEC 61511.

ABNT/CB-003
FEV 2024
Nas jurisdições em que as autoridades governamentais (por exemplo, nacionais, estaduais, municipais)
tenham estabelecido projeto de segurança de processo, gerenciamento de segurança de processo
ou outros regulamentos, estes têm precedência sobre os requisitos determinados na série IEC 61511.
Figura 1 – Estrutura geral da série IEC 61511

ABNT/CB-003
FEV 2024

1 Escopo
Esta Parte da ABNT NBR IEC 61511 apresenta os requisitos para especificação, projeto, instalação,
operação e manutenção de um sistema instrumentado de segurança (SIS), de modo que seja
confiavelmente garantido que este sistema alcance ou mantenha o processo em um estado seguro.
A ABNT NBR IEC 61511-1 foi desenvolvida como a implementação da série IEC 61508:2010 para
o setor de processo.
A ABNT NBR IEC 61511-1, em particular:
a) especifica os requisitos para se atingir a segurança funcional, mas não especifica quem
é responsável por implementar os requisitos (por exemplo, engenharia, fornecedores, companhia
operadora/proprietária, construtora). A responsabilidade é atribuída a diferentes entidades,
de acordo com o planejamento de segurança, planejamento e gerenciamento do projeto, e com
a regulamentação nacional;
b) aplica-se quando dispositivos que atendem aos requisitos da série IEC 61508, série publicada
em 2010, ou da IEC 61511-1:2016, 11.5, são integrados ao sistema global, que é utilizado
em uma aplicação do setor de processo. Não se aplica aos fabricantes que desejem reivindicar
que seus produtos sejam adequados para utilização em SIS para o setor de processo
(ver IEC 61508-2:2010 e IEC 61508-3:2010);
c) determina o relacionamento entre a ABNT NBR IEC 61511 e a série IEC 61508 (Ver Figuras 2 e 3);
d) aplica-se quando programas aplicativos são desenvolvidos para sistemas que tenham linguagem
de variabilidade limitada ou quando são utilizados dispositivos com linguagem de programação fixa,
mas não se aplica aos fabricantes, projetistas, usuários e integradores de SIS que desenvolvam
programa embarcado (software de sistema) ou na utilização de linguagens de variabilidade
completa (ver IEC 61508-3:2010);
e) aplica-se a uma ampla variedade de indústrias no setor de processo, incluindo indústria química,
óleo e gás, papel e celulose, farmacêutica, alimentícia, e geração de energia não nuclear;
NOTA 1 Algumas aplicações do setor de processo podem demandar requisitos adicionais, que têm
que ser atendidos.
NOTA BRASILEIRA Operações do setor industrial têm aplicado os requisitos e conceitos apresentados
nesta Parte da ABNT NBR IEC 61511, como forma de controle e redução de riscos de segurança
de processo, por meio da segurança funcional, incluindo os setores industriais de manuseio de materiais
e processamento mineral, químico, petroquímico, petróleo e gás, papel e celulose, farmacêutica,
alimentícia, energia elétrica, portuário, agronegócio e siderúrgico, entre outros.
f) apresenta a relação entre SIF e outras funções instrumentadas (ver Figura 4);
g) resulta na identificação dos requisitos funcionais e requisitos de integridade de segurança da SIF,

levando em consideração a redução de risco obtida por outros métodos;
NÃO TEM VALOR NORMATIVO 1/91

ABNT/CB-003
FEV 2024
h) especifica os requisitos do ciclo de vida para arquitetura do sistema e configuração de hardware,

programação do aplicativo e integração do sistema;
i) especifica os requisitos de programação do aplicativo para usuários e integradores de SIS;
j) aplica-se quando a segurança funcional é alcançada, utilizando-se uma ou mais SIF para proteção
de pessoas, proteção do público em geral ou proteção do meio ambiente;
k) pode ser aplicada a aplicações não voltadas à segurança, como proteção de ativos;
l) determina requisitos para implantação dos SIF como parte da arquitetura geral para se atingir
a segurança funcional;
m) utiliza o ciclo de vida de segurança do SIS (Figura 7) e especifica uma lista de atividades
necessárias para se determinarem os requisitos funcionais e os requisitos de integridade
de segurança para o SIS;
n) especifica que seja realizada a H&RA para que possam ser determinados os requisitos funcionais
de segurança e níveis de integridade de segurança (SIL) para cada SIF;
NOTA 2 A Figura 9 apresenta uma visão geral dos meios de redução de risco.
o) estabelece alvos numéricos para a probabilidade média de falha sob demanda (no modo
de demanda) e a frequência média de falhas perigosas (no modo de demanda e contínua)
para cada SIL;
p) especifica requisitos mínimos para tolerância a falha do hardware (HFT);
q) especifica técnicas e medidas requeridas para se atingir o SIL especificado;
r) determina um nível máximo de desempenho de segurança funcional (SIL 4) que pode ser atingido
por uma SIF que foi implementada de acordo com a ABNT NBR IEC 61511-1;
s) determina um nível mínimo de desempenho de segurança funcional (SIL 1) abaixo do qual

a ABNT NBR IEC 61511-1 não se aplica;
t) apresenta uma estrutura para estabelecer o SIL, mas não determina o SIL requerido para uma
aplicação específica (que convém que seja estabelecido com base no conhecimento da aplicação
particular e no objetivo geral de redução de risco);
u) especifica requisitos para todas as partes do SIS, desde o(s) sensor(es) até o(s) elemento(s) final(is);
v) determina a informação que é necessária durante o ciclo de vida de segurança do SIS;
w) especifica que o projeto de um SIS considere os fatores humanos;
x) não associa algum requisito direto sobre o operador individual ou mantenedor.
2/91 NÃO TEM VALOR NORMATIVO

ABNT/CB-003
FEV 2024
Figura 2 – Relacionamento entre a ABNT NBR IEC 61511 e a série IEC 61508
NOTA 3 A série IEC 61508 também é utilizada por projetistas, integradores e usuários de sistemas
instrumentados de segurança, quando orientados pela ABNT NBR IEC 61511.

ABNT/CB-003
FEV 2024
Figura 3 – Relacionamento detalhado entre a ABNT NBR IEC 61511 e a série IEC 61508
NOTA 4 As Subseções 7.2.2 na ABNT NBR IEC 61511-1 e A.7.2.2 na IEC 61511-2:2016 contêm orientações
sobre como lidar com a integração de subsistemas que atendem a outras normas (como máquinas,
caldeiras etc.).

ABNT/CB-003
FEV 2024
Figura 4 – Relacionamento entre funções instrumentadas de segurança e outras funções
2 Referências normativas
Os documentos a seguir são citados no texto de tal forma que seus conteúdos, totais ou parciais,
constituem requisitos para este Documento. Para referências datadas, aplicam-se somente as edições
citadas. Para referências não datadas, aplicam-se as edições mais recentes do referido documento
(incluindo emendas).
IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related

systems – Part 1: General requirements

systems – Part 2: Requirements for electrical/electronic/programmable electronic safety related systems

systems – Part 3: Software requirements

ABNT/CB-003
FEV 2024
3 Termos, definições e abreviaturas

3.1 Termos
Os termos são apresentados em 3.2.

3.2 Termos e definições
Para os efeitos deste documento, aplicam-se os seguintes termos e definições.
Em alguns casos, estas definições diferem das definições dos mesmos termos da IEC 61508-4:2010.
Em alguns casos, isto se deve à terminologia utilizada no setor da indústria de processos. Em outros
casos, essas definições foram alinhadas com outras referências definitivas aplicáveis (por exemplo,
IEC 60050, o Vocabulário Eletrotécnico Internacional, ISO/IEC Guide 51:2013). No entanto, salvo
indicação em contrário, não há diferença no significado técnico entre estas definições e as definições
dos mesmos termos na IEC 61508-4:2010.
3.2.1
arquitetura
configuração
configuração específica de componentes de hardware e software em um sistema
Nota 1 de entrada: Na série IEC 61511, isso pode significar, por exemplo, o arranjo dos subsistemas SIS,
a estrutura interna de um subsistema SIS, a disposição dos programas de software ou a estrutura interna dos
programas aplicativos do SIS.
3.2.2
proteção de ativos
função alocada ao sistema e projetado com o propósito de evitar perdas ou danos aos ativos
3.2.3
sistema básico de controle de processo
BPCS (Basic Process Control System)
sistema que responde aos sinais de entrada do processo, seus equipamentos associados, outros
sistemas programáveis e/ou a um operador, gerando sinais de saída de modo que o processo e seus
equipamentos associados operem da maneira pretendida, mas que não desempenha qualquer SIF
Nota 1 de entrada: Um BPCS inclui todos os dispositivos necessários para assegurar que o processo opere
da maneira pretendida.
Nota 2 de entrada: Um BPCS normalmente pode implementar diversas funções, como funções de controle
de processo, monitoramento e alarmes.
3.2.4
by-pass (desvio)
ação ou recurso para impedir que toda ou parte da funcionalidade do SIS seja executada
Nota 1 de entrada: Exemplos de by-pass incluem:
— o sinal de entrada é isolado da lógica de acionamento enquanto ainda apresenta os parâmetros de entrada
e alarme ao operador;
— o sinal de saída da lógica de acionamento para um elemento final é mantido no estado normal impedindo
a operação do elemento final;

ABNT/CB-003
FEV 2024
— uma linha de by-pass físico é instalada em torno do elemento final;
— o estado de entrada pré-selecionado (por exemplo, entrada ligada/desligada) ou definido é forçado por uma
ferramenta de engenharia (por exemplo, no programa aplicativo).
Nota 2 de entrada: Outros termos também são utilizados para se referir ao by-pass, como sobreposição,
anular, desabilitar, forçar, inibir ou silenciar.
3.2.5
canal
dispositivo ou grupo de dispositivos que, de forma independente, executa uma função específica
Nota 1 de entrada: Os dispositivos dentro de um canal poderiam incluir dispositivos de entrada/saída (E/S),
solucionadores lógicos, sensores, e elementos finais.
Nota 2 de entrada: Uma configuração de canal duplo (isto é, dois canais) é aquela em que dois canais,
de forma independente, realizam a mesma função. Canais podem se idênticos ou diversos.
Nota 3 de entrada: O termo pode ser utilizado para descrever um sistema completo ou uma parte de um sistema
(por exemplo, sensores ou elementos finais).
Nota 4 de entrada: O canal descreve os recursos de arquitetura de hardware do SIS frequentemente utilizados
para atender aos requisitos de tolerância a falhas de hardware.
3.2.6
causa comum
3.2.6.1
falhas por causa comum, pl
falhas simultâneas de diferentes dispositivos, resultantes de um único evento, onde essas falhas
não são consequências umas das outras
Nota 1 de entrada: Todas as falhas devido a uma causa comum não ocorrem necessariamente exatamente
ao mesmo tempo e isso pode dar tempo para detectar a ocorrência da causa comum antes que uma SIF
realmente falhe.
Nota 2 de entrada: Falhas de causa comum também podem levar a falhas de modo comum.
Nota 3 de entrada: O potencial para falhas de causa comum reduz o efeito da redundância do sistema
ou da tolerância a falhas (por exemplo, aumenta a probabilidade de falha de dois ou mais canais
em um sistema de múltiplos canais).
Nota 4 de entrada: Falhas de causa comum são falhas dependentes. Elas podem ser devidas a eventos
externos (por exemplo, temperatura, umidade, sobretensão, incêndio e corrosão), falha sistemática
(por exemplo, erros de projeto, montagem ou instalação, bugs), erro humano (por exemplo, uso indevido) etc.
Nota 5 de entrada: Por extensão, uma falha de causa comum (no singular) é uma falha pertencente
a um conjunto de falhas simultâneas (no plural), de acordo com a definição de 3.2.6.1.

ABNT/CB-003
FEV 2024
3.2.6.2
falhas por modo comum, pl
falhas simultâneas de diferentes dispositivos caracterizadas pelo mesmo modo de falha (ou seja,
falhas idênticas)
Nota 1 de entrada: As falhas no modo comum podem ter causas diferentes.

Nota 2 de entrada: Falhas de modo comum também podem ser o resultado de falhas de causa comum (3.2.6.1).
Nota 3 de entrada: O potencial para falhas de modo comum reduz a eficácia da redundância do sistema
e da tolerância a falhas (por exemplo, falha de dois ou mais canais da mesma maneira, causando o mesmo
resultado errôneo).
Nota 4 de entrada: Por extensão, uma falha de modo comum (no singular) é uma falha pertencente
a um conjunto de falhas simultâneas (no plural) de acordo com a definição de 3.2.6.2.
3.2.7
medida compensatória
implementação temporária de métodos planejados e documentados para gerenciamento de riscos
durante qualquer período de manutenção ou operação do processo, quando se sabe que o desempenho
do SIS está degradado
3.2.8
componente
uma das partes de um sistema, subsistema do SIS ou dispositivo desempenhando uma função
específica
Nota 1 de entrada: Componente também inclui software.
3.2.9
gerenciamento da configuração
disciplina de identificação dos componentes e dos arranjos desses componentes de um sistema
em evolução para fins de controle de alterações nesses componentes, mantendo a continuidade
do sistema e rastreabilidade ao longo de todo seu ciclo de vida
3.2.9.1
abordagem conservadora
maneira cautelosa de realizar análises e cálculos
Nota 1 de entrada: No campo da segurança, cada vez que uma análise, suposições ou cálculos
precisam ser feitos (sobre modelos, dados de entrada, cálculos computacionais etc.), esta abordagem
pode ser escolhida para assegurar a elaboração de resultados pessimistas.
3.2.10
sistema de controle
sistema que responde aos sinais de entrada do processo ou de um operador, gerando sinais de saída
de modo que o processo opere da maneira desejada
Nota 1 de entrada: O sistema de controle inclui sensores e elementos finais e pode ser um BPCS
ou um SIS ou uma combinação dos dois.

ABNT/CB-003
FEV 2024
3.2.11
falha perigosa
falha que impede ou desabilita uma determinada ação de segurança
Nota 1 de entrada: Uma falha é “perigosa” apenas em relação a uma determinada SIF.
Nota 2 de entrada: Quando a tolerância a falhas é implementada, uma falha perigosa pode levar a:
— uma SIF degradada em que a ação de segurança esteja disponível, mas há um PFD mais alto ou um PFH, ou
— uma SIF desabilitada em que a ação de segurança está completamente desabilitada ou o evento perigoso
foi induzido.
Nota 3 de entrada: Quando nenhuma tolerância a falhas é implementada, todas as falhas perigosas levam
a uma SIF desabilitada.
3.2.12
falha dependente
falha cuja probabilidade não pode ser expressa pelo simples produto das probabilidades não
condicionadas a cada um dos eventos individuais que a causaram
Nota 1 de entrada: Dois eventos A e B são dependentes, se a probabilidade da ocorrência de A e B, P (A e B)

for maior que P(A) × P(B).
Nota 2 de entrada: Ver 9.4.2 e IEC 61511-3:2016, Anexo J, para consideração de falhas dependentes entre
camadas de proteção.
Nota 3 de entrada: Falhas dependentes incluem causa comum.
3.2.13
detectada
revelada
evidente
falhas ou avarias de hardware e software, que não estão ocultas, porque são anunciadas ou reveladas
pela operação normal ou por métodos de detecção dedicados
Nota 1 de entrada: Existem algumas diferenças na utilização destes termos:
— ‘Evidente’ é utilizado para falhas ou avarias que se anunciam quando ocorrem (por exemplo,
devido à mudança de estado). A reparação dessas falhas pode começar assim que ocorrerem.
— ‘Detectada’ é utilizado para falhas ou avarias que não se anunciam quando ocorrem e que
permanecem ocultas até serem detectadas por algum meio (por exemplo, testes de diagnóstico,
testes de prova, intervenção do operador como inspeção física e testes manuais). A reparação
dessas falhas só pode começar depois de terem sido reveladas. Ver a Nota 2 para a utilização
específica deste termo na ABNT NBR IEC 61511.
— ‘Revelada’ é utilizado para falhas ou avarias que se tornam notórias por serem evidentes ou como
resultado de serem detectadas.
Nota 2 de entrada: Na ABNT NBR IEC 61511 e exceto quando o contexto sugerir outro significado,
os termos avarias/falhas perigosas detectadas estão relacionados a falhas perigosas detectadas
por testes de diagnóstico.
Nota 3 de entrada: Quando a detecção é muito rápida (por exemplo, por testes de diagnóstico),
as avarias ou falhas detectadas podem ser consideradas avarias ou falhas evidentes.

ABNT/CB-003
FEV 2024
Quando a detecção não é muito rápida (por exemplo, por meio de testes de prova), as avarias
ou falhas detectadas podem não ser consideradas avarias ou falhas evidentes ao abordar os níveis
de integridade de segurança.
Nota 4 de entrada: Uma falha perigosa revelada somente pode ser tratada como uma falha segura
se medidas eficazes, automáticas ou manuais forem tomadas em um tempo curto o suficiente para
manter a segurança do processo.
3.2.14
dispositivo
hardware, com ou sem software, capaz de desempenhar uma função específica
Nota 1 de entrada: Exemplos são sensores, elementos finais, solucionadores lógicos e dispositivos de interface
com o operador e fiação de campo.
3.2.14.1
dispositivo de campo
dispositivo do SIS ou do BPCS conectado diretamente ao processo ou localizado próximo ao processo
Nota 1 de entrada: Exemplos são sensores, elementos finais e chaves manuais.
3.2.15
diagnóstico
teste automático frequente (em relação ao tempo de segurança do processo) para revelar falhas
3.2.15.1
cobertura de diagnóstico (DC – Diagnostic Coverage)
fração das taxas de falhas perigosas detectadas por diagnóstico. Cobertura de diagnóstico não diz
respeito a quaisquer falhas detectadas pelos testes de prova
Nota 1 de entrada: Cobertura de diagnóstico é normalmente aplicada a dispositivos de SIS ou subsistemas

de um SIS. Por exemplo, a cobertura de diagnóstico normalmente é determinada para sensor, elemento final
ou solucionador lógico.
Nota 2 de entrada: Para aplicações de segurança, a cobertura de diagnóstico geralmente é aplicada às falhas
perigosas de dispositivo do SIS ou subsistema do SIS. Por exemplo, a cobertura de diagnóstico de falhas
perigosas em um dispositivo é DC = λDD/λDT, onde λDD é a taxa de falha perigosa detectada e λDT
é a taxa de falha perigosa total. Para um subsistema SIS com redundância interna, o DC depende do tempo:
DC(t) = λDD(t)/ λDT(t).
Nota 3 de entrada: Quando a cobertura de diagnóstico (DC) e a taxa total de falhas perigosas (λDT)
são fornecidas, as falhas perigosas detectadas (λ DD) e não detectadas (λDU) podem ser calculadas
da seguinte forma:
λDD = DC × λDT e λDU = (1-DC) × λDT
3.2.16
diversidade
diferentes meios para se executar uma função requerida
Nota 1 de entrada: Diversidade pode ser obtida por meios físicos diferentes, diferentes técnicas de programação,
ou abordagens de projeto diferentes.

ABNT/CB-003
FEV 2024
3.2.17
erro
discrepância entre um valor calculado, observado ou medido e seu respectivo valor ou condição
verdadeira, especificada ou teoricamente correta
[FONTE: IEC 60050-192:2015, 192-03-02]

3.2.18
falha
perda da capacidade de desempenhar conforme requerido
Nota 1 de entrada: Uma falha de um dispositivo é um evento que resulta em um estado de falha desse
dispositivo.
Nota 2 de entrada: Quando a perda de capacidade é causada por uma falha latente, a falha ocorre quando
um determinado conjunto de circunstâncias é encontrado.
Nota 3 de entrada: O desempenho das funções requeridas necessariamente exclui determinados

comportamentos e algumas funções podem ser especificadas em termos de comportamentos a serem
evitados. A ocorrência deste comportamento é uma falha.
Nota 4 de entrada: Falhas podem ser aleatórias ou sistemáticas (ver 3.2.59 e 3.2.81).
[FONTE: IEC 60050-192:2015, 192-03-01, modificada – Notas da entrada foram alteradas.]
3.2.18.1
modo de falha
maneira como ocorre a falha
Nota 1 de entrada: Um modo de falha pode ser determinado pela função perdida ou pela transição de estado
que ocorreu.
[FONTE: IEC 60050-192:2015, 192-03-17]
3.2.19
avaria
incapacidade de desempenhar conforme necessário, devido a um estado interno
Nota 1 de entrada: Uma avaria de um item resulta de uma falha, seja do próprio item ou de uma deficiência
em um estágio anterior do ciclo de vida, como especificação, projeto, fabricação ou manutenção.
Nota 2 de entrada: Uma avaria de um dispositivo resulta em falha quando um determinado conjunto
de circunstâncias é encontrado.
[FONTE: IEC 60050-192:2015, 192-04-01, modificada – Algumas notas do item foram alteradas,
outras foram excluídas]
3.2.20
prevenção de falhas
utilização de técnicas e procedimentos que visem evitar a introdução de falhas durante todas as fases
do ciclo de vida de segurança do SIS

ABNT/CB-003
FEV 2024
3.2.20.1
exclusão de falha
eliminação de considerações adicionais de falhas devido a modos de falha improváveis
Nota 1 de entrada: Mais informações sobre exclusão de falhas podem ser encontradas nas ISO 13849-1
e ISO 13849-2. Após essas normas, a exclusão de falhas pode ser baseada em
— improbabilidade técnica de ocorrência de algumas falhas,
— experiência técnica geralmente aceita, independentemente da aplicação considerada,
— requisitos técnicos relacionados com a aplicação e o perigo específico.
Nota 2 de entrada: Os modos de falha, identificados nos dispositivos que executam a função de segurança,
podem ser excluídos, porque suas taxas de falha perigosas relacionadas são muito baixas em comparação
com a medida de falha-alvo para a função de segurança que está sendo considerada. Ou seja, a soma das
taxas de falhas perigosas de todos os dispositivos nos quais a exclusão de falhas está sendo reivindicada,
geralmente não pode exceder mais de 1 % da medida de falha-alvo da análise.
3.2.21
tolerância a falhas
aptidão de um item funcional em continuar a desempenhar a função requerida mesmo na ocorrência
de falhas ou erros
3.2.22
elemento final
parte de um BPCS ou SIS que executa a ação física necessária para se alcançar ou manter o estado seguro
Nota 1 de entrada: Exemplos: válvulas, disjuntores e motores incluindo seus elementos auxiliares (como válvula
solenoide e atuador utilizados para operar uma válvula).
3.2.23
segurança funcional
parte da segurança total relacionada ao processo e ao BPCS, que depende do correto funcionamento
do SIS e de outras camadas de proteção
3.2.24
avaliação da segurança funcional
FSA (Functional Safety Assessment)
investigação, baseada em evidências, para julgar se a segurança funcional foi alcançada por
um ou mais SIS ou outras camadas de proteção
3.2.25
auditoria da segurança funcional
exame sistemático e independente para determinar se os procedimentos específicos aos requisitos
de segurança funcional estão em conformidade com as disposições planejadas, estão implementados
de maneira efetiva e são adequados para atingir os objetivos especificados
Nota 1 de entrada: A auditoria de segurança funcional pode ser realizada como parte de uma FSA.
3.2.26
integridade de segurança de hardware
parte da integridade de segurança do SIS relacionada a falhas de hardware aleatórias em um modo
de falha perigoso
Nota 1 de entrada: As duas medidas de falha que são relevantes neste contexto são a frequência média
de falhas perigosas e a probabilidade média de falha sob demanda.

ABNT/CB-003
FEV 2024
Nota 2 de entrada: Ver 3.2.82.
Nota 3 de entrada: Esta definição difere da IEC 61508-4:2010 para refletir as diferenças na terminologia do setor
de processo.
3.2.27
dano
lesões ou prejuízo à saúde das pessoas, ou impactos prejudiciais à propriedade ou ao meio ambiente
[FONTE: ISO/IEC Guide 51:2014, 3.1]
3.2.27.1
evento prejudicial
evento perigoso que causou dano
Nota 1 de entrada: Para um evento perigoso resultar ou não em danos, depende se as pessoas, a propriedade
ou o meio ambiente estão expostos à situação perigosa e, no caso de danos às pessoas, se essas pessoas
expostas podem escapar das consequências de o evento depois que ele ocorreu. Um evento perigoso que
causou danos é denominado evento prejudicial.
3.2.28
perigo
fonte potencial de dano
Nota 1 de entrada: O termo inclui tanto o perigo para pessoas que ocorre dentro de um curto período
(por exemplo, incêndio e explosão) como também aquele que tem um efeito a longo prazo sobre a saúde
de uma pessoa (por exemplo, liberação de uma substância tóxica ou radioatividade).
[FONTE: ISO/IEC Guide 51:2014, 3.2, modificada – Nota 1 de entrada foi adicionada]
3.2.28.1
evento perigoso
evento que pode causar danos
Nota 1 de entrada: Para um evento perigoso resultar ou não em danos, depende se as pessoas, a propriedade
ou o meio ambiente estão expostos à situação perigosa e, no caso de danos às pessoas, se essas pessoas
expostas podem escapar das consequências do evento após ele ter ocorrido.
[FONTE: ISO/IEC Guide 51:2014: 3.3, modificada – ver Nota 1]
3.2.28.2
situação perigosa
circunstância em que as pessoas, as propriedades ou o meio ambiente estão expostos a um ou mais perigos
3.2.29
erro humano
ação intencional ou não intencional, ou falta de ação humana, que leva a um resultado inapropriado
Nota 1 de entrada: Erros, deslizes e lapsos são exemplos de erros humanos.
Nota 2 de entrada: Exclui ações maliciosas.

ABNT/CB-003
FEV 2024
3.2.30
análise de impacto
atividade de determinar o efeito que a mudança de uma função ou componente traz a outras funções
ou componentes no mesmo sistema, bem como em outros sistemas
3.2.31
organização independente
organização separada e distinta, pelo gerenciamento e outros recursos, das organizações responsáveis
pelas atividades que ocorrem durante a fase específica do ciclo de vida de segurança do SIS que está
sujeito à FSA ou validação
3.2.32
pessoa independente
pessoa separada e distinta das atividades que ocorrem durante a fase específica do ciclo de vida
de segurança do SIS, que está sujeita à FSA ou à validação e não tem responsabilidade direta
por essas atividades
3.2.33
função de entrada
função que monitora o processo e seus equipamentos associados, de modo a prover informações
de entrada para o solucionador lógico
Nota 1 de entrada: Uma função de entrada pode ser uma função manual.
3.2.34
instrumento
dispositivo utilizado para executar uma ação (normalmente encontrado em sistemas instrumentados)
3.2.34.1
sistema instrumentado
sistemas compostos por sensores (por exemplo, transmissores de pressão, vazão, temperatura),
solucionadores lógicos (por exemplo, controladores programáveis, sistemas de controle distribuídos,
controladores discretos) e elementos finais (por exemplo, válvulas de controle, circuitos de controle
de motores)
Nota 1 de entrada: Os sistemas instrumentados desempenham funções instrumentadas, incluindo

funções de controle, monitoramento, alarme e funções de proteção. Sistemas instrumentados podem
ser SIS (ver 3.2.67) ou BPCS (ver 3.2.3).
3.2.35
função lógica
função que desempenha as transformações entre as informações de entrada (proporcionada
por um ou mais funções de entrada) e as informações de saída (utilizadas por uma ou mais funções
de saída)
Nota 1 de entrada: As funções lógicas apresentam a transformação de uma ou mais funções de entrada para
uma ou mais funções de saídas.
Nota 2 de entrada: Para obter mais orientações, ver IEC 61131-3:2012 e IEC 60617-12:1997.

ABNT/CB-003
FEV 2024
3.2.36
solucionador lógico (logic solver)
parte do BPCS ou do SIS que executa uma ou mais funções lógicas
Nota 1 de entrada: Na ABNT NBR IEC 61511, os seguintes termos para solucionadores lógicos são utilizados:
— sistemas lógicos elétricos para tecnologia eletromecânica;

— sistemas lógicos eletrônicos para tecnologia eletrônica;
— sistemas lógicos PE para sistemas eletrônicos programáveis.
Nota 2 de entrada: Exemplos: sistemas elétricos, sistemas eletrônicos, sistemas eletrônicos programáveis,
sistemas pneumáticos, sistemas hidráulicos. Sensores e elementos finais não são partes do solucionador lógico.
NOTA BRASILEIRA Exemplos de solucionador lógico (logic solver) para SIS são um CLP de segurança (SPLC)
ou um painel de relés eletromecânicos.
3.2.36.1
solucionador lógico PE configurado para segurança
solucionador lógico eletronicamente programável de uso geral industrial, que é especificamente
configurado para uso em aplicações de segurança
Nota 1 de entrada: Orientações adicionais podem ser encontradas em 11.5.
3.2.37
interface de manutenção ou engenharia
hardware e software disponibilizados para permitir manutenção ou modificação adequada do SIS
Nota 1 de entrada: A interface de manutenção/engenharia pode incluir instruções e diagnósticos que podem ser
encontrados no software, programação de terminais com protocolos de comunicação apropriados, ferramentas
de diagnóstico, indicadores, dispositivos de by-pass, dispositivos de teste e dispositivos de calibração.
3.2.37.1
tempo médio de reparo
MRT (Mean Repair Time)
tempo esperado para reparo total
Nota 1 de entrada: MRT engloba os tempos (b), (c) e (d) dos tempos para MTTR (ver 3.2.37.2).
3.2.37.2
tempo médio para restauração
MTTR (Mean Time to Restoration)
tempo esperado para alcançar a restauração
Nota 1 de entrada: MTTR abrange:
— tempo para detectar a falha (a);
— tempo gasto antes de iniciar a reparação (b);
— tempo efetivo para reparo (c);
— tempo antes do componente ser colocado novamente em operação (d).
A hora de início para (b) é o final de (a); o horário de início de (c) é o final de (b); o horário de início
de (d) é o final de (c).

ABNT/CB-003
FEV 2024
3.2.37.3
tempo máximo permitido de reparo
MPRT (Maximum Permitted Repair Time)
duração máxima permitida para reparar uma falha após ela ter sido detectada
Nota 1 de entrada: O MRT pode ser utilizado como MPRT, mas o MPRT pode ser definido independentemente
do MRT:
— Um MPRT menor que o MRT pode ser escolhido para diminuir a probabilidade de evento perigoso.
— Um MPRT maior que o MRT pode ser escolhido se a probabilidade de evento perigoso puder
ser relaxada.
Nota 2 de entrada: Quando um MPRT for definido, ele pode ser utilizado no lugar do MRT para calcular
a probabilidade de falhas aleatórias de hardware.
3.2.38
mitigação
ação que reduz a(s) consequência(s) do evento perigoso
Nota 1 de entrada: Exemplos incluem despressurização de emergência ou fechamento de dampers

de ventilação na detecção de incêndio ou confirmação de vazamento de gás ou início de sistema
de dilúvio na detecção confirmada de incêndio.
3.2.39
modo de operação (de uma SIF)
modo no qual uma SIF opera, que pode ser modo de baixa demanda, modo de alta demanda
ou modo contínuo
a) modo de baixa demanda: modo de operação no qual a SIF só é acionada sob demanda, a fim
de transferir o processo para um estado seguro especificado, e em que a frequência de demandas
não é superior a uma por ano.
b) modo de alta demanda: modo de operação no qual a SIF somente é acionada sob demanda,
a fim de transferir o processo para um estado seguro especificado, e em que a frequência
de demandas é superior a uma por ano.
c) modo contínuo: modo de operação no qual a SIF mantém o processo em estado seguro como
parte da operação normal.
3.2.39.1
SIF em modo de demanda
SIF que opera em modo de baixa demanda (3.2.39 a) ou modo de alta demanda (3.2.39 b)
Nota 1 de entrada: No caso de uma falha perigosa da SIF, um evento perigoso somente pode ocorrer:
— se a falha não for detectada e se ocorrer uma demanda antes do próximo teste de prova;
— se a falha for detectada pelos testes de diagnóstico, mas o processo relacionado e seus equipamentos
associados não tiverem sido movidos para um estado seguro antes de ocorrer uma demanda.
Nota 2 de entrada: No modo de alta demanda, normalmente é apropriado utilizar o critério do modo contínuo.
Nota 3 de entrada: Os níveis de integridade de segurança para SIF operando em modo demanda estão
definidos nas Tabelas 4 e 5.

ABNT/CB-003
FEV 2024
3.2.39.2
SIF em modo contínuo
SIF operando em modo contínuo (3.2.39 c)
Nota 1 de entrada: No caso de uma falha perigosa da SIF, um evento perigoso ocorrerá sem falha adicional,
a menos que sejam tomadas medidas para evitá-lo dentro do tempo de segurança do processo.
Nota 2 de entrada: O modo contínuo abrange aquelas SIF que implementam controle contínuo para manter
a segurança funcional.
Nota 3 de entrada: Os níveis de integridade de segurança para SIF operando em modo contínuo são definidos
na Tabela 5.
3.2.40
módulo
parte independente de um programa aplicativo de SIS (pode ser interno a um programa ou um conjunto
de programas) que executa uma função específica (por exemplo, sequência de início/parada/teste
de elemento final, uma sequência específica de aplicativo dentro de uma SIF)
Nota 1 de entrada: No contexto da IEC 61131-3:2012, um módulo de software é uma função ou um bloco
de função.
Nota 2 de entrada: A maioria dos módulos tem uso repetitivo em um programa aplicativo.
3.2.41
MooN
SIS, ou parte dele, composto por “N” canais independentes, conectados de forma que “M” canais
sejam suficientes para desempenhar a SIF
3.2.42
redução de risco necessária
redução de risco a ser alcançada pelo(s) SIS ou por outras camadas de proteção, para assegurar
que o risco tolerável não seja excedido
3.2.43
sistema não programável
sistema NP (Non-Programmable)
sistema que utiliza tecnologias que não se baseiam em computadores (isto é, um sistema não baseado
em eletrônicas programáveis [PE] ou software)
Nota 1 de entrada: Exemplos incluem sistemas elétricos ou eletrônicos interligados por fiação, sistemas
mecânicos, sistemas hidráulicos ou sistemas pneumáticos.
3.2.44
ambiente operacional
condições inerentes à instalação de um dispositivo que potencialmente afetem a sua funcionalidade
e integridade de segurança, como:
● ambiente externo, por exemplo, necessidades de preparação para o inverno, classificação

de áreas perigosas;
● condições operacionais do processo, por exemplo, extremos de temperatura, pressão, vibração;
● componentes do processo, por exemplo, sólidos, sais ou corrosivos;

ABNT/CB-003
FEV 2024
● interfaces de processo;
● integração nos sistemas gerais de gestão operacional e de manutenção da planta;
● efetividade da comunicação, por exemplo, interferência eletromagnética; e
● qualidade das utilidades, por exemplo, energia elétrica, ar, hidráulica.

Nota 1 de entrada: Algumas aplicações de processo podem ter requisitos operacionais especiais de ambiente
necessários para suplantar um acidente grave. Por exemplo, alguns equipamentos requerem invólucros
especiais, purga ou proteção.
3.2.45
modo operacional
modo de operação do processo
qualquer estado planejado de operação do processo, incluindo modos como partida após parada
de emergência, partida normal, operação e parada, operações temporárias e operação e parada
de emergência
3.2.46
interface de operação
meios pelos quais a informação é comunicada entre um operador humano e o SIS (por exemplo, por
meio de monitores, lâmpadas de indicação, botoeiras, buzinas e alarmes)
Nota 1 de entrada: A interface de operação é também chamada de interface homem-máquina (IHM).
3.2.47
função de saída
função que controla o processo e seus equipamentos associados, de acordo com as informações
de saída da função lógica
3.2.48
desempenho
realização de uma determinada ação ou tarefa medida em relação à especificação e à série
ABNT NBR IEC 61511
3.2.49
fase
período dentro do ciclo de vida de segurança do SIS, quando as atividades descritas na série
ABNT NBR IEC 61511 são realizadas
3.2.50
prevenção
ação que reduz a probabilidade de ocorrência de um evento perigoso
3.2.51
uso prévio (prior use)
avaliação documentada por um usuário de que um dispositivo é adequado para uso em um SIS
e pode atender aos requisitos de integridade funcional e de segurança requeridos, com base
na experiência operacional anterior em ambientes operacionais semelhantes
Nota 1 de entrada: Para qualificar um dispositivo SIS com base no uso prévio, o usuário pode documentar
que o dispositivo alcançou desempenho satisfatório em um ambiente operacional semelhante. Compreender

ABNT/CB-003
FEV 2024
como o equipamento se comporta no ambiente operacional é necessário para alcançar um alto grau
de certeza de que o projeto planejado, a inspeção, os testes, a manutenção e as práticas operacionais
são suficientes.
Nota 2 de entrada: O uso comprovado (proven in use) toma como referência as bases de projeto do fabricante
(por exemplo, limite de temperatura, limite de vibração, limite de corrosão, suporte de manutenção desejado)
para seu dispositivo. O uso prévio (prior use) trata do desempenho de um dispositivo quando instalado
em uma aplicação do setor de processo em um ambiente operacional específico que geralmente é diferente
das bases de projeto do fabricante.
3.2.52
risco de processo
riscos que surgem das condições de processo causadas por eventos anormais (incluindo o mau
funcionamento do BPCS)
Nota 1 de entrada: O risco neste contexto está associado a um evento perigoso específico no qual
o SIS será utilizado para apresentar a redução de risco necessária (isto é, o risco associado
à segurança funcional).
Nota 2 de entrada: A análise de risco de processo está descrita na IEC 61511-3:2016. O principal
propósito de se determinar o risco do processo é estabelecer um ponto de referência para o risco,
sem considerar a utilização das camadas de proteção.
Nota 3 de entrada: A avaliação deste risco pode incluir as questões associadas ao fator humano.
Nota 4 de entrada: Este termo equivale à definição de risco do EUC (Equipment Under Control/
equipamento sob controle) da IEC 61508-4:2010.
3.2.52.1
tempo de segurança do processo
período de tempo entre uma falha que ocorre no processo ou no sistema básico de controle
do processo (com potencial para dar origem a um evento perigoso) e a ocorrência do evento perigoso,
se a SIF não for acionada
Nota 1 de entrada: Esta é uma propriedade apenas do processo. A SIF tem que detectar a falha
e concluir a sua ação com tempo suficiente para evitar o evento perigoso, considerando qualquer
atraso no processo (por exemplo, resfriamento de um vaso).
3.2.53
dispositivo eletrônico programável
PE
item baseado em tecnologia computacional, que pode ser composto por hardware, software e unidades
de entrada ou saída
Nota 1 de entrada: Este termo abrange dispositivos microeletrônicos baseados em uma ou mais unidades
centrais de processamento (UCP) e respectivas memórias. Exemplos de dispositivos eletrônicos programáveis
na indústria de processo incluem:
— sensores e elementos finais inteligentes;
— solucionadores lógicos eletronicamente programáveis, incluindo:
— controladores programáveis;

ABNT/CB-003
FEV 2024
— controladores lógico programáveis; e
— controladores de malha.
3.2.54
sistemas eletrônicos programáveis
PES (Programmable Electronic System)
sistemas para controle, proteção ou monitoramento baseados em um ou mais dispositivos eletrônicos

programáveis, incluindo todos os dispositivos de um sistema como: fontes de alimentação sensores
e outros dispositivos de entrada, vias de dados e outras comunicações, atuadores e outros dispositivos
de saída (ver Figura 5)
Figura 5 – Sistema eletrônico programável (PES): estrutura e terminologia
3.2.55
programação
codificação
processo de projetar, escrever e testar um conjunto de instruções para resolver um problema
ou processar dados
Nota 1 de entrada: Na série IEC 61511, programação é normalmente associada aos dispositivos eletrônicos
programáveis (PE).
3.2.56
teste de prova (proof test)
teste periódico executado para detectar falhas perigosas ocultas em um SIS para que, se necessário,
um reparo possa restaurar o sistema para uma condição “como novo” ou o mais próximo possível
dessa condição
3.2.57
camada de proteção
qualquer mecanismo independente que reduza o risco por meio de controle, prevenção ou mitigação
Nota 1 de entrada: Pode ser um mecanismo de engenharia de processo, como o tamanho dos vasos
que contêm produtos químicos perigosos; ou um mecanismo mecânico, como uma válvula de alívio;

ABNT/CB-003
FEV 2024
ou um SIS; ou um procedimento administrativo, como um plano de emergência contra um perigo

iminente. Estas ações podem ser automatizadas ou iniciadas por ações humanas (ver Figura 9).
3.2.58
qualidade
totalidade das características de uma entidade que lhe conferem a capacidade de atender
às necessidades estabelecidas e implícitas
Nota 1 de entrada: Para mais detalhes, ver ABNT NBR ISO 9000.
3.2.59
falha aleatória de hardware
falha que ocorre em um tempo aleatório, resultante de um ou mais possíveis mecanismos
de degradação do hardware
Nota 1 de entrada: Existem muitos mecanismos de degradação que ocorrem a taxas diferentes em diferentes
componentes e como as tolerâncias de fabricação fazem com que os componentes falhem devido a esses
mecanismos após diferentes tempos de operação, as falhas de um equipamento total composto por muitos
componentes ocorrem com taxas previsíveis, mas com tempos imprevisíveis (isto é, aleatórios).
Nota 2 de entrada: Duas diferenças principais distinguem as falhas aleatórias de hardware e as falhas sistemáticas:
— uma falha aleatória de hardware envolve apenas o próprio sistema, enquanto uma falha sistemática envolve
tanto o próprio sistema (uma avaria) como uma condição específica (ver 3.2.81). Então, uma falha aleatória
de hardware é caracterizada por um único parâmetro de confiabilidade (ou seja, a taxa de falha), enquanto
uma falha sistemática é caracterizada por dois parâmetros de confiabilidade (ou seja, a probabilidade
da falha preexistente e a taxa de risco da condição específica);
— uma falha sistemática pode ser eliminada após ser detectada, enquanto falhas aleatórias de hardware
não podem.
Isto implica que os parâmetros de confiabilidade de falhas aleatórias de hardware podem ser
estimados a partir do retorno de informação de campo, embora seja muito difícil fazer isto para
as falhas sistemáticas. Uma abordagem qualitativa é preferida para falhas sistemáticas.
[FONTE: IEC 61508-4:2010, 3.6.5, modificada – As notas foram alteradas]
3.2.60
redundância
existência de mais de um meio para desempenhar uma função requerida ou para representar
informações
Nota 1 de entrada: Exemplos são o uso de dispositivos duplicados e a adição dos bits de paridade.
Nota 2 de entrada: A redundância é utilizada primariamente para aumentar a confiabilidade ou disponibilidade.
[FONTE: IEC 61508-4:2010, 3.4.6]
3.2.61
risco
combinação da probabilidade de ocorrência do dano com a severidade deste dano
Nota 1 de entrada: A probabilidade de ocorrência inclui a exposição a uma situação perigosa,

a ocorrência de um evento perigoso e a possibilidade de evitar ou limitar o dano.

ABNT/CB-003
FEV 2024
3.2.62
falha segura
falha que favorece uma determinada ação de segurança
Nota 1 de entrada: Uma falha é “segura” apenas em relação a uma determinada função de segurança.
Nota 2 de entrada: Quando a tolerância a falhas é implementada, a falha segura pode levar à:
— operação na qual a ação de segurança está disponível, mas com maior probabilidade de sucesso sob
demanda ou menor probabilidade de causar um evento perigoso;
— operação espúria em que a ação de segurança é iniciada.
Nota 3 de entrada: Quando nenhuma tolerância a falhas é implementada, falhas seguras resultam no início
da ação de segurança, independentemente da condição do processo. Isso também é conhecido como parada
de emergência espúria.
Nota 4 de entrada: Uma parada de emergência espúria pode ser segura em relação a uma determinada
função de segurança, mas pode ser perigosa em relação a outra função de segurança.
Nota 5 de entrada: Paradas de emergência espúrias também podem ter efeitos prejudiciais na disponibilidade
do processo de produção.
3.2.63
estado seguro
estado do processo quando a segurança é atingida
Nota 1 de entrada: Alguns estados são mais seguros que outros e, ao passar de uma condição potencialmente
perigosa para o estado seguro final, ou ao passar da condição normal segura para uma condição perigosa,
o processo pode ter que passar por uma série de estados seguros intermediários.
Nota 2 de entrada: Para algumas situações, um estado seguro existe apenas enquanto o processo for
continuamente controlado. Esse controle contínuo pode ocorrer por um período de tempo curto ou indefinido.
Nota 3 de entrada: Um estado seguro em relação a uma determinada função de segurança pode aumentar
a probabilidade de evento perigoso em relação a outra determinada função de segurança. Neste caso,
a frequência média máxima permitida de uma parada de emergência espúria (ver 10.3.2) para a primeira
função pode considerar o aumento potencial do risco associado à outra função.
Nota 4 de entrada: Este termo diverge da IEC 61508-4:2010 para refletir diferenças na terminologia
da indústria de processo.
3.2.64
segurança
livre de riscos que não são toleráveis
Nota 1 de entrada: De acordo com o ISO/IEC Guide 51, os termos “risco aceitável” e “risco tolerável”
são considerados sinônimos.
[FONTE: ISO/IEC Guide 51:2014, 3.14, modificada – A nota foi adicionada]
3.2.65
função de segurança
função a ser implementada por uma ou mais camadas de proteção, que se destina a alcançar
ou manter o estado seguro do processo, em relação a um evento perigoso específico

ABNT/CB-003
FEV 2024
3.2.66
função instrumentada de segurança
SIF
função de segurança a ser implementada por um sistema instrumentado de segurança (SIS)
Nota 1 de entrada: Uma SIF é projetada para atingir um SIL requerido que é determinado em relação
às outras camadas de proteção que participam da redução do mesmo risco.
3.2.67
sistema instrumentado de segurança
SIS
sistema instrumentado utilizado para implementar uma ou mais SIF
Nota 1 de entrada: Um SIS é composto por qualquer combinação de sensor(es), solucionador(es)

lógico(s) e elemento(s) final(is) (por exemplo, ver Figura 6). Também inclui equipamentos auxiliares
e de comunicação (por exemplo, cabos, tubulações, fonte de alimentação, linhas de impulso,
traceamento térmico).
Nota 2 de entrada: Um SIS pode incluir software.
Nota 3 de entrada: Um SIS pode incluir a ação humana como parte de uma SIF (ver ISA TR84.00.04:2015,
Parte 1).
Figura 6 – Exemplo de arquiteturas de SIS compreendendo três subsistemas
3.2.68
integridade de segurança
capacidade de um SIS desempenhar a SIF demandada como e quando necessário
Nota 1 de entrada: Esta definição equivale à confiabilidade do SIS em relação à SIF requerida. A confiabilidade,
sendo muitas vezes entendida como um conceito econômico e não como um conceito de segurança, não tem
sido utilizada para evitar equívoco.
Nota 2 de entrada: A capacidade inclui tanto a resposta funcional (por exemplo, fechar uma válvula específica
dentro de um tempo especificado) quanto a probabilidade de o SIS agir conforme necessário.
Nota 3 de entrada: Ao se determinar a integridade de segurança, todas as causas de falha aleatórias

de hardware e falhas sistemáticas que levam a uma condição insegura podem ser consideradas
(por exemplo, falhas do hardware, falhas induzidas pelo software e falhas devido à interferência elétrica).
Alguns desses tipos de falhas, em particular as falhas aleatórias de hardware podem ser quantificadas
utilizando-se medidas como a frequência média de falhas perigosas ou a probabilidade de falha sob demanda.
No entanto, a integridade de segurança também depende de diversos fatores sistemáticos que não podem
ser precisamente quantificados e são frequentemente considerados qualitativamente durante todo o ciclo
de vida. A probabilidade de falhas sistemáticas resultarem em falhas perigosas do SIS é reduzida pela
tolerância a falhas de hardware (ver 11.4) ou outros métodos e técnicas.

ABNT/CB-003
FEV 2024
Nota 4 de entrada: Integridade de segurança compreende a integridade de segurança do hardware

(ver 3.2.26) e a integridade de segurança sistemática (ver 3.2.82), mas falhas complexas causadas pela
conjunção de hardware e interação sistemática também podem ser consideradas.
3.2.69
nível de integridade de segurança
SIL (Safety Integrity Level)
nível discreto (de um a quatro) atribuído a uma SIF para especificar os requisitos de integridade
de segurança a ser atingido pelo SIS
Nota 1 de entrada: Quanto maior o SIL, menor o PFDavg esperado e menor a frequência média de uma falha
perigosa que causa um evento perigoso.
Nota 2 de entrada: A relação entre a medida do objetivo de falha e o SIL é especificada nas Tabelas 4 e 5.
Nota 3 de entrada: SIL 4 está relacionado ao mais alto nível de integridade de segurança; SIL 1 está
relacionado ao menor.
Nota 4 de entrada: Este termo diverge da IEC 61508-4:2010 para refletir diferenças na terminologia
da indústria de processo.
3.2.69.1
requisitos de integridade de segurança, pl
conjunto de requisitos da ABNT NBR IEC 61511 que devem ser atendidos por um SIS para reivindicar
um determinado SIL para uma SIF implementada por este SIS
Nota 1 de entrada: Os requisitos de integridade de segurança são reforçados quando o SIL relacionado aumenta.
3.2.70
ciclo de vida de segurança do SIS
atividades necessárias envolvidas na implementação da SIF que ocorrem durante um período de tempo
que inicia com a fase conceitual do projeto e termina quando todas as SIF já não estão disponíveis
para uso
Nota 1 de entrada: O termo “ciclo de vida de segurança funcional” é mais exato, porém o adjetivo “funcional”
não é considerado necessário dentro do contexto da série IEC 61511.
Nota 2 de entrada: O modelo de ciclo de vida de segurança do SIS utilizado na ABNT NBR IEC 61511
é apresentado na Figura 7.
3.2.71
manual de segurança
manual de segurança funcional
informação que especifica como o dispositivo de SIS, subsistema ou sistema pode ser utilizado
com segurança
Nota 1 de entrada: O manual de segurança pode incluir informações do fabricante e também do usuário.
Nota 2 de entrada: Para dispositivos compatíveis com a série IEC 61508, a informação do fabricante
é o manual de segurança.
Nota 3 de entrada: Este pode ser um documento independente genérico ou uma coleção de documentos.
Nota 4 de entrada: Esta definição difere da definição da IEC 61508-4:2010 para refletir diferenças
na terminologia do setor de processo.

ABNT/CB-003
FEV 2024
3.2.72
especificação dos requisitos de segurança
SRS
especificação que contém todos os requisitos funcionais das SIF e seus níveis de integridade
de segurança associados
[FONTE: IEC 61508-4:2010, 3.5.11, modificada – Alinhado com a terminologia da ABNT NBR IEC 61511]
3.2.73
sensor
parte do BPCS ou do SIS que pode medir ou detectar as condições do processo
Nota 1 de entrada: Por exemplo, transmissores, transdutores, chaves de processo e chaves de posição.
3.2.74
software
programas, procedimentos, dados, regras e quaisquer documentos pertinentes à operação
de um sistema de processamento de dados
Nota 1 de entrada: O software é independente do meio em que ele é gravado.
Nota 2 de entrada: Para exemplos de diferentes tipos de software, ver 3.2.75 e 3.2.76.
3.2.75
linguagens de programação de aplicativos
3.2.75.1
linguagem de programação fixa
FPL (Fixed Program Language)
linguagem em que o usuário é limitado ao ajuste de alguns conjuntos predefinidos e fixos de parâmetros
Nota 1 de entrada: Exemplos típicos de aplicação de dispositivos utilizando FPL são sensores inteligentes
(por exemplo, transmissores de pressão sem algoritmos de controle), elementos finais inteligentes
(por exemplo, válvula sem algoritmo de controle), pontos de alarme do sequenciador de eventos inteligente
dedicado. O uso de FPL é frequentemente referido como “configuração do dispositivo”.
3.2.75.2
linguagem de variabilidade limitada
LVL (Limited Variability Language)
linguagem de programação para controladores eletrônicos programáveis comerciais e industriais
com uma gama de recursos limitados à sua aplicação, conforme determinado no manual de segurança
associado. A notação desta linguagem pode ser textual ou gráfica ou possuir características de ambas
Nota 1 de entrada: Este tipo de linguagem é projetado para ser facilmente compreendido pelos usuários
do setor de processo e apresenta a capacidade de combinar funções de biblioteca predefinidas e específicas
do aplicativo para implementar a SRS. LVL apresenta uma estreita correspondência funcional com as funções
necessárias para construir a aplicação.
Nota 2 de entrada: A ABNT NBR IEC 61511 assume que as restrições necessárias para atingir
as propriedades de segurança são alcançadas pela combinação do manual de segurança, pela proximidade
das notações da linguagem com as funções que o programador da aplicação precisa para determinar
os algoritmos de controle do processo, e pelo tempo de compilação verificações de tempo de execução que
o provedor incorpora no programa do sistema do solucionador lógico e no seu ambiente de desenvolvimento.
As restrições identificadas no relatório de certificação e no manual de segurança podem assegurar que
os requisitos aplicáveis da IEC 61508-3:2010 estão atendidos.

ABNT/CB-003
FEV 2024
Nota 3 de entrada: LVL é a linguagem mais comumente utilizada quando a série IEC 61511 se refere
a “programa aplicativo”.
3.2.75.3
linguagem de variabilidade completa
FVL (Full Variability Language)s
linguagem concebida para ser compreensível para programadores de computador e que proporcione
a capacidade de implementar uma ampla variedade de funções e aplicativos
Nota 1 de entrada: Exemplo típico de sistemas utilizando FVL são computadores para propósito geral.
Nota 2 de entrada: No setor de processo, FVL é encontrado em software embarcado e raramente em programa
aplicativo.
Nota 3 de entrada: Exemplos de FVL incluem: Ada, C, Pascal, lista de instruções, linguagem assembler, C++,
Java, SQL.
3.2.76
tipos de programa e software
3.2.76.1
programa aplicativo
programa específico à aplicação de usuário contendo, em geral, sequências lógicas, permissões,
limites e expressões que controlam as entradas, saídas, cálculos e decisões necessárias para atender
aos requisitos funcionais do SIS
3.2.76.2
software embarcado
software que faz parte do sistema fornecido pelo fabricante e não é acessível para modificação pelo
usuário final
Nota 1 de entrada: Software embarcado também é chamado firmware ou software de sistema. Ver 3.2.75.3,
variabilidade de linguagem completa.
3.2.76.3
software utilitário
ferramentas de software para a criação, modificação e documentação de programas aplicativos
Nota 1 de entrada: Estas ferramentas de software não são necessárias para a operação do SIS.
3.2.77
ciclo de vida do programa aplicativo
atividades que acontecem durante um período de tempo que começa quando o programa aplicativo
é concebido e termina quando o programa aplicativo é permanentemente descontinuado
Nota 1 de entrada: Um ciclo de vida do programa aplicativo tipicamente, inclui uma fase de requisitos, fase
de desenvolvimento, fase de teste, fase de integração, fase de instalação e fase de modificação.
Nota 2 de entrada: Software, incluindo programa aplicativo, pode não ser mantido, mas sim modificado.
3.2.78
subsistema do SIS
parte independente de um SIS cuja falha perigosa incapacitante resulta em uma falha perigosa
incapacitante do SIS
Nota 1 de entrada: A Figura 6 apresenta um SIS composto por três subsistemas SIS.

ABNT/CB-003
FEV 2024
Nota 2 de entrada: Do ponto de vista da abordagem de corte do conjunto (ver IEC 61025), um corte
mínimo de um subsistema SIS também é um conjunto de corte mínimo de todo o SIS. Consequentemente,
as SIF implementadas em um SIS dependem inteiramente dos subsistemas SIS deste SIS (ou seja, quando
um subsistema do SIS falha, as SIF relacionadas também falham).
3.2.79
sistema
conjunto de dispositivos que interagem de acordo com uma especificação
Nota 1 de entrada: Uma pessoa pode fazer parte de um sistema.
Nota 2 de entrada: Esta definição desvia-se da definição da série IEC 61508 para refletir diferenças
na terminologia do setor de processo.
3.2.80
capabilidade sistemática
medida (expressa em uma escala de SC 1 a SC 4) da confiança de que a integridade de segurança
sistemática de um dispositivo atende aos requisitos do SIL especificado, em relação à função
de segurança especificada, quando o dispositivo é aplicado de acordo com as instruções especificadas
no manual de segurança do dispositivo
Nota 1 de entrada: A capabilidade sistemática é determinada em relação aos requisitos para evitar e controlar
falhas sistemáticas nas IEC 61508-2:2010 e IEC 61508-3:2010.
Nota 2 de entrada: O mecanismo de falha sistemática depende da natureza do dispositivo. Para um dispositivo
composto exclusivamente por hardware, apenas os mecanismos de falha de hardware são considerados.
Para um dispositivo composto por hardware e software, é necessário considerar as interações entre
os mecanismos de falha de hardware e de software.
Nota 3 de entrada: Uma capabilidade sistemática de SC N para um dispositivo significa que a integridade
de segurança sistemática de SC N foi atendida quando o dispositivo é aplicado de acordo com as instruções
especificadas no manual de segurança do dispositivo para SC N.
3.2.81
falha sistemática
falha relacionada a uma falha preexistente, que ocorre consistentemente sob condições particulares,
e que só pode ser eliminada removendo a falha por meio de: modificação do projeto ou do processo
industrial, procedimentos operacionais, documentação ou outros fatores relevantes
Nota 1 de entrada: A causa de falhas sistemáticas de software é conhecida como “bug”.
Nota 2 de entrada: Manutenção corretiva sem modificação, normalmente, não elimina a causa da falha que
envolve a falha sob condições particulares.
Nota 3 de entrada: Uma falha sistemática pode ser reproduzida aplicando-se deliberadamente as mesmas
condições, embora nem todas as falhas reproduzíveis sejam sistemáticas.
Nota 4 de entrada: Exemplos de avarias que levam à falha sistemática incluem erros humanos originados em:
— SRS;
— projeto, fabricação, instalação, operação ou manutenção do hardware;
— projeto ou implementação do software (incluindo programa aplicativo).

ABNT/CB-003
FEV 2024
Nota 5 de entrada: Dispositivos semelhantes projetados, instalados, operados, implementados ou mantidos

da mesma maneira provavelmente conterão as mesmas falhas. Portanto, eles estão sujeitos a falhas
de causa comum quando ocorrem as condições específicas.
3.2.82
integridade de segurança sistemática
parte da integridade de segurança do SIS relacionada a falhas sistemáticas em um modo perigoso
de falha
Nota 1 de entrada: A integridade de segurança sistemática geralmente pode não ser quantificada
(diferentemente da integridade de segurança de hardware).
Nota 2 de entrada: Ver também 3.2.26.
3.2.83
medida de falha-alvo
desempenho requerido da SIF e especificado em termos da probabilidade média de falha
no desempenho da SIF sob demanda para o modo de operação sob demanda ou da frequência
média de uma falha perigosa para o modo de operação contínuo
Nota 1 de entrada: A relação entre as medidas de falhas-alvo é apresentada nas Tabelas 4 e 5.
3.2.84
risco tolerável
nível de risco que é aceito em um determinado contexto baseado nos valores atuais da sociedade
Nota 1 de entrada: Ver IEC 61511-3. 2016, Anexo A.
[FONTE: [ISO/IEC Guide 51:2014, 3.15]
3.2.85
não detectável
não revelada
encoberta
não detectado, não revelado ou não evidente
Nota 1 de entrada: Na ABNT NBR IEC 61511, e exceto quando o contexto sugerir outro significado, o termo
“avarias/falhas perigosas não detectadas” está relacionado a avarias/falhas perigosas não detectadas por
testes de diagnóstico.
3.2.86
validação
confirmação por avaliação e fornecimento de evidências objetivas de que os requisitos específicos
para um uso específico pretendido estão atendidos
Nota 1 de entrada: Na série ABNT NBR IEC 61511, isso significa demonstrar que a(s) SIF e SIS após
a instalação atendem a SRS em todos os aspectos.
3.2.87
verificação
confirmação por avaliação e fornecimento de evidências objetivas de que os requisitos estão atendidos
Nota 1 de entrada: Na série IEC 61511, esta é a atividade que mostra para cada fase pertinente do ciclo
de vida de segurança do SIS, por análise ou testes, que, para entradas específicas, as saídas atendem
a todos os aspectos dos requisitos de segurança para determinada fase.

ABNT/CB-003
FEV 2024
Nota 2 de entrada: Exemplos de atividades de verificação incluem:
— revisões das saídas (documentos de todas as fases do ciclo de vida de segurança) para assegurar
a conformidade com os objetivos e requisitos da fase, considerando as entradas específicas para aquela fase;
— revisões de projeto;
— realização de testes dos produtos projetados para assegurar que eles têm desempenho conforme suas
especificações;
— execução de testes de integração, em que partes diferentes de um sistema são reunidas gradativamente,
e por desempenho de testes ambientais para assegurar que todas as partes trabalham juntas conforme
especificado.
3.2.88
vigilância “watchdog”
combinação de diagnósticos e de um dispositivo de saída (normalmente um interruptor-chave)
para monitorar a correta operação do dispositivo eletrônico programável (PE) e tomar a ação após
a detecção de uma operação incorreta
Nota 1 de entrada: A vigilância watchdog confirma que o sistema de software está operando corretamente
pela inicialização regular de um dispositivo externo (por exemplo, hardware temporizador de watchdog
eletrônico) por um dispositivo de saída controlado pelo software.
Nota 2 de entrada: A vigilância watchdog pode ser utilizada para desenergizar um grupo de saídas
de segurança, quando falhas perigosas forem detectadas, para manter ou levar o processo a um estado
seguro do processo em relação ao evento perigoso. A vigilância watchdog é utilizada para aumentar
o diagnóstico de cobertura on-line do solucionador lógico PE (ver 3.2.13 e 3.2.15).
3.3 Abreviaturas
As abreviaturas utilizadas na ABNT NBR IEC 61511 estão indicadas na Tabela 1. Também estão
incluídas algumas abreviaturas comuns relacionadas à segurança funcional do setor de processos.
Tabela 1 – Abreviaturas utilizadas na ABNT NBR IEC 61511

Abreviaturas Expressão completa
CA/CC Corrente Alternada / Corrente Contínua
AIChe American Institute of Chemical Engineers
ALARP As low as reasonably practicable
ANSI American National Standards Institute
AP Programa aplicativo (Application Program)
BPCS Sistema Básico de Controle de Processos (Basic Process Control System)
CCPS Center for Chemical Process Safety (AIChE)
DC Cobertura de diagnósticos (Diagnostic Coverage)
E/E/PE Electrical/electronic/programmable electronic
EMC Compatibilidade eletromagnética (Electro-Magnetic Compatibility)

ABNT/CB-003
FEV 2024

FAT Teste de Aceitação em Fábrica / TAF (Factory Acceptance Test)
FPL Linguagem de programação fixa (Fixed Program Language)
FSA Avaliação de segurança funcional (Functional Safety Assessment)
Sistema De Gerenciamento De Segurança Funcional (Functional Safety

FSMS
Management System)
FTA Análise da árvore de falhas (Fault Tree Analysis)
FVL Linguagem de variabilidade total (Full Variability Language)
HFT Tolerância à falha de hardware (Hardware Fault Tolerance)
H&RA Avaliação de risco e perigo (Hazard & Risk Assessment)
HMI Interface Humano Máquina (Human Machine Interface)
IEC International Electrotechnical Commission
ISA International Society of Automation
ISO International Organization for Standardization
LVL Linguagem de variabilidade limitada (Limited Variability Language)
MooN Arquitetura de canal “M” de “N” (“M” out of “N” channel architecture)
MPRT Tempo máximo permitido de reparo (Maximum Permitted Repair Time)
MRT Tempo médio de reparo (Mean Repair Time)
MTTR Tempo médio para restauração (Mean Time to Restoration)
NFPA National Fire Protection Association (US)
NP Não programável (Non-Programmable)
OEM Fabricante original do equipamento (Original Equipment Manufacturer)
PE Eletrônica programável (Programmable Electronics)
PES Sistema eletrônico programável (Programmable Electronic System)
Probabilidade de falha perigosa sob demanda (Probability of Dangerous Failure
PFD
on Demand)
Probabilidade média de falha perigosa sob demanda (Average Probability of
PFDavg
dangerous Failure on Demand)
Probabilidade (frequência média de falhas perigosas) de falha por hora
PFH
(Probability (average frequency of dangerous failures) of failure per hour)
pl Plural
PLC Controlador lógico programável (Programmable Logic Controller)
SAT Teste de aceitação em campo (Site Acceptance Test)
SC Capabilidade sistemática (Systematic Capability)

ABNT/CB-003
FEV 2024

SIF Função instrumentada de segurança (Safety Instrumented Function)
SIL Nível de integridade de segurança (Safety Integrity Level)
SIS Sistema Instrumentado de Segurança (Safety Instrumented System)
SRS Especificação dos requisitos de segurança (Safety Requirement Specification)
4 Conformidade com a ABNT NBR IEC 61511-1

Para estar em conformidade com a ABNT NBR IEC 61511-1, deve ser demonstrado que cada um dos
requisitos apresentados nas Seções 5 a 19 foram atendidos, de acordo com os critérios determinados e,
portanto, os objetivos dessas seções foram atendidos.
NOTA BRASILEIRA Para sensores, atuadores e elementos finais de SIS instalados em áreas classificadas
contendo atmosferas explosivas formadas por gases inflamáveis ou poeiras combustíveis, frequentemente
encontradas em indústrias de processo, estes dispositivos devem possuir tipos de proteção “Ex” adequados
à classificação de áreas dos locais de instalação, como por exemplo, segurança intrínseca (Ex “i”) ou uma
combinação de tipos de proteção “Ex”, como segurança aumentada (Ex “e”) e encapsulamento (Ex “m”).
Nos casos de utilização de dispositivos com o tipo de proteção segurança intrínseca, é recomendado que
as respectivas barreiras de proteção (equipamentos associados) sejam instaladas junto ao solucionador
lógico (“logic solver”). Mais informações podem ser encontradas na ABNT NBR IEC 60079-14.
5 Gerenciamento da segurança funcional

5.1 Objetivo
O objetivo dos requisitos da Seção 5 é identificar as atividades de gerenciamento que são necessárias
para assegurar que os objetivos da segurança funcional sejam atendidos.
NOTA A Seção 5 é exclusivamente voltada para a realização e manutenção da segurança funcional

do SIS e é separada e distinta das medidas gerais de saúde e segurança necessárias para a obtenção
da segurança no local de trabalho.
5.2 Requisitos
5.2.1 Geral
A política e a estratégia para alcançar a segurança funcional devem ser identificadas juntamente com
os métodos para avaliar a sua realização e devem ser comunicadas dentro da organização.
5.2.2 Organização e recursos
5.2.2.1 Pessoas, departamentos, organizações ou outras unidades, responsáveis por conduzir

e revisar cada uma das fases do ciclo de vida de segurança do SIS, devem ser identificadas
e informadas das responsabilidades atribuídas a ela.
5.2.2.2 Pessoas, departamentos ou organizações envolvidas nas atividades do ciclo de vida

de segurança do SIS devem ser competentes para conduzir as atividades pelas quais são responsáveis.

ABNT/CB-003
FEV 2024
As seguintes alíneas devem ser abordadas e documentadas ao considerar as competências das

pessoas, departamentos, organizações ou outras unidades envolvidas nas atividades do ciclo de vida
de segurança do SIS:
a) conhecimento em engenharia, treinamento e experiência apropriada para a aplicação do processo;

b) conhecimento em engenharia, treinamento e experiência apropriada na tecnologia aplicada a ser

utilizada (por exemplo, elétrico, eletrônico ou eletrônico programável);
c) conhecimento em engenharia, treinamento e experiência apropriada em sensores e elementos

finais;
d) conhecimento em engenharia de segurança (por exemplo, análise de segurança de processo);
e) conhecimento dos requerimentos legais e regulatórios de segurança funcional;
f) gerenciamento adequado e habilidades de liderança apropriadas para a sua função nas atividades
do ciclo de vida de segurança do SIS;
g) entendimento da consequência potencial de um evento;
h) SIL da SIF;
i) inovação e complexidade da aplicação e da tecnologia;
5.2.2.3 Deve haver um procedimento para gerenciar a competência de todos os envolvidos

no ciclo de vida do SIS. Avaliações periódicas devem ser realizadas para documentar a competência
dos indivíduos em relação às atividades que estão desempenhando e na mudança de um indivíduo
dentro de um cargo.
5.2.3 Avaliação do risco e gerenciamento do risco
Perigos devem ser identificados, riscos avaliados e a redução de risco necessária determinada
conforme especificado na Seção 8.
NOTA Pode ser benéfico considerar também potenciais perdas de capital, por razões econômicas.
5.2.4 Planejamento de segurança
Planejamento de segurança deve existir, de maneira a determinar as atividades requeridas a serem

conduzidas juntamente com as pessoas, departamentos, organizações ou outras unidades responsáveis
por conduzir estas atividades. Este planejamento deve ser atualizado conforme necessário durante
todo o ciclo de vida de segurança do SIS (ver Seção 6) e realizado a um nível de atividade detalhado
proporcional ao papel que o indivíduo ou organização desempenha no ciclo de vida de segurança
do SIS.
NOTA O planejamento de segurança pode ser incorporado em:
— uma seção do plano de qualidade intitulado “Plano do Ciclo de Vida de Segurança do SIS”; ou
— um documento separado intitulado “Plano do Ciclo de Vida de Segurança do SIS”; ou
— vários documentos que incluem procedimentos da companhia ou práticas de trabalho.

ABNT/CB-003
FEV 2024
5.2.5 Implementação e monitoramento
5.2.5.1 Procedimentos devem ser implementados de forma a assegurar acompanhamento imediato

e resolução satisfatória das recomendações provenientes do SIS decorrente de:
a) análises de perigo e avaliações de risco;

b) atividades de garantias;
c) atividades de verificação;
d) atividades de validação;
e) FSA;
f) auditorias de segurança funcional;
g) atividade pós-incidente e pós-acidente.
5.2.5.2 Qualquer fornecedor provendo produtos ou serviços a uma organização, com total
responsabilidade sobre uma ou mais fases do ciclo de vida de segurança do SIS, deve entregar
produtos ou serviços conforme especificado pela organização e deve ter um sistema de gerenciamento
da qualidade. Procedimentos devem existir de forma a demonstrar a adequação do sistema
de gerenciamento da qualidade.
Se um fornecedor fizer qualquer declaração de segurança funcional para um produto ou serviço,

que seja utilizada pela organização para demonstrar conformidade com os requisitos desta Parte
da ABNT NBR IEC 61511, o fornecedor deve ter um sistema de gestão de segurança funcional.
Devem existir procedimentos para demonstrar a adequação do sistema de gestão de segurança funcional.
O sistema de gerenciamento de segurança funcional deve atender aos requisitos da norma básica
de segurança IEC 61508-1:2010, Seção 6, ou aos requisitos de gerenciamento de segurança funcional
da norma derivada da série IEC 61508, à qual são feitas reivindicações de segurança funcional.
5.2.5.3 Procedimentos devem ser implementados para avaliar o desempenho do SIS diante dos
requisitos de segurança para:
● identificar e prevenir falhas sistemáticas que podem prejudicar a segurança;
● monitorar e avaliar se os parâmetros de confiabilidade do SIS estão conforme àqueles assumidos

durante o projeto;
● definir as ações corretivas necessárias a serem tomadas caso as taxas de falha sejam maiores
do que as assumidas durante o projeto;
● comparar a taxa de demanda da SIF durante a operação real com as considerações feitas durante
a avaliação de risco quando os requisitos SIL foram determinados.
5.2.5.4 Para os SIS existentes projetados e construídos de acordo com códigos, padrões ou práticas
anteriores à emissão desta norma, o usuário deve determinar que o equipamento foi projetado,
mantido, inspecionado, testado e está operando de maneira segura.

ABNT/CB-003
FEV 2024
5.2.6 Avaliação, auditoria e revisões
5.2.6.1 Avaliação da segurança funcional (FSA)
5.2.6.1.1 Um procedimento deve ser especificado e executado para uma FSA, de maneira que
um julgamento possa ser feito quanto à segurança funcional e integridade de segurança alcançada
por cada SIF do SIS. O procedimento deve requerer que um time de FSA seja apontado, o qual inclui
as especialidades técnicas, de aplicação e de operações necessárias para a aplicação em particular.
5.2.6.1.2 A composição da equipe de FSA deve incluir no mínimo uma pessoa sênior competente,
não envolvida no time de projeto (para as fases 1, 2 e 3) ou não envolvida na operação e manutenção
do SIS (para as fases 4 e 5).
5.2.6.1.3 O seguinte deve ser considerado ao planejar uma FSA:
— o escopo da FSA;
— quem deve participar na FSA;
— as habilidades, responsabilidades e autoridades do time da FSA;
— a informação gerada como resultado de qualquer atividade da FSA;
— a identidade de quaisquer órgãos de segurança envolvidos na FSA;
— os recursos requeridos para completar a atividade de FSA;
— o nível de independência do time da FSA;
— os métodos os quais a FSA é revalidada após modificações.
NOTA Quando a equipe da FSA for grande, pode ser considerado que tenha mais de um profissional
sênior competente no time e que seja independente do time de projeto.
5.2.6.1.4 Uma equipe de FSA deve revisar o trabalho realizado em todas as fases do ciclo de vida
de segurança antes da fase abrangida pela avaliação que ainda não tenha sido coberta por FSA
anteriores. Se FSA anteriores tiverem sido realizadas, então a equipe da FSA deve considerar
as conclusões e recomendações das avaliações anteriores. Os estágios no ciclo de vida de segurança
do SIS os quais as atividades de FSA são conduzidas devem ser identificadas durante o planejamento
de segurança.
NOTA 1 Atividades adicionais de FSA podem necessitar ser introduzidas na medida em que novos perigos
sejam identificados, após modificação e em intervalos periódicos durante a operação.
NOTA 2 Consideração pode ser dada para conduzir atividades FSA nos seguintes estágios (ver Figura 7).
— Estágio 1 – Após ser conduzida a H&RA, as camadas de proteção terem sido identificadas e a SRS
ter sido desenvolvida.
— Estágio 2 – Após o SIS ter sido projetado.
— Estágio 3 – Após completar a instalação, pré-comissionamento e validação final do SIS e procedimentos

de operação e manutenção tenham sido desenvolvidos.
— Estágio 4 – Após obter experiência em operação e manutenção.
— Estágio 5 – Após a modificação e antes do descomissionamento do SIS.

ABNT/CB-003
FEV 2024
NOTA 3 O número, tamanho e escopo das atividades de FSA podem depender de circunstâncias específicas.
É provável que os fatores nesta decisão incluam:
— tamanho do projeto;
— grau de complexidade;
— nível de integridade de segurança;
— duração do projeto;
— consequência no evento da falha;
— grau de padronização das características de projeto;
— requisitos regulatórios de segurança;
— experiência anterior com um projeto similar;
— consideração a fatores pertinentes como:
● tempo de operação;
● número e escopo das mudanças na operação;
● frequência dos testes de prova.
5.2.6.1.5 Antes dos perigos estarem presentes, o time da FSA deve realizar avaliações de segurança
funcional e confirmar se:
● a H&RA foi realizada (ver 8.1);
● as recomendações provenientes da H&RA que se aplicam ao SIS foram implementadas

ou resolvidas;
● os procedimentos de mudança de projeto estão disponíveis e foram propriamente implementados;
● as recomendações provenientes de qualquer FSA foram resolvidas;
● o SIS está projetado, construído e instalado de acordo com a especificação dos requisitos
de segurança, e quaisquer diferenças foram identificadas e resolvidas;
● os procedimentos de segurança, operação, manutenção e emergência pertencentes ao SIS

estão disponíveis;
● o planejamento de validação do SIS e as atividades de validação foram completados;
● o treinamento do empregado foi realizado e informação apropriada sobre o SIS foi entregue
ao pessoal de operação e manutenção;
● os planos ou estratégias para implementação de futuras FSA estão disponíveis.
5.2.6.1.6 Nos casos em que ferramentas de desenvolvimento de projeto e produção forem utilizadas
para qualquer atividade do ciclo de vida de segurança SIS, estas devem ser sujeitas a uma avaliação
que demonstre que não têm qualquer impacto negativo no SIS ou os resultados das ferramentas
devem ser confirmados por procedimentos de verificação.
NOTA 1 O grau no qual as ferramentas podem ser endereçadas depende do impacto no nível de risco
a ser atingido.

ABNT/CB-003
FEV 2024
NOTA 2 Exemplos de ferramentas de desenvolvimento e produção incluem ferramentas de modelagem

e simulação, equipamento de medição, equipamento de teste utilizado durante atividades de manutenção
e ferramentas de gerenciamento da configuração.
NOTA 3 A garantia da qualidade das ferramentas inclui, mas não está limitada à rastreabilidade dos padrões
de calibração, histórico de operação e lista de defeitos.
5.2.6.1.7 Os resultados da FSA devem estar disponíveis juntamente com qualquer recomendação
vinda desta avaliação.
5.2.6.1.8 Toda a informação pertinente deve ser disponibilizada para o time da FSA sob sua
solicitação.
5.2.6.1.9 Nos casos em que uma FSA é realizada em uma modificação, a avaliação deve considerar
a análise de impacto realizada na modificação proposta e confirmar que o trabalho de modificação
realizado está em conformidade com os requisitos da ABNT NBR IEC 61511.
NOTA Os requisitos do ciclo de vida de segurança (incluindo FSA) relacionados às modificações do SIS
podem ser encontrados em 17.2.3.
5.2.6.1.10 Uma FSA também deve ser realizada periodicamente durante a fase de operação
e manutenção para assegurar que a manutenção e a operação sejam realizadas de acordo com
as suposições feitas durante o projeto e que os requisitos da ABNT NBR IEC 61511 para gerenciamento
e verificação de segurança sejam atendidos.
5.2.6.2 Auditoria e revisão de segurança funcional
5.2.6.2.1 O objetivo da auditoria é revisar documentos e registros de informações para determinar

se o sistema de gestão de segurança funcional (FSMS) está em vigor, atualizado e sendo seguido.
Nos casos em que lacunas forem identificadas, são feitas recomendações de melhorias.
5.2.6.2.2 Todos os procedimentos identificados como necessários, resultantes de todas as atividades

do ciclo de vida de segurança, estão sujeitos à auditoria de segurança.
5.2.6.2.3 A auditoria de segurança funcional deve ser realizada por uma pessoa independente
que não realize trabalhos no SIS a ser auditado. Procedimentos devem ser determinados e executados
para auditar o atendimento com os requisitos, incluindo:
● frequência das atividades de auditoria de segurança funcional;
● grau de independência entre pessoas, departamentos, organizações e outras unidades conduzindo

o trabalho e aqueles conduzindo as atividades de auditoria de segurança funcional;
● atividades de registro e acompanhamento.
5.2.6.2.4 Procedimentos de gerenciamento de mudanças devem estar disponíveis para iniciar,

documentar, revisar, implementar e aprovar mudanças no SIS diferentes da mudança da mesma
espécie (isto é, igual por igual (like-for-like), uma duplicata exata de um elemento ou uma substituição
aprovada que não requer modificação no SIS conforme instalado).
5.2.6.2.5 Devem existir procedimentos de gerenciamento de mudanças que identifiquem mudanças

que afetarão os requisitos do SIS (por exemplo, reprojeto de um BPCS, mudanças na operação
em uma determinada área).

ABNT/CB-003
FEV 2024
5.2.7 Gerenciamento da configuração do SIS
5.2.7.1 Procedimentos para gerenciamento da configuração do SIS durante as fases do ciclo de vida
de segurança devem estar disponíveis.
NOTA Em particular, o seguinte pode ser especificado:

● estágio no qual um gerenciamento de configuração formal deve ser implementado;
● procedimentos a serem utilizados para unicamente identificar todos os componentes de um SIS ou de um

subsistema SIS (por exemplo, dispositivos, programação de aplicativos);
● procedimentos para prevenção de dispositivos não autorizados entrarem em serviço.
5.2.7.2 O software, o hardware e os procedimentos do SIS utilizados para desenvolver e executar

o programa aplicativo devem estar sujeitos ao gerenciamento de configuração e devem ser mantidos
sob controle de revisão.
NOTA O software do SIS inclui programas aplicativos (por exemplo, em solucionadores lógicos);
software embarcado (por exemplo, sensores, solucionadores lógicos, elementos finais); software utilitário
(ferramentas).
6 Requisitos do ciclo de vida de segurança

6.1 Objetivos
Os objetivos da Seção 6 são:
● determinar as fases e estabelecer os requisitos das atividades do ciclo de vida de segurança

do SIS,
● determinar e organizar as atividades técnicas em um ciclo de vida de segurança do SIS,
● assegurar que exista um planejamento adequado (ou está desenvolvido) que torne certo de que
o SIS atenda aos requisitos de segurança.
NOTA 1 A abordagem geral da ABNT NBR IEC 61511 é apresentada na Figura 7. Pode ser ressaltado que
esta abordagem é somente para ilustração e serve apenas para indicar as atividades típicas do ciclo de vida
de segurança do SIS, desde a concepção inicial até o seu descomissionamento.

ABNT/CB-003
FEV 2024
Figura 7 – Fases do ciclo total de vida de segurança do SIS e estágios de FSA
NOTA 2 As informações da Figura 7 podem fluir da operação e manutenção de volta aos estágios anteriores
do ciclo de vida para refletir o rastreamento de incidentes e falhas e para verificar suposições de engenharia.

ABNT/CB-003
FEV 2024
6.2 Requisitos
6.2.1 Um ciclo de vida de segurança do SIS incorporando os requisitos da série IEC 61511 deve
ser determinado durante o planejamento de segurança. O ciclo de vida de segurança também deve
abordar a programação do aplicativo (ver 6.3.1).
6.2.2 Cada fase do ciclo de vida de segurança do SIS deve ser determinada em termos de suas
entradas, saídas e atividades de verificação (ver Tabela 2).
Tabela 2 – Visão geral do ciclo de vida de segurança do SIS (continua)

Atividade ou fase do ciclo
de vida de segurança
Seção dos
Número da Objetivos Entradas Saídas
requisitos
caixa da Título
Figura 7
Determinar os perigos
e eventos perigosos
do processo e dos
equipamentos associados,
a sequência dos
Uma descrição dos
acontecimentos que Projeto do Processo,
perigos, das funções
levaram a eventos arranjo, disposições
de segurança
1 H&RA perigosos, os riscos de 8 de operação,
requeridas e a
processos associados objetivos de
redução de risco
com o evento perigoso, os segurança.
associada.
requisitos para a redução
de risco e as funções de
segurança necessárias para
atingir a redução de risco
necessária.
Uma descrição
Alocação das funções de da SIF requerida Descrição da
Alocação das funções
proteção nas camadas de e seus requisitos atribuição dos
2 de proteção nas 9
proteção e o SIL associado de integridade requisitos de
camadas de proteção
a cada SIF. de segurança segurança.
associados.
Especificar os requisitos
Requisitos de
para cada SIS, em termos Descrição da
Especificação segurança do
das SIF e suas integridades alocação dos
3 dos requisitos de 10 SIS; requisitos
de segurança associadas, requisitos de
Segurança do SIS de segurança do
para atingir a segurança segurança.
programa aplicativo.
funcional necessária.
Projeto do hardware e
Requisitos de do programa aplicativo
segurança do SIS. do SIS de acordo
Projetar o SIS para atender
Projeto e engenharia com os requisitos de
4 aos requisitos das SIF e da 11 e 12 Requisitos de
do SIS segurança do SIS;
integridade de segurança. segurança de planejamento para
programa aplicativo. teste de integração
do SIS.

ABNT/CB-003
FEV 2024
Tabela 2 (conclusão)
Atividade ou fase do ciclo
de vida de segurança
Seção dos
requisitos
caixa da Título
Figura 7
Funcionamento
completo do SIS
Integrar e testar o SIS. Projeto do SIS. de acordo com
os requisitos de
Validar que o SIS atende Plano de teste de segurança do SIS.
Comissionamento da em todos os aspectos os integração do SIS.
requisitos para segurança Resultados dos testes
5 instalação e validação 14 e 15 Requisitos de
nos termos das SIF de integração do SIS.
do SIS segurança do SIS.
requeridas e das suas Resultados
integridades de segurança Plano para validação da instalação,
associadas. de segurança do SIS. comissionamento
e atividades da
validação.
Assegurar que a segurança Requisitos do SIS. Resultados

Operação e funcional do SIS é mantida Projeto do SIS. das atividades
6 16
manutenção do SIS durante a operação e a Plano para operação de operação e
manutenção. e manutenção do SIS. manutenção.
Realizar correções,
melhorias ou adaptações do Requisitos de
Resultados da
7 Modificação do SIS SIS, assegurando que o SIL 17 segurança do SIS
modificação do SIS.
requerido seja alcançado e revisados.
mantido
Requisitos de
Assegurar a revisão
segurança conforme
adequada, a organização FIS retirada de
8 Descomissionamento 18 construído e
do setor e assegurar que a serviço.
informação do
FIS continue apropriada.
processo.
Testar e avaliar as saídas

de uma determinada fase
para assegurar a exatidão Plano de verificação Resultados da
9 Verificação do SIS e a consistência no que 7 e 12.5 do SIS para cada verificação do SIS
diz respeito aos produtos e fase. para cada fase.
padrões fornecidos como
entrada para esta fase.
Investigar e obter um Planejamento para

julgamento sobre a FSA do SIS. Resultados da FSA
10 FSA do SIS 5
segurança funcional Requisitos de do SIS.
alcançada pelo SIS. segurança do SIS.
Estrutura e Para estabelecer como as

11 planejamento do ciclo etapas do ciclo de vida são 6.2 Não aplicável. Plano de segurança.
de vida de segurança realizadas.
6.2.3 Para todas as fases do ciclo de vida de segurança do SIS, deve ser desenvolvido
um planejamento de segurança para determinar as atividades, os critérios, as técnicas, as medidas,
os procedimentos e as organizações/pessoas responsáveis por:
● assegurar que os requisitos de segurança do SIS sejam alcançados para todos os modos
pertinentes do processo; isto inclui os requisitos de funções e de integridade de segurança;
● assegurar a instalação e comissionamento corretos do SIS;
● assegurar a integridade de segurança das SIF após a instalação;

ABNT/CB-003
FEV 2024
● manter a integridade da segurança durante a operação (por exemplo, testes de prova, análise
de falhas);
● gerenciar os riscos de processo durante atividades de manutenção no SIS.
6.2.4 Se, em qualquer estágio do ciclo de vida de segurança, for necessária uma alteração
referente a uma fase anterior do ciclo de vida, então essa fase anterior do ciclo de vida de segurança
do SIS e as fases subsequentes devem ser reexaminadas, alteradas conforme necessário
e novamente verificadas.
6.3 Requisitos do ciclo de vida de segurança do programa aplicativo SIS
6.3.1 Cada fase do ciclo de vida de segurança do programa aplicativo (ver Figura 8) deve ser
determinada em termos de suas atividades elementares, objetivos, informações de entrada necessárias,
resultados de saída e requisitos de verificação (ver Tabela 3).
Figura 8 – Ciclo de vida de segurança do programa aplicativo e sua relação com o ciclo
de vida de segurança do SIS

ABNT/CB-003
FEV 2024
Tabela 3 – Ciclo de vida de segurança do programa aplicativo – Visão geral (continua)

Fase do ciclo de vida de
segurança
Seção dos
requisitos
caixa da Título
Figura 8
Especificar os requisitos
de segurança do Requisitos de Especificação
programa aplicativo para segurança do SIS. dos requisitos
Requisitos de cada SIS necessários de segurança do
segurança 10.3 Manuais de
10.3.2 para implementar a SIF programa aplicativo
do programa requerida. 11.5 segurança do SIS do SIS.
aplicativo selecionado.
Especificar os requisitos do Informações de
programa aplicativo de cada Arquitetura do SIS. verificação.
SIF alocada a esse SIS.
Planejamento Planeamento
Requisitos de da validação de
de validação Desenvolver um plano de
15.2.2, segurança do segurança do SIS.
15.2.2 de segurança validação do programa
15.2.5 programa aplicativo
do programa aplicativo. Informações de
do SIS.
aplicativo verificação.
Descrição do projeto
de arquitetura, por
Arquitetura. exemplo, segregação
do programa de
Criar uma arquitetura de aplicação em
programa aplicativo que subsistemas de
atenda aos requisitos processo relacionados
especificados para e SIL, por exemplo,
Requisitos de
segurança do programa reconhecimento
segurança do
aplicativo. de módulos de
Desenvolvimento 12.1 programa aplicativo
12.1 a 12.3 de programa Revisar e avaliar os do SIS. programas de
(também
aplicativo requisitos impostos ao aplicação comuns,
10.3, 12.2) Restrições de projeto
programa aplicativo pela como sequências de
de arquitetura de
arquitetura de hardware do bombas ou válvulas.
hardware do SIS.
SIS. Arquitetura do
Especificar os programa aplicativo
procedimentos para o e requisitos de teste
desenvolvimento do de integração de
programa aplicativo. subsistemas.
Informações de
verificação.
Projeto do programa
Desenvolver o projeto do Requisitos de
aplicativo.
programa aplicativo. segurança do
programa aplicativo Procedimentos
Identificar um conjunto para uso durante a
do SIS.
Projeto do adequado de ferramentas programação.
de configuração, biblioteca, Descrição do projeto
programa 12.3 de arquitetura. Descrição das funções
aplicativo gerenciamento e simulação
da biblioteca-padrão
e ferramenta de teste, ao Manuais do SIS.
(fabricantes) a ser
longo do ciclo de vida de Manual de segurança utilizada.
segurança do programa do solucionador lógico
aplicativo. Informação da
SIS selecionado.
verificação.

ABNT/CB-003
FEV 2024
Tabela 3 (conclusão)
Fase do ciclo de vida de
segurança
Seção dos
requisitos
caixa da Título
Figura 8
Programa aplicativo
Desenvolvimento (por exemplo,
de aplicativos e diagramas de blocos
desenvolvimento de de funções, lógica
módulos de aplicativos. Descrição do projeto. ladder).
Implementar um programa Lista de manuais e Simulação do
Implementação 12.4
12.4 aplicativo que atenda aos procedimentos do programa aplicativo e
do programa 12.3.4 solucionador lógico teste de integração.
12.6 requisitos especificados
aplicativo 12.6 selecionado para
para segurança da Requisitos de
aplicação. uso com o programa
segurança do
aplicativo.
Utilizar ferramentas de programa aplicativo
suporte e linguagens de para fins especiais.
programação adequadas. Informação da
verificação.
Simulação de
Verificar se os requisitos Resultados dos
programas aplicativos
de segurança do programa testes do programa
e requisitos de
aplicativo foram atendidos. aplicativo.
testes de integração
12.5 Verificação Mostrar que todos os 12.5 (testes baseados em Sistema de programa
do programa programas aplicativos do estrutura).
7.2.2 7.2.2 aplicativo verificado e
aplicativo SIS interagem corretamente
Requisitos de teste testado.
para executar as funções
de integração da Informação da
pretendidas e não executam
arquitetura do verificação.
funções não intencionais.
programa aplicativo.
Integrar o programa
Requisitos de teste Resultados dos testes
aplicativo no solucionador
de integração do de integração do
Teste de lógico alvo, incluindo
13 13 programa aplicativo programa aplicativo
integração do SIS interação com um conjunto
e do solucionador e do solucionador
de amostras de dispositivos
lógico. lógico.
de campo ou simulador.
6.3.2 Métodos, técnicas e ferramentas devem ser aplicados para cada fase do ciclo de vida,
de acordo com 12.6.2.
6.3.3 Cada fase do ciclo de vida de segurança do SIS para a qual o planejamento de segurança
foi realizado deve ser verificada (ver Seção 7) e os resultados devem estar disponíveis conforme
descrito na Seção 19.
7 Verificação
7.1 Objetivo
O objetivo da Seção 7 é demonstrar, por meio de revisão, análise e/ou testes, que as saídas
necessárias atendem aos requisitos determinados para as fases apropriadas (Figura 7) do ciclo
de vida de segurança conforme identificados pelo plano de verificação.
7.2 Requisitos
7.2.1 O plano de verificação deve ser realizado durante todo o ciclo de vida de segurança do SIS
e deve definir todas as atividades necessárias para a fase adequada (Figura 7) do ciclo total de vida

ABNT/CB-003
FEV 2024
de segurança do SIS, incluindo o programa aplicativo. Ele deve estar em conformidade com a série
IEC 61511, abordando o seguinte:
● atividades de verificação;
● procedimentos, medidas e técnicas a serem utilizadas para a verificação, incluindo a implementação

e resolução de recomendações decorrentes;
● quando estas atividades acontecerão;
● as pessoas, departamentos e organizações responsáveis por estas atividades, incluindo os níveis

de independência;
● identificação de itens a serem verificados;
● identificação das informações contra a qual a verificação é realizada;
● adequação das saídas em relação aos requisitos dessa fase;
● exatidão dos dados;
● como lidar com não conformidades;
● ferramentas de apoio e análise;
● integralidade da implementação do SIS e rastreabilidade dos requisitos;
● legibilidade e capacidade de auditoria da documentação;
● capacidade de teste do projeto.
7.2.2 Quando a verificação incluir testes, o planejamento de verificação também deve abordar
o seguinte:
● estratégia de integração de programas aplicativos e hardware e dispositivos de campo, incluindo

a integração de subsistemas que devem atender a outros padrões (como máquinas ou caldeiras);
● escopo do teste (descreve a configuração do teste e o tipo de teste a ser realizado, incluindo
o hardware, a programação do aplicativo e os dispositivos de programação a serem incluídos);
● casos de teste e dados de teste (serão cenários específicos com os dados associados);
● tipos de testes a serem realizados;
● ambiente de teste incluindo ferramentas, hardware, todo o software e configuração necessária;
● critérios de teste (por exemplo, critérios de aprovação/reprovação) nos quais os resultados

do teste serão avaliados;
● procedimentos para ação corretiva em caso de falha durante o teste;
● localização(ões) física(s) (por exemplo, fábrica ou campo);
● dependência de funcionalidades externas;

ABNT/CB-003
FEV 2024
● pessoal apropriado;
● gerenciamento de mudança;
● não conformidades.
7.2.3 Funções que não são de segurança integradas com funções de segurança devem ser
verificadas quanto à não interferência com as funções de segurança.
7.2.4 A verificação deve ser executada de acordo com o plano de verificação.
7.2.5 Durante os testes, qualquer modificação deve ser submetida a uma análise de impacto
que determina todos os componentes do SIS impactados e as atividades de reverificação necessárias.
7.2.6 Os resultados do processo de verificação devem estar disponíveis (ver Seção 19), inclusive
se o objetivo e os critérios dos testes forem atendidos.
NOTA 1 Seleção de técnicas e medidas para o processo de verificação e do grau de independência

dependem de uma série de fatores, incluindo grau de complexidade, inovação do projeto, inovação
da tecnologia e o SIL requerido.
NOTA 2 Exemplos de algumas atividades de verificação incluem revisões de projeto, utilização

de ferramentas e técnicas incluindo ferramentas de verificação de software e ferramentas de análise
de projeto baseadas em computador.
8 H&RA de processo
8.1 Objetivos
Os requisitos da Seção 8 tem por objetivo determinar:
● os perigos e eventos perigosos do processo e do equipamento associado;
● a sequência de eventos que levam ao evento perigoso;
● os riscos de processo associados com o evento perigoso;
● quaisquer requisitos para redução de riscos;
● as funções de segurança necessárias para atingir a redução de risco necessária;
● se alguma das funções de segurança é SIF.
NOTA 1 A Seção 8 é dirigida a engenheiros de processo, especialistas de perigo e risco, gestores

de segurança bem como a engenheiros de instrumentação. O propósito é reconhecer a abordagem
multidisciplinar normalmente necessária para a determinação de uma SIF.
NOTA 2 Nos casos em que for razoavelmente praticável, os processos podem ser projetados para serem
inerentemente seguros. Quando isto não for praticável, outras camadas de proteção (ver Figura 9) podem
ser necessárias. Em algumas aplicações, as normas das indústrias podem indicar a utilização de camadas
de proteção específicas.
NOTE 3 A redução do risco pode ser conseguida utilizando várias camadas de proteção (ver Seção 9).

ABNT/CB-003
FEV 2024
8.2 Requisitos
8.2.1 Uma H&RA deve ser realizada sobre os materiais, o processo e os seus equipamentos.
Esta deve resultar em:
● descrição de cada evento perigoso identificado e os fatores que contribuem para isto;
● descrição das consequências e probabilidade do evento perigoso;
● considerações de modos de operação do processo, como operação normal, partida, parada,

manutenção, anormalidades de processo e parada de emergência;
● determinação de redução de risco adicional necessária para alcançar a segurança funcional

requerida;
● descrição sobre as medidas tomadas para reduzir ou eliminar os perigos e riscos;
● descrição detalhada das suposições feitas durante a análise dos riscos, incluindo taxas
de demanda das camadas de proteção e a frequência média de falhas perigosas dos eventos
iniciadores, e de qualquer crédito tomado por restrições operacionais ou por intervenção humana;
● identificação daquelas funções de segurança aplicadas como SIF.
NOTA 1 Na determinação dos requisitos de integridade de segurança, pode ser considerado o efeito
da causa comum entre os sistemas que criam demandas e as camadas de proteção que são projetadas
para responder a essas demandas. Um exemplo disto seria nos casos em que podem surgir demandas
por falha no BPCS e nos equipamentos utilizados nas camadas de proteção idêntica ou similar ao equipamento
utilizado no BPCS. Nesses casos, a demanda causada por uma falha de equipamentos no BPCS pode não
ser respondida de forma eficaz se uma causa comum tornou o equipamento similar na camada de proteção
ineficaz. Pode não ser possível reconhecer as causas de problemas comuns durante a identificação dos
perigos e a análise de risco inicial, pois, nesta fase tão precoce, a concepção da camada de proteção
não necessariamente foi concluída. Nestes casos, será necessário rever os requisitos de integridade
de segurança e da SIF assim que o projeto do SIS e das outras camadas de proteção tiver sido concluída.
Ao determinar se o projeto geral do processo e camadas de proteção atendem aos requisitos, as falhas
de causa comum devem ser consideradas.
NOTA 2 Exemplos de técnicas que podem ser utilizadas para determinar os SIL requeridos de SIF são
apresentados na IEC 61511-3:2016.
8.2.2 A frequência média de falha perigosa do BPCS como evento iniciador não pode ser assumida
como sendo <10-5 por hora.
8.2.3 A H&RA deve ser registrada de forma que a relação entre os requisitos acima indicados seja
clara e rastreável.
NOTA 1 Os requisitos acima indicados não tornam mandatório que os requisitos de integridade de segurança
têm de ser atribuídos como valores numéricos. Também podem ser utilizadas abordagens qualitativas
ou semiquantitativas (ver IEC 61511-3:2016, Anexos C, D e E).
NOTA 2 Os requisitos de integridade de segurança variam dependendo da aplicação e de requisitos legais

nacionais. Um princípio aceito em muitos países é o de que medidas adicionais de redução de risco podem
ser aplicadas até que o custo se torne desproporcional à melhoria na integridade da segurança atingida.
8.2.4 Deve ser realizada uma avaliação de riscos de segurança física e cibernética para identificar
as vulnerabilidades da segurança física e cibernética do SIS. Isso deve resultar em:

ABNT/CB-003
FEV 2024
● uma descrição dos dispositivos abrangidos por esta avaliação de risco (por exemplo, SIS, BPCS
ou qualquer outro dispositivo conectado ao SIS);
● uma descrição das ameaças identificadas que podem explorar vulnerabilidades e resultar em eventos
de segurança física e cibernética (incluindo ataques intencionais ao hardware, programas
aplicativos e software relacionados, bem como eventos não intencionais resultantes de erro humano);
● uma descrição dos potenciais consequências resultantes dos eventos de segurança física
e cibernética e da probabilidade de ocorrência desses eventos;
● consideração de diversas fases, como projeto, implementação, comissionamento, operação

e manutenção;
● determinação de requisitos para redução adicional de riscos;
● uma descrição ou referências a informações sobre as medidas tomadas para reduzir ou eliminar
as ameaças.
NOTA 1 As orientações relacionadas à segurança cibernética do SIS são fornecidas nas ISA TR84.00.09,
ISO/IEC 27001:2013 e IEC 62443-2-1:2010.
NOTA 2 A informação e o controle das condições de limite necessárias para a avaliação de riscos
de segurança física e cibernética estão normalmente com o proprietário/empresa operadora de uma
instalação, e não com o fornecedor. Neste caso, a obrigação de cumprir o descrito em 8.2.4 pode ser
do proprietário/empresa operadora da instalação.
NOTA 3 A avaliação de riscos de segurança física e cibernética do SIS pode ser incluída em uma avaliação
geral de riscos de segurança física e cibernética de automação de processos.
NOTA 4 A avaliação de riscos de segurança física e cibernética do SIS pode variar em foco, desde uma SIF
individual até todos os SIS de uma empresa.
NOTA BRASILEIRA De acordo com a IEC 62511-1 (Power systems management and associated
information exchange – Data and communications security – Part 1: Communication network and system
security – Introduction to security issues), as ameaças à segurança geralmente são vistas como potenciais
ataques contra ativos. Esses ativos podem ser equipamentos físicos, hardware de computador, edificações
e até mesmo pessoas. No mundo cibernético, os ativos também incluem informações, bases de dados
e aplicações de software. Portanto, as contramedidas às ameaças à segurança devem incluir proteção tanto
contra-ataques físicos e funcionais como contra-ataques cibernéticos.
9 Alocação de funções de segurança às camadas de proteção

9.1 Objetivos
Os requisitos da Seção 9 tem por objetivo determinar:
● alocar funções de segurança nas camadas de proteção;
● determinar as SIF necessárias;
● determinar, para cada SIF, o nível de integridade de segurança associado.
NOTA 1 Podem ser considerados, durante o processo de alocação, outros códigos ou normas da indústria.
NOTA 2 Os requisitos de integridade para cada SIF podem incluir a redução de risco associada, PFD, PFH ou SIL.

ABNT/CB-003
FEV 2024
9.2 Requisitos do processo de alocação
9.2.1 O processo de alocação deve resultar em:
● alocação de funções de segurança requeridas para atingir a redução de risco necessária para
as camadas de proteção específicas;
● alocação de redução de riscos ou frequência média de falhas perigosas para cada SIF.
NOTA Requisitos legais ou outros códigos da indústria podem influenciar no processo de alocação.
9.2.2 O SIL requerido para uma SIF deve ser derivado considerando a PFD ou PFH requerida a ser
fornecida pela SIF.
NOTA Outras orientações podem ser encontradas na IEC 61511-3:2016.
9.2.3 Para cada SIF operando no modo de demanda, o SIL requerido deve ser especificado
de acordo com a Tabela 4 ou a Tabela 5.
9.2.4 Para cada SIF operando no modo contínuo, o SIL requerido deve ser especificado de acordo
com a Tabela 5.
Tabela 4 – Requisitos de integridade de segurança: PFDavg

MODO DE DEMANDA DE OPERAÇÃO
Nível de integridade Redução de risco
PFDavg
de segurança (SIL) requerida
4 ≥ 10-5 a < 10-4 > 10 000 a ≤ 100 000
3 ≥ 10-4 a < 10-3 > 1 000 a ≤ 10 000
2 ≥ 10-3 a < 10-2 > 100 a ≤ 1 000
1 ≥ 10-2 a < 10-1 > 10 a ≤ 100
Tabela 5 – Requisitos de integridade de segurança: frequência média de falhas perigosas da SIF

MODO CONTÍNUO OU MODO DE DEMANDA DE OPERAÇÃO
Nível de integridade de segurança Frequência média de falhas perigosas
(SIL) (falhas por hora)
4 ≥ 10-9 a < 10-8
3 ≥ 10-8 a < 10-7
2 ≥ 10-7 a < 10-6
1 ≥ 10-6 a < 10-5
NOTA 1 Outras orientações sobre os modos de operação podem ser encontradas em 3.2.39.
NOTA 2 O SIL é definido numericamente, apresentando então uma medida objetiva para comparação
de projetos e soluções alternativas. No entanto, é reconhecido que, devido ao estágio atual de conhecimento,
muitas causas sistemáticas de falhas somente podem ser avaliadas qualitativamente.

ABNT/CB-003
FEV 2024
NOTA 3 A frequência média requerida de falhas perigosas para uma SIF de modo contínuo ou demanda
é determinada considerando o risco causado pela falha da SIF atuando de modo contínuo ou demanda
em conjunto com a falha de outros dispositivos que levam ao mesmo risco, considerando a redução de riscos
fornecida por outras camadas de proteção.
9.2.5 Nos casos em que o processo de alocação resultar em um requisito de redução de risco
de >10 000 ou frequência média de falhas perigosas <10-8 por hora para um único SIS ou vários
SIS ou um SIS em conjunto com uma camada de proteção BPCS, deve haver uma reconsideração
da aplicação (por exemplo, processo, outras camadas de proteção) para determinar se algum dos
parâmetros de risco pode ser modificado de modo que o requisito de redução de risco de >10 000
ou a frequência média de falhas perigosas <10-8 por hora seja evitado. A revisão deve considerar se:
— o processo ou os vasos/tubulações podem ser modificados para remover ou reduzir os perigos

na fonte;
— os sistemas adicionais relacionados com a segurança ou outros meios de redução dos riscos,
não baseados em instrumentação, podem ser introduzidos;
— a gravidade da consequência pode ser reduzida, por exemplo, reduzindo a quantidade

de materiais perigosos;
— a probabilidade da consequência especificada pode ser reduzida, por exemplo, reduzindo

a probabilidade da fonte iniciadora do evento perigoso.
NOTA Aplicações que requerem a utilização de uma única SIF com um requisito de redução de risco
>10 000 ou frequência média de falhas perigosas <10-8 por hora precisam ser evitadas devido à dificuldade
em alcançar e manter níveis tão elevados de desempenho em todo o SIS ciclo de vida da segurança.
O requisito de redução de risco >10 000 ou frequência média de falhas perigosas <10-8 por hora pode
requerer altos níveis de competência e altos níveis de cobertura para todos os testes de aceitação de fábrica,
testes de prova, verificação e atividades de validação.
9.2.6 Se, após uma análise mais aprofundada da aplicação e confirmação, um requisito de redução
de risco >10 000 ou frequência média de falhas perigosas <10-8 por hora ainda for necessário, então
recomenda-se considerar o cumprimento do requisito de integridade de segurança usando um número
de camadas de proteção (por exemplo, SIS ou BPCS) com requisitos de redução de risco mais baixos.
Se a redução do risco for alocada a múltiplas camadas de proteção, essas camadas de proteção
devem ser independentes ou a falta de independência deve ser avaliada e demonstrada como
sendo suficientemente baixa em comparação com os requisitos de redução de risco. Os seguintes
fatores devem ser considerados durante esta avaliação:
— causa comum de falha do SIS e a causa da demanda;
NOTA 1 A extensão da causa comum pode ser avaliada considerando a diversidade de todos os dispositivos
em que a falha pode causar uma demanda e todos os dispositivos da camada de proteção do BPCS e/ou
do SIS utilizados para redução de risco.
NOTA 2 Um exemplo de causa comum entre o SIS e a causa da demanda é se a perda de controle
do processo por falha ou avaria do sensor puder causar uma demanda e o sensor utilizado para controle for
do mesmo tipo que o sensor utilizado para o SIS.
— causa comum de falha com outras camadas de proteção que proporcionam a redução de risco;
NOTA 3 A extensão da causa comum pode ser avaliada considerando a diversidade de todos os dispositivos
da camada de proteção do BPCS ou do SIS utilizados para atingir os requisitos de redução de risco.

ABNT/CB-003
FEV 2024
NOTA 4 Um exemplo de causa comum entre SIS que apresenta uma redução de risco é quando dois SIS
separados e independentes, com medições diversas e solucionadores lógicos diversos, são utilizados, mas
os dispositivos de atuação final são duas válvulas de corte de emergência de tipos semelhantes ou uma
única válvula de corte de emergência acionada por ambos os SIS.
— quaisquer dependências que possam ser introduzidas por operações comuns, manutenção,
inspeção ou atividades de teste ou por procedimentos de teste de prova e tempos de testes
de prova comuns;
NOTA 5 Mesmo que as camadas de proteção sejam diversas, os testes de prova síncronos reduzirão
a redução geral do risco alcançada e isso pode ser um fator significativo que impede a obtenção da redução
de risco necessária para o evento perigoso.
NOTA 6 Quando são necessários altos níveis de redução de risco e os testes de prova são dessincronizados
de acordo com a Nota 5, então o fator dominante normalmente é falha de causa comum, mesmo que múltiplas
camadas de proteção independentes sejam utilizadas para reduzir o risco. A dependência dentro e entre
as camadas de proteção, proporcionando redução do risco para o mesmo evento perigoso, pode ser avaliada
e demonstrada como suficientemente baixa.
9.2.7 Se for implementado um requisito de redução de risco >10 000 ou uma frequência média de
falhas perigosas <10-8 por hora, quer seja atribuído a um único SIS ou a múltiplos SIS ou um SIS
em conjunto com uma camada de proteção BPCS, então uma avaliação de risco adicional deve ser
realizada utilizando uma metodologia quantitativa para confirmar se os requisitos de integridade
de segurança são alcançados. A metodologia deve considerar a dependência e as falhas de causa
comum entre o SIS e:
— qualquer outra camada de proteção cuja falha possa impor-lhe uma demanda;
— qualquer outro SIS que reduza a probabilidade do evento perigoso;
— quaisquer outros meios de redução de risco que reduzam a probabilidade do evento perigoso
(por exemplo, alarmes de segurança).
9.2.8 Se a redução de risco requerida para um evento perigoso for alocada a várias SIF em um único
SIS, então o SIS deve atender ao requisito geral de redução de risco.
9.2.9 Os resultados do processo de alocação devem ser registrados de forma que as SIF sejam
descritas em termos das necessidades funcionais do processo, por exemplo, as ações a serem
tomadas, pontos de ajuste, tempos de reação, atrasos na ativação, tratamento de falhas, requisitos
para fechamento de válvula, e em termos dos requisitos de redução de risco.
NOTA Esta descrição pode estar em uma forma lógica inequívoca e pode ser chamada de especificação
de requisitos do processo ou descrição de segurança. A descrição pode deixar clara a intenção e a abordagem
utilizada no processo de alocação. A especificação de requisitos do processo é utilizada como informação
de entrada para o SRS abordado na Seção 10 e pode ser suficientemente detalhado para assegurar
especificações adequadas do SIS e dos seus dispositivos. Por exemplo, a descrição pode incluir os pontos
de ajuste dos sensores, o tempo de segurança do processo disponível para resposta e os requisitos
de fechamento da válvula.
9.3 Requisitos do sistema de controle básico de processo como uma camada

de proteção
9.3.1 O sistema de controle básico de processo pode ser reivindicado como uma camada
de proteção, conforme apresentado na Figura 9.

ABNT/CB-003
FEV 2024
Figura 9 – Camadas de proteção típicas e meios de redução de riscos
9.3.2 O fator de redução de risco reivindicado para um BPCS como uma camada de proteção deve
ser ≤ 10.
NOTA Pode-se considerar o fato de que um BPCS também pode ser a fonte iniciadora da demanda
de uma camada de proteção.
9.3.3 Se um fator de redução de risco > 10 for reivindicado para uma camada de proteção BPCS,
então este deve ser projetado e gerenciado para os requisitos dentro da série IEC 61511.
9.3.4 Caso não seja pretendido que o BPCS esteja em conformidade com a série IEC 61511, então:
● não mais do que uma camada de proteção BPCS deve ser reivindicada para a mesma sequência
de eventos que leve ao evento perigoso quando o BPCS for a fonte inicial da demanda na camada
de proteção; ou
● não mais do que duas camadas de proteção do BPCS devem ser reivindicadas para a mesma
sequência de evento que leve ao evento perigoso quando o BPCS não for a fonte iniciadora
da demanda.
NOTA A camada de proteção BPCS identificada pode consistir em um BPCS como fonte inicial
da demanda (ver 8.2.2) e uma segunda camada de proteção BPCS independente (ver 9.3.2 e 9.3.3),
ou até duas camadas de proteção BPCS independentes quando a fonte inicial não está relacionada à falha
do BPCS.

ABNT/CB-003
FEV 2024
9.3.5 Quando 9.3.4 for aplicável, cada camada de proteção do BPCS deve ser independente
e separada da fonte inicial e uma da outra, na medida em que a alegada redução de risco de cada
camada de proteção do BPCS não seja comprometida.
NOTA 1 A avaliação da separação e independência pode considerar o que é necessário para alcançar
a redução de risco, por exemplo, as unidades centrais de processamento (CPU), módulos de entrada/saída,
relés, dispositivos de campo, programação de aplicativos, redes, base de dados de programas, ferramentas
de engenharia, interface homem-máquina, ferramentas de by-pass e outros dispositivos.
NOTA 2 Um controlador de hot backup não é considerado independente do controlador primário, porque
está sujeito a falhas de causas comuns (por exemplo, controladores de hot backup têm componentes que
são comuns ao controlador primário e ao controlador de backup, como o backplane, firmware, diagnósticos,
mecanismos de transferência e falhas perigosas não detectadas).
9.4 Requisitos para prevenir falhas de causas comuns, modos comuns e dependentes
9.4.1 O projeto das camadas de proteção deve ser avaliado para assegurar que a probabilidade
de falhas de causas comuns, modos comuns e dependentes entre:
● camadas de proteção;
● camadas de proteção e o BPCS
seja suficientemente baixa em comparação com os requisitos de segurança geral das camadas
de proteção. A avaliação pode ser qualitativa ou quantitativa, a menos que o descrito em 9.2.7 se aplique.
NOTA Uma definição de falha dependente é apresentada em 3.2.12.
9.4.2 A avaliação deve considerar o seguinte:
● independência entre as camadas de proteção;
● diversidade entre as camadas de proteção;
● separação física entre as diferentes camadas de proteção;
● falhas de causas comuns entre as camadas de proteção e entre as camadas de proteção e o BPCS.
NOTA 1 As causas comuns do processo podem ser abordadas. O entupimento de válvulas de alívio
pode causar os mesmos problemas que o entupimento de sensores em um SIS.
NOTA 2 A independência e a separação física podem ser abordadas. Uma interface homem-máquina,
redes SIS/BPCS ou meios de by-pass podem causar falhas de causas comuns.
10 Especificação de requisitos de segurança do SIS (SRS)

10.1 Objetivo
O objetivo da Seção 10 é especificar os requisitos para o SIS, incluindo quaisquer programas aplicativos
e a arquitetura do SIS.

ABNT/CB-003
FEV 2024
10.2 Requisitos gerais
10.2.1 Os requisitos de segurança devem derivar da alocação das SIF e dos requisitos identificados
durante a H&RA. Os requisitos do SIS devem ser expressos e estruturados de maneira que sejam
● claros, precisos, auditáveis, mantidos e viáveis; e

● escritos de maneira a ajudar a compreensão e interpretação daqueles que utilizarão a informação

em qualquer fase do ciclo de vida de segurança.
10.3 Requisitos de segurança para o SIS
10.3.1 O objetivo de 10.3 é abordar questões que devem ser consideradas quanto ao desenvolvimento
dos requisitos de segurança do SIS.
10.3.2 Estes requisitos devem ser suficientes para projetar o SIS e devem incluir uma descrição
da intenção e da abordagem aplicadas durante o desenvolvimento dos requisitos de segurança do SIS,
conforme aplicável:
● uma descrição de todas as SIF necessárias para se obter a segurança funcional requerida
(por exemplo, um diagrama de causa e efeito, narrativa lógica);
● uma lista dos dispositivos de entrada e saída da planta relacionados a cada SIF que seja
claramente identificada pelos meios de identificação do equipamento da planta (por exemplo,
lista de tags de campo);
● os requisitos para identificar e considerar as falhas de causas comuns;
● uma definição do estado seguro de processo para cada SIF identificada, de modo que um estado
estável do processo tenha sido alcançado e o evento perigoso especificado tenha sido evitado
ou suficientemente mitigado;
● uma definição de qualquer estado de processo seguro individualmente que, se ocorrer

concomitantemente, cria um perigo adicional (por exemplo, sobrecarga do armazenamento
de emergência, múltiplos alívios para o sistema de flare);
● as fontes assumidas da demanda e taxas de demanda de cada SIF;
● os requisitos para intervalos de testes de prova;
● os requisitos relativos à implementação de testes de prova;
● o tempo de resposta para que cada SIF leve o processo para o estado seguro dentro do tempo
de segurança do processo;
NOTA Ver IEC 61511-2:2016 para uma discussão mais detalhada sobre o tempo de segurança do processo.
● o SIL requerido e o modo de operação (demanda/contínua) para cada SIF;
● uma descrição das variáveis de processo do SIS, ranges, exatidão e seus pontos de acionamento;
● uma descrição das ações de saída de processo da SIF e seu critério de operação bem sucedida,
por exemplo, taxas de vazamento para válvulas;

ABNT/CB-003
FEV 2024
● a relação funcional entre entradas e saídas, incluindo lógica, funções matemáticas e qualquer
função permissiva requerida para cada SIF;
● os requisitos para parada por acionamento manual para cada SIF;
● os requisitos relacionados a energizar ou desenergizar para acionamento de cada SIF;

● os requisitos para reinicializar cada SIF após uma parada (por exemplo, requisitos para
reinicializações manuais, semiautomáticos ou automáticos do elemento final após a parada
de emergência);
● a taxa máxima permissível de acionamento espúrio para cada SIF;
● os modos de falha para cada SIF e a resposta desejada do SIS (por exemplo, alarmes, parada
automática);
● quaisquer requisitos específicos relacionados a procedimentos de partida e reinicialização

do SIS;
● todas as interfaces entre o SIS e qualquer outro sistema (incluindo o BPCS e operadores);
● a descrição dos modos de operação da planta e os requisitos relativos à operação da SIF para
cada modo;
● os requisitos de segurança do programa aplicativo indicado em 10.3.3;
● os requisitos de by-passes incluindo procedimentos escritos a serem aplicados durante o estado

em by-pass que descrevem como serão controlados administrativamente e então liberados
na sequência;
● a especificação de qualquer ação necessária para obter ou manter o estado seguro do processo
em evento de falha(s) detectada(s) pelo SIS considerando todos os fatores humanos relevantes;
● o tempo médio de reparo viável para o SIS, considerando tempo de transporte, localização,
sobressalentes reservados, contratos de serviço e restrições ambientais;
● a identificação de combinações perigosas de estados de saída do SIS que necessitam

ser evitadas;
● a identificação dos extremos de todas as condições ambientais prováveis de impactarem

no SIS durante o embarque, armazenamento, instalação e operação. Pode ser necessário
considerar o seguinte: temperatura, umidade, contaminantes, aterramento, interferência
eletromagnética/radiofrequência (EMI/RFI), choques mecânicos/vibrações, descarga eletrostática,
classificação elétrica de área, alagamento, raios e outros fatores relacionados;
● a identificação de ambos os modos de operação normais e anormais para a planta como um todo
(por exemplo, partida da planta) e procedimentos operacionais individuais da planta (por exemplo,
manutenção de equipamentos, calibração ou reparo de sensores). SIF adicionais podem ser
requeridas para suportar estes modos de operação;
● a definição dos requisitos de qualquer SIF necessária para que se mantenha ativa em um evento
de acidentes de grandes proporções, por exemplo, tempo requerido para que uma válvula
se mantenha operacional durante um evento de fogo.

ABNT/CB-003
FEV 2024
10.3.3 Os requisitos de segurança do programa aplicativo devem ser derivados do SRS e da arquitetura
escolhida (disposição e estrutura interna) do SIS. Os requisitos de segurança do programa aplicativo
podem estar localizados no SRS ou em um documento separado (por exemplo, especificação
de requisitos do programa aplicativo). A entrada para os requisitos de segurança do programa aplicativo
para cada subsistema do SIS deve incluir:
a) os requisitos de segurança especificados de cada SIF, incluindo votação de sensores etc.;
b) os requisitos resultantes da arquitetura do SIS e do manual de segurança, como limitações

e restrições do hardware e software embarcado;
c) quaisquer requisitos de planejamento de segurança decorrentes de 5.2.4.
10.3.4 Os requisitos de segurança do programa aplicativo devem ser especificados para cada
dispositivo SIS programável necessário para implementar a SIF necessária, consistente com
a arquitetura do SIS.
10.3.5 A especificação dos requisitos de segurança do programa aplicativo deve ser suficientemente
detalhada para permitir que o projeto e a implementação alcancem a segurança funcional requerida
e para permitir que uma avaliação de segurança funcional seja realizada. Deve ser considerado
o seguinte:
● SIF suportadas pelo programa aplicativo e seus SIL;
● parâmetros de desempenho em tempo real, como capacidade da CPU, largura de banda

da rede, desempenho aceitável em tempo real na presença de avarias e todos os sinais de parada
de emergência são recebidos dentro de um período de tempo especificado;
● sequenciamento do programa e atrasos, se aplicável;
● equipamentos e interfaces de operação e sua operabilidade;
● todos os modos relevantes de operação do processo, conforme especificado na SRS;
● ações a serem tomadas em variáveis de processo ruins, como valor do sensor fora de faixa,
alteração excessiva de range, valor congelado, circuito aberto detectado, curto-circuito detectado;
● funções que permitem testes de prova e testes de diagnóstico automatizados de dispositivos

externos (por exemplo, sensores e elementos finais) realizados no programa aplicativo;
● automonitoramento do programa de aplicação (por exemplo, watchdogs conduzidos por aplicação e

validação de intervalo de dados);
● monitoramento de outros dispositivos dentro do SIS (por exemplo, sensores e elementos finais);
● quaisquer requisitos relacionados a testes periódicos da SIF quando o processo estiver operacional;
● referências aos documentos de entrada (por exemplo, especificação da SIF, configuração

ou arquitetura do SIS, requisitos de integridade de segurança de hardware do SIS);
● requisitos para interfaces de comunicação, incluindo medidas para limitar a sua utilização
e a validade dos dados e comandos recebidos e transmitidos;

ABNT/CB-003
FEV 2024
● estados perigosos do processo (por exemplo, o fechamento de duas válvulas de bloqueio

de gás ao mesmo tempo, que poderia levar a flutuações de pressão, levando assim a um estado
perigoso) gerados pelo programa aplicativo devem ser identificados e evitados;
● definições de critérios de validação de variáveis de processo para cada SIF.
10.3.6 A especificação dos requisitos de segurança do programa aplicativo deve ser expressa
e estruturada de forma que:
● descreva a intenção e a abordagem subjacentes aos requisitos de segurança do programa

aplicativo;
● seja clara e compreensível para aqueles que utilizarão o documento em qualquer fase do ciclo
de vida de segurança do SIS; isso inclui o uso de terminologia e descrições que sejam inequívocas
e compreendidas por todos os usuários (por exemplo, operadores das instalações, pessoal
de manutenção, programadores de aplicações);
● seja verificável, testável e modificável;
● seja rastreável por meio de todas as entregas, incluindo os documentos detalhados do projeto,
o SRS e a H&RA que identifica a SIF e o SIL requeridos.
11 Projeto e engenharia do SIS

11.1 Objetivo
O objetivo dos requisitos da Seção 11 é projetar um ou múltiplos SIS para as SIF e atender
aos requisitos de integridade especificados (por exemplo, SIL, redução de risco associado, PFD
e/ou PFH).
11.2.1 O projeto do SIS deve estar de acordo com as especificações dos requisitos de segurança
do SIS, considerando os requisitos da Seção 11.
11.2.2 Nos casos em que o SIS é utilizado para implementar as SIF e as não SIF, então todo
o hardware e software embarcado que possam afetar negativamente qualquer SIF sob condições
normais e em falha devem ser tratados como parte do SIS e atender aos requisitos do SIL mais alto
de qualquer uma das SIF que possa impactar.
11.2.3 Nos casos em que o SIS é utilizado para implementar a SIF de diferente SIL, então o hardware,
o software embarcado e o programa aplicativo comuns ou compartilhados devem atender ao SIL
mais alto.
NOTA Software embarcado ou programas aplicativos de diferentes SIL podem coexistir no mesmo
dispositivo, desde que possa ser demonstrado que a SIF do SIL inferior pode não afetar negativamente a SIF
do SIL superior.
11.2.4 Se for a intenção não qualificar o BPCS à série IEC 61511, então o SIS deve ser concebido
para ser separado e independente do BPCS, na medida em que a integridade de segurança do SIS
não for comprometida.
NOTA 1 Informações operacionais podem ser trocadas, mas não comprometer a segurança funcional do SIS.

ABNT/CB-003
FEV 2024
NOTA 2 Dispositivos do SIS podem ser utilizados para funções do BPCS, se for demonstrado que a falha
do BPCS não compromete as SIF do SIS.
11.2.5 Requisitos para operabilidade, manutenibilidade, diagnóstico, inspeção e testabilidade

devem ser abordados durante a concepção do SIS a fim de reduzir a probabilidade de falha perigosas.
11.2.6 O projeto do SIS deve considerar as capacidades e as limitações humanas, e ser adequado
para a tarefa atribuída aos operadores e ao pessoal de manutenção. O projeto das interfaces com
o operador deve seguir as boas práticas de fatores humanos e acomodar o nível provável
de treinamento que é recomendado que os operadores possuam.
NOTA Por exemplo, estudos de fator humano podem ser necessários, se a operação requerer entrada
regular de dados de limites de controle ou outras informações do operador.
11.2.7 O SIS deve ser projetado de maneira que, uma vez que o processo seja colocado
em um estado seguro, este deve permanecer no seu estado seguro até que uma reinicialização tenha
sido acionada, a menos que seja orientado de outra forma pela SRS.
11.2.8 Meios manuais (por exemplo, botoeira de parada de emergência), independentemente

do solucionador lógico, devem ser fornecidos para acionar os elementos finais do SIS a que seja
orientado de outra forma pela SRS.
11.2.9 O projeto do SIS deve considerar todos os aspectos da independência e da dependência

entre o SIS e o SBCP, e do SIS e outras camadas de proteção.
11.2.10 Um dispositivo utilizado pelo BPCS não pode ser utilizado pelo SIS, em que a falha deste
dispositivo pode resultar em uma demanda na SIF e uma falha perigosa na SIF, a menos que uma
análise tenha sido realizada para confirmar se o risco total seja aceito.
NOTA Quando uma parte do SIS é também utilizada para propósitos de controle e uma falha perigosa
do equipamento comum pode causar uma demanda da função executada pelo SIS, então um novo risco
é introduzido. O risco adicional é dependente da taxa de falha perigosa do dispositivo compartilhado, porque,
se o dispositivo compartilhado falhar, uma demanda é criada imediatamente, a qual o SIS pode não ser capaz
de responder. Por esta razão, análises adicionais podem ser necessárias nestes casos, para assegurar que
a taxa de falha perigosa do dispositivo compartilhado é suficientemente baixa. Sensores e válvulas são
exemplos de equipamentos frequentemente compartilhados com o BPCS.
11.2.11 Para qualquer dispositivo do SIS em que a perda de utilidades (por exemplo, energia
elétrica, suprimento de ar, hidráulico ou pneumático) não leve ao estado seguro, a perda de utilidades
e do circuito de integridade do SIS devem ser detectadas e alarmadas (por exemplo, monitoramento
elétrico fim de linha, medição de pressão de suprimento, medição de pressão pneumática ou hidráulica)
e ações devem ser tomadas de acordo com 11.3:
NOTA 1 A integridade das utilidades pode ser melhorada pelo uso de uma fonte suplementar (por exemplo, bateria
reserva, fontes de alimentação ininterruptas, reservatório de ar, acumulador hidráulico, segunda fonte de ar).
NOTA 2 A perda de uma utilidade provavelmente afeta múltiplas SIF e, possivelmente, múltiplos SIS.
11.2.12 O projeto do SIS deve proporcionar a resiliência necessária contra os riscos de segurança
física e cibernética identificados (ver 8.2.4).
NOTA As diretrizes relacionadas à segurança cibernética do SIS são fornecidas nas ISA TR 84.00.09,
ISO/IEC 27001:2013 e IEC 62443-2-1:2010.

ABNT/CB-003
FEV 2024
11.2.13 Um manual de segurança que abranja operação, manutenção, detecção de falhas e restrições
associadas ao SIS deve estar disponível para cobrir as configurações pretendidas dos dispositivos
e o ambiente operacional pretendido.
11.2.14 Todas as comunicações utilizadas para implementar uma SIF devem ser estabelecidas
utilizando técnicas apropriadas para aplicações de segurança cibernética para atender ao SIL requerido.
11.3 Requisitos para comportamento do sistema em caso de detecção de falha
11.3.1 Quando uma falha perigosa em um SIS for detectada (por testes de diagnóstico, testes
de prova ou por qualquer outro meio), medidas de compensação devem ser tomadas para manter
a operação segura. Se a operação segura não puder ser mantida, uma ação específica deve ser
tomada para alcançar ou manter um estado seguro do processo. Quando as medidas de compensação
dependerem de um operador tomar medidas específicas em resposta a um alarme (por exemplo,
abrir ou fechar uma válvula), o alarme é considerado parte do SIS.
NOTA 1 A ação especificada (reação de falha) necessária para alcançar ou manter o estado seguro
do processo pode ser especificada no SRS (ver 10.3.1). A ação especificada pode consistir na parada segura
do processo ou daquela parte do processo que dependa do SIS defeituoso para redução do risco.
NOTA 2 As medidas de compensação necessárias para operações seguras contínuas podem depender
dos requisitos de integridade de segurança, do risco tolerável associado ao evento perigoso, da tolerância
a falhas de hardware do SIS, do MRT previsto e da disponibilidade de quaisquer outras camadas de proteção.
Em alguns casos, pode ser adequado assegurar que sejam tomadas medidas para assegurar a reparação
da falha perigosa dentro do MPRT assumido no cálculo do PFDavg, mas, em outros casos, pode ser
considerado necessário apresentar outras medidas para compensar a redução do risco reduzido até o SIS
estar totalmente restaurado. Ver também 16.2.3.
11.3.2 Quando qualquer falha perigosa em um SIS for levada ao conhecimento de um operador
por um alarme, o alarme deve ser sujeito a testes de prova apropriados e gerenciamento de mudanças.
11.4 Tolerância à falha de hardware
11.4.1 O SIS deve ter uma HFT mínima em relação a cada SIF implementada.
NOTA Isso não exclui a possibilidade de que a HFT possa ser reduzida abaixo do requisito mínimo
em determinados momentos durante a operação do sistema após a ocorrência de falhas.
11.4.2 Quando o SIS puder ser dividido em subsistemas SIS independentes (por exemplo, sensores,
solucionadores lógicos e elementos finais), então a HFT pode ser atribuída ao nível do subsistema SIS.
11.4.3 A HFT do SIS ou seus subsistemas do SIS devem estar de acordo com:
● 11.4.5 a 11.4.9 da Seção 11; ou
● os requisitos de 7.4.4.2 (rota 1H) da IEC 61508-2:2010; ou
● os requisitos de 7.4.4.3 (rota 2H) da IEC 61508-2:2010.
NOTA A rota desenvolvida na ABNT NBR IEC 61511 é derivada da rota 2H da IEC 61508-2:2010.
11.4.4 Na determinação da HFT alcançada, determinadas falhas podem ser excluídas, desde
que a probabilidade de sua ocorrência seja muito baixa em relação aos requisitos de integridade
de segurança. Quaisquer exclusões de falhas devem ser justificadas e documentadas.

ABNT/CB-003
FEV 2024
NOTA Mais informações sobre exclusão de falhas podem ser encontradas nas ISO 13849-1:2006
e ISO 13849-2:2012.
11.4.5 A HFT mínima para um SIS (ou seus subsistemas SIS) que implementa uma SIF de um SIL
especificado deve estar de acordo com a Tabela 6 e, se apropriado, com 11.4.6 e 11.4.7.
NOTA Os requisitos de HFT na Tabela 6 representam o sistema mínimo ou, quando aplicável, a redundância
do subsistema SIS. Dependendo da aplicação, da taxa de falha do dispositivo e do intervalo de teste

de prova, redundância adicional pode ser necessária para atender à medida de falha da SIL da SIF de acordo
com 11.9.
Tabela 6 – Requisitos mínimos de HFT de acordo com o SIL
SIL HFT mínima requerida

1 (qualquer modo) 0
2 (modo de baixa demanda) 0
2 (modo contínuo ou de alta demanda) 1
3 (qualquer modo) 1
4 (qualquer modo) 2
11.4.6 Para um SIS ou subsistema SIS que não usa dispositivos programáveis FVL ou LVL e se a HFT
mínima especificada na Tabela 6 resultar em falhas adicionais e levar à diminuição da segurança geral
do processo, a HFT pode ser reduzida. Isto deve ser justificado e documentado. A justificativa deve
apresentar evidências de que a arquitetura proposta é adequada ao fim a que se destina e cumpre
os requisitos de integridade de segurança.
NOTA A tolerância a falhas é a solução preferida para alcançar a confiança necessária de que uma
arquitetura robusta foi alcançada. Quando 11.4.6 é aplicável, o objetivo da justificativa é demonstrar que
a arquitetura alternativa proposta apresenta uma solução equivalente ou melhor. Isto pode variar dependendo
da aplicação ou tecnologia em utilização; os exemplos incluem: arranjos de backup (por exemplo, redundância
analítica, substituição de uma saída de sensor com falha por resultados do cálculo físico de saídas de outros
sensores); utilizar itens mais confiáveis da mesma tecnologia (se disponível); mudar para uma tecnologia
mais confiável; diminuir o impacto de falhas de causa comum pelo uso de tecnologia diversa; aumentar
as margens de segurança do projeto; restringir as condições ambientais (por exemplo, para componentes
eletrônicos); diminuir a incerteza da confiabilidade coletando mais informações de campo ou julgamento
de especialistas.
11.4.7 Se uma tolerância a falhas igual a zero resultar da aplicação de 11.4.6, a justificativa requerida
por 11.4.6 deve apresentar evidências de que os modos de falha perigosos relacionados podem ser
excluídos, de acordo com 11.4.4, incluindo a consideração do potencial de falhas sistemáticas.
11.4.8 Os dispositivos programáveis FVL e LVL devem ter coberturas de diagnóstico não inferiores
a 60 %.
11.4.9 Os dados de confiabilidade utilizados no cálculo da medida de falha devem ser determinados
por um limite superior de confiança estatística não inferior a 70 %.

ABNT/CB-003
FEV 2024
11.5 Requisitos para seleção de dispositivos
11.5.1 Objetivos
Os objetivos dos requisitos de 11.5 são:
● especificar os requisitos para seleção dos dispositivos que são utilizados como parte de um SIS;
● especificar os requisitos para habilitar um dispositivo a ser integrado na arquitetura de um SIS;
● especificar critérios de aceitação para os dispositivos nos termos das SIF associadas e dos
requisitos de integridade de segurança.
11.5.2 Requisitos gerais
11.5.2.1 Dispositivos selecionados para utilização como parte de um SIS com um SIL especificado
devem estar de acordo com a IEC 61508-2:2010 e/ou com a IEC 61508-3:2010, e/ou 11.5.3 a 11.5.6,
conforme apropriado.
NOTA Dispositivos avaliados conforme as IEC 61508-2:2010 e IEC 61508-3:2010 podem ser aplicados
de acordo com os requisitos de capabilidade sistemática da IEC 61508-2:2010.
11.5.2.2 Todos os dispositivos devem ser adequados para o ambiente operacional, conforme
determinado pelas considerações na documentação do fabricante, das restrições da SRS e dos
parâmetros de confiabilidade assumidos em relação a 11.9. A adequação dos dispositivos selecionados
deve ser sempre considerada no contexto do ambiente operacional.
NOTA Os dispositivos podem apresentar diferentes taxas de falha dependendo do ambiente operacional
e do modo de operação. Os dados de taxa de falhas disponibilizados pelos fabricantes podem não ser válidos
em todas as aplicações. Por exemplo, a taxa de falha e a distribuição do modo de falha podem ser diferentes
para uma válvula que é acionada com frequência e para uma válvula que permanece parada por longos
períodos de tempo.
11.5.3 Requisitos para seleção de dispositivos baseados em utilização prévia
11.5.3.1 Evidências apropriadas de que os dispositivos são adequados para utilização em SIS devem
estar disponíveis.
NOTA 1 A principal intenção da avaliação de utilização prévia é reunir evidências de que as falhas
sistemáticas perigosas foram reduzidas a um nível suficientemente baixo em comparação com a integridade
de segurança requerida.
NOTA 2 O nível de detalhes da evidência pode estar de acordo com a complexidade dos dispositivos
considerados.
NOTA 3 Uma avaliação de uso prévio envolve a coleta de informações documentadas sobre o desempenho
do dispositivo em um ambiente operacional semelhante. O uso prévio demonstra a funcionalidade
e a integridade do dispositivo instalado, incluindo as interfaces de processo, limite completo do dispositivo,
comunicações e utilidades. A principal intenção da avaliação de utilização prévia é reunir evidências de que
as falhas sistemáticas perigosas foram reduzidas a um nível suficientemente baixo em comparação com
a integridade de segurança requerida.
NOTA 4 Os dados de uso prévio podem contribuir para uma base de dados para o cálculo das taxas
de falha de hardware, conforme descrito em 11.9.3.

ABNT/CB-003
FEV 2024
11.5.3.2 A evidência da adequação deve incluir o seguinte:
● considerações sobre a qualidade do fornecedor, gerenciamento e sistemas de gerenciamento

de configurações;
● identificação adequada e especificação dos dispositivos;

● demonstração de desempenho dos dispositivos em operações similares;
NOTA 1 No caso de dispositivos de campo (por exemplo, sensores e elementos finais) cumprindo
determinada especificação, o comportamento do dispositivo no ambiente operacional é geralmente
idêntica em aplicações de segurança e das que não são de segurança. Portanto, evidências do
desempenho de dispositivos semelhantes em aplicações que não são de segurança também podem ser
utilizadas para satisfazer esse requisito.
● volume da experiência operacional.
NOTA 2 Para dispositivos de campo, informações relativas à experiência operacional são registradas
principalmente na lista de usuários dos equipamentos aprovados para utilização em suas instalações,
com base em um extenso histórico de desempenho bem-sucedido nas aplicações de segurança e das
aplicações que não são de segurança, e na eliminação dos equipamentos que não desempenharam
de maneira satisfatória. A lista de dispositivos de campo pode ser utilizada para apoiar reivindicações
de experiência em operação, desde que:
— a lista seja atualizada e acompanhada regularmente;
— os dispositivos de campo sejam adicionados somente quando for obtida experiência

operacional suficiente;
— os dispositivos de campo sejam removidos quando demonstram histórico de não realizar

suas funções de forma satisfatória;
— o ambiente operacional seja incluído na lista em que for aplicável.
NOTA 3 O desempenho do dispositivo é altamente afetado pelo ambiente operacional. Geralmente

é recomendado que a seleção de dispositivos possa ser baseada no desempenho adequado de um número
suficiente de dispositivos instalados em múltiplas instalações para um tempo de operação suficiente.
A experiência adquirida pode dar tempo para revelar falhas precoces, como aquelas relacionadas
à especificação, manuseio, instalação e comissionamento.
NOTA 4 A quantidade de experiências operacionais para obter dados de confiabilidade estatística

é normalmente muito maior em comparação com as experiências operacionais necessárias para obter
evidências de “uso prévio” (“prior use”).
11.5.3.3 Todos os dispositivos selecionados com base no uso prévio devem ser identificados por
um número de revisão especificado e estar sob o controle de um procedimento de gerenciamento
de mudanças. No caso de uma alteração ser feita no dispositivo, a validade continuada da evidência
de utilização prévia é justificada pela avaliação da importância da alteração realizada.
11.5.4 Requisitos para seleção de dispositivos programáveis de FPL (por exemplo, dispositivos
de campo) baseados em utilização prévia
11.5.4.1 Para SIL 1, SIL 2 e SIL 3, os requisitos de 11.5.2 e 11.5.3 se aplicam em conjunto com
as seguintes subseções.

ABNT/CB-003
FEV 2024
11.5.4.2 Todas as opções de configuração do dispositivo que possam influenciar a segurança devem
ser identificadas e consideradas. É importante verificar se, sempre que não forem determinadas
configurações específicas, as configurações-padrão do dispositivo serão confirmadas como
apropriadas. Recursos não utilizados dos dispositivos devem ser identificados com evidência
da aplicabilidade, e deve ser estabelecido que é improvável que comprometam a SIF requerida.
11.5.4.3 Para a configuração específica e do ambiente de operação do dispositivo, a evidência

de aptidão deve considerar:
● características de sinais de entrada e saída;
● modos de utilização;
● funções e configurações utilizadas;
● utilização prévia em ambientes de operação semelhantes.
11.5.4.4 Adicionalmente, para aplicações SIL 3, uma avaliação do dispositivo de FPL deve ser
realizada para demonstrar que:
● o dispositivo FPL é tanto capaz de realizar as funções requeridas e que o “uso prévio” (“prior use”)
tenha mostrado que existe uma probabilidade baixa o suficiente de que o dispositivo irá falhar
de uma forma que poderia levar a um evento perigoso quando utilizado como parte do SIS, devido
a quaisquer falhas aleatórias de hardware ou falhas sistemáticas em hardware ou software;
● os padrões adequados de hardware e software foram aplicados;
● o dispositivo FPL foi utilizado ou testado em configurações representativas dos perfis

operacionais pretendidos.
11.5.5 Requisitos para seleção de dispositivos programáveis de LVL baseados na utilização prévia
11.5.5.1 Os seguintes requisitos aplicam-se aos dispositivos PE utilizados em SIS que implementam
SIF SIL 1 ou SIL 2.
11.5.5.2 Os requisitos de 11.5.4 são aplicáveis.
11.5.5.3 Nos casos em que houver qualquer diferença entre o ambiente de operação de um dispositivo
conforme experimentado anteriormente e o ambiente operacional do dispositivo quando utilizado
em um SIS, então estas diferenças devem ser identificadas e deve ser realizada uma avaliação com
base em análises e testes, conforme apropriado, para demonstrar que a probabilidade de falhas
sistemáticas quando utilizados no SIS é suficientemente baixa.
11.5.5.4 A experiência operacional considerada necessária para justificar a aptidão deve ser
determinada considerando:
● o SIL da SIF;
● a complexidade e a funcionalidade dos dispositivos.
11.5.5.5 Para aplicações SIL 1 ou 2, um solucionador lógico de segurança PE configurado pode ser
utilizado, desde que todas as seguintes disposições adicionais sejam cumpridas:
● entendimento dos modos de falha insegura;

ABNT/CB-003
FEV 2024
● utilização de técnicas para a configuração de segurança que tratem os modos de falha identificados;
● o software embarcado tenha um bom histórico de utilização em aplicações de segurança;
● proteção contra modificações não autorizadas ou não intencionadas.
NOTA Um solucionador lógico PE de segurança configurado é um solucionador lógico industrial

de utilização geral que é configurado especificamente pelo OEM, um engenheiro de sistemas ou um

usuário final para utilização em aplicações de segurança.
11.5.5.6 Uma avaliação formal de qualquer solucionador lógico PE utilizada em aplicações SIL 2
deve ser realizada para demonstrar que:
● é capaz tanto de executar as funções requeridas e que o “uso prévio” (“prior use”) tenha mostrado
que há uma probabilidade baixa o suficiente de que ele falhará de uma forma que poderia levar
a um evento perigoso quando utilizado como parte do SIS, devido a falhas aleatórias de hardware
ou a falhas sistemáticas em hardware ou software;
● medidas estão implementadas para detectar falhas durante a execução do programa e iniciar
uma resposta adequada; estas medidas devem incluir o seguinte:
— monitoramento da sequência do programa;
— proteção contra alterações do código ou detecção de falhas por monitoramento on-line;
— confirmação de falha ou de programação diversa;
— verificação da faixa (range) de variáveis ou verificação da plausibilidade de valores;
— abordagem modular;
— padrões de codificação adequados tenham sido utilizados para o software embarcado

e o software utilitário;
— tenha sido testado em configurações típicas, com casos de testes representativos dos perfis
operacionais pretendidos;
— módulos e componentes de software verificados e confiáveis foram usados;
— sistema submetido à análise dinâmica e testes;
— sistema sem uso de inteligência artificial ou reconfiguração dinâmica;
— testes documentados de inserção de falhas (teste negativo) realizados.
11.5.6 Requisitos para a seleção de dispositivos programáveis de FVL
Quando as aplicações são programadas usando uma FVL, o dispositivo PE deve estar em conformidade
com as IEC 61508-2:2010 e IEC 61508-3:2010.
11.6 Dispositivos de campo
11.6.1 Dispositivos de campo devem ser selecionados e instalados para minimizar falhas que poderiam
resultar em informações inexatas decorrentes do ambiente de operação. As condições que convém

ABNT/CB-003
FEV 2024
considerar incluem corrosão, congelamento de materiais em tubulações, sólidos em suspensão,

polimerização, coqueamento, temperaturas e pressões extremas, condensação na perna seca
de linhas de impulso e condensação insuficiente em pernas cheias de linhas de impulso.
11.6.2 Circuitos do tipo “energizar para acionar” devem aplicar meios para assegurar a integridade
do circuito e da fonte de alimentação.
NOTA 1 Um exemplo desse meio é um monitor de fim de linha, em que um monitor de corrente
é continuamente monitorado para detectar a continuidade do circuito e em que o monitor de corrente não
é de magnitude suficiente para afetar a operação adequada da E/S.
NOTA 2 Requisitos adicionais para perda de energia podem ser encontrados em 11.2.11.
11.6.3 Sensores inteligentes devem ser protegidos contra escrita para impedir a modificação
inadvertida, a menos que uma revisão de segurança apropriada (por exemplo, H&RA) permita
a utilização de leitura/ escrita.
NOTA A revisão pode levar em conta fatores humanos, como a falha em seguir procedimentos.
11.7 Interfaces
11.7.1 Geral
Interfaces para o SIS podem incluir, mas não são limitadas a:
● interface(s) do operador;
● interface(s) de manutenção/engenharia;
● interface(s) de comunicação.
11.7.2 Requisitos de interface do operador
11.7.2.1 Quando a interface com o operador SIS for pela interface com o operador BPCS, devem ser
consideradas falhas que possam ocorrer na interface do operador do BPCS.
NOTA Isso pode incluir a preparação de planos para permitir uma parada ordenada e segura no caso
de falha total dos monitores operacionais.
11.7.2.2 O projeto do SIS deve minimizar a necessidade de seleção de opções pelo operador
e a necessidade de by-pass do sistema enquanto os perigos estiverem presentes. Se o projeto requer
a utilização de ações do operador, recomenda-se que o projeto inclua recursos para proteção contra
erros do operador.
NOTA Se o operador tiver que selecionar uma opção em particular, pode haver uma etapa de confirmação.
11.7.2.3 Chaves ou outros meios de by-pass devem ser protegidos para evitar a utilização não
autorizada (por exemplo, por cadeados ou senhas em conjunto com controles de gestão eficazes).
NOTA Pode-se considerar a aplicação de limites de tempo na operação de by-pass e a limitação

do número de by-passes que possam estar ativos a qualquer momento.
11.7.2.4 A informação de status da SIF que seja crítica para a manutenção da SIF deve estar disponível
como parte da interface do operador. Esta informação pode incluir:
● onde o processo está em sua sequência;

ABNT/CB-003
FEV 2024
● indicação de que a ação de proteção do SIS ocorreu;
● indicação de que uma função de proteção está em by-pass;
● indicação de que uma ação automática (s), como a degradação da votação e/ou tratamento
da falha ocorreu;
● status de sensores e elementos finais;
● perda de energia em que esta perda de energia impacte na segurança;
● resultados dos diagnósticos;
● falha do equipamento de condicionamento ambiental necessário para suportar o SIS.
11.7.2.5 O projeto de interface de operação do SIS (ver 11.7.2.7) deve ser de maneira que previna
mudanças no programa aplicativo do SIS.
11.7.2.6 Quando as informações forem transferidas do BPCS para o SIS, os sistemas, equipamentos
ou procedimentos devem ser aplicados para confirmar se a informação correta foi transferida e não
compromete a integridade de segurança do SIS.
NOTA Os sistemas, equipamentos ou procedimentos utilizados podem incluir controle sobre escrita
seletiva do BPCS para variáveis específicas do SIS.
11.7.2.7 O projeto da interface do operador do SIS por meio da interface do operador do BPCS
deve ser de forma que o fornecimento de informações ou dados incorretos do BPCS para o SIS não
possa comprometer a segurança.
11.7.3 Requisitos de interface de manutenção/engenharia
11.7.3.1 O projeto da interface de manutenção/engenharia do SIS deve assegurar que qualquer falha
desta interface não possa afetar adversamente a capacidade do SIS em atuar as SIF requeridas.
Isso pode requerer a desconexão da interface de manutenção ou engenharia, como em painéis
de programação, durante a operação normal do SIS.
11.7.3.2 A interface de manutenção/engenharia deve apresentar as seguintes funções com proteção

de acesso de segurança física e cibernética para cada:
● modo de operação do SIS, programa, dados, meios de desativar a comunicação de alarme, teste,
desvio (by-pass), manutenção;
● diagnóstico do SIS, votação e tratamento de falhas;
● adição, exclusão ou modificação do programa aplicativo;
● dados necessários para solucionar problemas do SIS;
● nos casos em que by-passes sejam requeridos, recomenda-se que sejam instalados de forma
que alarmes e recursos de parada manual não sejam desabilitados.
11.7.3.3 A interface de manutenção/engenharia não pode ser utilizada como interface do operador.
11.7.3.4 Habilitar e desabilitar o acesso de leitura e escrita deve ser realizado apenas por um processo
de gerenciamento de configuração usando a interface de manutenção/engenharia com a documentação
e medidas de segurança física e cibernética adequadas como autenticação e canais seguros de usuário.

ABNT/CB-003
FEV 2024
11.7.4 Requisitos de interface de comunicação
11.7.4.1 O projeto de qualquer interface de comunicação do SIS deve assegurar que qualquer falha
da interface de comunicação não afete a capacidade do SIS de atingir ou manter um estado seguro.
11.7.4.2 Quando o SIS for capaz de se comunicar com o SBCP e seus periféricos, a interface
de comunicação, o BPCS ou os periféricos não podem impactar negativamente nenhuma das SIF no SIS.
11.7.4.3 A interface de comunicação deve ser suficientemente robusta para resistir à interferência
eletromagnética, incluindo picos de energia sem causar uma falha perigosa do SIS.
11.7.4.4 A interface de comunicação deve ser adequada para a comunicação entre dispositivos
conectados a diferentes potenciais de aterramento.
NOTA Um meio alternativo (por exemplo, fibra óptica) pode ser requerido.
11.8 Requisitos de projeto de manutenção ou testes
11.8.1 O projeto deve permitir testar o SIS de “ponta a ponta” ou em segmentos. Nos casos em que
o intervalo entre as paradas de processo programadas for maior que o intervalo de testes de prova,
então são requeridas instalações para testes on-line.
NOTA O termo “ponta a ponta” significa do fluido de processo na extremidade do sensor até o fluido
de processo na extremidade do atuador.
11.8.2 Quando testes de prova on-line forem necessários, as instalações de testes devem ser parte
integrante do projeto do SIS.
11.8.3 Quando instalações de teste ou by-pass estiverem incluídas no SIS, elas devem estar
em conformidade com o seguinte:
● o SIS deve ser projetado em conformidade com os requisitos de manutenção e testes definidos
na SRS;
● o operador deve ser alertado para o by-pass de qualquer parte do SIS por meio de um alarme
ou procedimento operacional.
11.8.4 Deve ser determinado o tempo máximo que o SIS pode ficar em by-pass (reparo ou teste)
enquanto a operação segura do processo for definida.
11.8.5 Medidas de compensação que garantem uma operação segura e contínua devem ser fornecidas
de acordo com 11.3, quando o SIS estiver em by-pass (reparo ou teste).
11.8.6 Forçar entradas e saídas em um SIS PE não pode ser utilizado como parte do programa
aplicativo, procedimento(s) operacional(is) e manutenção (exceto como abaixo).
Forçar entradas e saídas sem ter o SIS fora de serviço não é permitido, a menos se isso for
complementado por procedimentos e acessos de segurança física e cibernética. Qualquer sinal
forçado deve ser anunciado ou disparar um alarme, se apropriado.

ABNT/CB-003
FEV 2024
11.9 Quantificação de falha aleatória
11.9.1 A medida de falha calculada de cada SIF deve ser igual, ou melhor do que a medida de falha-alvo
especificada relacionada ao SIL como especificado na SRS. Esta medida deve ser determinada
por cálculos.
NOTA Em aplicações complexas, a frequência de eventos perigosos pode ser utilizada como uma
alternativa às medidas de falha-alvo (por exemplo, se diferentes causas de demanda tiverem diferentes
requisitos de integridade de segurança ou se SIS não independentes atuarem em sequência).
11.9.2 A medida de falha calculada de cada SIF devido a falhas aleatórias deve considerar os fatores
contribuintes, incluindo o seguinte:
a) a arquitetura do SIS e dos subsistemas do SIS em que for aplicável no que se refere a cada
SIF em questão;
b) a taxa de falha estimada de cada modo de falha devido a falhas aleatórias de hardware, que
contribuiria para uma falha perigosa do SIS, mas que seja detectada por testes de diagnóstico;
c) a taxa de falha estimada de cada modo de falha devido a falhas aleatórias de hardware, que
contribuiria para uma falha perigosa do SIS que não seja detectada por testes de diagnóstico,
mas que seriam detectadas por testes de prova;
d) a taxa de falha estimada relacionada a cada modo de falha, devido a falha aleatória de hardware,
que poderia contribuir para uma falha perigosa do SIS, cuja falha não seja detectada pelos testes
de diagnóstico e não seja detectadas pelos testes de prova;
e) a suscetibilidade do SIS a falhas causadas pelos próprios testes de prova;
f) a suscetibilidade do SIS a falhas de causa comum;
g) a cobertura de diagnóstico de quaisquer testes periódicos de diagnóstico, o intervalo de testes

de diagnóstico associados e a probabilidade de falha das instalações de diagnóstico;
h) a cobertura de quaisquer testes de prova periódicos, o procedimento de teste de prova associado

e a confiabilidade das instalações e procedimentos do teste de prova;
i) os tempos de reparo de falhas detectadas e o estado do SIS durante as reparações (on-line

ou off-line);
j) a taxa de falha perigosa estimada de qualquer processo de comunicação em qualquer um dos

modos que causaria uma falha perigosa do SIS (ambas detectadas e não detectadas por testes
de diagnóstico);
k) a probabilidade estimada da resposta do operador que causaria uma falha perigosa do SIS
(detectadas e não detectadas por testes de diagnóstico);
l) a confiabilidade de qualquer utilidade necessária ao SIS.
NOTA Diversas abordagens de modelagem estão disponíveis, sendo a abordagem mais adequada
uma questão para o analista resolver e que pode depender das circunstâncias. Os meios disponíveis
incluem (ver IEC 61508-6:2010, Anexo B):
— análise de causa e consequência;

ABNT/CB-003
FEV 2024
— diagramas de blocos de confiabilidade;
— análise de árvore de falhas;
— modelos Markov;
— modelos de redes Petri.

Os cálculos probabilísticos podem ser realizados analiticamente ou por simulação numérica

(por exemplo, simulação de Monte Carlo).
11.9.3 Os dados de confiabilidade utilizados ao quantificar o efeito de falhas aleatórias devem ser
confiáveis, rastreáveis, documentados, justificados e baseados em informações de campo de dispositivos
similares utilizados em um ambiente operacional semelhante.
NOTA 1 Isso inclui dados coletados pelo usuário, dados de fornecedor/provedor/usuário derivados
de dados coletados em dispositivos, dados de bases de dados gerais de confiabilidade de informação
de campo etc. Em alguns casos, o julgamento de engenharia pode ser utilizado para avaliar dados
de confiabilidade ausentes ou avaliar o impacto sobre dados de confiabilidade coletados em um ambiente
operacional diferente.
NOTA 2 A falta de dados de confiabilidade que reflitam o ambiente operacional é uma deficiência
recorrente dos cálculos probabilísticos. Os usuários finais podem organizar coletas de dados relevantes
sobre confiabilidade de dispositivos de acordo com a IEC 60300-3-2:2004 ou ISO 14224:2006, para melhorar
a implementação da série IEC 61511.
NOTA 3 Os dados do fornecedor baseados em devoluções podem ser restritos a uma população em que haja
pleno conhecimento do ambiente operacional e totalmente registrados de acordo com a IEC 60300-3-2:2004
ou ISO 14224:2006. O usuário também pode registrar o ambiente operacional da SIF e demonstrar que
os dados do ambiente operacional do fornecedor correspondem ao ambiente da SIF.
11.9.4 As incertezas dos dados de confiabilidade devem ser avaliadas e consideradas no cálculo
da medida de falha.
NOTA 1 As incertezas dos dados de confiabilidade podem ser avaliadas de acordo com a quantidade
de informação de campo (menos informação de campo resulta em mais incerteza) e/ou com o exercício
de julgamento especializado. Normas publicadas (como a IEC 60605-4), abordagens bayesianas, técnicas
de julgamento de engenharia etc. podem ser utilizadas para estimar as incertezas dos dados de confiabilidade.
NOTA 2 As seguintes técnicas podem ser utilizadas para calcular as medidas de falha (mais informações
podem ser encontradas na IEC 61511-2:2016):
— utilização de um limite superior de confiança de 70 % para cada parâmetro de confiabilidade

de entrada, em vez da sua média, a fim de obter estimativas pontuais conservadoras das medidas
de falha; ou
— utilização das funções de distribuições probabilísticas dos parâmetros de confiabilidade de entrada,

realização das simulações de Monte Carlo para obter um histograma representando a distribuição
da medida de falha e avaliação de um valor conservador desta distribuição (por exemplo,
que há uma confiança de 90 % de que a medição de uma falha verdadeira é melhor que
o valor calculado).
11.9.5 Se, para um projeto específico, a medida de falha-alvo para a SIF aplicável não for alcançada, então:
a) identificar os dispositivos ou parâmetros que mais contribuem para a medição da falha;
NOTA A análise do conjunto de cortes da árvore de falhas pode ser útil aqui.

ABNT/CB-003
FEV 2024
b) avaliar o efeito de possíveis medidas de melhoria nos dispositivos ou parâmetros identificados

(por exemplo, dispositivos mais confiáveis, defesas adicionais contra falhas de modo comum,
maior cobertura de diagnóstico ou teste de prova, aumento de redundância, intervalo de teste
de prova reduzido, testes estagiados etc.);
c) selecionar e implementar medidas de melhoria para estabelecer o novo resultado;

d) comparar o novo resultado com a medida de falha-alvo e repetir as alíneas a) a d) até que
a medida de falha-alvo seja alcançada de maneira conservadora.
12 Desenvolvimento do programa aplicativo do SIS

12.1 Objetivo
O objetivo da Seção 12 é estabelecer os requisitos para o desenvolvimento do programa aplicativo.
12.2.1 O programa aplicativo do SIS deve estar de acordo com os requisitos de segurança do programa
aplicativo (ver 10.3.3) e todos os requisitos desta Seção para todos os SIL até SIL 3 inclusive.
12.2.2 O programador do aplicativo deve revisar as informações no SRS e os requisitos de segurança

do programa aplicativo para assegurar que os requisitos sejam abrangentes, inequívocos,
compreensíveis e consistentes. Quaisquer deficiências nos requisitos de segurança do programa
aplicativo devem ser identificadas e resolvidas e, se forem feitas alterações nos requisitos de segurança
do programa aplicativo, uma análise de impacto deve ser realizada.
12.2.3 A série IEC 61511 aborda a programação em Linguagens de Variabilidade Limitada (LVL - Limited
Variability Languages) e a utilização de dispositivos que utilizam Linguagens de Programa Fixas (FPL
- Fixed Program Languages). A série IEC 61511 não aborda Linguagens de Variabilidade Completa
(FVL - Full Variability Language) e a série IEC 61511 não aborda a programação de aplicativos SIL
4. Se os blocos funcionais forem escritos em FVL, eles devem ser desenvolvidos e modificados de
acordo com a IEC 61508-3:2010.
12.2.4 Nos casos em que o programa aplicativo do SIS implementar funções de segurança
e de não segurança, todo o programa aplicativo deve ser tratado como parte do SIS e deve estar
em conformidade com esta Norma e, além disso, deve ser mostrado por meio de avaliação e teste
de que as funções não relacionadas à segurança não interferem nas funções de segurança.
12.2.5 O programa aplicativo deve ser projetado de forma a assegurar que, uma vez que o SIS tenha
colocado o processo em um estado seguro, o processo permaneça no estado seguro, inclusive sob
condições de perda de energia e na restauração de energia, até que uma reinicialização seja acionada,
a menos que seja orientado de outra forma pelo SRS.
NOTA 1 Se a SIF não tiver uma reinicialização, pode haver um argumento de engenharia documentada
sobre porque é aceitável reiniciar o processo sem requerer o tempo de atraso seguro que uma
reinicialização imporia.
NOTA 2 Mais informações podem ser encontradas em 11.2.7.
12.2.6 Durante a partida (ou energização) do SIS, o programa aplicativo deve assegurar que as saídas
de segurança permaneçam no estado seguro (normalmente no estado desenergizado) até que uma
reinicialização seja acionada, a menos que seja orientado de outra forma pelo SRS.

ABNT/CB-003
FEV 2024
12.2.7 O programa aplicativo deve ser projetado de forma que todas as partes do programa aplicativo
sejam executadas em cada varredura do programa aplicativo, a menos que haja um requisito alternativo
específico que seja suportado no manual de segurança. Os requisitos de tempo de segurança
do processo devem ser considerados ao estabelecer os requisitos de varredura do programa aplicativo.
12.2.8 O programa de aplicação do SIS e os dados devem ser objeto de modificação, análise crítica,
controle, gerenciamento de versão, back-up e restauração de procedimentos.
12.2.9 O planejamento do ciclo de vida de programação do aplicativo do SIS deve abordar

os seguintes aspectos:
● fases e atividades do ciclo de vida de segurança do SIS que são aplicadas durante a concepção
e desenvolvimento do programa aplicativo. Estes requisitos incluem a aplicação de medidas
e técnicas que visam evitar erros no programa aplicativo e controlar falhas que possam ocorrer;
● informações relativas à validação do programa aplicativo a serem repassadas à organização que

realiza a integração do SIS;
● preparação de informações e procedimentos necessários ao usuário para operação e manutenção

do SIS;
● procedimentos e especificações a serem cumpridos pela organização que realiza modificações

no programa aplicativo.
12.3 Projeto do programa aplicativo
12.3.1 Um projeto de programa aplicativo deve abordar toda a lógica do SIS, incluindo todos os modos
de operação do processo para cada SIF.
12.3.2 A entrada para o projeto do programa aplicativo deve ser o SRS, incluindo os requisitos
do programa aplicativo (ver Seção 10), a arquitetura do SIS (ver Seção 11) e os meios e ferramentas
para desenvolver o projeto do programa aplicativo (ver 12.6). O projeto do programa aplicativo deve
ser consistente e rastreável até o SRS.
12.3.3 O projeto do programa aplicativo deve permitir a realização de uma avaliação

da segurança funcional.
12.3.4 O projeto do programa aplicativo e sua decomposição em módulos, se aplicável, devem

abordar como os requisitos são implementados, incluindo o seguinte, conforme apropriado:
● as funções que permitem ao processo atingir ou manter um estado seguro;
● a especificação de todos os componentes identificados do programa aplicativo e a descrição das

conexões e interações entre os componentes identificados;
● as restrições de tempo associadas às funções do programa aplicativo e sua implementação no(s)

tempo(s) de varredura do programa;
● uma descrição detalhada dos módulos de biblioteca-padrão (blocos funcionais) utilizados;
● uma descrição detalhada dos módulos específicos da aplicação (blocos funcionais) utilizados;
● uma descrição da forma como a alocação de memória foi obtida;
● a lista de variáveis globais utilizadas e a forma como a sua integridade é protegida;

ABNT/CB-003
FEV 2024
● a identificação de todas as não SIF e das interfaces com partes não relacionadas à segurança
do programa aplicativo, para assegurar que não possam afetar a operação adequada de qualquer SIF;
● a definição de interfaces de entrada e saída, incluindo listagens de tags e tipos de dados associados;
● os detalhes dos dados trocados entre o programa aplicativo do SIS e as interfaces do operador;
● os detalhes dos dados trocados entre o programa aplicativo do SIS e o BPCS e periféricos como
impressoras, armazenamento de dados etc.;
● como as informações de diagnóstico externas e internas serão processadas e registradas;
● a descrição detalhada de como são implementadas as interfaces de operação e manutenção,

incluindo a forma como os alarmes são priorizados, indicados e aceitos;
● uma descrição detalhada de quaisquer diagnósticos em nível de aplicação que possam ser
implementados, como monitoramento externo, verificação de integridade de dados de aplicação,
validação de sensor para atender ao SIL requerido;
● as verificações de configuração do sistema, incluindo a existência e acessibilidade de dispositivos

de hardware e módulos de software esperados;
● como a complexidade no projeto do programa aplicativo é minimizada, por exemplo, pelo uso
de projeto modular e funcionalidade simples;
● as funções relacionadas com a detecção, anúncio e gestão de falhas em subsistemas do SIS;
● as funções relacionadas com testes periódicos de SIF on-line;
● as funções relacionadas com testes periódicos de SIF off-line;
● as funções que permitem realizar a manutenção do SIS com segurança;
● as referências a documentos nos quais se baseia a especificação de projeto do programa

aplicativo.
12.3.5 O projeto do programa aplicativo deve assegurar:
● integridade em relação à SRS e à finalidade pretendida;
● correção em relação à SRS e à finalidade pretendida;
● ausência de ambiguidade, ou seja, estar claro para aqueles que utilizarão o documento
em qualquer fase do ciclo de vida de segurança do SIS; isso inclui o uso de terminologia
e descrições que sejam inequívocas e compreendidas pelos operadores da planta e mantenedores
do sistema, bem como pelos programadores de aplicações;
● ausência de falhas de projeto.
12.4 Implementação do programa aplicativo
12.4.1 A metodologia de desenvolvimento do programa aplicativo deve obedecer às ferramentas

e restrições de desenvolvimento fornecidas pelo fabricante do subsistema SIS PE no qual o programa
aplicativo será utilizado.

ABNT/CB-003
FEV 2024
12.4.2 As seguintes informações devem constar no programa aplicativo ou na documentação relacionada:
a) originador do programa aplicativo;
b) descrição da finalidade do programa aplicativo;
c) versões dos manuais de segurança utilizadas;

d) identificação da dependência de cada SIF nas partes (módulos) do programa aplicativo;
e) rastreabilidade à especificação dos requisitos de segurança do programa aplicativo;
f) identificação de cada SIF e seu SIL;
g) identificação e descrição dos símbolos utilizados, incluindo convenções lógicas, funções

de biblioteca-padrão, funções de biblioteca de aplicação;
h) identificação dos sinais de entrada e saída do solucionador lógico do SIS;
i) caso o SIS global utilize comunicações, uma descrição do fluxo de informação das comunicações;
NOTA Um exemplo seria quando uma SIF usa vários solucionadores lógicos.
j) descrição da estrutura do programa, incluindo uma descrição da ordem do processamento lógico

dos dados em relação aos subsistemas de entrada/saída e quaisquer limitações impostas pelos
tempos de varredura;
k) se exigido pela SRS, os meios pelos quais:
● a exatidão dos dados de campo é assegurada (por exemplo, comparação entre sensores
analógicos para melhorar a cobertura do diagnóstico);
● a exatidão dos dados enviados por meio de um link de comunicação é assegurada

(por exemplo, ao comunicar-se a partir de uma IHM, antes da implementação de um comando,
um ‘ack’ ou ‘acknowledge’ (reconhecimento) é transmitido);
● as comunicações são seguras (por exemplo, medidas de segurança cibernética);
l) identificação da versão e histórico de alterações.
12.4.3 Se funções de biblioteca de programas aplicativos previamente desenvolvidas forem utilizadas

como parte do projeto, sua adequação deve ser justificada e baseada em:
● conformidade com a série IEC 61508; se a avaliação em uso for comprovada para FVL
em conformidade com a IEC 61508-3:2010 sendo realizada, os dispositivos programáveis nos
quais as funções da biblioteca de programas aplicativos são executadas também devem ser
avaliados como em uso comprovado de acordo com a IEC 61508-2:2010; ou
● conformidade com os requisitos de uso prévio da ABNT NBR IEC 61511 (ver 11.5.4 ou 11.5.5)
ao utilizar FPL ou LVL;
● em todos os casos, demonstrar que quaisquer funções não utilizadas não causam impacto
negativo no programa aplicativo.

ABNT/CB-003
FEV 2024
12.4.4 O programa aplicativo deve ser produzido de forma estruturada de forma a alcançar:
● decomposição modular da funcionalidade;
● manutenção da complexidade do programa de aplicação da SIF em um mínimo consistente com

a complexidade da SIF exigida;
● testabilidade da funcionalidade (incluindo recursos de tolerância a falhas) e da estrutura interna

do programa aplicativo;
● rastreabilidade e explicação de funções de aplicação e restrições associadas;
● mapeamento individual entre a arquitetura de hardware e a arquitetura do programa aplicativo.
12.5 Requisitos para verificação do programa aplicativo (revisão e teste)

12.5.1 O planejamento da verificação deve ser realizado de acordo com a Seção 7.
12.5.2 O programa aplicativo, incluindo sua documentação, deve ser revisado por uma pessoa
competente não envolvida no desenvolvimento original. A abordagem utilizada para a revisão
e os resultados da revisão devem ser documentados.
12.5.3 O programa aplicativo, incluindo sua decomposição em módulos, se apropriado, deve ser
verificado por meio de técnicas de análise crítica, análise, simulação e teste utilizando procedimentos
escritos e especificações de teste, que devem ser realizados para confirmar se as funções do programa
aplicativo atendem ao SRS e se funções não intencionais não são executadas e se não há efeitos
colaterais não intencionais em relação à SIF. Deve ser abordado o seguinte:
● conformidade com as especificações de projeto do programa aplicativo, os meios e procedimentos

definidos e os requisitos de validação de segurança e planejamento de testes;
● envolvimento de todas as partes do programa aplicativo;
● envolvimento de uma faixa representativa de condições de dados;
● testes para condições de falha (isto é, testes negativos);
● temporização e sequência de execução;
● testes de comunicações de e para o SIS;
● integração do programa aplicativo off-line com o hardware do solucionador lógico e o PE subjacente;
● verificações do fluxo de dados interno para confirmar se o solucionador lógico não está apenas
aparentemente funcionando, mas também conforme o esperado;
● quando possível, integração do programa aplicativo e dispositivos de terceiros.
12.5.4 O mapeamento dos dados de E/S para o programa aplicativo, incluindo tipo de dados e faixa,
deve ser verificado.
12.5.5 Durante os testes, as modificações no programa aplicativo estarão sujeitas a uma análise
de impacto para determinar:
● todas as partes do programa aplicativo afetadas;
● as atividades necessárias de reprojeto e reverificação.

ABNT/CB-003
FEV 2024
12.5.6 Os resultados dos testes do programa aplicativo devem ser documentados e incluir:
● as versões do programa aplicativo e sua documentação de suporte sendo testadas;
● as versões do software de suporte e das ferramentas de teste;
● os nomes das pessoas que realizaram os testes, análises críticas e datas;

● as descrições dos testes, análises críticas e datas realizadas;
● os resultados dos testes;
● se o objetivo e os critérios dos testes foram cumpridos;
● se houve falha durante o teste, as razões pelas quais a falha ocorreu, a análise da falha e os registros
de sua correção e requisitos de reteste.
12.6 Requisitos para metodologia e ferramentas do programa aplicativo
12.6.1 O desenvolvimento do programa aplicativo deve cumprir as restrições do(s) manual(is)

de segurança aplicáveis.
NOTA Ao executar análises críticas dos manuais de segurança, se necessário para uma aplicação
específica, procedimentos adicionais e/ou restrições à utilização de metodologias e ferramentas podem ser
implementados.
12.6.2 Métodos, técnicas e ferramentas devem ser selecionados e aplicados para cada fase do ciclo
de vida, de modo a:
● minimizar o risco de introdução de falhas no programa aplicativo;
● revelar e remover falhas já existentes no programa aplicativo;
● assegurar, tanto quanto possível, que quaisquer falhas remanescentes no programa aplicativo
não levarão a resultados inaceitáveis;
● melhorar os meios de gestão das alterações do programa de aplicação ao longo da vida do SIS;
● apresentar evidências de que o programa aplicativo tem a qualidade requerida.
13 Teste de aceitação em fábrica (TAF)

13.1 Objetivos
13.1.1 O objetivo da Seção 13 é testar os dispositivos do SIS para assegurar o cumprimento

dos requisitos estabelecidos na SRS.
NOTA 1 Por meio de testes do solucionador lógico, dos softwares e hardwares associados antes da instalação,
os erros podem ser facilmente identificados e corrigidos.
NOTA 2 O TAF é referenciado algumas vezes como um teste de integração e pode ser parte da validação.
NOTA 3 O teste de elementos de campo junto com o solucionador lógico pode ser recomendado quando for
necessário haver uma alta confiança na operação antes da instalação final, por exemplo, aplicações submarinas.

ABNT/CB-003
FEV 2024
NOTA BRASILEIRA Requisitos sobre Testes de Aceitação em Fábrica (TAF), Testes de Aceitação
em Campo (TAC) e Testes de Integração em Campo (TIF) são apresentados na ABNT NBR IEC 62381,
Sistemas de automação na indústria de processo – Testes de Aceitação em Fábrica (TAF), Testes de Aceitação
em Campo (TAC) e Testes de Integração em Campo (TIC).
13.2 Recomendações
13.2.1 A necessidade de um TAF deve ser especificada durante o planejamento de segurança

do projeto.
NOTA 1 Uma estreita cooperação entre o fornecedor do solucionador lógico e do projetista contratado pode
ser necessária, a fim de desenvolver os testes de integração.
NOTA 2 As atividades seguem as fases de concepção e desenvolvimento e precedem a instalação

e o comissionamento.
NOTA 3 As atividades são aplicáveis aos subsistemas de um SIS com ou sem eletrônica programável.
NOTA 4 É normal que o TAF seja realizado no ambiente da fábrica antes da instalação e do comissionamento
na planta.
13.2.2 O plano de um TAF deve especificar o seguinte:
● Tipos de testes a serem realizados, incluindo testes de funcionalidade de sistemas tipo caixa-preta,
verificações internas; testes de desempenho; testes ambientais; testes de interface, testes
de degradação ou condições de falha, teste de exceção, testes para reação segura em caso
de falha de energia (incluindo reinicialização após a restauração da energia), aplicação dos
manuais de manutenção e de operação do SIS.
NOTA 1 O teste de funcionalidade “caixa-preta” é um método de teste de projeto que trata o

sistema como uma “caixa-preta”, por isso não usa explicitamente o conhecimento de sua estrutura
interna. Teste de projeto de caixa-preta é geralmente descrito como tendo foco no teste dos requisitos
de funcionalidade. Sinônimos para caixa-preta incluem teste comportamental, funcional, caixa opaca
ou testes de caixa fechada.
NOTA 2 Os testes de desempenho determinam se o sistema atende ao tempo, confiabilidade

e disponibilidade, integridade, metas e restrições de segurança.
NOTA 3 Os testes ambientais incluem EMC, testes de vida e de estresse.
NOTA 4 Verificações internas do fluxo de dados podem ser realizadas para confirmar se o SIS está
processando dados de entrada e gerando resposta de saída conforme especificado.
● Os casos de testes, a descrição e os dados de teste.
NOTA 5 Clareza na definição de quem é o responsável pelo desenvolvimento do caso de teste e quem
será o responsável por realizar o teste, e testemunhar o teste pode ser muito importante.
● A dependência de outros sistemas/interfaces.
● Ambiente e ferramentas de teste.
● Configuração do solucionador lógico, sensor e elemento final.

ABNT/CB-003
FEV 2024
● Critérios de teste pelos quais a conclusão do teste será julgada.
● Procedimentos para ações corretivas em caso de falha do teste.
● Teste de competências de pessoas.
● Localização física.
● Perigos apresentados pelos testes, especialmente no que diz respeito à energia armazenada;
● Um diagrama claro da configuração do teste.
● Registro de testes realizados, dados, resultados e observações enquanto os testes estão

sendo realizados.
NOTA 6 Testes que não podem ser demonstrados fisicamente normalmente são resolvidos por uma
linha de raciocínio formal quanto ao porquê de o SIS alcançar o requisito, meta ou restrição.
13.2.3 O TAF deve ser executado com uma versão definida do solucionador lógico.
13.2.4 O TAF deve ser executado de acordo com o plano de TAF. Os testes devem demonstrar que
toda a lógica é executada corretamente.
13.2.5 Para cada teste realizado deve ser abordado o seguinte:
● a versão do plano de teste utilizada;
● a SIF e a característica de desempenho a ser testada;
● os procedimentos detalhados de testes e descrições de teste;
● um registro cronológico das atividades de teste;
● as ferramentas, equipamentos e interfaces utilizadas.
13.2.6 Os resultados do TAF devem ser documentados, indicando:
● os casos de teste;
● os resultados do teste;
● se os objetivos e os critérios dos critérios de teste foram alcançados.
Se houver uma falha durante o teste, as razões para a falha devem ser documentadas e analisadas,
e é recomendado que medidas corretivas apropriadas sejam implementadas.
13.2.7 Durante o TAF, qualquer modificação ou alteração deve ser objeto de uma análise de segurança
para determinar:
● a extensão do impacto em cada SIF; e
● a extensão do teste e verificação que deve ser definida e implementada.
NOTA O comissionamento pode começar enquanto a ação corretiva é realizada, dependendo dos
resultados do TAF.

ABNT/CB-003
FEV 2024
14 Instalação e comissionamento do SIS

14.1 Objetivos
14.1.1 Os objetivos dos requisitos da Seção 14 são:
● instalar o SIS de acordo com as especificações e desenhos;

● comissionar o SIS para que esteja pronto para a validação final do sistema.
NOTA O objetivo das atividades de comissionamento é assegurar que cada um dos dispositivos SIS
esteja individualmente pronto para operar, conforme especificado na fase de projeto.
14.2 Requisitos
14.2.1 O plano de instalação e comissionamento deve determinar todas as atividades requeridas para
instalação e comissionamento. O plano deve conter o seguinte:
● as atividades de instalação e comissionamento;
● os procedimentos, medidas e técnicas a serem utilizadas para a instalação e comissionamento;
● quando estas atividades serão realizadas;
● as pessoas, departamentos e organizações responsáveis por estas atividades.
O plano de instalação e comissionamento pode ser integrado ao plano geral do projeto nos casos
apropriados.
14.2.2 Todos os dispositivos do SIS devem ser instalados de acordo com o(s) plano(s) de projeto
e instalação.
14.2.3 O SIS deve ser comissionado de acordo com o plano em preparação para a validação final
do sistema. As atividades de comissionamento devem incluir, mas não se limitar à confirmação
do seguinte:
● se conexões de aterramento (terra) foram executadas corretamente;
● se fontes de alimentação foram devidamente conectadas e estão operacionais;
● se limitadores para transporte e materiais de embalagem foram removidos;
● se nenhum dano físico está presente;
● se todos os instrumentos foram devidamente calibrados e configurados;
● se todos os dispositivos de campo estão operacionais;
● se solucionador lógico e entradas/saídas estão operacionais;
● se interfaces com outros sistemas e periféricos estão operacionais
● se todas as comunicações entre sistemas SIS remotos estão operacionais.
14.2.4 Registros adequados do comissionamento do SIS devem ser realizados, indicando

os resultados das atividades e se os objetivos e critérios identificados durante a fase de projeto foram
cumpridos. Se houver uma falha, as razões da falha devem ser registradas.

ABNT/CB-003
FEV 2024
14.2.5 Quando for estabelecido que a instalação real não está de acordo com as informações
de projeto, a diferença deve ser avaliada por uma pessoa competente e determinado o impacto
desta diferença sobre a segurança. Se for verificado que a diferença não tem impacto na segurança,
as informações de projeto devem ser atualizadas para o status de “conforme construído”.
Se a diferença tiver um impacto negativo sobre a segurança, a instalação deve ser modificada
para atender aos requisitos de projeto.
15 Validação de segurança do SIS

15.1 Objetivo
15.1.1 O objetivo dos requisitos da Seção 15 é validar, por meio de inspeção e testes, que o SIS
instalado e comissionado e suas SIF associadas alcançam os requisitos conforme indicados na SRS.
NOTA Algumas vezes este teste é referenciado como Teste de Aceitação em Campo (TAC).
15.2 Requisitos
15.2.1 O planejamento de validação do SIS deve ser realizado durante todo o ciclo de vida
de segurança do SIS e para determinar todas as atividades e equipamentos necessários para
a validação. As seguintes alíneas devem ser incluídas:
● as atividades de validação, incluindo a validação do SIS com relação à SRS, incluindo

a implementação e resolução de recomendações resultantes;
● a validação de todos os modos aplicáveis de operação do processo e dos seus equipamentos

associados, incluindo:
— preparação para utilização incluindo a configuração e ajuste;
— partida, automático, manual, semiautomático, em estado estacionário de operação;
— reconfiguração, parada, manutenção;
— outros modos identificados em fases anteriores do ciclo de vida de segurança do SIS;
● os procedimentos, medidas e técnicas a serem utilizadas para validação, incluindo a forma como
as atividades de validação podem ser realizadas, sem colocar a instalação e o processo em risco
dos eventos perigosos contra os quais o SIS deve proteger;
● as pessoas, departamentos e organizações responsáveis por estas atividades e os níveis

de independência para as atividades de validação;
● referência a informações contra as quais a validação deve ser confrontada (por exemplo, diagrama
de causa e efeito);
● os equipamentos e instalações que precisam ser instalados ou disponibilizados (por exemplo,

válvulas de bloqueio e equipamentos de detecção de vazamentos que serão necessários para
o teste de válvulas).
NOTA Exemplos de atividades de validação incluem testes de malha, teste de lógica, procedimentos
de calibração, simulação do programa da aplicação.

ABNT/CB-003
FEV 2024
15.2.2 O planejamento para a validação para o programa aplicativo deve incluir o seguinte:
● identificação das funções do programa aplicativo que precisa ser validado para cada modo
de operação de processo antes do início de comissionamento;
● estratégia técnica para a validação, incluindo (onde se for aplicável):

— técnicas manuais e automatizadas;
— técnicas estáticas e dinâmicas;
— técnicas analítica e estatística;
● de acordo com o item acima, as medidas (técnicas) e os procedimentos que serão utilizados
para confirmar se cada SIF está em conformidade com os requisitos de segurança especificados
e o SIL requerido;
● ambiente no qual as atividades de validação devem acontecer (por exemplo, para testes isto
inclui ferramentas e equipamentos calibrados);
● programa aplicativo;
● critérios de aprovação/falha para a realização de validação, incluindo:
— o processo necessário e sinais de operador de entrada com suas sequências e seus valores;
— os sinais de saída antecipada com suas sequências e seus valores;
— outros critérios de aceitação, por exemplo, a utilização de memória, tempo e valores de tolerância;
● políticas e procedimentos para a avaliação dos resultados da validação, em especial falhas;
● todos os documentos (ver Seção 19) são validados quanto à exatidão, consistência e rastreabilidade
da SIF desde o início, durante a H&RA, até a SIF final instalada.
15.2.3 Se a exatidão da medição for necessária como parte da validação, então é recomendado
que os instrumentos utilizados para esta função sejam calibrados contra uma especificação rastreável
feita com base em uma norma dentro de uma incerteza apropriada para a aplicação. Se essa calibração
não for viável, um método alternativo deve ser utilizado e documentado.
15.2.4 A validação do SIS e das SIF associadas deve ser realizada em conformidade com
o planejamento de validação do SIS. As atividades de validação devem incluir, mas não se limitar,
ao seguinte:
● a confirmação de que o SIS tem seu desempenho em modos de operação do processo normais
e anormais (por exemplo, partida, parada) conforme identificadas SRS;
● a confirmação de que a interação adversa do BPCS e outros sistemas conectados não afeta
o bom funcionamento do SIS;
● o SIS se comunica corretamente (quando necessário) com o BPCS ou qualquer outro sistema
ou rede, inclusive durante condições anormais, como sobrecarga de dados;

ABNT/CB-003
FEV 2024
● os sensores, solucionadores lógicos e elementos finais tem seus desempenhos em conformidade

com a SRS, incluindo todos os canais redundantes, inclusive durante condições anormais, como
sobrecarga de dados;
NOTA Se um teste de aceitação de fábrica (TAF) for executado nos solucionadores lógicos conforme
descrito na Seção 13, créditos devem ser tomados pela validação do solucionador lógico no TAF. Depois
que todos os equipamentos estiverem instalados na planta, a validação completa da malha testará
funcionalidade dos solucionadores lógicos e suas conexões com outros subsistemas do SIS.
● a documentação do projeto do SIS é consistente com o sistema instalado;
● a confirmação de que a SIF tem seu desempenho conforme especificado nos valores das variáveis
inválidas no processo (por exemplo, fora de faixa);
● a sequência apropriada de parada é ativada;
● o SIS apresenta os alarmes corretos e telas de operação adequadas;
● os cálculos computacionais que estão incluídos no SIS estão corretos para a faixa de valores
esperados, mas também nos limites e acima dos limites;
● as funções de reinicialização do SIS têm seu desempenho como definido na SRS;
● as funções de by-pass funcionam corretamente;
● os overrides de partida funcionam corretamente;
● os sistemas de parada manual funcionam corretamente;
● as políticas de intervalos de teste de prova estão documentadas nos procedimentos de manutenção;
● as funções de alarme de diagnóstico têm seu desempenho conforme requerido;
● a confirmação de que o SIS tem seu desempenho como exigido na perda de utilidades
(por exemplo, energia elétrica, de ar, sistema hidráulico) e a confirmação de que, quando
as utilidades são restauradas, o SIS retorna para o estado desejado;
● a confirmação de que foi alcançada a imunidade EMC, conforme especificado na SRS (ver 10.3).
15.2.5 A validação do programa aplicativo deve demonstrar que:
● todos os requisitos de segurança do programa aplicativo especificados (ver 10.3.2) são executados
de maneira correta;
● o programa aplicativo não compromete os requisitos de segurança em condições de falha

do SIS e nos modos degradados de operação e para condições de falha do BPCS para quaisquer
interfaces entre o SIS e o BPCS;
● o programa aplicativo não compromete os requisitos de segurança por executar uma funcionalidade
de software “não utilizada”, por exemplo, uma funcionalidade não definida na especificação.
As informações das atividades de validação devem estar disponíveis.
15.2.6 Os resultados das atividades do plano de validação devem representar e abranger todo
o processo de validação do SIS. Deve ser apresentada documentação de validação do SIS que inclua:
● a versão do planejamento de validação do SIS que está sendo utilizada;

ABNT/CB-003
FEV 2024
● as SIF em teste (ou análise), juntamente com a referência específica do requisito identificado
durante o planejamento de validação do SIS;
● as ferramentas e equipamentos utilizados, juntamente com os dados de calibração;
● os resultados de cada teste;

● a versão da especificação do ensaio utilizado;
● os critérios de aceitação dos testes finalizados;
● a versão do hardware, do programa aplicativo e qualquer outro software do SIS que está
sendo testado;
● qualquer discrepância entre os resultados esperados e reais e a resolução dessa discrepância;
● a análise feita e as decisões tomadas sobre a possibilidade de continuar o teste ou emitir uma
solicitação de alteração, no caso que discrepâncias ocorram.
15.2.7 Os resultados devem ser verificados em relação aos resultados esperados. Todas
as discrepâncias devem ser analisadas e as conclusões devem estar disponíveis como parte
da documentação de validação. Isto inclui a análise feita e as decisões tomadas quanto à continuação
da validação ou a emissão de uma solicitação de mudança para retornar para uma parte anterior
do ciclo de vida de desenvolvimento.
15.2.8 Após a validação do SIS e antes de os riscos identificados estarem presentes, as seguintes
atividades devem ser realizadas:
● todas as funções de by-pass (por exemplo, solucionadores lógicos PE e sensores PE forçados,

alarmes desabilitados) devem ser retornadas à sua posição normal;
● todas as válvulas de isolamento do processo devem ser configuradas de acordo com os requisitos
e procedimentos de partida do processo;
● todos os materiais de testes (por exemplo, fluidos) devem ser removidos;
● todos os overrides do comissionamento e permissões forçadas devem ser retirados.
16 Operação e manutenção do SIS

16.1 Objetivos
Os requisitos desta Seção 16 tem por objetivo determinar:
● o SIL requerido de cada SIF seja mantido durante a operação e manutenção;
● o SIS é operado e mantido de uma forma que sustente a integridade de segurança requerida.
16.2 Requisitos
16.2.1 O planejamento de operação e de manutenção do SIS deve ser desenvolvido e deve conter
o seguinte:
● atividades operacionais de rotina e anormais;

ABNT/CB-003
FEV 2024
● inspeção, testes de prova, atividades de manutenção preventiva e de parada não programada;
● procedimentos, medidas e técnicas a serem utilizados para a operação e manutenção;
● resposta operacional a avarias e falhas identificadas por diagnósticos, inspeções ou testes

de prova;
● verificação de conformidade aos procedimentos de operação e manutenção;
● pessoas, departamentos e organizações responsáveis por estas atividades;
● plano de manutenção do SIS.
NOTA O plano de manutenção do SIS pode indicar diferentes recursos de manutenção dependendo
do SIL.
16.2.2 Procedimentos de operação e manutenção devem ser desenvolvidos em conformidade com

o planejamento de segurança pertinente e devem apresentar o seguinte:
a) os métodos e procedimentos de rotina que precisam ser realizados para manter a segurança
funcional “conforme projetado” do SIS;
b) os procedimentos utilizados para assegurar a qualidade e consistência dos testes de prova

e para assegurar que a validação adequada esteja sendo realizada após a substituição
de qualquer dispositivo;
c) as medidas e restrições que são necessárias para evitar um estado inseguro e/ou reduzir
as consequências de um evento perigoso durante a manutenção ou operação (por exemplo,
quando um sistema precisa ser colocado em by-pass para testes ou manutenção, em que redução
de risco adicional precisa ser implementada);
d) os métodos e procedimentos utilizados para testar os diagnósticos;
e) as informações que precisam ser mantidas em caso de falha do sistema e as taxas de demanda
do SIS;
f) os procedimentos de coleta de dados relativos à taxa de demanda e aos parâmetros

de confiabilidade do SIS;
NOTA 1 A coleta e análise de dados de falhas trazem muitos benefícios, incluindo o potencial de reduzir
custos de manutenção, se as taxas de falhas em operação forem significativamente mais baixas do que
as previstas durante o projeto. Os custos de implementação de novas instalações também podem ser
reduzidos, porque os novos projetos podem basear-se em taxas de falha menos conservadoras.
g) as informações que precisam ser mantidas mostrando resultados de auditorias e testes do SIS;
h) os procedimentos de manutenção a serem seguidos quando ocorrem falhas ou defeitos

no SIS, incluindo:
● procedimentos para diagnóstico e reparo de falhas;
● procedimentos de revalidação;

ABNT/CB-003
FEV 2024
● requisitos de relatórios de manutenção;
● procedimentos para acompanhar o desempenho da manutenção.
NOTA 2 Considerações incluem:

— procedimentos para reportar falhas;
— procedimentos para analisar falhas sistemáticas;
— ações para permitir a parada segura em caso de falha do BPCS;
— assegurar que os equipamentos de testes estejam adequadamente calibrados e mantidos.
16.2.3 Os procedimentos operacionais devem ser disponibilizados. Devem ser aplicadas medidas
de compensação que garantam a segurança contínua enquanto o SIS estiver desativado ou degradado
devido a by-pass (reparação ou teste), com os limites de operação associados (duração, parâmetros
de processo etc.). O operador deve receber informações sobre os procedimentos a serem aplicados
antes e durante o by-pass, o que se recomenda que seja feito antes da remoção do by-pass e do tempo
máximo permitido para permanecer no estado de by-pass. Estas informações devem ser revisadas
regularmente.
NOTA Os procedimentos de operação e manutenção podem incluir a verificação de que os by-passes

foram removidos após o teste de prova.
16.2.4 A operação contínua do processo com um dispositivo SIS em by-pass somente é permitida
se uma análise de perigos tiver determinado que medidas de compensação estão em vigor
e apresentam redução de risco adequada. Os procedimentos operacionais devem ser desenvolvidos
em conformidade.
16.2.5 Operação e manutenção devem ser efetuadas em conformidade com os procedimentos

pertinentes.
16.2.6 Os operadores devem ser treinados sobre a função e operação do SIS na sua área. Esta
formação deve assegurar que eles entendam:
● como funciona o SIS (pontos de acionamento e a ação resultante que é tomada pelo SIS);
NOTA 1 Isso também pode incluir o impacto de uma ação do SIS no restante da operação da planta.
● o perigo que o SIS esteja protegendo;
● a correta operação e gerenciamento de todas as chaves de by-pass e override, e sob que

circunstâncias devem ser utilizadas;
● a operação de quaisquer chaves de parada manual e atividades de partida manual e quando

essas chaves manuais devem ser ativadas;
NOTA 2 Isto pode incluir “reiniciar o sistema” e “repartir o sistema”.
● a expectativa na ativação de qualquer alarme de diagnóstico (por exemplo, quais medidas devem
ser tomadas quando algum alarme do SIS for ativado indicando que há um problema com o SIS);
● a verificação adequada do diagnóstico.

ABNT/CB-003
FEV 2024
16.2.7 O estado de todos os by-passes deve ser registrado em um registro de by-pass. Todos
os by-passes necessitam de autorização e indicação.
16.2.8 O pessoal de manutenção deve ser treinado conforme necessário para manter o pleno
desempenho funcional do SIS (hardware e software), para atingir o SIL requerido de cada SIF.
16.2.9 As discrepâncias entre o comportamento esperado e o comportamento real do SIS devem

ser analisadas e, se necessário, modificações devem ser feitas de forma que a segurança necessária
seja mantida. Isto deve incluir o acompanhamento do seguinte:
● taxa de demanda de cada SIF (ver 5.2.5.3);
● ações tomadas na sequência de uma demanda no sistema;
● falhas e modos de falha dos equipamentos que fazem parte do SIS, incluindo aqueles identificados
durante a operação normal, inspeção, testes ou demanda de cada SIF;
● causa das demandas;
● causa e frequência dos acionamentos espúrios;
● falha de equipamentos que façam parte de quaisquer medidas compensatórias.
16.2.10 Os procedimentos de operação e manutenção podem requerer revisão, se necessário, seguindo:
● auditorias de segurança funcional;
● testes no SIS;
● experiência de eventos normais ou anormais de operação e manutenção.
16.2.11 Procedimentos escritos de teste de prova devem ser desenvolvidos para cada SIF, para
revelar falhas perigosas não detectadas por diagnósticos. Estes procedimentos escritos de teste
devem descrever cada passo a ser executado e devem incluir:
● correto funcionamento de cada sensor e elemento final;
● ação lógica correta;
● alarmes corretos e indicações.
NOTA Os seguintes métodos podem ser utilizados para determinar as falhas não detectadas
que precisam ser testadas:
— análise de árvores de falhas;
— análise do modo de falha e efeito;
— manutenção centrada em confiabilidade.
16.2.12 As peças sobressalentes do SIS devem ser identificadas e disponibilizadas para minimizar
a duração do by-pass devido à indisponibilidade de qualquer peça de reposição para o SIS.
NOTA As substituições que não sejam da mesma espécie (iguais) podem ser gerenciadas como uma
modificação no SIS.

ABNT/CB-003
FEV 2024
16.2.13 As pessoas responsáveis pelas operações e pela manutenção devem fazer a análise crítica
de perigo e risco, alocação e projeto para assegurar que as suposições feitas sejam válidas, por
exemplo, suposições sobre ocupação e proteção contra corrosão.
16.3 Teste de prova e inspeção

16.3.1 Teste de prova
16.3.1.1 Testes de prova periódicos devem ser realizados por meio de um procedimento escrito que
revele falhas não detectadas que impeçam o funcionamento do SIS em conformidade com a SRS.
NOTA 1 Atenção especial pode ser dada para identificar causas de falha que podem levar a falhas
de causa comum.
NOTA 2 Os procedimentos de teste de prova também podem enfatizar a necessidade de evitar a introdução
de falhas de causa comum.
16.3.1.2 O conjunto SIS deve ser testado, incluindo os sensores, o solucionador lógico e os elementos
finais (por exemplo, válvulas de parada de processo e desligamento de motores).
NOTA O teste do SIS pode ser realizado de “ponta a ponta” ou em segmentos (ver 11.8.1).
16.3.1.3 O cronograma dos testes de prova deve estar de acordo com a SRS. A frequência dos
testes de prova deve ser determinada pelo cálculo de PFDavg ou PFH, de acordo com 11.9 para o SIS
instalado no ambiente operacional.
NOTA Diferentes partes do SIS podem requerer intervalos de teste diferentes, por exemplo, o solucionador
lógico pode requerer um intervalo de teste diferente dos sensores e elementos finais.
16.3.1.4 Qualquer deficiência encontrada durante o teste funcional deve ser reparada de forma segura
e em tempo hábil. Um teste de prova deve ser repetido após a conclusão do reparo.
16.3.1.5 Em algum intervalo periódico (determinado pelo usuário), a frequência dos testes deve ser
reavaliada com base em vários fatores, incluindo dados históricos de testes, a experiência da planta
e degradação do hardware.
NOTA O usuário pode ajustar a frequência de teste com base nesses dados e em uma análise da base
original da frequência de teste.
16.3.1.6 Qualquer alteração no programa aplicativo requer validação completa e um teste de prova
de qualquer SIF impactado pela alteração. As exceções são permitidas se as análises críticas
adequadas e os testes parciais das mudanças forem realizados para assegurar que as mudanças
foram projetadas de acordo com os requisitos de segurança atualizados e implementadas corretamente.
16.3.1.7 Procedimentos de gestão adequados devem ser aplicados para rever adiamentos e evitar
atrasos significativos nos testes de prova.
16.3.2 Inspeção
Cada SIS deve ser periodicamente inspecionado visualmente para assegurar que não existam
modificações não autorizadas e que não exista deterioração detectável (por exemplo, parafusos
ou invólucro de instrumento em falta, suportes enferrujados, fios abertos, eletrodutos quebrados,
traços de aquecimento quebrados e falta de isolamento).
NOTA Esses problemas podem indicar um aumento na frequência de falhas.

ABNT/CB-003
FEV 2024
16.3.3 Documentação de testes de prova e inspeção
O usuário deve manter registros que indiquem que os testes de prova e as inspeções foram concluídos
como requerido. Esses registros devem incluir no mínimo as seguintes informações:
a) descrição dos testes e inspeções realizadas, incluindo a identificação do procedimento

de teste utilizado;
b) datas dos testes e inspeções;
c) nome(s) da(s) pessoa(s) que realizou(aram) os testes e inspeções;
d) número de série ou outro identificador único do sistema testado (por exemplo, o número da malha,
número do tag, número de equipamento e número da SIF);
e) resultados dos testes e inspeções (por exemplo, condições “como encontrado”, todas as falhas
encontradas (incluindo o modo de falha) e condição “como deixado”).
17 Modificações do SIS
17.1 Objetivos
Os objetivos dos requisitos da Seção 17 são:
● que as modificações em qualquer SIS sejam devidamente planejadas, verificadas, aprovadas

e documentadas antes de fazer a mudança;
● assegurar que a integridade de segurança requerida do SIS seja mantida, apesar de todas
as alterações feitas no SIS.
NOTA Modificações no BPCS e outros equipamentos, processos ou condições de operação podem

ser revistas para determinar se elas são de forma que a natureza ou a frequência de demandas no SIS
seja afetada. Aquelas que têm efeitos adversos podem ter considerações adicionais para determinar
se o nível de redução de risco continuará a ser suficiente.
17.2 Requisitos
17.2.1 Antes de efetuar qualquer modificação de um SIS, devem ser colocados em prática
procedimentos de autorização e controle de mudanças.
17.2.2 Os procedimentos devem incluir um método claro para identificar e solicitar os trabalhos
a serem realizados e os perigos que podem ser afetados.
17.2.3 Antes de realizar qualquer modificação em um SIS (incluindo o programa aplicativo), uma
análise deve ser efetuada para determinar o impacto na segurança funcional como resultado
da modificação proposta. Quando a análise mostrar que a modificação proposta pode causar impacto
na segurança, então se deve retornar para a primeira fase do ciclo de vida de segurança do SIS
afetado pela modificação.
17.2.4 O planejamento de segurança para a modificação e reverificação deve estar disponível.

Modificações e reverificações devem ser realizadas de acordo com o planejamento.
17.2.5 Toda a documentação afetada pela modificação deve ser atualizada.

ABNT/CB-003
FEV 2024
17.2.6 Atividades de modificação não podem ser iniciadas até que uma FSA seja concluída de acordo
com 5.2.6.1.9 e após a devida autorização.
17.2.7 A informação apropriada deve ser mantida para todas as mudanças no SIS. Esta informação
deve incluir
● uma descrição da modificação ou mudança;
● razão da mudança;
● perigos identificados que podem afetar as SIF;
● uma análise do impacto da atividade de modificação no SIS;
● todas as aprovações requeridas para as mudanças;
● testes utilizados para verificar se a mudança foi implementada apropriadamente e se o SIS tem
desempenho conforme requerido;
● detalhes de todas as atividades de modificação do SIS (por exemplo, um registro de modificações);
● histórico de configuração apropriado;
● testes utilizados para verificar se as mudanças não afetam adversamente partes do SIS que não
foram modificadas.
17.2.8 Modificações devem ser executadas com pessoal qualificado apropriadamente treinado.
É recomendado que todo o pessoal relacionado e envolvido seja notificado da mudança e treinado
em relação a ela.
18 Descomissionamento do SIS
18.1 Objetivos
Os requisitos desta Seção 18 tem por objetivo determinar:
● antes do descomissionamento de qualquer SIS do serviço ativo, uma revisão apropriada seja
conduzida e a autorização requerida seja obtida; e
● as SIF requeridas permaneçam operacionais durante as atividades de descomissionamento.
18.2 Requisitos
18.2.1 Antes de executar qualquer atividade de descomissionamento de parte ou de todo um SIS

ou SIF, os procedimentos de autorização e controle de mudanças devem ser efetuados.
18.2.2 Os procedimentos devem incluir um método claro de identificação e requisição do trabalho

a ser realizado e de identificação dos perigos que podem afetados.
18.2.3 Uma análise deve ser executada para avaliar o impacto na segurança funcional como resultado
das atividades de descomissionamento propostas. Esta avaliação deve incluir uma atualização
da H&RA suficiente para determinar o âmbito do impacto no ciclo de vida de segurança do SIS.

ABNT/CB-003
FEV 2024
As fases subsequentes do ciclo de vida de segurança do SIS têm de ser reavaliadas. A avaliação deve
também considerar:
● a segurança funcional durante a execução das atividades de descomissionamento;
● o impacto do descomissionamento de um SIS nas unidades operacionais e instalações adjacentes.

18.2.4 Os resultados da análise de impacto devem ser utilizados durante o planejamento de segurança
para reimplementar os requisitos aplicáveis da série IEC 61511, incluindo a reverificação e revalidação.
18.2.5 Atividades de descomissionamento não podem ser iniciadas sem a documentação

e a autorização apropriadas.
19 Informação e requisitos de documentação

19.1 Objetivos
Os objetivos dos requisitos da Seção 19 são assegurar que a informação necessária está disponível
e documentada de modo que:
● todas as fases do ciclo de vida de segurança do SIS possam ser efetivamente desempenhadas; e
● as atividades de verificação, validação e de avaliação da segurança funcional possam ser

desempenhadas efetivamente.
19.2 Requisitos
19.2.1 A documentação requerida pela série IEC 61511 deve estar disponível ao pessoal que
implementa os requisitos da série IEC 61511.
19.2.2 A documentação deve:
● descrever a instalação, sistema ou equipamento e a sua utilização;
● ser exata e estar atualizada;
● ser de fácil entendimento;
● ser adequada ao propósito pretendido;
● estar disponível de forma acessível, atualizada e editável, para que documentos apropriados
e aplicáveis possam ser identificados, localizados, recuperados e revisados com rapidez e exatidão.
NOTA Mais detalhes sobre os requisitos de informações estão incluídos nas Seções 14 e 15.
19.2.3 A documentação deve possuir identidades únicas para ser possível referenciar as diferentes partes.
19.2.4 A documentação deve ter designações que indiquem o tipo de informação.
19.2.5 A documentação deve ser rastreável aos requisitos funcionais e de integridade desta Norma,
incluindo a H&RA.
19.2.6 A documentação deve ter um índice de revisão (números da versão) para tornar possível
identificar as diferentes versões da informação.

ABNT/CB-003
FEV 2024
19.2.7 A documentação deve ser estruturada para tornar possível a busca por informações pertinentes.
Deve ser possível identificar a última revisão (versão) de um documento.
NOTA A estrutura física da documentação pode variar dependendo de um número de fatores, como
o tamanho do sistema, sua complexidade e os requisitos de organização.
19.2.8 Todas as documentações aplicáveis devem ser revisadas, aditadas, revistas e aprovadas,
e devem estar sob o controle de um sistema de informação apropriado.
19.2.9 A documentação atual pertinente ao seguinte deve ser mantida:
a) resultados da H&RA e as suposições relacionadas;
b) equipamento utilizado para a SIF junto com os requisitos de segurança;
c) organização responsável por manter a segurança funcional;
d) procedimentos necessários para atingir e manter a segurança funcional do SIS;
e) informação de modificação conforme definido em 17.2.5;
f) manual(is) de segurança
g) projeto, implantação, teste e validação
NOTA Detalhes adicionais destes requisitos para informação estão incluídos em 12.4.2, nas Seções
14 e 15 e em 16.3.3.

ABNT/CB-003
FEV 2024
Bibliografia
[1] IEC 60050 (todas as partes), International Electrotechnical Vocabulary (disponível

em http://www.electropedia.org/)
[2] ISO/IEC Guide 51:2014, Safety aspects – Guidelines for their inclusion in standards
[3] IEC 60300-3-2:2004, Dependability management – Part 3-2: Application guide – Collection
of dependability data from the field
[4] IEC 60605-4:2001, Equipment reliability testing – Part 4: Statistical procedures for exponential
distribution – Point estimates, confidence intervals, prediction intervals and tolerance intervals
[5] IEC 60617-12:1997, Graphical symbols for diagrams – Part 12: Binary logic elements
[6] IEC TS 61000-1-2:2008, Electromagnetic compatibility (EMC) – Part 1-2: General – Methodology
for the achievement of functional safety of electrical and electronic systems including equipment
with regard to electromagnetic phenomena
[7] IEC 61025, Fault tree analysis (FTA)
[8] IEC 61131-3:2013, Programmable controllers – Part 3: Programming language
[9] IEC 61131-6:2012, Programmable controllers – Part 6: Functional Safety
[10] IEC 61506:1997, Industrial-process measurement and control – Documentation of application

Software
[11] IEC 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety

related systems – Part 4: Definitions and abbreviations
[12] IEC 61508-6:2010, Functional safety of electrical/electronic/programmable electronic safety

related systems – Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
[13] IEC 61511-2:2016, Functional safety – Safety instrumented systems for the process industry
sector – Part 2: Guidelines for the application of IEC 61511-1:2016
[14] IEC 61511-3:2016, Functional safety – Safety instrumented systems for the process industry
sector – Part 3: Guidance for the determination of the required safety integrity levels
[15] IEC 61784-3:2010, Industrial communication networks – Profiles – Part 3: Functional safety
fieldbuses – General rules and profile definitions
[16] IEC 62443-2-1:2010, Industrial communication networks – Network and system security – Part 2-1:
Establishing an industrial automation and control system security program
[17] IEC 62682:2014, Management of alarms for the process industry
[18] IEC/ISO 2382:2006, Information technology – Vocabulary

ABNT/CB-003
FEV 2024
[19] ISO/IEC 27001:2013, Information technology – Security techniques – Information security

management systems – Requirements
[20] ISO/IEC 90003:2014, Software engineering – Part 3: Guidelines for the application
of ISO 9001:2000 to computer software
[21] IEC/ISO 2382-1:1993, Information technology – Vocabulary – Part 1: Fundamental terms
[22] ISO 9000:2005, Quality management systems -- Fundamentals and vocabulary
[23] ISO 9001:2008, Quality management systems – Requirements
[24] ISO TR 12489:2013, Petroleum, petrochemical and natural gas industries – Reliability modelling
and calculation of safety systems
[25] ISO 13849-1:2006, Safety of machinery – Safety related parts of control systems – Part 1: General
principles for design
[26] ISO 13849-2:2012, Safety of machinery – Safety related parts of control systems – Part 2:
Validation
[27] ISO 14224:2006, Petroleum, petrochemical and natural gas industries- Collection and exchange
of reliability and maintenance of data for equipment
[28] ISA TR 84.00.04 Part 1:2015, Guidelines on the Implementation of ANSI/ISA-84.00.01-2004

(IEC 61511)
[29] ISA TR 84.00.09:2013, Security Countermeasures Related to Safety Instrumented Systems (SIS)

ABNT NBR IEC 61511 1 Sistemas Instrumentados de Seguran A 1707398384

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ABNT NBR IEC 61511 1 Sistemas Instrumentados de Seguran A 1707398384

Enviado por

Direitos autorais:

Formatos disponíveis

ABNT/CB-003

PROJETO ABNT NBR IEC 61511-1

Segurança funcional — Sistemas instrumentados de segurança

b) não tem valor normativo.

3) Analista ABNT – Newton Ferraz.

NÃO TEM VALOR NORMATIVO

Segurança funcional — Sistemas instrumentados de segurança

A Associação Brasileira de Normas Técnicas (ABNT) é o Foro Nacional de Normalização. As Normas

Os Documentos Técnicos internacionais adotados são elaborados conforme as regras da

NÃO TEM VALOR NORMATIVO

O Escopo da ABNT NBR IEC 61511-1 em inglês é o seguinte:

NÃO TEM VALOR NORMATIVO

padrões e níveis de desempenho mínimos.

NÃO TEM VALOR NORMATIVO

Figura 1 – Estrutura geral da série IEC 61511

NÃO TEM VALOR NORMATIVO

Segurança funcional — Sistemas instrumentados de segurança

A ABNT NBR IEC 61511-1, em particular:

g) resulta na identificação dos requisitos funcionais e requisitos de integridade de segurança da SIF,

NÃO TEM VALOR NORMATIVO 1/91

h) especifica os requisitos do ciclo de vida para arquitetura do sistema e configuração de hardware,

i) especifica os requisitos de programação do aplicativo para usuários e integradores de SIS;

de pessoas, proteção do público em geral ou proteção do meio ambiente;

p) especifica requisitos mínimos para tolerância a falha do hardware (HFT);

q) especifica técnicas e medidas requeridas para se atingir o SIL especificado;

s) determina um nível mínimo de desempenho de segurança funcional (SIL 1) abaixo do qual

v) determina a informação que é necessária durante o ciclo de vida de segurança do SIS;

w) especifica que o projeto de um SIS considere os fatores humanos;

x) não associa algum requisito direto sobre o operador individual ou mantenedor.

2/91 NÃO TEM VALOR NORMATIVO

NÃO TEM VALOR NORMATIVO 3/91

4/91 NÃO TEM VALOR NORMATIVO

Figura 4 – Relacionamento entre funções instrumentadas de segurança e outras funções

IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related

IEC 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safety-related

IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related

NÃO TEM VALOR NORMATIVO 5/91

3 Termos, definições e abreviaturas

Os termos são apresentados em 3.2.

3.2 Termos e definições

Para os efeitos deste documento, aplicam-se os seguintes termos e definições.

Nota 1 de entrada: Exemplos de by-pass incluem:

6/91 NÃO TEM VALOR NORMATIVO

— uma linha de by-pass físico é instalada em torno do elemento final;

NÃO TEM VALOR NORMATIVO 7/91

Nota 1 de entrada: As falhas no modo comum podem ter causas diferentes.

Nota 1 de entrada: Componente também inclui software.

8/91 NÃO TEM VALOR NORMATIVO

Nota 1 de entrada: Dois eventos A e B são dependentes, se a probabilidade da ocorrência de A e B, P (A e B)

Nota 3 de entrada: Falhas dependentes incluem causa comum.

Nota 1 de entrada: Existem algumas diferenças na utilização destes termos:

NÃO TEM VALOR NORMATIVO 9/91

manter a segurança do processo.

Nota 1 de entrada: Exemplos são sensores, elementos finais e chaves manuais.

Nota 1 de entrada: Cobertura de diagnóstico é normalmente aplicada a dispositivos de SIS ou subsistemas

λDD = DC × λDT e λDU = (1-DC) × λDT

10/91 NÃO TEM VALOR NORMATIVO

[FONTE: IEC 60050-192:2015, 192-03-02]

Nota 3 de entrada: O desempenho das funções requeridas necessariamente exclui determinados

[FONTE: IEC 60050-192:2015, 192-03-01, modificada – Notas da entrada foram alteradas.]

[FONTE: IEC 60050-192:2015, 192-03-17]

NÃO TEM VALOR NORMATIVO 11/91

— improbabilidade técnica de ocorrência de algumas falhas,