Planear a substituição de uma CPU de PLC obsoleta antes da paragem

Ouve dizer que uma referência está obsoleta e o instinto manda encomendar qualquer coisa, seja o que for, antes de ela desaparecer. Retarde esse pensamento dez minutos. Verifique o estado de obsolescência contra a informação publicada atual do fabricante, não contra a memória ou a lembrança de um colega. Os fabricantes movem as referências por fases de ciclo de vida, e um estado que estava atual na última auditoria pode ter entretanto mudado.

Esquema do sistema ampliado

×

O caminho forte passa pela fonte publicada e entra no registo com uma data. As alegações fracas apontam de volta para a mesma fonte para confirmação.

O estado também pode diferir por região e por canal. Uma referência que circula como sobresselente num mercado pode estar esgotada noutro, e uma listagem de um distribuidor não é a mesma evidência que um anúncio de fim de vida do fabricante. Registe que fonte disse o quê, e quando. Uma nota de estado sem data não pode ser creditada um ano depois, porque a referência pode ter voltado a mudar. Uma listagem de distribuidor pode estar atual e ainda assim não provar nada sobre a descontinuação, porque o inventário de um revendedor e o estado do ciclo de vida são factos diferentes.

A verificação leva minutos e ancora o plano inteiro numa fonte datada e citável. A fonte que regista hoje é aquela que volta a consultar quando o plano for revisto, por isso a citação pertence ao registo de planeamento e não à caixa de entrada de alguém. Registe também o caminho para recuperar a fonte, para que a pessoa seguinte possa repetir a verificação sem perguntar como a encontrou.

Os fabricantes normalmente movem uma referência por fases com nome: um período ativo, um anúncio publicado de descontinuação, uma data final de entrega e, depois, uma cauda de suporte de duração variável. A fase em que a sua referência se encontra decide quanto tempo o plano tem, por isso registe o nome da fase e a sua data em vez de apenas a palavra obsoleta. Um anúncio com dois anos e outro publicado no mês passado descrevem margens de manobra muito diferentes para a mesma referência.

Registe a referência exata, a revisão e o estado do firmware enquanto a unidade ainda funciona. Uma CPU obsoleta em funcionamento é ela própria evidência, e desaparece no dia em que falha. Todos os factos que podiam ser lidos na unidade em marcha, como a versão de firmware reportada pela ferramenta de engenharia, tornam-se irrecuperáveis depois. Esse é o argumento mais forte para documentar cedo em vez de esperar que a máquina pare.

Esquema do sistema ampliado

×

As três capturas partilham um prazo: o dia em que a unidade falha. As setas mostram o que depende da unidade continuar a funcionar.

Note se existe uma cópia de segurança do projeto e onde está guardada, e depois verifique se a cópia é legível em vez de presumir que é. Sem uma cópia utilizável, todas as rotas de recuperação ficam mais difíceis: uma troca padrão equivalente torna-se uma reconstrução, e uma migração torna-se um esforço de reprogramação. Esse facto pertence ao registo de planeamento, porque muda o custo e o tempo de todas as rotas da lista.

Fotos da placa de características tiradas agora não custam nada e respondem a perguntas que nenhuma listagem de sobresselentes consegue. Capture a composição do rack e a lista de dispositivos de rede da mesma forma, porque o planeamento de obsolescência cobre tudo o que está ligado à CPU, não apenas a CPU. A mesma foto também ancora as posições de slot que vai citar em todas as comparações posteriores.

Se máquinas ou linhas irmãs partilham a referência, capture-as também, ainda que rapidamente. Uma linha por máquina, com a sua própria localização no armário e condição, transforma o registo de planeamento de uma nota de unidade única numa vista de frota. Uma vista de frota muda a economia: um sobresselente partilhado torna-se mais defensável, uma migração toca mais unidades, e a urgência de qualquer falha mede-se pelo número de unidades ainda em funcionamento.

Descreva o que a máquina faz e o que uma falha da CPU realmente para: uma máquina, uma célula inteira, ou uma função com envolvimento de segurança. Esta declaração de risco determina quanta urgência cada rota de recuperação merece e quem tem de estar envolvido na decisão. Uma CPU que para uma de cinco linhas idênticas é um problema de planeamento diferente do de uma unidade de fonte única que trava uma secção inteira da fábrica.

Esquema do sistema ampliado

×

Duas entradas dimensionam o risco: o raio de impacto de uma falha e o número de ligações que uma migração tocaria.

Pergunte a quem opera a máquina, não apenas a quem a mantém, porque a paragem sente-se de forma diferente de cada lado. A perspetiva de operação traz muitas vezes alternativas de contorno e opções de linhas irmãs que uma vista puramente técnica perde, e essas opções mudam a rota que merece investimento. A perspetiva de operação muda muitas vezes o prazo tanto quanto a lista de prioridades.

Capture o contexto envolvente da mesma forma: a composição do rack, a lista de dispositivos de rede e os projetos HMI que referenciam a CPU. O esforço de migração cresce com tudo o que está ligado à CPU. Uma comparação de sucessor para uma CPU com três projetos ligados é um trabalho diferente daquele para uma sem nenhum.

O envolvimento de segurança pertence à declaração de risco numa linha própria. Uma aplicação fail-safe muda quem tem de estar envolvido, que rotas de recuperação são discutíveis e quanta revalidação uma migração transporta. Trate essa linha como uma instrução de encaminhamento para o plano, não como um adjectivo. Uma declaração de risco que lista o envolvimento de segurança como um facto entre vários esconde o único facto que remodela todos os restantes. A estimativa de esforço é também o que torna a rota de migração comparável com as outras.

Liste as rotas candidatas sem se comprometer com nenhuma: aprovisionar uma unidade correspondente, uma pista de reparação ou de troca padrão, e uma migração para uma família atual. Cada rota precisa de evidência diferente. O aprovisionamento apoia-se na referência exata e na revisão; a reparação apoia-se no histórico de avarias e nas fotos; a migração apoia-se no projeto e nos registos de rede. A lista de rotas diz-lhe que lacunas fechar primeiro.

Esquema do sistema ampliado

×

Cada rota nomeia as suas próprias necessidades de evidência. As lacunas, não a preferência, decidem o que fechar a seguir.

Escrever as rotas expõe opções que ninguém considerou, como recorrer a uma unidade de uma linha irmã enquanto se aprovisiona um substituto. Cada ligação que captura agora é uma incógnita a menos durante uma migração futura. A lista também impede que um momento de pressão estreite as escolhas ao primeiro fornecedor que telefonar de volta.

Mantenha a fase de evidência separada da fase de decisão. Uma referência documentada, uma declaração de risco e uma lista de rotas permitem que uma decisão analisada aconteça mais tarde sem repetir o trabalho no armário. Também impedem que a decisão seja forçada por uma paragem. Uma lista de rotas revista após cada acontecimento mantém-se curta; uma revisitada anos depois chega como arqueologia.

Dê à lista de rotas um ritmo de revisão ligado a acontecimentos reais e não apenas ao calendário. Reveja-a quando o estado de descontinuação mudar, quando uma unidade irmã falhar, ou quando a máquina for novamente assistida, e registe o que a revisão mudou. Uma lista de rotas nunca revisitada fica desatualizada em silêncio, e a primeira decisão forçada chega contra uma lista que ninguém verificou há anos.

Disponibilidade, prazos de entrega e custo de migração permanecem perguntas em aberto até uma fonte os confirmar, por isso mantenha esses campos explícitos e mantenha as alegações sem data fora do plano. O registo deve declarar o que é conhecido, o que é presumido e o que ainda precisa de uma cotação ou de uma confirmação de fornecedor. Uma decisão analisada precisa dessa separação. Cada campo pode trazer a sua própria data, para que a coluna do conhecido se mantenha verificável linha a linha.

Esquema do sistema ampliado

×

A separação em três vias é o que torna o registo analisável. Uma decisão pode pesá-lo sem voltar a derivar o histórico.

O plano funciona exatamente como pretendido quando a máquina falha e a resposta começa a partir de um registo completo em vez de uma corrida desordenada. Esse é o teste de todo o exercício: a paragem torna-se o momento em que o plano compensa, não o momento em que uma decisão é forçada. Essa diferença só é visível se o plano disser o que pretendia alcançar.

Um plano que marca as suas próprias lacunas pode ser entregue a outra pessoa. A pessoa seguinte vê que campos são factos, quais são pressupostos e que rotas nunca foram avaliadas. Essa qualidade de entrega, mais do que qualquer facto isolado do registo, é o que mantém o plano vivo durante os anos em que uma CPU obsoleta pode continuar a funcionar.

• Verifique a obsolescência contra publicações atuais do fabricante e registe a fonte e a data.
• Capture a referência, o firmware, o estado da cópia de segurança e o risco da máquina enquanto a unidade funciona.
• Liste as rotas de aprovisionamento, reparação ou troca, e migração, e feche depois as lacunas de evidência de cada uma.
• A disponibilidade e os prazos de entrega permanecem em aberto até uma fonte os confirmar.

• a secção de PLC e CPU da Ardkor
• como comparar uma referência sucessora
• evidência para reparar ou substituir