Há vários sistemas de detecção de sobre-velocidade (ODS) no mercado que são equipados com um gerador de funções integrado para fins de teste on-line, e esse recurso é frequentemente encontrado nas especificações de requisitos de ODS. Qual é a origem desse recurso e ele ainda é necessário?
Teste e reteste
Todo hardware tem um determinado valor de confiabilidade, que se degrada com o tempo. Para validar a confiabilidade de um sistema de segurança, os testes iniciais de comissionamento e os testes de prova periódicos são práticas comuns no setor. Para acompanhar as crescentes demandas por segurança verificável, era necessário um hardware mais confiável ou testes mais frequentes. No entanto, nem sempre é possível criar um hardware mais confiável, e testes mais frequentes atrapalham o processo. Um método para testes on-line com equipamentos de teste e procedimentos de teste incorporados ofereceu uma saída.
Normas
O requisito de um gerador de funções a bordo foi incluído no API 670. O primeiro requisito do API 670 tem origem em 2001, quando o ODS foi introduzido na4ª edição desse padrão. Embora a primeira edição da diretriz de segurança funcional IEC 61508 já tivesse sido lançada, a especificação, o projeto e o monitoramento interno de um ODS foram deixados a cargo do fabricante do sistema. Fazia muito sentido para a API especificar um procedimento de teste para usuários finais; isso permitiu uma alta cobertura de teste do ODS, incluindo o solucionador lógico e o elemento final.
Atualmente, a5ª edição da norma API ainda contém uma redação sobre a geração de funções a bordo, mas também faz referência à IEC 61508 como um método para projetar sistemas de segurança funcional. No entanto, a IEC 61508 não identifica funções ou métodos específicos para sistemas de segurança - o requisito da IEC 61508 limita-se ao projeto e à construção de um sistema seguro inerente, adequado à aplicação.
Leia mais sobre o que a API declara sobre sistemas de detecção de sobre-velocidade »
Nova geração
Nas novas gerações de hardware ODS, a segurança verificável pode ser obtida de diferentes maneiras. Pense em circuitos de monitoramento de funções paralelas, redundâncias internas e projetos de hardware à prova de falhas que permitem a criação de sistemas de segurança funcional certificados com longos intervalos de testes de comprovação. É possível obter mais melhorias projetando o hardware especificamente para a segurança funcional e mantendo o produto pequeno e focado em seu núcleo: a segurança. Porque quanto menos recursos e elementos houver em sua cadeia de segurança, menos será necessário testar. Isso também se aplica ao gerador de funções integrado.
O fim dos testes de prova on-line
Isso não significa que os testes de prova de diagnóstico on-line não sejam mais necessários. O principal requisito para um intervalo de teste de prova mais curto geralmente está no equipamento de rejeitos, como o sistema de controle, o sistema de desligamento de emergência (ESD) ou o elemento final (FE). Isso significa apenas que, se o ODS for seguro por projeto, o sistema é adequado para longos intervalos de teste de prova e não precisa ser incluído nos testes de diagnóstico on-line. Assim como os sensores não são incluídos nesses testes. Isso elimina a necessidade de um gerador de funções integrado e os procedimentos que o acompanham.
SpeedSys 300
O sistema de detecção de sobre-velocidade SpeedSys 300 tem um intervalo típico de teste de prova de mais de 10 anos, certificado de acordo com a norma IEC 61508. Portanto, um SpeedSys 300 geralmente não requer nenhum teste on-line durante esse período. Para permitir intervalos de teste de prova mais curtos para equipamentos de rejeitos, o SpeedSys 300 apresenta uma função de teste de prova automatizada, controlada por meio da entrada e saída digitais. Esse teste comuta os relés de saída do SpeedSys 300, mas não inclui um gerador de funções ou qualquer substituição temporária da lógica do sistema.
A principal vantagem dessa abordagem de teste de prova é que ela é controlada por um sistema de controle externo, como DCS ou PLC. Ele permite o monitoramento e o registro externos do teste de prova e oferece suporte a um planejamento de teste de prova mais inteligente para atender às condições específicas do processo. Além disso, é possível evitar testes durante condições de processo em que a disponibilidade do maquinário é crítica.
Leia mais sobre o SpeedSys 300 »
Sobre os padrões
Tanto a API 670 quanto a IEC 61508 são consideradas diretrizes e não impõem obrigações legais diretas. Elas fornecem uma estrutura para segurança de máquinas e boas práticas. A IEC 61508 se concentra na segurança funcional e consiste em métodos sobre como aplicar, projetar, implantar e manter sistemas de proteção automática. O API 670 é um padrão líder para sistemas de proteção de máquinas em equipamentos rotativos do American Petroleum Institute.
