Reparação ou substituição de uma CPU de PLC: que provas decidem

A máquina está parada, alguém pede um orçamento, e a tentação é descrever a avaria de memória. Resista. Anote o que a máquina fez antes de parar: que LEDs estavam ativos na CPU, que códigos de erro apareceram e se a avaria se repete após um rearranque controlado. Um sintoma sem data e sem fonte é uma história, e uma avaliação de reparação construída sobre histórias produz orçamentos para a avaria errada.

Esquema do sistema ampliado

×

Três observações tornam um sintoma utilizável. A data é o que permite comparar dois incidentes.

Anote o que já foi tentado e o que mudou como resultado. Um ciclo de alimentação que limpou a avaria durante duas horas, um sensor substituído sem qualquer efeito, um cabo reassentado antes da paragem: são factos que orientam um diagnóstico. Sem esse histórico, uma oficina de reparação repete os mesmos passos e fatura o privilégio, enquanto a decisão de substituição se toma com informação incompleta.

Fotografias dos estados dos LEDs no momento da falha contam como observação e sobrevivem melhor do que descrições. Um registo de hora na nota é o que a torna comparável mais tarde, porque dois incidentes descritos da mesma forma podem ser avarias diferentes quando as datas e as condições são comparadas. Uma fotografia tirada no primeiro minuto da paragem sobrevive a todas as recordações dela.

Uma cautela acompanha a recolha de sintomas. As observações que vêm de operar a máquina, como ver que LEDs estão ativos no momento da falha, são seguras de registar. As intervenções que mudam o estado da máquina, como reiniciar ou reassentar, pertencem ao procedimento do próprio local e ao seu estado seguro. Registe o que foi feito e quando, e deixe o fazer às pessoas e ao processo responsáveis por isso.

Mantenha o registo de sintomas factual e livre de conclusões. Uma nota que diz LED de alimentação apagado, SF ativo, ocorreu duas vezes esta semana após o arranque da linha é prova utilizável. Uma nota que diz a CPU está provavelmente morta é uma conclusão, e pode encerrar um caminho mais barato antes de alguém ter olhado para a unidade.

Esquema do sistema ampliado

×

Dois tipos de conteúdo chegam ao registo. Só a parte observada tem peso até alguém a verificar.

A disciplina é a mesma que mantém qualquer prova honesta: separe o que viu do que pensa que significa. A observação pertence ao registo. A interpretação pertence a uma nota claramente marcada, se pertencer a algum sítio, porque quem analisa precisa de saber que parte lhe está a ser pedida para verificar.

A mesma separação decide como o registo é usado mais tarde. Um registo factual pode ser entregue a um avaliador de reparações, citado numa análise de substituição e reutilizado para a avaria seguinte. Um registo de conclusões só pode ser discutido. Mantenha-o factual, e o registo trabalha durante anos.

Uma CPU transporta o programa, a identidade de rede e a afinação da máquina, e o trabalho de recuperação difere por completo consoante esse conteúdo está ou não salvaguardado. Se existe uma cópia de segurança do projeto verificada, uma substituição torna-se uma tarefa de reposição: carregar o projeto, repor o nome de dispositivo e o endereçamento e verificar os dispositivos ligados. Se não existe cópia de segurança, uma substituição significa reconstruir o programa a partir da documentação ou da unidade avariada.

Esquema do sistema ampliado

×

Um facto, cópia de segurança verificada ou não, muda o custo de todo o caminho. As setas mostram os dois trajetos de custo.

São projetos diferentes em escala e custo, e a diferença mede-se em semanas de tempo de engenharia, não no preço da unidade. O preço da unidade raramente é onde o custo real vive. Um orçamento que parece caro ao lado de uma substituição barata pode ser o caminho mais barato quando a reconstrução é contada, e só o estado de cópia de segurança registado expõe isso. Uma cópia de segurança que abre é um facto; uma cópia de segurança que se presume que abre é o risco que o registo existe para eliminar.

Verifique a cópia de segurança em vez de confiar na sua existência. Um ficheiro que abre no software de engenharia e corresponde à versão do programa da CPU em funcionamento é uma cópia de segurança verificada. Um ficheiro de idade desconhecida numa unidade partilhada não é. O passo de verificação é rápido enquanto a máquina funciona, e decide que caminho é realista muito antes de alguém pedir um orçamento.

A afinação da máquina é a parte silenciosa da questão da cópia de segurança. Para além do programa, uma CPU pode transportar parâmetros ajustados durante a colocação em serviço e nunca escritos em mais lado nenhum. Se o estado da cópia de segurança é desconhecido, a questão da afinação é desconhecida com ele, e essa incerteza pertence ao registo ao lado do estado da cópia de segurança. Muda o valor de uma unidade recuperada tanto como o programa.

Para uma pista de reparação, reúna a referência completa com revisão, o histórico de avarias datado e fotografias nítidas da unidade, incluindo a etiqueta. A avaliação de reparação vive dos sintomas e do estado da unidade, pelo que esse conjunto é o núcleo. Acrescente se a unidade foi aberta ou modificada, porque as intervenções não registadas mudam o que uma oficina pode concluir da inspeção. Detalhes que parecem menores na bancada decidem muitas vezes a avaliação.

Esquema do sistema ampliado

×

Ambas as vias partem do mesmo registo e ramificam nas provas que cada avaliação realmente pesa.

Para uma substituição, acrescente o contexto de rede e de projeto para que uma unidade sucessora ou equivalente possa ser verificada corretamente. O conjunto relevante inclui o nome de dispositivo, o endereçamento, a lista de dispositivos ligados e o estado da cópia de segurança verificada. A via da substituição é decidida por provas de configuração mais do que por provas de avaria. Uma unidade equivalente sem o seu contexto de rede continua a ser um palpite.

É por isso que as duas vias puxam por partes diferentes do mesmo registo. Construa ambos os conjuntos de provas a partir de um registo de sintomas factual e de um estado de cópia de segurança verificado, e cada via recebe o que precisa sem o trabalho ser feito duas vezes. Dizer que intervenções foram registadas, e quais não, é em si uma prova útil para quem avalia.

As intervenções não registadas merecem uma linha própria em ambos os conjuntos de provas. Uma unidade que foi aberta, um módulo trocado entre racks, um terminal religado durante uma avaria anterior: cada uma destas situações muda o que quem avalia pode concluir e o que uma verificação de substituição deve confirmar. Registar não é uma admissão de culpa; é a diferença entre uma inspeção que parte de factos e uma que parte de surpresas.

A tolerância à paragem também pertence ao dossier. Indique quanto tempo a máquina pode esperar, se existe uma solução temporária e quem detém a decisão. A urgência é um facto sobre o negócio, e registá-la deixa que as provas, e não a pressão do momento, orientem que via é confirmada com as pessoas responsáveis pela máquina.

Esquema do sistema ampliado

×

Três entradas, uma comparação. A tolerância e o responsável mantêm a urgência dentro do registo em vez de dentro da decisão.

Uma oferta de permuta e um orçamento de reparação respondem a perguntas diferentes. A permuta responde a quão depressa a máquina volta a funcionar; a reparação responde ao que aconteceu à unidade e quanto vale uma unidade restaurada. O dossier impede que as duas sejam comparadas apenas pelo preço, porque é a que uma decisão pressionada recai.

O registo torna essa comparação possível meses mais tarde. Uma decisão tomada sob pressão de paragem, com a tolerância declarada e as provas anexadas, pode ser revista e ensinar algo. Uma decisão tomada sem registo só pode ser lamentada ou repetida. A comparação, não a escolha, é o objetivo das provas.

Uma solução temporária muda a aritmética e deve ser registada como facto. Se a linha pode funcionar numa máquina irmã, ou num modo reduzido, a tolerância à paragem é um número diferente do de uma paragem total, e as vias podem ser pesadas contra o prazo real. Indique a solução temporária, os seus limites e quanto tempo se pode segurar. As soluções temporárias que se presume que aguentam indefinidamente são onde os planos falham em silêncio.

• Registe sintomas datados e específicos e todas as intervenções anteriores antes de pedir qualquer coisa.
• Verifique que a cópia de segurança do projeto abre e corresponde à versão do programa em funcionamento.
• Construa as provas de reparação a partir de sintomas e fotografias, e as de substituição a partir do contexto de rede e de projeto.
• Declare a tolerância à paragem para que a comparação seja honesta quanto à urgência.

• a página da categoria PLC e CPU
• o que registar antes de uma recuperação fail-safe
• o que enviar com um pedido de reparação