Pular para o conteúdo
Sistemas Logísticos

Integrações

WCS e PLC: handshake, watchdog e retomada de comandos

Como projetar a fronteira entre controle de fluxo e controlador industrial sem confundir comunicação, execução e segurança.

ABNET • Guia técnico · 6 min de leitura

Responsabilidades e tempos

O WCS coordena tarefas e rotas; o PLC executa lógica local, sinais e intertravamentos do equipamento. A distribuição exata deve estar no projeto. Funções de segurança precisam de dispositivos e lógica adequados à análise de risco e não podem depender de uma resposta do WCS.

A frequência de leitura de dados não deve ser escolhida apenas pelo menor valor possível. Considere atualização do controlador, rede, quantidade de sinais e necessidade operacional. Um comando de destino e uma malha de controle de movimento têm requisitos temporais diferentes.

Contrato de comando

Um handshake pode transportar identificador, sequência, parâmetros e estado de processamento. Separe comando solicitado, reconhecido, em execução e concluído. Especifique quem pode escrever cada campo e em qual momento os parâmetros são considerados consistentes.

Se os campos forem transferidos separadamente, o receptor pode observar uma mistura de comandos. Use o mecanismo de consistência acordado, como estrutura validada e sequência de publicação. A implementação depende da plataforma; apenas adicionar um bit de validade sem definir sua atualização não resolve a corrida.

Watchdog e reconexão

Um watchdog detecta ausência de atualização dentro de um limite, mas não prova que toda a aplicação está saudável. Um processo pode continuar alternando um sinal enquanto sua fila de comandos está travada. Monitore também progresso, idade das solicitações e estado do canal.

Na reconexão, diferencie dados atuais de valores retidos. O modo de retomada deve observar estado físico e sequência reconhecida. Uma interrupção não autoriza zerar todos os estados: isso pode esconder uma carga em movimento ou reaplicar um comando antigo.

Exemplo: comando concluído, resposta perdida

O PLC executa o comando 204, mas a confirmação não chega ao WCS. Reenviar 204 deve resultar em reconhecimento do estado existente quando o protocolo oferecer essa capacidade. Se o equipamento não distinguir duplicatas, a retomada exige consulta ou reconciliação controlada antes de nova ordem.

Teste perda de conexão antes do aceite, durante o movimento e depois da conclusão. Registre o comportamento físico esperado em cada ponto. O aceite inclui ausência de movimento indevido, estados coerentes e uma explicação operacional para qualquer bloqueio restante.

Definir propriedade, consistência e identidade do comando

Um contrato de PLC precisa dizer quem escreve, quem lê e quando o conjunto de parâmetros está pronto. Atualizar destino, carga e sinal de solicitação em escritas separadas pode permitir que o controlador leia campos de gerações diferentes. O projeto deve usar um mecanismo de consistência suportado e testado, não presumir atomicidade porque os campos estão na mesma tela.

Uma opção de referência é preparar os parâmetros e publicar uma sequência de comando somente após o conjunto estar coerente. O receptor captura e valida a geração antes de aceitar. Isso exige garantias sobre visibilidade e atualização dos dados no mecanismo escolhido; a sequência, sozinha, não torna várias escritas atômicas.

Definir propriedade, consistência e identidade do comando
Dado lógicoProprietário de escritaRegra de referência
Identidade / geração do comandoWCS ou adaptador autorizadoEstável no retry; não confundir reinício com comando novo.
Parâmetros da tarefaEmissor do comandoNão alterar parâmetros já aceitos sem fluxo de atualização.
Identidade reconhecida e resultadoControlador / interface de equipamentoRelacionar a resposta à solicitação correta.
Modo e disponibilidadeControlador responsávelValidar modo operacional antes de admitir trabalho.
Identificador de sessão ou reinícioCada ponta, conforme contratoDetectar perda de histórico e exigir reconciliação.

Sequência de transferência sem depender de pulsos curtos

Um pulso pode surgir e desaparecer entre duas leituras. Para eventos que não podem ser perdidos, o contrato pode manter solicitação e resposta até reconhecimento ou usar um histórico recuperável. A escolha depende da plataforma e do volume; confirme limites e comportamento após reconexão.

  1. Emissor → área de comando

    Preparar parâmetros e publicar a geração coerente.

  2. Receptor → validação

    Verificar identidade, modo, elegibilidade e consistência.

  3. Receptor → reconhecimento

    Informar qual geração foi aceita ou rejeitada.

  4. Equipamento → execução

    Executar conforme lógica e intertravamentos locais.

  5. Receptor → resultado

    Manter identidade e resultado até confirmação conforme contrato.

  6. Emissor → próximo ciclo

    Registrar o resultado antes de reutilizar o canal.

Um protocolo com apenas uma solicitação em voo simplifica correlação, mas pode limitar vazão. Várias solicitações em voo exigem identidade, capacidade de fila e ordenação explicitamente definidas.

Watchdog, timeout de comando e falta de progresso

Separe três relógios: idade dos dados de comunicação; prazo para reconhecer um comando; tempo esperado de execução ou progresso. Um heartbeat recente não prova que a fila está avançando. Da mesma forma, uma execução longa não prova perda de comunicação: ela pode estar aguardando um destino bloqueado.

Para estimar detecção, considere intervalo de produção, período de leitura/assinatura, atrasos da rede e margem observada. Em exemplo didático, atualização a cada 100 ms e avaliação a cada 200 ms já exigem considerar a defasagem entre os ciclos antes de escolher um limite. Esses valores não são recomendação de configuração: o limite real depende do equipamento e do comportamento acordado.

Watchdog, timeout de comando e falta de progresso
IndicadorInterpretaçãoAção de projeto
Dado envelhecidoObservação pode não representar o estado atualImpedir decisões dependentes desse dado e diagnosticar canal.
Comando sem reconhecimentoAceite ainda não conhecidoConsultar resultado; não assumir que a ordem não chegou.
Execução sem progressoCarga pode estar bloqueada ou em condição anormalExaminar motivo, posição e procedimento de exceção.
Reconexão com nova sessãoHistórico pode ter sido reinicializadoConciliar antes de liberar novos comandos.

Reinício independente das duas pontas

Teste WCS e PLC reiniciando separadamente. Uma ponta pode manter valores enquanto a outra perde o registro da última operação. O procedimento deve identificar o histórico disponível e reconciliar comandos abertos com o estado físico. Não zere bits ou reservas como substituto de descobrir onde está a carga.

Contadores também precisam de regra para retorno ao zero, estouro e reutilização. Uma sessão ou geração de inicialização pode distinguir comandos de períodos diferentes, quando o protocolo permitir. Se o equipamento não suportar essa distinção, a retomada deve usar bloqueio e reconciliação operacional controlada.

Reinício independente das duas pontas
CenárioVerificaçãoCondição de retomada
WCS reinicia; PLC continuaComando reconhecido e carga em trânsitoEstado recuperado corresponde à execução.
PLC reinicia; WCS continuaModo, valores retidos e perda de sequênciaIdentidade e posição verificadas.
Ambos reiniciamHistórico persistido e cargas presentesPendências conciliadas, sem replay cego.
Resposta antiga chega após retomadaSessão e identidade da solicitaçãoEvento antigo não altera tarefa nova.

Evidência mínima de teste de interface

Registre versão do contrato, configuração, sequência de solicitações e respostas, modo do equipamento e observações de carga. Injete interrupções antes do reconhecimento, durante o movimento e depois da conclusão. Verifique que o operador consegue distinguir falha de comunicação de bloqueio operacional.

O critério é ausência de movimento duplicado, nenhuma conclusão sem evidência e retomada explicável. A validação de funções de segurança pertence ao plano específico da máquina e aos seus responsáveis. Este handshake descreve integração de execução, não substitui esse plano.

Critérios para verificar no projeto

  • Definir o único escritor de cada campo do handshake.
  • Testar leitura parcial, valores retidos e sequências repetidas.
  • Verificar retomada sem reenviar cegamente comandos de movimento.

Os exemplos descrevem decisões de engenharia e cenários de teste. Interfaces, limites e recursos implantados são definidos no escopo de cada projeto.

Continue a leitura

Aplicação no ABNET WCS