QUESTÃO 5 - DIRCURSIVA

CAPACIDADE: Demonstrar fluxo de automação.

Contexto:

O projeto RNC visa automatizar o processo de registro e consulta da ficha RNC (Relatório de Não Conformidade) em um ambiente industrial de usinagem, utilizando ferramentas como TIA Portal V19, IHM, CLP Siemens, banco de dados SQLite e integração via Node-RED.

Comando:

Descreva detalhadamente o fluxo completo do projeto RNC, desde a entrada de dados na IHM até a gravação no banco SQLite, incluindo protocolos, blocos de dados, lógica de controle, redes industriais e integração com Node-RED.

Passo 1

O enunciado pede uma descrição detalhada do fluxo completo do projeto RNC, desde a entrada de dados na IHM até a gravação no banco SQLite, incluindo: protocolos usados, blocos de dados no PLC/TIA Portal, lógica de controle (máquina de estados, validações, handshakes), redes industriais envolvidas e a integração com Node-RED.
Informações fornecidas pelo enunciado (que vou usar sem pedir nada a mais): IHM via TIA/WinCC (TIA Portal V19), CLP Siemens (S7 family típica: S7‑1200 / S7‑1500), banco SQLite para armazenamento final e Node-RED como middleware/integrador.

Passo 2

Visão de arquitetura — componentes e canais de comunicação (resumo alto nível)
  • Componentes: IHM (painel), CLP Siemens, rede industrial (Profinet/Ethernet), Node-RED (executando em um industrial PC / Raspberry / servidor), banco SQLite (local ao Node-RED ou num servidor acessível pelo Node-RED), opcional servidor de arquivos para anexos/imagens.
  • Canais/protocolos típicos:
    • IHM ↔ CLP: Profinet (camada de rede determinística) ou S7 comm via Ethernet integrada do painel; ações de IHM escrevem tags do PLC.
    • CLP ↔ Node-RED: OPC UA (recomendado) ou S7comm/ADS (alternativa). OPC UA usa tipicamente a porta 4840.
    • Node-RED ↔ SQLite: driver SQLite local (socket de arquivo), via nó node-red-node-sqlite.
      Explicação rápida: Profinet é a rede industrial usada pelos dispositivos Siemens para comunicação rápida; OPC UA é um padrão para expor variáveis e permitir assinaturas/leituras seguras e estruturadas do PLC para sistemas IT como Node-RED.

Passo 3

Modelo de dados (no PLC e no SQLite) — o que precisa gravar
  • Estrutura lógica de um registro RNC (campos sugeridos):
    • id: identificador único (inteiro)
    • timestamp: data/hora do registro (string ISO ou tipo composto)
    • operador: id do operador (string, p. ex. tamanho 20)
    • máquina: id da máquina (string, 20)
    • peça: número do peça/lot (string, 30)
    • descrição: texto curto do não conformidade (string, 200)
    • severidade: enum/int (ex.: 1 baixo, 2 médio, 3 alto)
    • ação_corretiva: texto (string, 200)
    • status: enum/int (p.ex. 0=novo, 1=gravado, 2=em tratamento)
    • imagem_path: caminho/URL para imagem (string, 200), opcional
  • No PLC: criar um UDT chamado `RNC_Record` contendo esses campos com tipos Siemens (STRING[n], INT, BYTE). Em seguida criar um DB chamado `DB_RNC_Buffer` com uma ou mais instâncias (array) se quiser filas de N RNCs.
  • No SQLite: tabela `rnc` com colunas correspondentes; usar `id INTEGER PRIMARY KEY`, `timestamp TEXT`, etc.
Por que isso? UDTs e DBs no TIA deixam os dados organizados e facilitam mapeamento para IHM e exposição via OPC UA. No SQLite, tipos simples e um índice por id permitem buscas e relatórios.

Passo 4

Projeto da IHM e como os dados saem dela (passo a passo de operação)
  • Tela de criação RNC com campos mapeados a tags (cada campo ligado a um elemento do UDT `RNC_Record` no PLC). Ex.: campo “Descrição” mapeado para `DB_RNC_Buffer.RNC[slot].descricao`.
  • Validações na IHM (cliente): verificar campos obrigatórios, máximo de caracteres, seleção de severidade. Explicar brevemente: validar no cliente evita tráfego desnecessário e dá feedback rápido ao operador.
  • Botões:
    • “Enviar”: faz uma ação atômica: escreve os campos no DB de requisição do PLC (buffer) e dispara um bit de requisição `RNC_Request` (rising edge). Tipicamente a IHM fará um bloco de escrita atômico via write-to-PLC.
    • “Cancelar”: limpa os campos locais.
    • “Anexar foto”: abre interface para capturar/selecionar imagem; para imagens, sugerir upload direto para Node-RED via HTTP (end-point) e gravar o caminho retornado em `imagem_path` no DB do PLC.
  • Observação sobre mapeamento: cuidado com comprimentos de STRING Siemens (sempre definir tamanho fixo, p. ex. STRING( 200)). Strings maiores truncam.

Passo 5

Blocos no TIA Portal: organização lógica e responsabilidades
  • OB1 (main cyclic): ciclo principal que chama FB/FCs de serviço.
  • FB_RNC_Manager (instanciado com DB de instância): gerencia a fila de RNCs, estados de cada slot, contadores e flags. Mantém dados persistentes no DB de instância.
  • FC_Validate_RNC: funções puras para checar consistência (campos obrigatórios, limites de tamanho, conversões).
  • FC_PackForOPC/FC_PrepareTransfer: prepara o bloco de dados que será lido por Node-RED (por exemplo, copia do DB circular para um DB de transferência `DB_RNC_XFER` de tamanho previsível).
  • DBs:
    • `DB_RNC_Buffer` (array de slots) — recebe inserts vindos da IHM.
    • `DB_RNC_XFER` (uma estrutura de transferência por vez) — exposição clara e curta para Node-RED ler rapidamente.
    • `DB_RNC_Index` — contador/ponteiro de escrita, flags de estado.
      Explicação didática: FB (Function Block) guarda estado em um DB de instância — ideal para gerenciar filas e estados. FC (Function) não guarda estado e é usado para cálculos/validações.

Passo 6

Máquina de estados no PLC — como garantir integridade e evitar condições de corrida
  • Estados simplificados por registro (por slot):
    1. IDLE — slot livre.
    2. RECEIVED — IHM escreveu dados e pulou bit `RNC_Request` (detecção de flanco com bloco `R_TRIG`).
    3. VALIDATING — chamar `FC_Validate_RNC`. Se falhar, setar `error` e informar IHM (tag de retorno com mensagem).
    4. READY_TO_SEND — dados validados, mover para `DB_RNC_XFER` e setar a flag `NewRNCPending` para Node-RED.
    5. WAIT_ACK — aguardando confirmação (ACK) do Node-RED/SQLite que a gravação externa ocorreu.
    6. COMPLETE / ERROR — com ações de follow-up (limpar slot, registrar log, incrementar contadores).
  • Handshake de comunicação (boas práticas):
    • Uso de flanco de subida (p. ex. `R_TRIG`) para detectar a chegada de nova RNC.
    • Flag `NewRNCPending = TRUE` exposta ao Node-RED.
    • Node-RED ao terminar de gravar escreve `NewRNCAck = TRUE` e opcionalmente `RNC_AssignedID = <id>`.
    • PLC detecta `NewRNCAck` e move o registro para histórico interno (DB de logs) ou limpa o slot.
      Explicação: handshakes evitam perda de dado e permitem reenvio/retentativa em caso de falha.

Passo 7

Exposição de dados do PLC para Node-RED — opções e recomendação
  • Opção recomendada: habilitar OPC UA Server no CLP (S7‑1500 tem builtin). Publicar `DB_RNC_XFER`, `NewRNCPending`, `NewRNCAck`, e tags de status. Vantagens: segurança, facilidade de assinatura (subscription), tipificação de dados.
  • Alternativa: usar node-red-contrib-s7 ou ADS (S7comm) para ler DBs diretamente; funciona, mas menos padrão e pode exigir atenção a locks.
  • Endereço/porta: OPC UA padrão 4840 (usar certificados para produção).
  • No Node-RED: usar um node OPC UA Client configurado com endpoint da PLC, subscrever a flag `NewRNCPending`. Ao receber TRUE, fazer Read do DB completo para obter todos os campos.

Passo 8

Flow do Node-RED — transformação e gravação no SQLite (detalhado)
  • Nós e responsabilidades:
    1. opcua-subscribe / s7-watch: detecta `NewRNCPending`.
    2. opcua-read / s7-read: lê `DB_RNC_XFER` (todos os campos do registro).
    3. function node: valida novamente (duplicidade, sanidade) e monta objeto JSON com campos mapeados para a tabela SQLite; aqui pode gerar o ID se for necessário (ex.: usar timestamp + incremental ou deixar SQLite gerar `id` autoincrement).
    4. sqlite node: executa SQL de inserção. Exemplo de SQL gerado:
      INSERT INTO rnc (timestamp, operador, maquina, peça, descricao, severidade, acao_corretiva, status, imagem_path)
      VALUES (‘2025-11-30T12:34:56’, ‘OP123’, ‘MC01’, ‘PZA-45’, ‘Descrição…’, 2, ‘Ação…’, 0, ‘/files/img123.jpg’);
    5. function node: verifica resultado do SQLite (sucesso/falha). Em caso de sucesso, captura `lastID`.
    6. opcua-write / s7-write: escreve de volta para o PLC: `NewRNCAck = TRUE`, `RNC_AssignedID = <lastID>` (ou escreve status = 1).
  • Observações:
    • Fazer validação dupla no Node-RED por segurança (é o ponto que grava persistentemente).
    • Para imagens: Node-RED pode expor um endpoint HTTP para upload direto da IHM; retorna um URL salvo em `imagem_path`. A IHM pode mandar a imagem via HTTP e só depois acionar o botão “Enviar” com o path preenchido.

Passo 9

Transações, confiabilidade e tratamento de erros entre PLC e Node-RED
  • Sequência de segurança:
    • PLC marca `NewRNCPending`, espera por ACK por tempo máximo T_{ack} (p.ex. 30 segundos).
    • Node-RED tenta gravar; em caso de falha temporária (ex.: falha de BD), faz retry com backoff e sinaliza `ErrorCode` via tag se exceder tentativas.
    • PLC, ao detectar timeout, mantém o slot e exibe mensagem na IHM “Envio pendente — verificar rede”. Não perder o dado.
  • Locks e concorrência:
    • SQLite é um banco embutido com lock por escrita; garanta que somente Node-RED (único escritor) faça inserts para evitar conflitos. Se múltiplos processos precisarem escrever, usar um servidor DB (Postgres/MySQL) ou configurar um serviço de fila.
  • Logs:
    • Node-RED mantém log detalhado de cada tentativa (timestamp, payload, result). Em caso de repeated failure, enviar alerta/alarme para supervisão.

Passo 10

Exemplo concreto do fluxo cronológico (um caso real simplificado)
  1. Operador preenche formulário na IHM, anexa foto via upload HTTP opcional.
  2. Operador clica “Enviar”. A IHM escreve os campos em `DB_RNC_Buffer.slot[k]` e faz pulse no bit `RNC_Request[k]`.
  3. No PLC, `R_TRIG` detecta flanco -> FB_RNC_Manager coloca estado do slot em RECEIVED -> chama FC_Validate_RNC.
  4. Se OK, PLC copia para `DB_RNC_XFER` e set `NewRNCPending = TRUE`.
  5. Node-RED, subscrito a `NewRNCPending`, recebe evento, lê `DB_RNC_XFER`, cria JSON e executa INSERT no SQLite.
  6. SQLite retorna sucesso com `lastID`. Node-RED escreve `NewRNCAck = TRUE` e `RNC_AssignedID = lastID` para o PLC.
  7. PLC ao ver ACK move slot para histórico (DB interno) e seta `status=1`, limpa `NewRNCPending` e libera slot na IHM. IHM mostra “Gravado com id: <lastID>.”
  8. Em caso de erro no SQLite, Node-RED tenta retries; se falhar persistentemente, escreve `NewRNCError` com código e mensagem para o PLC e envia alerta.

Passo 11

Boas práticas de implementação e dicas para prova/produção (por que cada escolha)
  • Gerenciamento de IDs: prefira que o banco SQL (SQLite) gere `id` autoincremento; Node-RED devolve esse `id` ao PLC. Evita colisões.
  • Timestamps: gerá-los em Node-RED (server time UTC) para consistência entre registros; PLC pode também enviar seu RTC se necessário.
  • Backup do SQLite: configurar backup periódico; usar WAL mode para melhor concorrência; monitorar tamanho do arquivo.
  • Segurança: segregar rede OT (Profinet) e IT (Node-RED) com firewall/VLAN; usar OPC UA com certificados e usuários autenticados.
  • Testes: criar rotina de testes com injeção de registros, simular falhas de rede e garantir timeouts e retrys.
  • Performance: expor apenas DBs necessários para leitura por Node-RED (DB_XFER), não toda a memória do PLC. Limitar frequência de polling usando subscriptions OPC UA.

Passo 12

Checklist prático para desenvolver no TIA Portal V19 e Node-RED (passos de implementação)
  1. No TIA: criar UDT `RNC_Record` e DBs (`DB_RNC_Buffer`, `DB_RNC_XFER`, `DB_RNC_HIST`).
  2. Criar FB_RNC_Manager com DB de instância; implementar máquina de estados e R_TRIG para detectar entrada.
  3. Criar telas HMI com mapeamento direto para tags PLC e ações (botões para escrever + flanco). Implementar upload de imagens se for o caso (HTTP para Node-RED).
  4. Habilitar OPC UA no CLP, publicar as tags do `DB_RNC_XFER` e flags de controle. Configurar segurança/certificados.
  5. No Node-RED: configurar node OPC UA Client (endpoint do PLC), nós de leitura/assinatura, function nodes de transformação, node sqlite para INSERT e nó OPC UA Write para ACK.
  6. Testar fim-a-fim: preencher IHM → ver dados no PLC DB → Node-RED detecta → gravar SQLite → ACK → PLC finaliza.
  7. Implementar monitoração e backup.

Passo 13

Resumo didático final — como eu aplicaria isso na prova (resumido e objetivo)
  • Pense em três camadas: interface (IHM) → controle (PLC) → integração/persistência (Node-RED + SQLite).
  • Use DBs/UDTs no PLC para estruturar dados; use FB para gerenciar estado e handshakes; exponha apenas um DB de transferência para integração.
  • Use OPC UA (porta 4840) ou S7comm; Node-RED faz a leitura por subscription, transforma o payload e executa o INSERT no SQLite. Node-RED escreve ACK de volta para o PLC.
  • Controle de erro por flags, timeout e retries; imagens via upload HTTP direto para Node-RED, só o path vai para o banco.
  • Em provas, descreva cada bloco (OB1, FB, DB), as flags de handshake (`NewRNCPending`, `NewRNCAck`) e o SQL de inserção — isso demonstra domínio da solução completa.

Resposta

Fluxo: IHM (preenche formulário e opcionalmente faz upload de imagem) → escreve campos no DB do PLC (`DB_RNC_Buffer`) e dispara bit de requisição → PLC (OB1 chama FB_RNC_Manager) valida e copia registro para `DB_RNC_XFER` e seta `NewRNCPending` → Node-RED (via OPC UA ou S7) subscreve `NewRNCPending`, lê `DB_RNC_XFER`, transforma e faz INSERT na tabela SQLite → Node-RED escreve ACK e `AssignedID` de volta ao PLC → PLC confirma, move registro para histórico e limpa slot; tratamento de erros por retries, timeouts e flags de erro.

Exercícios relacionados