Principais mal-entendidos sobre segurança funcional

Frequentemente, os fabricantes apenas calculam um valor de PFD/PFH (probabilidade de falha sob demanda/probabilidade de falhas por hora) para seu sistema ou subsistema e reivindicam posteriormente um SIL para ele. A PFH/PFD expressa a probabilidade de falha perigosa de um sistema (ou subsistema) relacionado à segurança por hora (PFH) ou sob demanda (PFD). Ambos os valores tratam de falhas de hardware aleatórias e geralmente são calculados com o uso de FMEDAs (Análise de Modos de Falhas e Efeitos). O cumprimento de um nível de integridade de segurança (SIL) específico requer não apenas o controle de falhas aleatórias de hardware, mas também a prevenção e o controle de falhas sistemáticas em hardware e software. O último é expresso como Capacidade Sistemática (Systematic Capability, ou SC, valores de 1 a 4, correspondendo aos quatro valores SIL) e reflete os métodos e técnicas usados durante o desenvolvimento do sistema relacionado à segurança. Portanto, um SIL sempre consiste em: PFD/PFH e uma determinação da solidez do seu processo de desenvolvimento, ou seja, o SC.

Às vezes, integradores de sistemas e fabricantes de instalações exigem que seus fornecedores forneçam sistemas de controle para operação normal com um SIL, pensando que isso garantirá uma certa confiabilidade do sistema de controle e/ou utilidade. Porém, o objetivo de uma função de segurança (que é executada por um sistema relacionado à segurança) é colocar um Equipamento Sob Controle (Equipment Under Control, EUC) em um estado seguro para não aumentar a disponibilidade.

Um estado seguro de um EUC é o resultado da análise de perigo e risco. Ele depende de seus diferentes modos operacionais. Nesse contexto, frequentemente observamos mal-entendidos sobre estratégias e conceitos relativos a cenários de segurança contra falhas, por exemplo, desligar o EUC em caso de falha e cenários operacionais de falha, por exemplo, manter o EUC tanto quanto possível em operação.

Falhas aleatórias de hardware (e de confiabilidade) são calculadas com base nas taxas de falha. Em termos de segurança funcional, as taxas de falha são divididas em falhas seguras e perigosas. Somente falhas perigosas (impedindo o funcionamento da função de segurança conforme planejado) são consideradas no cálculo dos valores PFD/PFH. Um SIL, portanto, é apenas um grau de confiabilidade de que a função de segurança será executada conforme planejado quando for necessário para colocar o EUC em um estado seguro.

Os circuitos watchdogs do microcontrolador (µC) muitas vezes apenas reinicializam o controlador, mas não controlam nenhuma saída de forma direta e independente. No caso de uma falha dentro do µC, é necessário um comportamento determinista da saída. Não é suficiente usar um watchdog interno, porque não é garantido que a saída irá para o estado desejado: o watchdog interno faz parte do microcontrolador com defeito, portanto, não é possível garantir que ele funcione corretamente.

Ainda observamos abordagens para reivindicar capacidade sistemática para SW existente com base na experiência operacional (Rota 2S na IEC 61508). Como na IEC TS 61508-3-1, todas as falhas individuais do SW precisam ser detectadas e relatadas durante o período de observação e também todas as combinações de dados de entrada, sequências de execução e relações de tempo devem ser documentadas. Essa abordagem geralmente não é possível do ponto de vista prático.

Normalmente observamos projetos de sistema onde peças/componentes/elementos de projeto não seguros são mesclados a elementos de segurança. Esta é uma abordagem padrão para reduzir a complexidade e os custos do sistema. No entanto, a evidência de liberdade de interferência é necessária quando técnicas mistas de projeto de nível de integridade de segurança são usadas. A análise deve ser realizada em nível detalhado de hardware ou software (dependendo do sistema), considerando quaisquer modos de falha possíveis das partes não seguras e o impacto relacionado na parte segura (por exemplo, sobretensão, dados errados, curto-circuito em partes não seguras etc.).

No desenvolvimento de software crítico para a segurança, a utilização de ferramentas automatizadas é a tendência em termos de eficiência e segurança. Entretanto, vemos com alguma frequência tais ferramentas serem utilizadas incorretamente. A especificação do teste de unidade deve ser escrita primeiramente com base na especificação da unidade/módulo de software, e não apenas pela análise de caixa branca do código-fonte. O objetivo é testar o comportamento funcional desejado da unidade de software. A evidência da cobertura do teste obrigatório no nível de código, para o qual a análise de caixa branca pode ser exigida, também deve ser cumprida, mas não é o único objetivo do teste de unidade.

Em sistemas de segurança relevantes, modernos e complexos, o uso de sensores inteligentes está se tornando cada vez mais importante. As funções dos sensores devem ser fornecidas com a integridade exigida ou a isenção de interferência para a função de segurança geral deve ser justificada. Alguns projetos de sistema são erroneamente baseados na suposição de que os modos de falha dos sensores inteligentes complexos (ou seja, com unidade de processamento lógico, protocolo de comunicação etc.) podem ser diagnosticados e mitigados por alguma unidade de segurança externa dentro da cobertura de diagnóstico necessária e detecção de falhas/tempo de reação.

Vemos problemas recorrentes relacionados à falta de proteção/supervisão da fonte de alimentação. As normas de segurança não especificam como as medidas de sobretensão/subtensão devem ser implementadas em detalhes, mas os mecanismos adequados para proteção devem ser implementados, dependendo do nível SIL exigido. O uso de mecanismo de proteção contra sobretensão não redundante para arquitetura que requer HFT> 1 é, por exemplo, um problema recorrente típico. O monitoramento da tensão de alimentação (incluindo a reação necessária como desligamento e estado seguro) deve ser feito por um componente separado com capacidade de faixa de tensão mais ampla e, portanto, não tenha sido afetado pela condição de sobretensão/subtensão. Até mesmo uma curta sobretensão pode ter danificado permanentemente partes do microcontrolador, sem ser óbvia. Assim, uma reinicialização do microcontrolador após a sobretensão não é uma medida adequada. Após a condição de subtensão, a reinicialização pode ser inofensiva, desde que a subtensão não persista.

A detecção de superaquecimento e a respectiva reação (entrar no estado seguro, desligar...) não podem ser realizadas por um componente (por exemplo, microcontrolador) que é operado fora das faixas especificadas em caso de condição de superaquecimento. Um reset simples também não é útil aqui; deve-se presumir que a condição de superaquecimento persiste ou já está presente durante a inicialização. A baixa temperatura às vezes não é considerada pelas normas de segurança (por exemplo, EN50129), mas as condições de aplicação (manual do usuário) devem garantir que o dispositivo seja acionado apenas dentro das faixas de temperatura especificadas (para todos os componentes).

A abreviatura SIL (Nível de integridade de segurança) é usada por várias normas. Em cada norma, entretanto, ela se relaciona a diferentes requisitos arquitetônicos, técnicos e de processo. Algumas das normas usam abreviações diferentes, como ASIL (SIL automotivo). Outras usam a mesma abreviatura (SIL), com risco de confusão e mal-entendidos.

Por exemplo, o nível SAS (alemão: "Sicherheitsanforderungsstufe" para Nível de integridade de segurança), conforme usado pelo SIRF (Sicherheitsrichtlinie Fahrzeug - EBA) não é o mesmo que o nível SIL ("Nível de integridade de segurança"), conforme usado pela EN 50128/EN 50129. O SIRF (SAS) usa apenas parte das medidas listadas no apêndice E da EN 50129, menos medidas organizacionais e de processo, e nenhum limite definido para a taxa de risco. SIL no contexto da IEC 61508 é diferente de SIL no contexto da EN50129. Às vezes, mais complexidade é adicionada com a definição de SIL como Nível de integridade de software, em vez de Nível de integridade de segurança (por exemplo, EN 50657).

Não é possível elevar o nível SIL de um sistema combinando sistemas sem evidências de segurança ou usando redundância homogênea. Por exemplo, não é possível aumentar o SIL para SIL4 simplesmente combinando vários sistemas/canais SIL2 (por exemplo, alcançar SIL3 no nível do sistema por vários sistemas de controle SIL2). Um motivo é que, por exemplo, os processos de software SIL2 não evitam falhas sistemáticas de software da mesma forma (integridade) necessária para os SIL4. A norma IEC 61508 permite aumentar a capacidade sistemática em 1 se dois sistemas independentes forem usados em uma estrutura de canal duplo. Em caso de redundância homogênea, isso não é possível. Outras normas (por exemplo, EN 50129) não oferecem essa possibilidade.

A causa comum é frequentemente esquecida na Análise da Árvore de Falhas (FTA). Falhas que podem afetar várias partes de um sistema ao mesmo tempo (por exemplo, perda de alimentação) devem ser incluídas como eventos básicos em todos os ramos relevantes da Árvore de Falhas. Alternativa: implementar a causa comum usando um "fator beta" na ferramenta FTA.

A definição de SIL (nível de integridade de segurança) se aplica a funções que foram originadas por algum tipo de análise/classificação de risco. Para um sistema/componente, é comum ouvir frases como "um controlador SIL 2", "um sistema de freios SIL3", etc. Em termos corretos SIL está relacionado apenas a funções específicas (de segurança). O objetivo da análise de risco é especificar quais funções são de segurança. Uma definição mais correta é que um "sistema é capaz de implementar funções de segurança até SILx". Isso significa que os requisitos de processo, arquitetônicos e técnicos das normas são atendidos pelo sistema.

Os limites do sistema a serem analisadas do ponto de vista da segurança e as interfaces com outras partes do sistema muitas vezes não são claramente definidos no início de um projeto. Por exemplo, não está claro quais componentes fazem parte do sistema, quais variantes de sensores/atuadores devem ser consideradas etc. Iniciar uma análise de segurança sem definir o escopo simplesmente não é possível, sem evitar várias iterações cada vez que o escopo é alterado.

Não existe algo como um nível SIL separado de blocos de Detecção e Monitoramento de Falha (Diagnóstico) pertencente a uma função de segurança classificada para determinado SIL. Algumas normas permitem reduzir o nível de integridade exigido em 1, mas do ponto de vista da segurança funcional, o diagnóstico faz parte das funções de segurança. Os requisitos de integridade também se aplicam ao diagnóstico. Uma análise de decomposição adicional pode permitir reduzir o nível de integridade, mas geralmente não exclui quaisquer requisitos de segurança.

Algumas medições de integridade/diagnóstico são executadas em cada inicialização do sistema (por exemplo, teste de RAM, verificação de Flash CRC, testes de saída etc.). Esses testes são muito importantes, pois são usados, por exemplo, para argumentação sobre medidas de diagnóstico ou para o tempo de detecção de falhas (intervalo de teste) na análise de segurança. No entanto, em algum momento a condição de operação pode mudar (novo projeto, novos requisitos etc.). Sistemas que eram desligados regularmente permanecem ligados por mais tempo. Por exemplo, atualmente os sistemas ferroviários modernos permanecem ligados de forma contínua com frequência, sem reinicialização todas as manhãs. Em tais casos, as medidas de diagnóstico pretendidas não se tornarão eficazes. Portanto, se necessário pela análise de segurança, a reinicialização regular deverá ser explicitamente especificada no manual de segurança, na documentação do operador etc.