Sistema Instrumentado de Segurança (SIS): SIF e arquitetura

Entenda o que é SIS, diferença entre SIS, SIF e SIL, arquitetura, SRS, independência, FAT, SAT, validação, proof tests e governança segundo a IEC 61511.

Confira!

Um Sistema Instrumentado de Segurança (SIS, Safety Instrumented System) é um sistema de instrumentação e automação destinado a executar uma ou mais Funções Instrumentadas de Segurança (SIF) para levar ou manter um processo em estado seguro quando condições perigosas são detectadas. Em aplicações da indústria de processo, o SIS não é apenas um PLC dedicado: cada SIF envolve a cadeia completa de sensores, lógica, elementos finais, interfaces, alimentação, diagnóstico, testes, procedimentos e gestão ao longo do ciclo de vida. A IEC 61511 estabelece requisitos para especificação, projeto, instalação, operação e manutenção desses sistemas. O valor técnico do SIS está na redução de risco efetivamente demonstrável, na independência em relação às causas que podem iniciar o cenário e na capacidade de cumprir a função de segurança quando demandada.

O que é um Sistema Instrumentado de Segurança

O SIS é uma camada instrumentada de proteção empregada quando a análise de risco demonstra que controles de processo, alarmes, barreiras mecânicas, procedimentos e demais salvaguardas não reduzem determinado risco até o critério definido pela organização. Sua finalidade não é otimizar produção, aumentar rendimento ou executar o controle regulatório normal. Sua finalidade é atuar diante de condições previamente especificadas para impedir ou limitar uma consequência perigosa.

Na terminologia de Segurança Funcional, o SIS pode conter várias SIFs. Cada SIF atende um cenário ou requisito de segurança específico e possui um desempenho requerido, frequentemente expresso por SIL quando aplicável. Por isso, dizer que uma planta “tem um SIS SIL 2” sem identificar quais funções possuem esse requisito pode ocultar uma modelagem inadequada. O nível de integridade é atribuído à função, e não ao sistema inteiro como rótulo comercial.

SIS, SIF e SIL são conceitos diferentes

SIS é o sistema instrumentado que implementa funções de segurança. SIF é uma função específica que detecta uma condição e executa uma ação de segurança. SIL é uma medida discreta do nível de integridade requerido ou atingido por determinada SIF dentro das condições estabelecidas pela norma e pelo projeto.

Exemplo conceitual: um transmissor detecta pressão excessiva em um vaso; o logic solver processa o sinal; válvulas de bloqueio fecham e uma alimentação é interrompida. Essa cadeia pode constituir uma SIF. O conjunto de várias funções, sua infraestrutura e os recursos associados compõem o SIS.

Relação entre processo, SIF e componentes de um Sistema Instrumentado de Segurança

SIS não é o mesmo que BPCS

O BPCS, Basic Process Control System, executa o controle básico do processo: malhas regulatórias, sequências normais, supervisão, receitas, permissivos operacionais e diversas funções necessárias à produção. O SIS atua como camada de proteção para funções de segurança definidas.

A distinção arquitetural importa porque uma mesma falha não deve invalidar simultaneamente o controle normal e a proteção que deveria responder à perda desse controle. Compartilhamento de sensores, comunicação, alimentação, software, estações de engenharia ou infraestrutura pode introduzir dependências que precisam ser avaliadas. Separação física absoluta não é a única forma de alcançar independência, mas qualquer compartilhamento precisa ser tecnicamente justificado e compatível com os requisitos da aplicação.

Como uma necessidade de SIS é identificada

A necessidade de uma SIF deve permanecer rastreável desde o cenário de risco até a SRS. A Engenharia Consultiva pode organizar estudos, responsabilidades e critérios antes da contratação do integrador.

Conheça a Consultoria Técnica de Engenharia

Um SIS não deve nascer da escolha de um fabricante ou da preferência por um “Safety PLC”. A necessidade surge do processo de identificação e avaliação de perigos. HAZID pode revelar perigos em estágios iniciais; HAZOP aprofunda desvios de processo; LOPA pode verificar se as camadas independentes de proteção existentes são suficientes e quantificar, de forma semiquantitativa, a redução adicional necessária.

Quando o risco residual permanece acima do critério adotado, uma SIF pode ser especificada para fornecer parte da redução requerida. A decisão deve permanecer rastreável desde o cenário de risco até o requisito funcional.

Do cenário de perigo à SIF

Um encadeamento tecnicamente saudável é:

identificar o perigo e a consequência;
definir o cenário e seus eventos iniciadores;
avaliar salvaguardas e camadas independentes existentes;
comparar o risco mitigado com o critério de tolerabilidade;
definir a redução adicional necessária;
estabelecer a função de segurança apropriada;
especificar o SIL requerido quando aplicável;
registrar requisitos na SRS;
projetar, verificar, testar e validar a função.

A criação de uma SIF sem esse vínculo pode gerar tanto subproteção quanto sobre-especificação. Uma função excessivamente complexa pode aumentar indisponibilidade, manutenção, disparos espúrios e custo sem benefício proporcional de risco.

Arquitetura de uma SIF

A representação clássica de uma SIF possui três subsistemas: sensor, logic solver e elemento final. Essa simplificação é útil, mas o desempenho real depende de componentes auxiliares e condições de instalação que frequentemente são ignorados em análises superficiais.

Subsistema de sensores

O subsistema sensor identifica a variável ou condição que demanda a ação. Pode incluir transmissores de pressão, temperatura, nível ou vazão; detectores de gás e chama; chaves; posicionadores; entradas digitais; condicionamento de sinal; barreiras; isoladores; alimentação e infraestrutura de campo.

O projeto precisa considerar faixas, precisão, tempo de resposta, ambiente, diagnóstico, cobertura de teste, modo de falha, calibração, instalação, linhas de impulso, possibilidade de entupimento, congelamento, corrosão ou condições que tornem a medição não representativa do processo.

Redundância de sensores pode aumentar tolerância a falhas, mas sensores aparentemente independentes podem sofrer causa comum quando compartilham tomada de processo, tecnologia, localização, alimentação, rota de cabo ou vulnerabilidade ambiental.

Logic solver

O logic solver recebe sinais, executa a lógica da SIF e comanda ações. Pode ser uma plataforma dedicada de segurança, sistema eletrônico programável apropriado ou outra arquitetura aceita pela aplicação. Sua seleção precisa ser compatível com os requisitos de Segurança Funcional, arquitetura, capacidade diagnóstica, ciclo de vida do software e ambiente de operação.

A lógica deve ser controlada por processo formal de configuração: requisitos aprovados, versionamento, segregação de acesso, revisão, testes, backup, gestão de mudanças e rastreabilidade entre SRS, causa e efeito, código e resultados dos testes.

Elementos finais

O elemento final é frequentemente a parcela dominante do risco de falha de uma SIF. Válvulas, atuadores, solenoides, contatores, relés, dampers, sistemas de trip e outros dispositivos precisam efetivamente conduzir o processo ao estado seguro.

Uma válvula pode possuir controlador certificado e ainda assim falhar por travamento mecânico, dimensionamento incorreto, baixa pressão de ar, posição de falha inadequada, solenoide degradado, bypass aberto ou manutenção deficiente. Segurança Funcional não pode ser reduzida ao certificado eletrônico de um componente.

Estado seguro e ação da SIF

A especificação deve definir o que significa “estado seguro” para o cenário analisado. Em alguns casos significa fechar alimentação; em outros, abrir alívio, parar compressor, desenergizar aquecimento, iniciar ventilação, manter circulação, transferir material ou executar uma sequência coordenada.

O estado seguro não é necessariamente “tudo desligado”. Um desligamento indiscriminado pode criar consequência pior. Portanto, a função deve derivar da análise do processo, das condições transitórias e das interfaces com outros sistemas.

Tempo de segurança do processo

A SIF precisa responder dentro do tempo disponível antes que a condição perigosa se desenvolva. Isso envolve tempo de detecção, filtragem, processamento, comunicação, atuação do elemento final e dinâmica física do processo.

Se o processo alcança condição intolerável em poucos segundos, uma cadeia com atraso excessivo é inadequada mesmo que seus componentes tenham alta confiabilidade. O requisito temporal deve estar na SRS e ser verificado em testes.

Safety Requirements Specification — SRS

A SRS é um dos documentos centrais do ciclo de Segurança Funcional. Ela transforma resultados da análise de risco em requisitos verificáveis para cada SIF. Não deve ser confundida com uma lista de I/O nem com uma matriz causa e efeito simplificada.

Uma SRS robusta normalmente estabelece, conforme aplicabilidade:

identificação e objetivo da SIF;
perigos e cenários associados;
entradas e condições de demanda;
ações e estado seguro;
SIL requerido;
tempo de resposta;
lógica e votação;
requisitos de reset e rearme;
condições de bypass e override;
comportamento em falhas detectadas;
requisitos de independência;
interfaces com BPCS e outros sistemas;
proof test e intervalo associado;
requisitos de diagnóstico e alarmes;
ambiente, alimentação e comunicação;
critérios de validação;
restrições operacionais e de manutenção.

A SRS deve permitir que outra equipe leia o requisito e consiga projetar, testar e verificar a função sem depender de memória informal de reuniões.

Fluxo de requisitos desde a análise de risco até a validação de uma SIF

Matriz de causa e efeito no SIS

A matriz de causa e efeito é útil para sintetizar relações entre eventos, condições e ações. Em projetos industriais, ela melhora comunicação entre processo, automação, instrumentação, elétrica, operação e integrador.

Entretanto, a matriz não contém necessariamente todos os requisitos funcionais. Ela pode não registrar tempo de resposta, critérios de votação, comportamento de falhas, intervalos de teste, bypasses, prioridades, reset, requisitos de independência ou condições de operação degradada. Por isso, deve ser tratada como parte da documentação, não como substituta automática da SRS.

Intertravamento, permissivo e SIF

Nem todo intertravamento é uma SIF. Muitas lógicas de intertravamento existem para proteção de equipamento, sequência operacional, qualidade, disponibilidade ou prevenção de operação incorreta. Para que uma função seja tratada como SIF, ela precisa estar vinculada a um requisito de Segurança Funcional dentro do processo de avaliação de risco.

Da mesma forma, um permissivo que impede partida fora de condição pode ser importante, mas não recebe automaticamente crédito de redução de risco. É necessário verificar independência, confiabilidade, especificação, teste e governança compatíveis com o papel atribuído à função.

SIL e desempenho da SIF

O SIL especifica faixas de desempenho para funções relacionadas à segurança. Em modo de baixa demanda, a análise frequentemente usa PFDavg; em alta demanda ou modo contínuo, outros parâmetros são aplicáveis. O valor requerido deriva da redução de risco necessária, não do SIL máximo que um fabricante consegue oferecer.

A verificação da SIF considera a cadeia completa. Taxas de falha, cobertura diagnóstica, intervalo de proof test, cobertura do teste, arquitetura, falha de causa comum, tempo de reparo, restrições arquiteturais e capacidade sistemática influenciam o resultado.

Safety PLC não define sozinho o SIL

Uma controladora capaz de uso em aplicações SIL 3 não transforma automaticamente uma função em SIL 3. Sensores e elementos finais podem não atender ao desempenho necessário; intervalos de teste podem estar incompatíveis; falha de causa comum pode invalidar a premissa; a SRS pode estar incompleta; o software de aplicação pode não ter sido desenvolvido e validado adequadamente.

Esse é um dos motivos pelos quais aquisição baseada apenas em certificado de produto é insuficiente.

Independência entre SIS e BPCS

Independência é uma propriedade de engenharia, não apenas uma separação de gabinetes. Deve-se examinar se a mesma causa pode comprometer o sistema que inicia ou controla o cenário e a camada que deveria protegê-lo.

Fontes de dependência incluem:

sensores ou tomadas de processo compartilhados;
fonte de alimentação comum;
rede ou infraestrutura de comunicação comum;
estações de engenharia compartilhadas;
credenciais e administração comuns;
software ou bibliotecas comuns;
rotas de cabos expostas ao mesmo evento;
condições ambientais comuns;
manutenção que indisponibiliza simultaneamente BPCS e SIS.

A avaliação precisa considerar o cenário específico. Compartilhamento pode ser aceitável em algumas arquiteturas e inadequado em outras.

Falha segura e falha perigosa

Uma falha que leva o processo a uma condição segura pode reduzir disponibilidade e provocar trip espúrio, mas não tem o mesmo significado de uma falha perigosa não detectada, na qual a SIF permanece aparentemente disponível e falha quando demandada.

O projeto procura controlar ambos os efeitos: manter baixa probabilidade de falha perigosa e evitar indisponibilidade excessiva. Uma arquitetura que dispara continuamente pode ser tecnicamente insustentável porque incentiva bypasses e deteriora confiança da operação.

Disparos espúrios e disponibilidade

A Segurança Funcional não deve ser otimizada isoladamente de operabilidade. Trips espúrios frequentes podem causar perdas de produção, transientes, desgaste de equipamentos e comportamentos operacionais adversos.

Redundância, votação e diagnóstico podem equilibrar segurança e disponibilidade, mas cada escolha cria novas dependências e requisitos de teste. A arquitetura deve ser fundamentada em risco, dados de confiabilidade, condições de processo e filosofia operacional.

Proof test e testes periódicos

Falhas perigosas ocultas precisam ser reveladas por testes. O proof test é desenhado para detectar falhas que o diagnóstico automático não identifica. O intervalo entre testes influencia diretamente a probabilidade de falha sob demanda em muitas arquiteturas.

Um plano de proof test deve especificar:

função e componentes testados;
condição inicial;
sequência de teste;
cobertura esperada;
critérios de aceitação;
instrumentos necessários;
restauração após teste;
registros e evidências;
tratamento de falhas encontradas.

Testar apenas se “o PLC recebeu o sinal” pode deixar não verificadas falhas de transmissor, válvula, solenoide, linha de impulso, atuador ou lógica de interface.

Partial stroke test

Para válvulas críticas, o partial stroke test pode revelar parte dos modos de falha sem executar um fechamento completo. Ele não substitui automaticamente o proof test integral. O crédito de redução de PFD depende da cobertura real, frequência, arquitetura e dados utilizados na verificação.

A política de teste deve evitar converter uma ferramenta de diagnóstico em “crédito matemático” não sustentado por evidência operacional.

Bypass, override e manutenção

Sistemas reais precisam de manutenção, calibração e testes. Portanto, bypasses podem ser necessários. O risco aparece quando bypass deixa de ser condição temporária controlada e se transforma em estado operacional normalizado.

A governança deve estabelecer autorização, justificativa, tempo máximo, compensações, alarmes, registro, revisão de risco e remoção do bypass. A sala de controle deve conhecer claramente quais funções estão degradadas.

Filosofia de alarmes do SIS

Alarmes de diagnóstico, falha, bypass, perda de alimentação, inconsistência de votação e outras condições do SIS precisam ser racionalizados. O objetivo não é simplesmente enviar todos os bits de diagnóstico ao operador.

Cada alarme deve ter significado operacional, prioridade compatível, resposta definida e documentação. Alarmes críticos perdidos em uma avalanche de mensagens comprometem a capacidade de intervenção.

Interfaces com SCADA, IHM e historiador

A supervisão do SIS pode fornecer estado de SIFs, trips, bypasses, falhas e diagnósticos, mas a integração deve preservar a independência e a segurança da função. O caminho usado para visualizar informação não deve criar um meio não controlado de alterar lógica ou setpoints.

Históricos de eventos, sequência de eventos e sincronismo de tempo ajudam na investigação de trips e incidentes. A qualidade temporal é particularmente relevante para distinguir causa inicial de efeitos posteriores.

Cibersegurança aplicada ao SIS

Sistemas instrumentados modernos utilizam tecnologias digitais, estações de engenharia, redes e interfaces que podem introduzir riscos cibernéticos. Segurança Funcional e cibersegurança não são disciplinas substitutas: uma ameaça pode se tornar causa de falha da função de segurança e, portanto, precisa ser considerada no ciclo de vida.

Controles relevantes incluem segmentação, gestão de acesso, hardening, controle de mídia, backups validados, gestão de patches, monitoramento, proteção de estações de engenharia e governança de mudanças. A estratégia precisa respeitar disponibilidade e requisitos de segurança do processo.

Engenharia de aplicação e software

O software da aplicação é parte do desempenho sistemático da função. Falhas lógicas podem surgir de requisito ambíguo, implementação incorreta, conversão de unidades, timers, sequências, reset, estados degradados ou tratamento inadequado de sinais inválidos.

Boas práticas incluem rastreabilidade de requisitos, padrões de programação, revisão, controle de versão, testes unitários quando aplicáveis, simulação, FAT, gestão de mudanças e segregação entre ambientes de desenvolvimento e produção.

FAT de um SIS

O Factory Acceptance Test deve verificar o sistema antes da instalação em campo, dentro dos limites do ambiente de fábrica. Um FAT maduro testa lógica, I/O simulados, voting, falhas, diagnósticos, alarmes, reset, bypasses, tempos, interfaces e cenários definidos na SRS.

O FAT não comprova sozinho que a SIF instalada funciona no processo real. Sensores, elementos finais, cabeamento, utilidades e condições de campo podem não estar representados.

SAT e testes em campo

O Site Acceptance Test verifica a instalação e a integração no local. Deve confirmar, conforme o escopo, identificação, cabos, sinais, alimentação, redes, lógica carregada, interfaces, atuação de elementos finais e condições de campo.

É essencial preservar distinção entre SAT e validação de Segurança Funcional. Um SAT pode verificar itens de instalação sem demonstrar integralmente que cada SIF atende todos os requisitos da SRS.

Validação de Segurança Funcional

FAT, SAT, validação e partida precisam de critérios documentados e evidências. O comissionamento independente reduz o risco de aceitar um sistema apenas porque o hardware foi instalado e energizado.

Conheça o Comissionamento de Engenharia

A validação demonstra que as SIFs instaladas e configuradas atendem aos requisitos especificados. Precisa ser planejada, executada com procedimentos aprovados e documentada com resultados, desvios e evidências.

O teste deve partir dos requisitos: condição de demanda, sensores, lógica, voting, ação final, tempo de resposta, reset, diagnósticos, bypasses e comportamento em falhas. A validação incompleta é um risco documental e técnico, pois uma função pode “tripar” e ainda assim não cumprir integralmente sua especificação.

Sequência de testes e evidências desde a engenharia até a operação do SIS

Mechanical Completion e pré-comissionamento

Antes de testes funcionais completos, o sistema precisa atingir condições de conclusão física e prontidão. Inspeções, loop checks, verificação de alimentação, continuidade, identificação, calibração e documentação reduzem o risco de usar a validação para descobrir defeitos básicos de montagem.

Separar etapas evita que punch items de instalação sejam confundidos com falhas de requisito funcional.

Comissionamento e partida

Durante comissionamento, algumas funções podem estar temporariamente bloqueadas ou operar com premissas diferentes das condições normais. A gestão de Segurança Funcional deve controlar essas transições.

Planos de partida precisam identificar proteções disponíveis, condições temporárias, responsabilidades, testes prévios, critérios de abortar partida e restauração da configuração final. Sistemas críticos não devem chegar à operação comercial com bypasses provisórios sem gestão formal.

SIS em projetos brownfield

Modernizações em plantas existentes são especialmente desafiadoras porque documentação, lógica e campo podem divergir. Antes de modificar um SIS, é necessário construir uma base confiável do estado existente.

Levantamentos podem incluir As Built, lista de I/O, lógica carregada, firmware, redes, painéis, bypasses, histórico de trips, proof tests, certificados, cálculos de SIL e mudanças acumuladas. Uma migração pode falhar mesmo com nova plataforma tecnicamente superior se requisitos antigos forem perdidos ou se interfaces não documentadas forem ignoradas.

Migração de SIS

A migração exige estratégia de cutover e rollback. O projeto precisa definir quais funções ficam indisponíveis, quais proteções compensatórias serão usadas, como versões serão congeladas, quem autoriza cada etapa e quais critérios determinam retorno à configuração anterior.

A janela de parada deve contemplar não apenas instalação, mas testes e validação. Encerrar a intervenção assim que o novo hardware “liga” é insuficiente.

Management of Change — MOC

Alterações em setpoints, lógica, voting, instrumentos, tempo de trip, bypasses permanentes, intervalos de teste ou elementos finais podem modificar o risco. Por isso, a gestão de mudanças precisa avaliar impacto antes da implementação e atualizar documentação após aprovação.

MOC eficaz conecta mudança, análise de risco, SRS, projeto, testes, treinamento, As Built e registros operacionais. Mudança de software sem rastreabilidade é especialmente crítica porque pode ser difícil de detectar visualmente em campo.

Operação e manutenção do SIS

O SIS precisa continuar atendendo ao desempenho requerido durante sua vida útil. Isso exige manutenção, testes, gestão de falhas, treinamento, controle de bypasses, revisão de dados e atualização de documentação.

Indicadores úteis podem incluir funções em bypass, proof tests vencidos, falhas detectadas, trips espúrios, demandas reais, tempo de reparo, recorrência de defeitos e backlog de recomendações. O objetivo não é gerar dashboard ornamental, mas identificar degradação de barreiras.

Demanda real sobre a SIF

Toda demanda real é uma oportunidade de verificar desempenho e aprender. Deve-se avaliar se a SIF atuou conforme especificado, qual foi o evento iniciador, quais outras camadas responderam, se houve atraso, falha parcial ou consequência não prevista.

Essas informações podem alterar frequências usadas em LOPA, premissas de confiabilidade e estratégia de manutenção.

Auditorias e Functional Safety Assessment

O ciclo de vida exige verificações e avaliações em momentos apropriados. Auditoria de processo verifica se procedimentos e gestão são seguidos; avaliações de Segurança Funcional examinam se as atividades e evidências sustentam a confiança necessária para avançar.

O grau de independência da equipe avaliadora depende da fase, complexidade e requisitos aplicáveis. A organização deve definir isso no planejamento de Segurança Funcional em vez de improvisar somente antes da partida.

Procurement de SIS

Uma contratação madura especifica requisitos funcionais e de ciclo de vida, não apenas uma lista de hardware. RFPs e especificações devem definir responsabilidades sobre SRS, dados de confiabilidade, cálculos, software, FAT, documentação, treinamento, testes, certificados e suporte.

Também precisam estabelecer limites entre proprietário, projetista, integrador, fabricante e empresa de comissionamento. Lacunas de responsabilidade são frequentes quando todos presumem que “o fornecedor do PLC” entregará a Segurança Funcional completa.

Technical Bid Evaluation

A avaliação técnica de propostas deve verificar aderência aos requisitos e não apenas comparar marcas. Pontos relevantes incluem arquitetura, independência, capacidade sistemática, dados utilizados, ferramentas, versões, licenças, filosofia de teste, documentação, experiência da equipe e tratamento de obsolescência.

Exceções e desvios precisam permanecer rastreáveis. Uma solução mais barata pode transferir custo para engenharia, operação ou manutenção.

Owner’s Engineering em projetos de SIS

Projetos de SIS envolvem processo, instrumentação, automação, elétrica, operação, manutenção e fornecedores. Owner’s Engineering ajuda a preservar requisitos, interfaces e decisões do proprietário ao longo da implantação.

Conheça Owner’s Engineering

A Engenharia do Proprietário pode atuar como camada independente entre requisitos do ativo e fornecedores. O papel inclui governar interfaces, revisar documentos, acompanhar decisões, controlar desvios, coordenar respostas técnicas e preservar rastreabilidade.

Isso é especialmente útil quando processo, instrumentação, automação, elétrica, TI/OT, operação, manutenção e integradores diferentes compartilham responsabilidades sobre a mesma função.

Design Review

Design Review de SIS deve verificar se o projeto traduz a SRS sem introduzir dependências ou omissões. A revisão pode examinar arquitetura, voting, segregação, I/O, alimentação, redes, lista de instrumentos, causa e efeito, software, bypasses, diagnóstico, testes e manutenção.

O objetivo não é refazer o projeto do fornecedor, mas identificar incompatibilidades antes que sejam materializadas em painéis, programação e campo.

Engenharia Consultiva sem fornecimento do SIS

Uma empresa de Engenharia Consultiva pode gerar valor sem fornecer controladores, programar Safety PLC ou emitir certificação de produto. O escopo pode abranger diagnóstico, organização do ciclo de vida, facilitação de análises, definição de requisitos, padronização documental, Design Review, suporte ao Procurement, acompanhamento de FAT/SAT, gestão de interfaces e governança de ações.

Esse modelo separa a função de representar tecnicamente o proprietário da função de vender a plataforma de automação. A independência comercial pode melhorar a qualidade de especificações e avaliações, desde que a equipe tenha competência adequada ao escopo assumido.

Limites de responsabilidade e competência

Segurança Funcional exige competência demonstrável por atividade. Facilitar workshop, revisar governança, verificar documentação, calcular PFDavg, desenvolver aplicação ou executar validação são trabalhos distintos.

O contrato deve deixar explícitos escopo, premissas, responsabilidades e exclusões. Expressões genéricas como “certificar SIL” devem ser evitadas quando não correspondem a um processo ou acreditação claramente definidos.

Documentação mínima ao longo do ciclo

A documentação exata varia por empreendimento, mas um conjunto típico pode incluir:

política e plano de Segurança Funcional;
estudos de risco e registros de recomendações;
lista de SIFs;
SIL requerido e memória de determinação;
SRS;
filosofia de SIS;
arquitetura e diagramas;
listas de I/O e instrumentos;
matrizes de causa e efeito;
memória de verificação SIL;
especificações e datasheets;
documentos de software;
procedimentos e relatórios FAT/SAT;
plano e relatório de validação;
procedimentos de proof test;
registros de bypass e MOC;
As Built e backups controlados.

Documentação não é burocracia paralela: é a evidência que conecta risco, requisito, implementação e condição atual da instalação.

Erros recorrentes em projetos de SIS

Entre os erros mais críticos estão comprar hardware antes de consolidar requisitos; chamar todo intertravamento de SIF; atribuir SIL ao PLC; usar causa e efeito como única SRS; compartilhar recursos sem avaliar independência; aceitar dados de confiabilidade sem premissas; considerar FAT como validação final; deixar proof test para depois da partida; e permitir alterações de lógica sem MOC.

Outro erro é tratar o SIS como projeto exclusivo da automação. Processo, instrumentação, mecânica, elétrica, operação e manutenção influenciam diretamente o desempenho das funções.

Critérios para contratar apoio independente

Apoio consultivo é especialmente útil quando a organização possui múltiplos fornecedores, retrofit brownfield, requisitos dispersos, documentação inconsistente, grande volume de SIFs, mudanças frequentes, baixa maturidade de proof tests ou necessidade de estruturar governança corporativa.

Também é indicado antes de uma contratação relevante, porque corrigir ambiguidade na especificação custa menos do que corrigir arquitetura, software e campo após fabricação.

Considerações finais

O Sistema Instrumentado de Segurança deve ser entendido como uma camada de proteção governada ao longo de todo o ciclo de vida. Seu desempenho depende da coerência entre análise de risco, SRS, arquitetura, sensores, lógica, elementos finais, testes, operação, manutenção e gestão de mudanças.

O erro mais comum é reduzir esse sistema ao equipamento mais visível. Um Safety PLC pode ser excelente e ainda estar inserido em uma função inadequadamente especificada ou mantida. A engenharia precisa preservar a cadeia causal completa: por que a SIF existe, qual redução de risco precisa fornecer, como foi implementada, como será verificada e como sua integridade será sustentada durante a operação.

Para o proprietário, a governança técnica independente é particularmente valiosa quando várias disciplinas e fornecedores dividem responsabilidades. Ela permite transformar Segurança Funcional em requisitos verificáveis, decisões rastreáveis e critérios objetivos de contratação e aceite.

Referências técnicas

[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). IEC 61511-1:2016+AMD1:2017 CSV — Functional safety — Safety instrumented systems for the process industry sector — Part 1. Disponível em: https://webstore.iec.ch/en/publication/61289

[2] INTERNATIONAL SOCIETY OF AUTOMATION (ISA). ISA-84 Series of Standards — Functional Safety and Safety Instrumented Systems. Disponível em: https://www.isa.org/standards-and-publications/isa-standards/isa-84-standards

[3] INTERNATIONAL SOCIETY OF AUTOMATION (ISA). ISA84 — Instrumented Systems to Achieve Functional Safety in the Process Industries. Disponível em: https://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa84

[4] CENTER FOR CHEMICAL PROCESS SAFETY (CCPS). Layer of Protection Analysis — LOPA resources. Disponível em: https://www.aiche.org/ccps/resources/tools/lopa

Perguntas frequentes

O que é um Sistema Instrumentado de Segurança (SIS)?

É um sistema instrumentado destinado a executar uma ou mais Funções Instrumentadas de Segurança para levar ou manter um processo em estado seguro quando condições perigosas especificadas são detectadas.

Qual a diferença entre SIS, SIF e SIL?

SIS é o sistema que implementa funções de segurança; SIF é uma função específica de detecção e ação segura; SIL é o nível de integridade requerido ou atingido por uma SIF conforme os critérios aplicáveis.

Um Safety PLC SIL 3 torna todo o sistema SIL 3?

Não. O desempenho é avaliado para a SIF completa, incluindo sensores, logic solver, elementos finais, arquitetura, testes, falhas de causa comum e requisitos sistemáticos.

Todo intertravamento industrial é uma SIF?

Não. Muitos intertravamentos têm finalidade operacional ou de proteção de equipamento. Uma SIF precisa estar vinculada a um requisito de redução de risco definido pelo processo de Segurança Funcional.

O que é SRS em Segurança Funcional?

Safety Requirements Specification é a especificação que transforma os requisitos de risco em requisitos verificáveis para as SIFs, incluindo ações, estado seguro, SIL, tempos, voting, interfaces, testes, bypasses e critérios de validação.

FAT e SAT são suficientes para validar um SIS?

Não necessariamente. FAT e SAT verificam partes importantes da solução, mas a validação de Segurança Funcional deve demonstrar que as SIFs instaladas atendem aos requisitos da SRS.

Uma consultoria pode atuar em SIS sem fornecer Safety PLC?

Sim. Pode atuar em governança do ciclo de vida, requisitos, Design Review, Procurement, Owner's Engineering, acompanhamento de FAT/SAT, documentação e gestão de interfaces, desde que limite claramente o escopo e disponha de competência para as atividades assumidas.

Quando um SIS precisa de proof test?

O proof test é usado para revelar falhas perigosas ocultas não detectadas pelo diagnóstico automático. Frequência, cobertura e procedimento devem ser definidos de acordo com a SIF e sua verificação.