Resposta: O RK3568 foi concebido especificamente para implementações de gateways de IoT industrial — a sua CPU Cortex-A55 de quatro núcleos, duas portas Gigabit Ethernet, barramento CAN nativo, RS-485/RS-232 e interface PCIe 3.0 cobrem todas as ligações de dispositivos «southbound» exigidas por um chão de fábrica. Em combinação com uma pilha de protocolos baseada em Linux que suporta Modbus RTU/TCP, MQTT e OPC UA simultaneamente, um gateway RK3568 pode agregar centenas de dispositivos de campo, pré-processar dados na periferia e encaminhar cargas úteis estruturadas para o AWS IoT, o Azure IoT Hub ou uma plataforma SCADA privada — tudo dentro de um envelope térmico de 5 W que cabe num invólucro para calha DIN.
O mercado global de dispositivos de gateway para a Internet das Coisas (IoT) foi avaliado em 5,5 mil milhões de dólares em 2026, prevendo-se que atinja os 14,3 mil milhões de dólares até 2035, impulsionada pela migração dos sistemas OT legados para arquiteturas de nuvem de borda. No centro desta transição está o gateway industrial — o dispositivo que faz a ponte entre sensores Modbus e PLCs com décadas de existência e as modernas análises na nuvem baseadas em MQTT. A escolha do processador certo para esse gateway é a decisão de engenharia que determina se a implementação durará três ou doze anos.
Este guia aborda a arquitetura do RK3568 no contexto da conceção de gateways de IoT industrial: por que razão o seu conjunto de interfaces de hardware corresponde aos requisitos do chão de fábrica, como construir a pilha de software de tradução de protocolos, quais são as opções de topologia de implementação em diferentes segmentos industriais e como escolher entre os formatos SBC e SoM do RK3568, dependendo do seu cenário de produção. Quer esteja a migrar uma instalação Modbus já existente ou a conceber um nó de IIoT totalmente novo, esta é a referência técnica de que a sua equipa necessita antes do primeiro layout da placa de circuito impresso (PCB).
Principais conclusões
- As interfaces duplas Gigabit Ethernet + RS-485 + CAN bus do RK3568 cobrem o lado «southbound» de qualquer gateway industrial sem necessidade de chips de expansão externos
- O PCIe 3.0 permite a integração de modems celulares 4G/5G para implementações remotas através de uma única ranhura M.2 — sem a perda de desempenho associada à latência do USB
- O kernel Linux 5.10 LTS no RK3568 oferece suporte estável a longo prazo, com manutenção do BSP da Rockchip a nível do upstream
- Pilha de protocolos: Modbus RTU → libmodbus → Node-RED → Mosquitto MQTT → nuvem é o caminho de referência validado para implementações do RK3568
- O RK3568J (variante de nível industrial) funciona entre -40 °C e +85 °C e conta com um compromisso de disponibilidade prolongada dos componentes
- O formato SoM (por exemplo, a placa base RK3568 da ieeker) reduz o tempo de lançamento no mercado de caixas de gateway personalizadas, em comparação com o projeto a partir de um SoC
- A funcionalidade de servidor OPC UA permite a integração direta com SCADA/MES sem necessidade de uma camada de middleware separada
- O pré-processamento na periferia reduz os custos de ingestão de dados na nuvem em 60–80%, em comparação com as arquiteturas de reencaminhamento de fluxos em bruto
Por que razão o RK3568 foi concebido para gateways de IoT industrial
Nem todos os SoC ARM são processadores viáveis para gateways de IoT industrial. Os critérios de seleção para os chips de gateway diferem fundamentalmente das aplicações incorporadas de consumo: é necessário um tempo de interface determinístico para a sondagem de fieldbus em série, capacidade de CPU suficiente para executar daemons de tradução de protocolos em paralelo, baixo consumo de energia em modo inativo para sustentar o funcionamento 24 horas por dia, 7 dias por semana, e um conjunto de periféricos que cubra a conectividade industrial sem chips externos que aumentem o custo da lista de materiais (BOM) e criem pontos de falha.
O RK3568 cumpre os quatro requisitos de forma nativa. Eis o que este chip oferece a um gateway de IoT industrial concepção sem quaisquer periféricos externos:
| Interface | Capacidade nativa do RK3568 | Utilização do Industrial Gateway |
|---|---|---|
| Ethernet Gigabit dupla | 2 MACs GbE independentes | Separação entre LAN (dispositivos de campo) e WAN (ligação à nuvem) sem um chip de comutação |
| PCIe 3.0 × 2 | Expansão M.2 / mPCIe | Modem 4G LTE / 5G NR, SSD NVMe para o histórico local |
| CAN Bus × 2 | Em conformidade com a norma ISO 11898-1 | Conectividade direta entre PLC e atuadores, integração de sensores automóveis |
| UART × 3 | Full-duplex, até 4 Mbps | Polling Modbus RTU RS-232 / RS-485 (com conversor de níveis) |
| USB 3.0 × 1 + USB 2.0 × 2 | Host + OTG | Adaptadores USB para série, dongles de rede móvel (solução alternativa), dispositivos de armazenamento USB |
| SATA III | 6 Gbps | Arquivo histórico de dados local (SSD de 2,5", anos de dados de processo) |
| SPI / I²C / GPIO | Vários canais | Sensores ambientais, RTC, expansão DI/DO, circuitos de vigilância |
| NPU (1,0 TOPS) | Motor de inferência RKNN | Detecção de anomalias no próprio dispositivo, modelos de ML para manutenção preditiva |
A Ethernet Gigabit dupla merece destaque especial. A maioria dos projetos de gateways exige uma separação física entre a rede de campo (onde os PLCs, sensores e contadores comunicam) e a ligação à WAN (por onde fluem os dados para a nuvem). Conseguir isto com um SoC de Ethernet única requer um switch gerido externo — o que acarreta custos adicionais, ocupa espaço na placa e constitui um potencial ponto de falha. Os dois MACs GbE independentes do RK3568 permitem uma topologia adequada de duas interfaces no Linux (br0 para a LAN de campo, eth1 (para WAN) com regras de firewall que isolam o tráfego OT da Internet sem recurso a hardware externo.
Para uma comparação mais aprofundada entre o RK3568 e o RK3588 em aplicações com elevada exigência computacional, consulte o nosso Guia comparativo entre o RK3568 e o RK3588. No que diz respeito especificamente ao funcionamento de gateways de IoT, o menor consumo de energia do RK3568 (3–5 W, tipicamente, contra 8–12 W do RK3588 em cargas de trabalho de gateway) torna-o a escolha certa na maioria das implementações em calha DIN.
A pilha de software do gateway IoT RK3568: do dispositivo no terreno à nuvem
A capacidade do hardware é apenas metade da equação. Um gateway de IoT industrial executa uma pilha de software que deve desempenhar de forma fiável quatro funções em simultâneo: interagir com dispositivos de campo na direção «sul», converter protocolos, pré-processar e filtrar dados, e reencaminhar cargas úteis estruturadas na direção «norte» para a nuvem ou para o SCADA. No RK3568, esta pilha é executada em Linux — quer seja um sistema Buildroot mínimo para implementação em produção, quer seja uma imagem completa do Debian/Ubuntu durante o desenvolvimento.
Camada 1 — Sistema operativo: Linux 5.10 LTS
O sistema operativo de referência para o RK3568 em produção Gateway IoT A versão utilizada nas implementações é o Linux 5.10 LTS (Suporte a Longo Prazo), mantido no BSP upstream da Rockchip. Os kernels LTS recebem correções de segurança durante seis anos — o que é fundamental para implementações em que as atualizações de firmware são pouco frequentes ou exigem procedimentos de controlo de alterações. Para desenvolvimento e prototipagem rápida, o Ubuntu 22.04 LTS oferece o ecossistema de pacotes mais abrangente e está totalmente validado na plataforma RK3568.
Elementos-chave da configuração do kernel para implementações de gateway: ativar CONFIG_CAN e CONFIG_CAN_FLEXCAN para o barramento CAN, CONFIG_SERIAL_8250 para UART/RS-485, e CONFIG_BRIDGE para a configuração da ponte LAN/WAN. do ieeker's Placa industrial RK3568 O SDK inclui uma versão pré-configurada do kernel do gateway, com todos os controladores de interfaces industriais compilados — não é necessária qualquer configuração manual do kernel.
Camada 2 — Protocolo de ligação com o equipamento: Modbus, CAN, OPC UA
A camada de transmissão para sul liga-se aos dispositivos de campo — PLCs, sensores, contadores, variadores. Três protocolos abrangem a maioria das instalações industriais:
- Modbus RTU (RS-485): O protocolo industrial mais utilizado a nível mundial. No RK3568,
libmodbusfornece uma biblioteca C para a sondagem Modbus RTU/TCP. Uma configuração típica sonda 32 dispositivos escravos a 115 200 baud com um tempo de ciclo de 100 ms — o que é perfeitamente exequível numa única thread UART com uma utilização da CPU ≤2%. Conforme explicado no Especificação do protocolo Modbus, o modelo de sondagem mestre-escravo é síncrono e determinístico, o que facilita a sua implementação como um daemon no espaço de utilizador do Linux. - Modbus TCP (Ethernet): No caso dos PLCs e contadores ligados por Ethernet, o Modbus TCP funciona através da interface LAN do RK3568. O mesmo
libmodbusA biblioteca suporta tanto RTU como TCP através de uma simples mudança na camada de transporte. - CAN Bus (ISO 11898): No caso dos sensores industriais derivados do setor automóvel (gestão de baterias de AGV, barramentos CAN de veículos, alguns PLCs), os dois controladores CAN nativos do RK3568 com
SocketCANO suporte a controladores no Linux fornece um padrãocan0/can1interface de rede. Ferramentas comocandumpecansendpermitir a realização de testes rápidos. - OPC UA: Para a integração com PLCs modernos (Siemens S7-1200/1500, Allen-Bradley), open62541 — a pilha OPC UA de código aberto — funciona de forma eficiente no RK3568, consumindo aproximadamente 30 MB de RAM para uma instância completa do servidor OPC UA. Isto permite a comunicação bidirecional: o gateway pode ler os valores do processo e reescrever os pontos de regulação no PLC.
Camada 3 — Processamento na periferia: Node-RED ou daemon personalizado em Python/C
Os dados brutos de campo raramente são enviados diretamente para a nuvem. Antes do encaminhamento para a nuvem, o gateway realiza filtragem, conversão de unidades, alertas de limiar e agregação de dados — o que o setor denomina «relatórios por exceção». Isto reduz drasticamente os custos de ingestão de dados na nuvem. De acordo com análise das implementações de computação na periferia com Modbus-MQTT, uma estratégia de encaminhamento baseada em eventos (que apenas envia dados quando os valores se alteram para além de um limiar) reduz o consumo de largura de banda a montante em 60–80%, em comparação com o encaminhamento por sondagem constante.
Duas abordagens práticas para a camada de processamento de ponta no RK3568:
- Node-RED: A ferramenta de programação de fluxos visuais funciona no Node.js e é implementada em menos de 5 minutos no RK3568 com Debian/Ubuntu. Os nós Modbus, MQTT e OPC UA do Node-RED cobrem a maioria dos casos de utilização de gateways sem necessidade de código personalizado. A ocupação de RAM em modo inativo é de aproximadamente 80 MB — bem dentro da configuração típica de 2 a 4 GB de LPDDR4 do RK3568. Adequado para implementação rápida e projetos em que pessoas sem formação em engenharia precisam de modificar fluxos de dados.
- Daemon personalizado em C/Python: Para sondagens de alta frequência (ciclo inferior a 10 ms) ou implementações que exijam uma quantidade mínima de RAM, um daemon personalizado escrito em C (utilizando
libmodbus+libmosquitto) atinge uma latência de sondagem Modbus inferior a um milésimo de segundo, com um consumo de memória RAM inferior a 10 MB. Esta é a abordagem preferida para gateways com um elevado número de canais (mais de 100 escravos Modbus) ou quando o gateway também está a executar cargas de trabalho de inferência na NPU.
Camada 4 — Sentido Norte: MQTT + Integração com a plataforma na nuvem
O MQTT é o protocolo «northbound» padrão para gateways de IoT industrial. No RK3568, o Mosquitto fornece o broker MQTT local (para a comunicação entre processos entre o daemon Modbus e o encaminhador para a nuvem), e o libmosquitto A biblioteca do cliente gere as ligações à nuvem para o AWS IoT Core, o Azure IoT Hub ou um broker auto-hospedado.
A configuração MQTT de produção para implementações de gateways RK3568 deve incluir: encriptação TLS 1.2/1.3 na porta 8883, nível de QoS 1 para mensagens de alarme críticas (entrega «pelo menos uma vez»), buffer local de armazenamento e reencaminhamento (SQLite ou ficheiro simples) para funcionamento offline durante falhas na WAN e reconexão automática com backoff exponencial para evitar a sobrecarga do broker aquando da recuperação da rede.
Para compreender as vantagens e desvantagens da escolha do sistema operativo nas plataformas Rockchip (em particular, Linux vs. Android para casos de utilização como gateway e HMI), consulte o nosso artigo detalhado Comparação entre os sistemas operativos industriais Linux e Android.
Do chão de fábrica: Migração de 140 sensores Modbus para MQTT numa fábrica de pneus
Há cerca de catorze meses, liderei a seleção do hardware dos gateways para um projeto de modernização IIoT numa fábrica de vulcanização de pneus na província de Shandong. A fábrica contava com 140 sensores de temperatura e pressão distribuídos por 18 prensas de vulcanização — todos ligados via Modbus RTU em barramentos RS-485, originalmente instalados em 2009. O objetivo do cliente era simples: integrar todos os dados dos sensores no seu novo MES baseado na AWS sem substituir qualquer cablagem de campo ou sensores. O orçamento total para a modernização era limitado.
O desafio residia no facto de a topologia do barramento Modbus existente não ser padrão — três segmentos RS-485 separados, cada um com entre 40 e 55 dispositivos, a funcionar a 9600 baud com endereços de dispositivos de diferentes fabricantes (alguns duplicados dentro dos segmentos devido a uma expansão anterior que nunca foi devidamente documentada). O ambiente da fábrica apresentava uma temperatura ambiente de 55–65 °C junto às prensas. Qualquer hardware de gateway tinha de funcionar de forma fiável a essa temperatura e gerir três threads de sondagem Modbus simultâneas sem conflitos de endereços.
Selecionámos a nossa placa de gateway baseada no RK3568J por duas razões específicas: o SoC de classe J está classificado para uma temperatura de junção de 85 °C (proporcionando uma margem térmica confortável num invólucro com ventilação montado em calha DIN a uma temperatura ambiente de 65 °C) e as três interfaces UART permitiram a utilização de três mestres Modbus RTU independentes — um por segmento RS-485 — a funcionar separadamente libmodbus instâncias de daemon com espaços de endereços de dispositivos isolados. Não se verificou qualquer problema de conflito de endereços entre segmentos, uma vez que cada segmento estava logicamente isolado na camada de software.
A pilha de software completa era a seguinte: três daemons Modbus → broker Mosquitto local → agregador em Python com médias móveis de 10 segundos e alertas de limiar → AWS IoT Core via MQTT com TLS 1.2. Latência total de sondagem para todos os 140 sensores: menos de 800 ms de ida e volta em todos os três segmentos. O volume de dados na nuvem foi reduzido para aproximadamente 8% da taxa de sondagem bruta através da filtragem de relatórios por exceção — o custo de ingestão de dados do cliente na AWS diminuiu em 73% em relação à sua estimativa inicial.
A implementação está em funcionamento há catorze meses, sem qualquer tempo de inatividade não planeado atribuível ao hardware do gateway. Foram aplicadas duas atualizações de firmware através de SSH — um patch de segurança do BSP e uma melhoria na camada de aplicação relativa à lógica de alertas de limiar. A imagem térmica que obtivemos no sexto mês revelou que o RK3568J funcionava a uma temperatura de junção de 71 °C sob carga total de sondagem num ambiente com temperatura ambiente de 65 °C — bem dentro do máximo nominal de 85 °C.
Topologias de implementação do gateway de IoT industrial RK3568
A arquitetura do gateway varia significativamente consoante o setor, o ambiente de conectividade e o volume de dados. O RK3568 suporta quatro padrões principais de implementação, cada um com diferentes requisitos de configuração de hardware e pilha de software.
Topologia 1 — Gateway de fábrica com ligação por cabo (LAN Ethernet + WAN)
A topologia mais comum para implementações em chão de fábrica. As duas interfaces GbE do RK3568 estão configuradas da seguinte forma: eth0 como a rede LAN de campo (ligada a um switch gerido que serve PLCs, contadores e sensores compatíveis com Ethernet) e eth1 como a WAN da fábrica (ligada à rede informática da fábrica ou ao router de Internet). Os espaços de nomes de rede do Linux ou as regras do firewall iptables garantem o isolamento entre as redes OT e IT. Latência entre a consulta Modbus e a publicação MQTT: normalmente 50–150 ms, incluindo o processamento na periferia.
Topologia 2 — Gateway celular (implantação remota 4G/5G)
No que diz respeito às infraestruturas remotas (estações de bombagem, subestações, monitorização agrícola, monitorização de condutas), a ranhura PCIe 3.0 do RK3568 aceita um modem M.2 4G LTE ou 5G NR. O modem aparece como uma interface de rede (wwan0) no Linux através do mbim ou qmi-wwan driver. Um buffer de armazenamento e reenvio no SQLite local gere a persistência dos dados durante interrupções na rede móvel — o gateway continua a interrogar os dispositivos de campo e a armazenar os dados em buffer localmente, sendo estes depois transferidos para a nuvem assim que a ligação for restabelecida. Capacidade típica do buffer: 30 dias de leituras de sensores a cada minuto, provenientes de 64 dispositivos, em menos de 500 MB.
Topologia 3 — Agregação multiprotocolo (Modbus + CAN + BLE)
Os ambientes de produção utilizam, cada vez mais, ecossistemas de dispositivos mistos: medidores Modbus mais antigos, atuadores CAN-bus mais recentes e sensores BLE sem fios de sistemas de monitorização de estado. O RK3568 processa os três simultaneamente: Modbus RTU em UART, CAN bus através do SocketCAN e BLE através de um dongle USB Bluetooth 5.0 ou de uma placa de suporte com Bluetooth integrado. Os três fluxos de dados alimentam a camada de processamento de ponta, que os normaliza num payload JSON unificado antes do reencaminhamento via MQTT.
Topologia 4 — Gateway de IA na Periferia (Detecção de Anomalias Acelerada por NPU)
A NPU de 1,0 TOPS do RK3568 permite uma inferência de ML leve no próprio gateway. Para aplicações de manutenção preditiva, um modelo LSTM quantizado ou um modelo de autoencoder (normalmente com 2–8 MB no formato RKNN) é executado na NPU para avaliar as leituras dos sensores em tempo real. Apenas as anomalias — padrões de vibração, padrões de temperatura, formas de onda de corrente — desencadeiam o envio para a nuvem; as leituras normais são resumidas em agregados horários. Isto reduz significativamente os custos de armazenamento e processamento na nuvem, permitindo simultaneamente a deteção de anomalias em menos de um segundo, sem a latência de ida e volta da nuvem.
Para compreender todo o fluxo de trabalho de inferência da NPU nas plataformas Rockchip utilizando o RKNN-Toolkit2, consulte o nosso Análise aprofundada do desempenho da NPU — o fluxo de trabalho do RKNN é idêntico entre o RK3568 e o RK3588, diferindo apenas no débito máximo (1,0 TOPS contra 6,0 TOPS).
SBC vs. SoM: Qual o formato do RK3568 mais adequado para o seu projeto de gateway?
Depois de ter validado a plataforma RK3568 para a sua aplicação de gateway, a próxima decisão diz respeito ao formato do hardware: utilizar um padrão Placa de desenvolvimento RK3568 (SBC) diretamente, ou construir uma caixa personalizada à volta de um RK3568 SoM (Sistema num Módulo) montado numa placa de suporte personalizada. Esta decisão influencia os custos, o tempo de lançamento no mercado, o âmbito da certificação e a complexidade da cadeia de abastecimento a longo prazo.
| Fator | SBC RK3568 | SoM RK3568 + Placa de suporte personalizada |
|---|---|---|
| Tempo até ao primeiro protótipo | Dias (apenas software) | 8–12 semanas (concepção da placa de suporte + fabrico) |
| Custo do NRE | $0 (placa padrão) | $4 000–$12 000 (concepção da estrutura) |
| Custo unitário para 500 unidades | Mais elevado (lista de materiais completa do SBC) | Mais baixo (o operador tem uma lista de materiais mínima) |
| Flexibilidade no formato | Fixo (dimensões padrão) | Totalmente personalizável (adapta-se a qualquer caixa) |
| Personalização da interface | Limitado (disposição fixa dos conectores) | Completo (a operadora define toda a configuração de E/S) |
| Âmbito da certificação CE/FCC | SBC já certificado (verificar SKU) | É necessária uma certificação ao nível do sistema para o produto final |
| Volume de produção recomendado | <500 unidades/ano | >500 unidades/ano |
O ponto de equilíbrio no custo total de propriedade situa-se normalmente entre 300 e 600 unidades produzidas, dependendo da complexidade da placa de suporte. Abaixo desse volume, o custo NRE nulo do SBC torna-o a escolha certa, mesmo que o custo unitário seja mais elevado. Acima desse volume, o SoM + placa de suporte personalizada amortiza o NRE ao longo de um número suficiente de unidades para proporcionar poupanças unitárias significativas, permitindo simultaneamente o formato personalizado e o layout de interface que os produtos vendidos através dos canais de distribuição normalmente exigem.
Para uma análise completa do quadro de decisão entre SoM e SBC, incluindo a repartição dos custos da lista de materiais (BOM), consulte o nosso Guia de conceção SoM vs SBC. A ieeker disponibiliza tanto a placa de desenvolvimento RK3568 para prototipagem rápida como o SoM RK3568 com serviço de personalização da placa de suporte para programas OEM de gateways à escala de produção.
Aplicações do gateway IoT RK3568 por setor
A versatilidade da interface do RK3568 significa que uma única plataforma de hardware pode servir setores industrialmente distintos, com diferenciação principalmente ao nível da camada de software. Eis como a arquitetura do gateway se adapta aos quatro setores de implementação de gateways de IoT industrial com maior volume.
Fabrico Inteligente / Indústria 4.0
O principal caso de utilização: ligar PLCs antigos, máquinas CNC, sistemas SCADA e medidores de potência a plataformas de análise na nuvem. O gateway RK3568 situa-se normalmente ao nível da célula ou da linha de produção — um gateway por célula de produção, agregando 20 a 60 dispositivos através de Modbus TCP/RTU e reencaminhando os dados para um sistema de registo histórico ao nível da fábrica (OSIsoft PI, Ignition) ou diretamente para o MES na nuvem. A NPU permite a deteção do desgaste das ferramentas e o cálculo da OEE diretamente no dispositivo, sem dependência da nuvem.
Energia e Serviços Públicos (Rede Inteligente, BESS, Energia Solar)
As subestações, as cadeias de inversores solares e os sistemas de armazenamento de energia em baterias (BESS) exigem, cada vez mais, monitorização remota através de ligação celular. A ranhura para modem PCIe 4G/5G do RK3568, juntamente com o SSD SATA para armazenamento local de registos históricos, torna-o a escolha certa para estas implementações frequentemente isoladas. O Modbus TCP estabelece ligação aos inversores; o barramento CAN gere os sistemas de gestão de baterias (BMS) do BESS que utilizam o CANopen ou um protocolo CAN proprietário. A norma IEC 60870-5-104 (o protocolo SCADA do setor dos serviços públicos) é suportada através de bibliotecas de código aberto.
Automação de edifícios (BACnet / KNX)
Os sistemas de edifícios inteligentes (AVAC, iluminação, controlo de acessos, medição de energia) utilizam o BACnet/IP como protocolo dominante. O RK3568 executa uma pilha BACnet/IP (BACnet4Linux de código aberto ou opções comerciais) na sua interface LAN, agregando dados dos subsistemas do edifício para plataformas BEMS. Este é um mercado particularmente promissor para os designs compactos de gateways RK3568 para calha DIN, tendo em conta o ambiente com temperaturas normalmente amenas e os ciclos de substituição de 5 a 10 anos na infraestrutura de edifícios comerciais.
Cadeia de Frio e Logística
A monitorização de armazéns frigoríficos e do transporte requer a agregação de dados de vários sensores (temperatura, humidade, estado das portas, consumo de energia) com ligação celular e um sistema fiável de armazenamento e reenvio de dados. A integração do modem celular do RK3568 e o buffer SQLite local tornam-no ideal para implementações em que a ligação à Internet é intermitente. A integração de sensores BLE (para registadores de temperatura sem fios ao nível das prateleiras) através da ligação USB Bluetooth permite uma cobertura de alta densidade no armazém sem a necessidade de instalar nova cablagem.
Caso de projeto: Criação de um gateway celular de IoT para monitorização remota de parques solares
Uma das demonstrações mais claras da capacidade do RK3568 como gateway celular surgiu de um projeto que apoiámos para um operador de energias renováveis no Médio Oriente. O cliente operava 14 parques solares em locais remotos do deserto na Arábia Saudita, cada um com entre 20 e 45 inversores de string ligados via Modbus TCP numa rede LAN Ethernet local. Cada parque dispunha de um router celular comercial para acesso à Internet, mas o seu hardware de gateway SCADA existente — placas com formato PC104 de um fornecedor europeu — estava a chegar ao fim da vida útil e a apresentar falhas a um ritmo acelerado, devido às temperaturas ambientes superiores a 55 °C.
Os requisitos de substituição: uma placa de gateway capaz de funcionar a uma temperatura ambiente de 55 °C sem refrigeração ativa, consultar todos os inversores através de Modbus TCP a intervalos de 1 minuto, encaminhar os dados de produção para o respetivo Azure IoT Hub, manter um buffer de dados local de 90 dias para cumprimento da regulamentação e caber no invólucro existente para calha DIN (com dimensões limitadas a uma área de 150 mm × 100 mm na placa de circuito impresso).
Fornecemos uma placa de suporte RK3568J personalizada, construída de acordo com essas dimensões: duas portas GbE (LAN de campo + WAN celular através de um módulo LTE M.2), 32 GB de eMMC + 256 GB de SSD SATA para o registador de dados, dissipador de calor passivo com capacidade para 60 °C de temperatura ambiente e uma placa de circuito impresso com revestimento conformado para o ambiente desértico com elevado nível de poeira. A pilha de software executava o Buildroot Linux com um daemon de polling Modbus TCP personalizado e integração com o SDK do Azure IoT Hub.
Resultados da implementação ao longo dos primeiros 12 meses em todos os 14 locais: tempo de atividade do gateway de 99,71 TP3T (o tempo de inatividade de 0,31 TP3T deveu-se a duas falhas na rede móvel, sem perda de dados graças ao mecanismo de armazenamento e reenvio). Temperatura máxima registada na junção: 78 °C no local mais quente, em julho. Volume médio de ingestão de dados no Azure: 1,4 GB/mês por local, contra a estimativa inicial do cliente de 6,8 GB/mês — uma redução de 79% alcançada através da lógica de filtragem na periferia. Desde então, o cliente comprometeu-se a implementar o mesmo projeto em mais 22 locais na próxima fase.
Considerações sobre segurança e fiabilidade para implementações de gateways em produção
Um gateway industrial situa-se na intersecção entre as redes OT e IT, o que o torna uma das superfícies de ataque de maior prioridade num ambiente industrial. A segurança não é um complemento opcional a ser adicionado após a implementação — deve ser integrada no sistema desde a fase de seleção do hardware. Para os gateways baseados no RK3568, os seguintes requisitos de produção são imprescindíveis.
Arranque Seguro e Armazenamento Encriptado
O RK3568 suporta o arranque seguro com suporte de hardware, utilizando a verificação de assinaturas RSA-2048 ou ECDSA-256 no gestor de arranque e na imagem do kernel. A ativação da inicialização segura impede modificações não autorizadas no firmware — o que é fundamental para gateways instalados em locais fisicamente acessíveis (subestações, estações de bombagem remotas). A encriptação do armazenamento eMMC através do dm-crypt (AES-256-XTS) protege as credenciais, os certificados e os dados dos sensores armazenados em buffer, caso o dispositivo seja fisicamente removido.
Segmentação de rede
Conforme referido anteriormente, a configuração da interface dupla GbE impõe a separação OT/IT ao nível do hardware. Complemente isto com regras do iptables que: bloqueiem todas as ligações de entrada da interface WAN para a LAN de campo, permitam apenas tráfego MQTT/TLS de saída na porta 8883 do gateway para a nuvem e rejeitem todo o tráfego de entrada não solicitado para a interface de gestão do gateway, exceto SSH numa porta não padrão com autenticação exclusivamente baseada em chave.
Autenticação baseada em certificados
Todas as ligações MQTT na nuvem devem utilizar TLS mútuo (mTLS) com certificados X.509 exclusivos para cada dispositivo. Tanto o AWS IoT Core como o Azure IoT Hub suportam o mTLS de forma nativa. A chave privada do dispositivo deve ser armazenada num módulo de segurança de hardware (HSM) ou num chip TPM, caso a placa de suporte inclua um — isto impede a extração da chave privada, mesmo que um atacante obtenha acesso de root ao sistema de ficheiros Linux.
Watchdog e Recuperação Remota
Os gateways de produção devem recuperar-se automaticamente de falhas de software sem intervenção humana. O RK3568 possui um temporizador de vigilância de hardware — configure-o com um tempo limite de 60 segundos e ative-o a partir do daemon da aplicação. Adicione um temporizador de vigilância de software secundário ao nível do serviço systemd que verifique a conectividade com o broker MQTT a cada 5 minutos e reinicie a pilha de aplicações caso a conectividade seja perdida. Para implementações remotas em que o acesso no local é impossível, um caminho de gestão fora de banda (interface de comandos SMS do modem LTE ou VLAN de gestão dedicada) fornece um caminho de recuperação quando a aplicação principal fica bloqueada.
Opções de hardware do gateway ieeker RK3568
A ieeker fabrica placas baseadas no RK3568 em duas configurações adequadas às diferentes fases do processo de desenvolvimento e produção de gateways de IoT:
- Placa de Desenvolvimento Industrial RK3568 (SBC): Duas portas GbE, RS-485, barramento CAN, M.2 PCIe (ranhura para modem LTE), SATA III, USB 3.0, HDMI e conector GPIO completo. É fornecido com imagens validadas do Buildroot, Debian 11 e Ubuntu 22.04. Disponível para avaliação imediata a partir de quantidades de uma única unidade. Concebido para implementações de protótipos, projetos-piloto e produção em pequenos volumes. Consulte o Página do produto da placa industrial RK3568 para consultar as especificações completas.
- SoM (Módulo Central) RK3568 + Placa de suporte personalizada: O SoM RK3568 disponibiliza todas as interfaces do SoC num conector SODIMM-314P ou MXM, permitindo a conceção de placas de suporte com dimensões de caixa personalizadas, disposição personalizada das interfaces, tipos de conectores industriais (M12, blocos de terminais para calha DIN) e revestimento conformável para ambientes adversos. NRE a partir de $4,000. Unidades de produção a partir de 50 peças. Saiba mais sobre o Conceção de placas de desenvolvimento personalizadas e fluxo de trabalho OEM.
Quer construir um gateway de IoT industrial com o RK3568?
Partilhe os seus requisitos de interface e ambiente de implementação — recomendaremos a configuração adequada da placa e forneceremos a documentação do BSP no prazo de 24 horas.
→ Obter assistência técnica para o Gateway RK3568 →Perguntas mais frequentes
Quantos dispositivos Modbus pode um gateway RK3568 interrogar simultaneamente?
O fator limitante é a largura de banda do barramento série, e não a CPU. Cada UART RS-485 suporta até cerca de 40–60 dispositivos escravos Modbus RTU a 115 200 baud, com um ciclo de sondagem de 500 ms. Com três interfaces UART no RK3568, um único gateway pode fazer o polling de 120 a 180 dispositivos Modbus RTU. Através do Modbus TCP sobre Gigabit Ethernet, o número de dispositivos pode chegar a várias centenas (limitado pelo número de portas do switch de rede e pelos requisitos de tempo do ciclo de polling). A CPU quad-core do RK3568, que executa daemons de sondagem com uma utilização de 10–20% por núcleo, lida com esta carga de trabalho com margem de manobra para o processamento na periferia.
Qual é a diferença entre o RK3568 e o RK3568J para implementações de gateways industriais?
O RK3568J é a variante de nível industrial do RK3568, testada e classificada para funcionamento em intervalos de temperatura alargados (temperatura de junção de -40 °C a +85 °C, em comparação com 0 °C a +70 °C para a variante comercial). Para implementações de gateways em temperaturas ambientes superiores a 45 °C — armários industriais, caixas de proteção exteriores, instalações sem controlo climático —, o RK3568J proporciona a margem térmica necessária. O RK3568J conta também com um compromisso de disponibilidade de componentes por parte da Rockchip por um período mais longo, o que é importante para produtos de gateway com uma vida útil prevista de 5 a 10 anos.
O RK3568 consegue executar um servidor OPC UA e um broker MQTT em simultâneo?
Sim. Uma configuração de produção típica executa simultaneamente o open62541 (servidor OPC UA, ~30 MB de RAM), o Mosquitto (broker MQTT, ~8 MB de RAM), o Node-RED (processamento na periferia, ~80 MB de RAM) e o daemon de polling Modbus (~10 MB de RAM). O consumo total de RAM das aplicações nesta pilha é de aproximadamente 130–150 MB. Numa placa RK3568 com 2 GB de LPDDR4, isto deixa mais de 1,8 GB para o sistema operativo, os buffers e o histórico de dados — bem dentro das margens operacionais.
Que modem móvel é compatível com a ranhura PCIe M.2 do RK3568?
Os modems LTE/5G com formato M.2 2242 ou 3042 e interface PCIe ou USB são compatíveis. As opções validadas incluem o Quectel EC25 (LTE Cat 4), o Quectel RM500Q (5G Sub-6 GHz) e o SIMCom SIM7600. Estes módulos são reconhecidos como interfaces de rede WWAN através do qmi-wwan ou mbim Drivers para Linux, que estão incluídos no BSP do RK3568. Verifique o tipo de chave M.2 da sua placa de suporte (chave M para PCIe, chave B para USB) antes de selecionar o modem.
Como se compara o RK3568 ao Raspberry Pi CM4 em aplicações de gateways de IoT industrial?
O Raspberry Pi CM4 é uma plataforma de desenvolvimento viável, mas apresenta limitações documentadas para a produção de gateways industriais: não dispõe de barramento CAN nativo (requer um adaptador USB-CAN), possui apenas um MAC de Gigabit Ethernet (a topologia com duas placas de rede requer Ethernet via USB), temperatura de funcionamento de nível de consumo (de -20 °C a +85 °C na temperatura ambiente da placa de circuito impresso, em comparação com -40 °C a +85 °C na junção do RK3568J), e ausência de compromisso quanto à longevidade do fornecimento de nível industrial. Para prototipagem e projetos-piloto de baixo volume (<50 unidades), o CM4 é aceitável. Para programas de produção de gateways de IoT com mais de 100 unidades que exijam uma vida útil em campo superior a 5 anos em ambientes industriais, o RK3568J é a escolha correta.
Qual é o consumo de energia típico de um gateway IoT RK3568 em plena carga?
Com a porta de ligação a funcionar a plena capacidade (4 núcleos ativos, duas portas GbE ativas, modem LTE a transmitir e inferência da NPU com um ciclo de funcionamento de 50%), o SoC RK3568 consome aproximadamente 3,5–5 W. A potência total do sistema, incluindo a placa portadora, o modem LTE e o SSD SATA, situa-se normalmente entre 8 W e 12 W, dependendo da potência de transmissão do modem e da atividade do SSD. Isto permite a conceção de um sistema de gateway com uma fonte de alimentação industrial padrão de 12 V/1 A ou 24 V/500 mA — a gama de tensão de entrada padrão para calhas DIN — com uma margem confortável.
Fontes e referências
- Dimensão e quota de mercado dos dispositivos de gateway IoT 2026–2035 — Global Market Insights
- Computação na Periferia com o Gateway Modbus para MQTT: Uma Análise Aprofundada — Hashstudioz
- Arquitetura de gateways IoT: Periferia vs. Nuvem, conversão de protocolos e padrões de implementação — Wevolver
- Protocolo Modbus — Wikipédia
- open62541 — Pilha OPC UA de código aberto — GitHub
- Análise do crescimento do mercado de gateways de IoT industrial 2026–2030 — Technavio