O que registar antes de recuperar uma CPU fail-safe de um PLC

Uma CPU fail-safe, habitualmente escrita F-CPU, executa dois programas em simultâneo: o programa de controlo normal e um programa de segurança separado que o runtime do fabricante mantém isolado dele. Retira uma CPU, lê a família e o número, e tudo parece padrão. Depois a máquina recusa aceitar um programa de segurança. Essa é a armadilha fail-safe.

Esquema do sistema ampliado

×

A separação é funcional, não física: ambos os programas correm na mesma unidade, mas o lado da segurança é isolado pelo runtime.

A Siemens envia variantes fail-safe dentro das famílias S7-1200F e S7-1500F, e a marcação F aparece no número de artigo e na etiqueta da carcaça. O hardware não anuncia a diferença por si, por isso a marcação é a primeira coisa a verificar e a primeira a registar. Um carácter extra no número de artigo separa uma unidade que aceita um projeto de segurança de uma que não o consegue aceitar.

Os dois programas mantêm-se separados por desenho. O programa de segurança corre sob as suas próprias regras de runtime, e o programa padrão não o pode modificar. Esse isolamento é a razão pela qual uma CPU padrão não pode simplesmente ser carregada com um projeto de segurança, e pela qual o estado F molda cada pergunta de recuperação que se segue.

Consegue detetar a marcação F sem abrir nada. Nos números de artigo Siemens a capacidade fail-safe aparece na própria referência, e a etiqueta da carcaça também traz a marcação. A ferramenta de engenharia também a mostra, quando a unidade está na rede. O que não pode fazer é inferi-la do comportamento da máquina, porque uma CPU padrão pode correr o mesmo processo até ao momento em que alguém tenta carregar um projeto de segurança. A marcação é um facto impresso, trate-a como tal e leia-a.

A marcação muda o que uma referência correspondente tem de incluir. Duas CPUs que partilham o número base podem diferir em se aceitam de todo um programa de segurança, e essa capacidade está ligada à unidade específica e à sua configuração. É por isso que o estado F pertence à primeira linha do seu registo, antes da revisão ou das fotos.

Esquema do sistema ampliado

×

O número base abre a porta, mas o registo F decide o que pode passar por ela. Esta é uma verificação funcional, não de cablagem.

O programa de segurança e a sua configuração F, as definições que ligam a função de segurança à unidade, fazem parte da identidade de uma segunda forma. Uma unidade com o número de artigo correto pode ainda recusar-se a correr um projeto de segurança se a configuração não corresponder ao que o projeto espera. Nenhum valor da placa de características prova que um substituto aceitará o projeto. Essa evidência tem de ser registada, nunca presumida. A lista de módulos F também protege a análise de uma segunda armadilha: uma CPU de substituição que parece completa no papel, enquanto o conjunto configurado em torno dela fica sem registo.

Os módulos de E/S fail-safe ligados, os módulos F, pertencem ao mesmo conjunto configurado. Uma F-CPU e os seus F-IO configuram-se juntos no projeto, e uma alteração a qualquer membro desse conjunto pode exigir a revalidação do programa de segurança. Por isso a pergunta de correspondência nunca para na CPU; estende-se a todos os módulos F em redor. A distinção é invisível de fora do armário, por isso a marcação impressa pesa tanto.

Para um pedido, a consequência prática é o âmbito. Diga que a CPU está numa aplicação fail-safe mesmo quando a sua pergunta é apenas sobre a CPU, porque quem analisa não pode saber se os módulos F em redor fazem parte da pergunta até que o diga. Quem descobre os módulos F a meio da análise tem de reabrir a admissão, e as referências dos módulos F que listou antes tornam-se a razão pela qual a análise não precisou disso.

Capture o número de artigo completo com a sua marcação F, a versão do firmware tal como impressa e a geração de hardware. Fotografe a placa de características e qualquer rotulagem relacionada com segurança no armário, incluindo sinais ou documentos que nomeiem a função de segurança que a CPU serve. As fotografias transportam a redação exata, e rótulos de segurança parafraseados perdem o significado num registo. Duas fontes de rótulo para a mesma unidade são normais, e cada uma fotografada é um detalhe menos a reconstruir de memória.

Esquema do sistema ampliado

×

Quatro grupos de registo alimentam o dossier. Cada um responde a uma pergunta que quem analisa teria de fazer duas vezes.

Liste os módulos F ligados com as suas próprias referências. Nomeie cada módulo F, a sua posição de slot ou de estação, e o seu número de artigo completo, da mesma forma que registou a própria CPU. Onde os módulos se encontram importa, porque a pergunta de revalidação segue a cablagem.

Se existir uma cópia de segurança do projeto, registe a versão do programa de segurança e onde a cópia está guardada, ao lado da versão do programa padrão. As duas versões podem diferir, e quem analisa precisa de ambas para julgar o que uma unidade restaurada correria de facto. Se não existir cópia de segurança, escreva esse facto no registo, porque ele muda todas as rotas de recuperação que se seguem. A localização de arquivo importa tanto como a versão; uma cópia que ninguém encontra comporta-se como uma cópia em falta.

A rotulagem de segurança merece uma passagem deliberada. Procure sinais de aviso à porta do armário, bolsas de documentação e qualquer placa que nomeie a função de segurança que a CPU serve, e fotografe o que encontrar. Esses itens transportam a redação com que quem analisa segurança trabalha, e uma paráfrase nas suas notas não a consegue reproduzir. Se nada estiver rotulado, registe essa ausência como um facto, porque ela diz a quem analisa quanta parte do contexto de segurança não está documentada.

Date cada entrada e mantenha o dossier factual. Opiniões sobre o que provavelmente causou uma avaria, ou sobre o que um fornecedor poderá ter disponível, não pertencem junto a factos medidos. A data é o que transforma uma afirmação num registo, porque um facto sem data não pode ser reverificado contra nada.

Esquema do sistema ampliado

×

A confiança vem de três campos por linha. As lacunas declaradas fazem parte da evidência, não são uma falha do registo.

Um dossier datado e apoiado em fontes permite a quem vier depois verificar linha a linha em vez de a voltar a derivar. Cada valor deve trazer a sua fonte: placa de características, ferramenta de engenharia ou ficheiro de projeto. Quando duas fontes discordam, registe ambas as leituras em vez de as mediar, e deixe a análise resolver o conflito.

A mesma disciplina aplica-se às lacunas. Um estado de firmware desconhecido ou uma cópia de segurança em falta são factos sobre o registo, e declará-los abertamente é evidência mais forte do que adivinhar. As lacunas também dizem a quem analisa que passos de identificação repetir primeiro.

Quando duas fontes discordam, registe ambas as leituras com as suas fontes e datas, e deixe o juízo à análise. Um valor de firmware da ferramenta de engenharia e outro diferente numa lista de peças é um achado normal numa planta envelhecida, e escolher um em silêncio transforma o seu registo numa afirmação. Duas leituras registadas são evidência; uma leitura escolhida é uma opinião. Quem analisa resolve o conflito uma vez, com as fontes à frente, em vez de o descobrir duas vezes.

Uma CPU fail-safe não é apenas uma pergunta de troca padrão equivalente. O trabalho relacionado com segurança pertence a pessoal qualificado, sob as regras aplicáveis à máquina, e nenhuma entrada de catálogo, ficha técnica ou alegação de fornecedor muda isso. O dossier de evidência é um contributo para esse trabalho, não um substituto.

Esquema do sistema ampliado

×

O dossier termina onde começa a qualificação de segurança. As setas mostram a entrega das perguntas, não a entrega do trabalho.

Registe o que sabe e declare o que não sabe, depois encaminhe as perguntas do programa de segurança para as pessoas responsáveis pela máquina. Um registo que lista abertamente as suas lacunas é mais útil a quem analisa do que um que as disfarce. Onde exista uma lacuna, diga quem normalmente a fecharia e que ferramenta precisaria para isso.

Trate a compatibilidade e os resultados como perguntas em aberto no pedido. Se um substituto específico aceita o projeto de segurança existente, e se uma reparação pode preservar a configuração F, são decisões para a análise com as pessoas responsáveis, apoiadas pela sua evidência. A incerteza aqui é normal, e declará-la é o que mantém uma recuperação de segurança honesta.

• Capture o número de artigo com a marcação F, a versão do firmware e a geração de hardware.
• Liste todos os módulos de E/S fail-safe ligados com a sua própria referência e posição.
• Registe ambas as versões de programa, ou declare claramente que não existe cópia de segurança.
• O trabalho no programa de segurança cabe a pessoal qualificado. Note esse limite no pedido.

• a página da categoria de CPUs de PLC
• o percurso dos campos da placa de características
• o dossier de evidência para um pedido de PLC