Ponte Rolante Inteligente com Gémeo Digital

Na indústria de fabrico de pontes rolantes, os sistemas de controlo e as plataformas digitais estão a tornar-se o fator decisivo da competitividade dos produtos. Enquanto a maioria das empresas ainda recorre à solução "standard" de um CLP genérico com IHM de terceiros, a Kelude Indústrias Pesadas optou por uma via técnica completamente diferente — do hardware de base aos algoritmos de topo, da aquisição de dados ao Gêmeo Digital, tudo é desenvolvido internamente. Esta opção não visa embelezar a lista de fornecedores; prende-se, sim, com o facto de as soluções genéricas apresentarem um teto de desempenho intrínseco quando confrontadas com as condições de operação complexas de uma ponte rolante.

Este artigo analisa a lógica técnica da solução desenvolvida pela Kelude em três níveis: a arquitetura integrada de hardware e software do sistema de controlo, a capacidade de modelação e previsão da plataforma Gêmeo Digital e a solução de integração da plataforma de dados. Em cada nível, faremos uma comparação horizontal com as soluções genéricas em termos de custo, desempenho e escalabilidade.

Sistema de controlo próprio: IPC + Linux em tempo real + algoritmos internos em substituição do CLP genérico

Plataforma Gêmeo Digital: Unity 3D + WebGL, modelo reduzido POD, previsão LSTM

A plataforma Gêmeo Digital da Kelude não serve para "mostrar efeitos 3D" — o seu valor central assenta em três pilares: ver com clareza, calcular com precisão e prever com antecedência. A lógica subjacente da plataforma pode resumir-se a um circuito fechado: "dados → modelo → inferência → decisão".

Camada de visualização: interação WebGL baseada em Unity 3D. A Kelude escolheu o Unity 3D como motor de renderização 3D e compila as cenas para o formato WebGL, permitindo que os utilizadores acedam ao modelo digital tridimensional completo da ponte rolante através de um navegador, sem necessidade de instalar qualquer software cliente. Este modelo não é uma simples apresentação CAD — reflete em tempo real todos os estados de movimento do equipamento: posição de translação da ponte, posição do carro, Altura de Elevação e ângulo de balanço da carga, tudo enviado em tempo real da plataforma de dados para o front-end via WebSocket, com uma frequência de atualização de 20fps (resolução de 50ms) e latência visual inferior a 100ms. O operador, ao abrir o navegador na sala de controlo no solo, vê exatamente a mesma cena tridimensional que veria na Cabine do Operador.

Para garantir um carregamento rápido da cena 3D no navegador, a equipa de desenvolvimento implementou uma série de otimizações de desempenho: o número de polígonos do modelo foi reduzido de 8 milhões no CAD original para 150 mil (preservando todas as características exteriores e eliminando detalhes internos invisíveis), as texturas utilizam compressão KTX2 para reduzir o consumo de memória gráfica, o controlador de animação usa um modelo de máquina de estados em vez de animação quadro a quadro, e o carregamento do primeiro frame é controlado em menos de 4 segundos (em condições de rede de 100Mbps).

Camada de inferência física: modelo reduzido POD para resolver o desafio da simulação em tempo real. A maior dificuldade técnica do Gêmeo Digital não é "parecer real", mas sim "calcular depressa". Um modelo de elementos finitos típico da Viga Principal de uma ponte rolante de 100 toneladas pode ter mais de 300 mil graus de liberdade. Resolver um único cenário estático com software FEA comercial (como ANSYS ou Abaqus) demora 3 a 5 minutos — algo totalmente inaceitável para inferência em tempo real.

A solução adotada pela equipa da Kelude é o modelo reduzido POD (Proper Orthogonal Decomposition — decomposição ortogonal própria). A ideia central é simples: a distribuição de Tensão da estrutura na grande maioria das condições de operação pode ser aproximada por uma combinação linear de um pequeno número de "modos base". A equipa calculou previamente, com recurso ao ANSYS, a resposta de Tensão de campo completo da estrutura para 1000 condições de operação típicas (combinações de diferentes posições e magnitudes de Carga e diferentes posições do carro). De seguida, através de decomposição em valores singulares (SVD), extraiu os primeiros 15 modos base com maior contribuição energética — a energia cumulativa destes 15 modos atinge 99,2%, o que significa que com 15 funções base é possível reconstruir a grande maioria da informação das 1000 condições de operação.

Em tempo de execução, o sistema apenas necessita de interpolar e combinar linearmente no espaço de baixa dimensão (15 dimensões) com base nas condições de Carga medidas em tempo real. O tempo de cálculo de um único campo de Tensão é reduzido para 15~30ms, com controle de perda de precisão inferior a 5%. Isto significa que o sistema Gêmeo Digital pode acompanhar cada movimento de Içamento da ponte rolante e atualizar em tempo real o mapa de calor do campo de Tensão completo da Viga Principal — o operador deixa de ver no ecrã alguns valores isolados de extensómetros e passa a ter uma visão panorâmica de "onde há Tensão, onde há Fadiga" em toda a Viga Principal.

Dados reais de implementação: em 3 pontes rolantes de 100 toneladas, foram instalados 16 pontos de medição de deformação por fibra óptica (FBG) e 4 pontos de medição de aceleração em cada uma, com uma frequência de aquisição de dados de 1Hz. O modelo POD completa uma inferência do campo de Tensão completo por segundo e sobrepõe o resultado no modelo Unity 3D. O sistema opera de forma contínua e estável há mais de 14 meses (até junho de 2026), tendo realizado mais de 37 milhões de inferências sem qualquer divergência do modelo ou anomalia nos resultados de cálculo.

Camada de previsão: modelo de séries temporais LSTM para previsão de vida útil restante. A capacidade avançada do Gêmeo Digital não é "compreender o presente", mas sim "prever o futuro". A Kelude adicionou, sobre os dados do campo de Tensão gerados pelo modelo reduzido POD, um módulo de previsão da vida à fadiga baseado em LSTM (Long Short-Term Memory — memória de curto e longo prazo).

As características de entrada do modelo LSTM incluem: o valor máximo de Tensão equivalente da Viga Principal inferido pelo POD, o número de ciclos de tensão (extraído por contagem rainflow), a distribuição da média e amplitude do espectro de carga, o tempo de operação acumulado do equipamento e a Temperatura Ambiente. A saída é: a vida residual à fadiga das zonas críticas da Viga Principal (expressa em número de ciclos) e o nível de alerta precoce (quatro níveis: verde/amarelo/laranja/vermelho). O modelo utiliza uma janela deslizante de entrada com tamanho de 720 passos de tempo (correspondente a 12 horas de dados históricos) para prever a acumulação de Fadiga nos próximos 7 dias.

Fonte de dados para treinamento: antes da entrada em operação, a equipa de desenvolvimento treinou offline o modelo LSTM com 12 meses de dados históricos de operação de 3 Protótipos de ensaio (incluindo 1,2 milhões de amostras válidas). Após a entrada em operação real, o modelo é atualizado incrementalmente a cada 24 horas, incorporando novos dados no conjunto de treinamento para se adaptar às tendências de Envelhecimento do equipamento e às mudanças nas condições de operação. Na validação em operação real entre outubro de 2025 e junho de 2026, o erro percentual absoluto médio (MAPE) entre o valor previsto para 7 dias da acumulação de Fadiga da Viga Principal e o valor medido foi de 8,3%, com uma antecedência de previsão suficiente para permitir que a equipa de manutenção programe intervenções antes de uma parada não programada.

Além disso, a plataforma integra também módulos de previsão de vibração para a Caixa de engrenagens do mecanismo de elevação e para o rolamento do motor. Através da extração de características no domínio do tempo e da frequência do sinal de aceleração (FFT + espectro de envelope), combinada com o modelo LSTM, é possível alertar com 7 a 14 dias de antecedência para falhas no Anel Interno/Anel Externo do Rolamento. Nos 8 equipamentos já implementados, o modelo emitiu 47 alertas, dos quais 43 foram confirmados como falhas reais após inspeção com o equipamento parado — uma precisão de alerta de 91,5% e uma antecedência média de 11,3 dias.

Plataforma de dados: aquisição OPC UA/MQTT, base de dados de séries temporais, gateway de API

O sistema de controlo gera dados, o Gêmeo Digital consome dados — a ponte entre ambos é a plataforma de dados. A arquitetura da plataforma de dados da Kelude segue um design em três camadas — "aquisição na borda, armazenamento, serviço de saída" —, cada uma com uma lógica de seleção tecnológica bem definida.

Camada de aquisição na borda: OPC UA como protocolo principal, MQTT como complemento. No lado do equipamento, o gateway de borda de aquisição "KruEdge", desenvolvido internamente pela Kelude, opera no computador industrial dentro do Quadro de Comando e comunica com o runtime KruControl através do protocolo OPC UA. A escolha do OPC UA tem razões claras: suporta nativamente modelação de dados (não se limitando a transmitir dados brutos, mas sim dados "com semântica" — por exemplo, "Tensão equivalente máxima da Viga Principal/MPa/ponto de medição FBG-03"), encriptação de segurança (autenticação mútua com certificados X.509 + encriptação de transmissão AES-256) e mecanismo de reenvio automático de dados históricos. Os dados recolhidos pelo gateway incluem três categorias principais: variáveis de estado do equipamento (velocidade, Corrente, Torque e posição dos três mecanismos — Elevação/Ponte/Carro), variáveis de segurança (sensor de sobrecarga, Fim de Curso, estado do Freio) e variáveis de saúde estrutural (deformação FBG, aceleração, temperatura), totalizando cerca de 600 pontos de dados, com frequência de aquisição configurável entre 1~100Hz.

Para equipamentos mais antigos que não suportam OPC UA (como modelos anteriores a 3 anos, alguns dos quais utilizam Protocolo Modbus RTU), o gateway de borda faz a ponte através de um módulo de adaptação de protocolo Modbus para OPC UA. Além disso, para uma pequena quantidade de dados telemétricos sem requisitos de tempo real elevados (como posição GPS, Temperatura Ambiente e humidade, estatísticas de consumo de energia), é utilizado o protocolo MQTT com um período de reporte de 5 minutos, de modo a reduzir a carga de dados na camada de controlo.

Camada de armazenamento: arquitetura de armazenamento híbrido baseada em base de dados de séries temporais. Com 600 pontos de dados a serem adquiridos continuamente a uma frequência de 1~100Hz, um único equipamento gera cerca de 1,5~5GB de dados por dia (dependendo da densidade de aquisição). Se 50% dos equipamentos vendidos pela Kelude (cerca de 200 unidades) estiverem ligados à plataforma de dados, o volume anual de escrita de dados atingirá 100~360TB. Uma base de dados relacional tradicional não consegue, obviamente, suportar tal carga de escrita.

A solução de armazenamento da Kelude é uma arquitetura híbrida de dois níveis: o primeiro nível é a cache local — o gateway de borda de cada equipamento está equipado com um SSD NVMe de 256GB, que armazena em cache todos os dados dos últimos 30 dias (cerca de 45~150GB por equipamento). Em caso de interrupção de rede, os dados não se perdem e são reenviados automaticamente após a recuperação. O segundo nível é a base de dados de séries temporais na nuvem — é utilizada a base de dados open-source TimescaleDB (extensão de base de dados de séries temporais baseada em PostgreSQL), implementada em servidores privados, com uma estrutura de tabela "larga" concebida segundo "ID do equipamento + timestamp + ID do ponto de medição" e uma granularidade de partição temporal de 72 horas. Desempenho de escrita medido: um único nó (8 núcleos, 32GB) processa de forma estável 240 mil escritas por segundo, com latência de consulta no percentil 95 inferior a 50ms (para consultas de todos os dados de um único equipamento num intervalo de 30 dias).

Para resolver o problema do custo de armazenamento de dados históricos, a equipa concebeu também uma estratégia de compressão e agregação de dados: os dados originais são retidos durante 90 dias (para diagnóstico de falhas e treinamento do modelo); os dados entre 90 dias e 1 ano são reduzidos para uma amostra por minuto (agregação por média + máximo + mínimo); os dados com mais de 1 ano são reduzidos para uma amostra por hora. O armazenamento total — dados completos mais as duas versões reduzidas — representa apenas 12%~15% do volume de dados originais.

Camada de serviço: gateway de API unificado. Depois dos dados armazenados, quem os consome? O front-end do Gêmeo Digital necessita de dados de estado em tempo real, o front-end Web necessita de curvas de tendência históricas, a aplicação de terminal móvel necessita de notificações de alerta, e sistemas de terceiros (como o MES ou ERP do cliente) necessitam de interfaces de integração — cada consumidor tem requisitos diferentes de formato de dados, protocolo de transmissão e permissões. A Kelude desenvolveu internamente o gateway de API "KruGateway" para resolver este problema.

O KruGateway foi desenvolvido com base no gateway de código aberto Kong, com funcionalidades personalizadas para cenários industriais: suporta acesso unificado a quatro protocolos — OPC UA, MQTT, HTTP REST e gRPC — convertendo internamente todos os dados para o formato JSON padrão antes de os distribuir aos consumidores. A gestão de permissões na camada de gateway segue um controlo em três eixos: «dimensão do dispositivo + dimensão dos dados + dimensão das funções». Por exemplo, um cliente pode apenas visualizar os 10 dispositivos registados em seu nome (dimensão do dispositivo), consultar dados de estado sem poder alterar parâmetros de controlo (dimensão das funções) e, dentro dos dados de estado, não ter acesso aos dados dos sensores de segurança (dimensão dos dados). A camada de gateway inclui ainda controlo de fluxo de dados e aceleração por cache — para pedidos de alta frequência do frontend do Gêmeo Digital (atualização a 20fps), o gateway armazena automaticamente em cache os snapshots dos últimos 3 segundos, evitando que cada renderização no frontend passe por uma consulta à base de dados.

Até junho de 2026, o KruGateway processa uma média diária de cerca de 2,8 milhões de chamadas de API, com um tempo de resposta no percentil 95 inferior a 15ms e uma disponibilidade mensal média de 99,97%.

Comparação abrangente com soluções genéricas: custo, desempenho e escalabilidade

Os três cenários técnicos acima descrevem a lógica subjacente à solução proprietária da Kelude. No entanto, quem decide a seleção da solução não é a equipa de desenvolvimento, mas sim a gestão — e a questão central que a gestão coloca é apenas uma: em que medida esta solução proprietária é superior a uma solução genérica? E valerá o investimento adicional em recursos e esforço?

A tabela seguinte apresenta uma comparação quantitativa global em três dimensões: custo, desempenho e escalabilidade:

Da comparação acima, emerge uma linha lógica clara: o "teto" da solução com CLP genérico não é uma questão de preço, mas de arquitetura. A sua capacidade de processamento, tempo real, abertura e escalabilidade determinam que fique confinado ao nível de "controlo lógico programável", incapaz de suportar capacidades de ordem superior, como algoritmos inteligentes, gémeos digitais e análise de big data industrial. A solução IPC + Linux em tempo real da Kelude consiste, essencialmente, em "rebaixar" um computador industrial de alto desempenho ao papel de controlador — trocando o excesso de capacidade de processamento por flexibilidade de desenvolvimento e espaço de expansão futura.

Naturalmente, esta solução tem os seus custos. O maior é o investimento em I&D — desde a conceção do projeto em 2021 até à produção em massa em 2024, a plataforma KruControl acumulou um investimento superior a 32 milhões de CNY (cerca de 4,1 milhões de EUR), com mais de 120 pessoas-ano dedicadas. Para uma empresa de média dimensão com receitas anuais na casa das centenas de milhões, é um valor bastante "visível" na demonstração de resultados. O segundo custo é a gestão da cadeia de abastecimento — a aquisição de componentes para computadores industriais, o ciclo de produção de placas-mãe personalizadas (em média 12 a 16 semanas) e a validação da adaptação do kernel Linux em tempo real são processos consideravelmente mais complexos do que comprar um CLP pronto a usar.

No entanto, a gestão da Kelude é clara quanto a esta linha tecnológica: no ponto de viragem em que o setor dos guindastes transita da "competição por escala" para a "competição por tecnologia", o "suficiente" do CLP genérico está a tornar-se "insuficiente". Em vez de esperar que os concorrentes conquistem primeiro o mercado de topo com soluções próprias, é preferível investir três anos a cavar o fosso tecnológico.

Conclusão: mais do que fabricar guindastes

Voltando ao título deste artigo: mais do que fabricar guindastes. A Kelude Indústrias Pesadas fabrica guindastes há vinte anos, mas o que verdadeiramente a distingue dos concorrentes não é a capacidade de produzir maiores tonelagens, nem a complexidade das encomendas que aceita, mas sim o que está "invisível" no interior do guindaste — cada linha de código do sistema de controle, cada função de base do gémeo digital, cada pipeline de dados na plataforma de dados central — tudo é desenvolvido internamente.

A solução com CLP genérico é, sem dúvida, madura e fiável, mas os limites que define são o teto de desempenho do guindaste. A Kelude optou por quebrar esse teto com a arquitetura IPC + Linux em tempo real, transformar o gémeo digital de ferramenta de demonstração em ferramenta de engenharia através do modelo reduzido POD, e converter dados de equipamentos em ativos empresariais com a plataforma de dados central própria. Em conjunto, estes três pilares constituem a base tecnológica da Kelude no segmento das pontes rolantes inteligentes.

Este percurso não foi rápido — desde o arranque em 2021 até à produção em massa em 2024, foram mais de três anos; também não foi barato — um investimento de 32 milhões de CNY (cerca de 4,1 milhões de EUR) em I&D não é montante despiciendo para uma empresa de fabrico. Mas há um consenso na equipa da Kelude: o fosso tecnológico é o único ativo que nenhuma guerra de preços consegue erodir. O que a solução com CLP genérico não consegue fazer, a solução própria da Kelude consegue — é essa a origem da diferenciação.

Perguntas frequentes

P: Qual é a diferença essencial entre o sistema de controle IPC + Linux em tempo real desenvolvido pela Kelude e um CLP genérico?
R: A diferença essencial reside na abertura da arquitetura do sistema e no teto de capacidade de processamento. O software e hardware de um CLP genérico são definidos de forma fechada pelo fabricante; o utilizador só pode programar dentro do enquadramento estipulado (por exemplo, diagrama ladder, linguagem SCL), não podendo executar algoritmos avançados próprios, e a capacidade de processamento está limitada a processadores ARM de baixo consumo. A solução IPC da Kelude utiliza processadores Intel x86, com capacidade de processamento 8 a 10 vezes superior à de um CLP de topo, incorpora o kernel Linux em tempo real PREEMPT_RT e permite executar código arbitrário em C++/Python no espaço do utilizador, com suporte para implementação em contentores e atualização remota OTA. Em suma, o CLP é um "controlador lógico programável"; a solução IPC é um "computador industrial programável" — o primeiro alcança o controlo; o segundo alcança a fusão de controlo + computação + expansão.

P: O que é o modelo reduzido POD? Porque é tão importante para o gémeo digital?
R: POD (Proper Orthogonal Decomposition, ou Decomposição Ortogonal Própria) é um método de redução de ordem de modelos orientado por dados. Através da decomposição em valores singulares de um grande volume de dados pré-calculados, extrai os "modos de base" com maior fração de energia, comprimindo uma análise FEA de alta dimensão que demoraria minutos para um cálculo de interpolação de baixa dimensão que leva dezenas de milissegundos. Para o gémeo digital, sem a redução POD, a inferência do campo de tensões em tempo real seria uma tarefa impossível — não se pode pedir ao operador que espere 3 a 5 minutos pela conclusão da FEA para ver o resultado. A solução da Kelude reconstrói 99,2% da informação de 1000 condições de operação com 15 modos de base, com um tempo de cálculo online de apenas 15 a 30 ms.

P: Como é que a plataforma de dados central da Kelude processa volumes massivos de dados de equipamentos?
R: Utiliza uma arquitetura de três níveis. Nível de borda (gateway KruEdge): cada equipamento armazena localmente 30 dias de dados completos (cerca de 45 a 150 GB), com cache automática em caso de interrupção de rede e reenvio após restabelecimento. Nível de armazenamento: baseado na base de dados de séries temporais TimescaleDB, um único nó processa 240 mil escritas por segundo; os dados brutos são retidos durante 90 dias e depois reduzidos automaticamente para granularidade de minutos e horas. Nível de serviço: o gateway de API KruGateway fornece saída unificada, com suporte para quatro protocolos — OPC UA, MQTT, HTTP REST e gRPC — processando uma média de 2,8 milhões de chamadas de API por dia, com resposta no percentil 95 inferior a 15 ms. A gestão de permissões é controlada em três dimensões — "equipamento + dados + funcionalidade" — garantindo a segurança dos dados em cenários multi-inquilino.

P: Esta solução própria é adequada para todos os clientes?
R: Atualmente, destina-se principalmente a clientes e cenários de aplicação com requisitos elevados de inteligência, como as indústrias metalúrgica, portuária e de energia nuclear, que necessitam de operação remota, gestão de saúde de equipamentos ou manutenção lean. Para cenários genéricos que apenas requerem funcionalidades básicas de içamento, a Kelude continua a oferecer a linha de produtos padrão baseada em soluções CLP maduras. A solução própria e a solução genérica coexistem — a primeira cria diferenciação e constrói barreiras tecnológicas; a segunda cobre o mercado de base sensível ao preço. As duas abordagens não são mutuamente exclusivas, mas sim uma estratégia de produtos em camadas dirigida a diferentes segmentos de clientes.