Sebenta · Desenvolver sistemas de automação integrados com IoT (UC03885)

Introdução

Esta sebenta ensina a desenvolver e implementar sistemas de automação integrados com a Internet das Coisas (IoT), do sensor mais simples até uma plataforma na cloud a mostrar dados em tempo real. A IoT já não é uma curiosidade de laboratório: é hoje o pilar da Indústria 4.0, presente em empresas de automação, empresas de controlo industrial e empresas industriais em geral, os contextos de trabalho previstos para esta unidade curricular.

O percurso é o de um técnico que constrói um sistema de automação de ponta a ponta: primeiro percebe o que é a IoT e como se organiza em camadas, depois escolhe o sistema operativo e a plataforma de desenvolvimento certos, programa o firmware que lê sensores e controla atuadores, escolhe as redes e os protocolos de comunicação, envia os dados para uma plataforma cloud, constrói uma aplicação de back-end/front-end para os apresentar, e por fim garante que tudo isto é seguro e integra corretamente com PLC e SCADA existentes na fábrica.

Objetivos de aprendizagem (referencial): desenvolver e implementar firmware para dispositivos IoT; configurar e utilizar redes de comunicação específicas para IoT; e integrar dispositivos IoT com plataformas na cloud, sempre considerando os requisitos definidos e específicos dos componentes, garantindo envio e receção de dados sem falhas e em segurança, garantindo a funcionalidade e sincronização do sistema, e cumprindo as normas em vigor.

1. IoT: conceito, relevância e campos de aplicação

A IoT (Internet of Things, Internet das Coisas) é a rede de objetos físicos equipados com sensores, capacidade de processamento e ligação de rede, capazes de recolher, trocar e agir sobre dados com pouca ou nenhuma intervenção humana. Um objeto ganha assim uma identidade digital: pode ser lido, monitorizado e, muitas vezes, controlado à distância.

A IoT nasce do encontro de três áreas:

IoT na indústria (IIoT)

Aplicada à indústria, a IoT chama-se IIoT (Industrial IoT) e é um dos pilares da Indústria 4.0, a par da automação e da robótica. Campos de aplicação típicos:

• Manutenção preditiva: sensores de vibração e temperatura antecipam avarias de motores e rolamentos antes da paragem.
• Monitorização de produção: contagem de peças, deteção de defeitos, tempos de paragem por linha.
• Gestão energética: consumo elétrico por máquina, deteção de desperdício.
• Logística e rastreabilidade: localização e estado de mercadorias e ativos.
• Agricultura de precisão, edifícios inteligentes e cidades inteligentes, como áreas próximas que partilham a mesma tecnologia de base.

O desenvolvimento e a relevância da IoT na indústria não estão em substituir a automação clássica, mas em acrescentar-lhe visibilidade e dados que antes não existiam.

2. Arquitetura de um sistema IoT

Um sistema IoT organiza-se, quase sempre, em quatro camadas:

Dispositivos, sensores, atuadores e plataformas de dados

• Dispositivo (device / node): a unidade física com microcontrolador, sensores e/ou atuadores.
• Sensor: converte uma grandeza física (temperatura, luz, presença, corrente, vibração) num sinal elétrico que o dispositivo consegue ler.
• Atuador: converte um sinal elétrico numa ação física (relé, motor, válvula, LED, buzina).
• Plataforma de dados: onde os dados chegam, são validados, guardados e disponibilizados a outras aplicações (ex.: Node-RED, ThingsBoard, AWS IoT Core).
• Aplicações: dashboards, apps móveis e integrações com sistemas de gestão (ERP) ou de supervisão (SCADA).

Exemplo resolvido · classificar um sistema por camadas

Sistema: uma estufa agrícola com sensor de humidade do solo, uma eletroválvula de rega, ligação LoRa a um gateway, e uma app que mostra o histórico e permite regar manualmente.

1. Perceção: sensor de humidade do solo (lê) e eletroválvula (atua).
2. Rede: LoRa entre o dispositivo de campo e o gateway.
3. Processamento: gateway encaminha para uma plataforma cloud, que guarda o histórico de humidade.
4. Aplicação: app do agricultor, com histórico e botão de rega manual.

Este exercício de "separar por camadas" é a primeira coisa a fazer perante qualquer sistema novo: ajuda a perceber onde está cada responsabilidade e onde procurar uma falha.

3. Sistemas operativos para dispositivos IoT

Nem todos os dispositivos IoT correm o mesmo tipo de software, e escolher bem é uma das aptidões do referencial (selecionar dispositivos, sistemas operativos, redes e aplicações; operar com sistemas operativos):

• Bare-metal / sem SO: o código corre diretamente sobre o microcontrolador (ex.: um sketch simples de Arduino). Simples, previsível, mas limitado a uma tarefa de cada vez.
• RTOS (Real-Time Operating System): sistema operativo de tempo real, com tarefas concorrentes e prazos garantidos (ex.: FreeRTOS, Zephyr). Usa-se quando há várias tarefas a correr "ao mesmo tempo" com prazos críticos.
• Linux embutido: em dispositivos mais potentes (ex.: Raspberry Pi), permite correr aplicações completas, redes, ficheiros e vários processos, tal como um computador normal.

Operar com sistemas operativos implica saber usar comandos básicos de diagnóstico (em Linux: ls, cd, systemctl, journalctl), gerir processos e serviços que arrancam com o dispositivo, e atualizar o sistema de forma controlada, sem interromper o serviço a meio.

4. Redes de comunicação para IoT

Configurar e utilizar redes de comunicação específicas para IoT é uma das três realizações desta UC. As redes distinguem-se sobretudo por alcance e consumo de energia:

A regra geral: quanto maior o alcance e menor o consumo, menor a largura de banda disponível. Uma rede LoRa envia poucos bytes de cada vez; não serve para vídeo, mas é perfeita para uma leitura de sensor a cada 10 minutos, durante meses, com uma pilha.

Exemplo resolvido · configurar um dispositivo numa rede

Cenário: ligar um sensor de temperatura ESP32 à rede Wi-Fi de uma oficina e garantir que os dados chegam sem falhas.

1. Credenciais de rede: definir SSID e password no firmware (idealmente fora do código-fonte, num ficheiro de configuração).
2. Endereçamento: usar DHCP para simplicidade, ou IP estático se o dispositivo precisar de ser sempre encontrado no mesmo endereço.
3. Alcance e sinal: testar o RSSI (força de sinal) no local final de instalação, não só junto ao router.
4. Teste de envio/receção sem falhas: enviar 100 leituras seguidas e confirmar que todas chegam à plataforma, sem perdas.
5. Reconexão automática: o firmware deve tentar religar-se sozinho se a rede cair, sem intervenção manual.

Este é exatamente o critério de desempenho "garantindo envio e receção de dados sem falhas e em segurança" a ser aplicado na prática.

5. Protocolos IoT e protocolos de comunicação industrial

Protocolos de dados IoT

Um protocolo define o formato e as regras de troca de mensagens entre dispositivos:

• MQTT: protocolo publish/subscribe, muito leve, ideal para dispositivos com poucos recursos. Um dispositivo publica num tópico (ex.: estufa/temp); outros subscrevem esse tópico e recebem as atualizações.
• HTTP/HTTPS: protocolo de pedido/resposta, mais pesado, comum quando o dispositivo fala diretamente com uma API web.
• CoAP: semelhante ao HTTP mas otimizado para redes de baixo consumo e baixa largura de banda.
• WebSocket: ligação persistente e bidirecional, útil quando se quer ver dados a mudar em tempo real num dashboard.

Protocolos de comunicação industrial

Um sistema de automação integrado com IoT precisa quase sempre de traduzir entre o mundo industrial (Modbus, OPC UA) e o mundo IoT/cloud (MQTT, HTTPS). Esse papel de tradução é feito por um gateway, que fica entre o PLC e a plataforma cloud.

Exemplo resolvido · escolher o protocolo certo

Situação: um sensor a bateria, isolado, a enviar uma leitura a cada 15 minutos durante 2 anos sem trocar de pilha.

1. Descartar HTTP: o overhead do protocolo consome bateria a mais para tão pouca informação.
2. Escolher MQTT sobre uma rede de baixo consumo (ex.: LoRaWAN ou NB-IoT), que mantém as mensagens curtas e as ligações pouco frequentes.
3. Configurar a qualidade de serviço (QoS) do MQTT ao nível suficiente para garantir a entrega sem exigir confirmações excessivas.

Resultado: dados entregues com fiabilidade e consumo mínimo, o compromisso certo para este cenário.

6. Plataformas de desenvolvimento, prototipagem e firmware

Plataformas de desenvolvimento IoT

Utilizar plataformas de desenvolvimento e prototipagem é uma aptidão central desta UC:

• Arduino (Uno, Nano, Mega): microcontrolador simples, ótimo para aprender e prototipar depressa.
• ESP32 / ESP8266: microcontroladores com Wi-Fi e Bluetooth integrados, muito usados em IoT real.
• Raspberry Pi: computador completo, corre Linux, para projetos que precisam de mais processamento.
• Autómatos (PLC) e módulos compatíveis, com as respetivas consolas gráficas, para automação industrial mais robusta.

A escolha depende da complexidade do projeto, do consumo de energia disponível e do ambiente de instalação (laboratório vs. chão de fábrica).

Desenvolver e implementar firmware

Desenvolver e implementar firmware para dispositivos IoT é a primeira realização do referencial. O firmware é o software que corre diretamente no dispositivo. Na estrutura típica do Arduino/ESP32:

• setup(): corre uma vez, ao ligar o dispositivo. Serve para inicializar sensores, pinos e a ligação de rede.
• loop(): corre continuamente, enquanto o dispositivo está ligado. É onde se lê o sensor, se decide e se atua.

setup():
  iniciar sensores
  ligar à rede
loop():
  ler sensor
  decidir (com base no valor lido)
  atuar (se necessário)
  enviar dados
  aguardar

As linguagens mais usadas para programar dispositivos IoT são o C/C++ (Arduino e a maioria dos microcontroladores, com controlo direto do hardware) e o MicroPython (Python simplificado, mais rápido de prototipar em placas como o ESP32 ou o Raspberry Pi Pico). Instalar e configurar o firmware de execução das funções especificadas significa confirmar, no final, que o código faz exatamente o que o projeto exige, nem mais nem menos.

Exemplo resolvido · firmware mínimo de um sensor

Objetivo: ler um sensor de temperatura a cada 30 segundos e imprimir o valor no monitor série.

#include <DHT.h>
DHT dht(4, DHT22);

void setup() {
  Serial.begin(115200);
  dht.begin();
}

void loop() {
  float temp = dht.readTemperature();
  Serial.print("Temperatura: ");
  Serial.println(temp);
  delay(30000);
}

Passo a passo: setup() inicia a comunicação série e o sensor; loop() lê a temperatura, imprime-a e aguarda 30 segundos antes de repetir. Este esqueleto é a base sobre a qual se acrescenta depois rede, protocolo e envio de dados.

7. Sensores, atuadores e recolha de dados em tempo real

Ler sensores

• Sensores analógicos (ex.: LDR, potenciómetro): devolvem uma tensão variável, convertida por um ADC (conversor analógico-digital) num número.
• Sensores digitais (ex.: DHT22, botão): devolvem 0/1 diretamente ou comunicam por protocolo (I²C, SPI, one-wire).
• Frequência de amostragem: com que regularidade ler o sensor, equilibrando precisão com consumo de energia.
• Filtragem básica: descartar leituras absurdas (ex.: -127 °C de um sensor mal ligado) antes de as usar.

Controlar atuadores

• Digital ON/OFF: relé, LED.
• PWM (largura de impulso): controlo proporcional, para variar a intensidade de um LED ou a velocidade de um motor.
• Comandos por protocolo: atuadores mais avançados que recebem ordens por I²C/SPI ou pela rede.
• Segurança do atuador: nunca atuar sem confirmar o estado do sistema (ex.: não ligar um motor com uma proteção aberta).

Técnicas de recolha, envio e armazenamento de dados em tempo real

1. Recolher o dado com a frequência adequada ao fenómeno físico (temperatura muda devagar; vibração muda depressa).
2. Enviar, empacotando os dados (tipicamente em JSON) e publicando-os no protocolo escolhido.
3. Registar o timestamp da leitura, essencial para qualquer análise posterior.
4. Guardar num tipo de base de dados adequado, normalmente uma base de dados de série temporal (time-series), otimizada para grandes volumes de leituras com hora.
5. Analisar: gerar alertas em tempo real (valor fora de intervalo) e relatórios históricos (tendências, padrões).

Exemplo resolvido · do sensor ao registo

Objetivo: gerar e enviar uma leitura estruturada de temperatura.

{
  "dispositivo": "sensor-01",
  "temperatura": 23.4,
  "timestamp": "2026-09-04T10:15:00Z"
}

Passo a passo: o firmware lê a temperatura (23.4 °C), obtém a hora atual, monta este objeto JSON e publica-o no tópico MQTT correspondente. Do outro lado, o back-end recebe a mensagem, valida-a e grava-a com o timestamp, pronta a ser consultada num gráfico.

8. Integração com plataformas cloud e aplicações back-end/front-end

Integrar dispositivos IoT com plataformas na cloud

Integrar dispositivos IoT com plataformas na cloud é a terceira realização do referencial. Os passos típicos:

1. Registar o dispositivo na plataforma cloud (nome, tipo, credenciais únicas).
2. Configurar o firmware com o endereço do servidor, as credenciais e o protocolo (normalmente MQTT sobre TLS).
3. Testar a ligação, confirmando que os dados chegam à plataforma em tempo real.
4. Criar regras e alertas, para ações automáticas quando um valor ultrapassa um limite definido.
5. Ligar a um dashboard, para visualização por parte do utilizador final.

Exemplos de plataformas: AWS IoT Core, Azure IoT Hub, Google Cloud IoT, e alternativas open-source como ThingsBoard ou Node-RED.

Back-end e front-end

Aplicar linguagens de programação para desenvolvimento de aplicativos de back-end ou front-end fecha o ciclo entre o dispositivo e o utilizador:

• Back-end: recebe os dados dos dispositivos (por exemplo, subscrevendo tópicos MQTT), processa-os, guarda-os e expõe uma API (normalmente REST) para outras aplicações consumirem.
• Front-end: interface visual, web ou app móvel, onde o utilizador vê os dados e pode enviar comandos.
• A ligação entre back-end e front-end faz-se por API REST (pedido/resposta) ou WebSocket (dados em tempo real, sem ter de pedir repetidamente).

Exemplo resolvido · do sensor ao dashboard

Cenário: sensor de temperatura numa estufa, com alerta se ultrapassar 30 °C.

1. Firmware (ESP32 + DHT22): lê a temperatura a cada 30 s e publica em MQTT no tópico estufa/temp.
2. Broker MQTT: recebe a publicação e distribui a quem subscreveu o tópico.
3. Back-end: subscreve estufa/temp, grava o valor com timestamp na base de dados, e verifica se ultrapassa 30 °C.
4. Alerta: se ultrapassar, o back-end envia uma notificação por email.
5. Front-end: um dashboard mostra o gráfico da temperatura ao longo do dia.

Mudar o limite de alerta de 30 °C para 32 °C faz-se no back-end, sem reprogramar o dispositivo: é uma das vantagens de separar bem as responsabilidades.

9. Segurança em sistemas de automação IoT

Segurança em sistemas de automação IoT é simultaneamente um conhecimento do referencial e parte de um critério de desempenho: garantir envio e receção de dados sem falhas e em segurança.

Desafios

• Superfície de ataque grande: muitos dispositivos, muitas vezes com pouca capacidade própria de defesa.
• Credenciais fracas ou por defeito: uma das principais causas de dispositivos comprometidos em todo o mundo.
• Dados sensíveis em trânsito: sem cifra, podem ser intercetados por terceiros.
• Firmware desatualizado: mantém vulnerabilidades conhecidas por corrigir.
• Impacto físico: um ataque a IoT industrial pode causar dano físico real, ao contrário de um ataque a um site comum.

Práticas de segurança

Cumprir as normas em vigor aplica-se também aqui: segurança e proteção de dados não são um extra, são parte do critério de avaliação de qualquer sistema entregue.

10. PLC, SCADA e integração automação-IoT: benefícios, desafios e escalabilidade

Dispositivos IoT e sistemas de controlo industrial

• PLC (Programmable Logic Controller / Autómato): controlador robusto que executa lógica de automação em tempo real (arrancar/parar motores, sequências de produção, segurança de máquinas).
• SCADA (Supervisory Control and Data Acquisition): sistema de supervisão que recolhe dados de vários PLCs e apresenta um painel de controlo centralizado.

A integração com IoT acrescenta a estes sistemas acesso remoto, análise na cloud e manutenção preditiva, sem substituir a robustez do PLC no controlo em tempo real: as paragens de emergência e a segurança de máquinas continuam a depender do PLC local, nunca de uma ligação à internet.

Aplicar as normas e práticas de operação de sistemas robóticos aplica-se também às células industriais ligadas a redes IoT: procedimentos de segurança de máquinas, zonas de segurança e testes em modo seguro antes de ligar qualquer atuação automática vinda da cloud.

Benefícios e desafios da integração

Benefícios: visibilidade em tempo real sobre processos antes "às cegas"; manutenção preditiva, com menos paragens não planeadas; otimização de recursos (energia, materiais, tempo); escalabilidade, ao acrescentar novos sensores ou máquinas sem reconstruir o sistema; decisão baseada em dados, não em intuição.

Desafios: interoperabilidade com sistemas antigos (legacy), que exige gateways de tradução; custo inicial de sensores, rede e plataforma; complexidade acrescida de manutenção, com mais dispositivos e mais pontos de falha possíveis.

Design para eficiência, escalabilidade e manutenção

• Escolher a frequência de amostragem e o protocolo certos, sem desperdiçar energia nem largura de banda.
• Usar nomenclatura consistente de dispositivos, para o sistema continuar legível quando crescer.
• Centralizar atualizações de firmware e configuração, em vez de atualizar dispositivo a dispositivo à mão.
• Documentar esquemas, endereços de rede e protocolos usados, para a manutenção futura de quem vier a seguir.

Um bom projeto de automação integrado com IoT pensa, desde o primeiro esboço, em como o sistema vai crescer e em como vai ser mantido daqui a dois anos.

Erros comuns

• Escolher sempre Wi-Fi por hábito, ignorando alcance, consumo e o local real de instalação do dispositivo.
• Bloquear o loop() do firmware com delay() longos, impedindo o dispositivo de reagir a outros eventos.
• Usar credenciais partilhadas entre todos os dispositivos, em vez de uma identidade única por dispositivo.
• Enviar dados sem timestamp, tornando impossível reconstruir a ordem real dos acontecimentos.
• Ligar um atuador de potência diretamente ao pino do microcontrolador, sem relé nem driver, danificando o hardware.
• Confiar que o IoT substitui o PLC no controlo crítico, quando deve complementá-lo, nunca substituir a segurança local.
• Deixar interfaces de configuração sem password, abrindo a porta a acessos indevidos.
• Projetar só para o protótipo (2 sensores) e o sistema não aguentar quando cresce para produção (200 sensores).

Glossário

• IoT / IIoT · Internet das Coisas / IoT Industrial, aplicada à indústria.
• Firmware · software que corre diretamente no dispositivo.
• RTOS · sistema operativo de tempo real, com tarefas concorrentes e prazos garantidos.
• Gateway · dispositivo que liga redes diferentes, traduzindo protocolos entre elas.
• MQTT · protocolo publish/subscribe leve, muito usado em IoT.
• Modbus / OPC UA · protocolos de comunicação industrial.
• PLC (autómato) · controlador programável que executa lógica de automação em tempo real.
• SCADA · sistema de supervisão e aquisição de dados de vários PLCs.
• API REST · interface que permite a comunicação entre back-end e outras aplicações.
• TLS/SSL · protocolos de cifra usados para proteger dados em trânsito.
• Time-series (base de dados de série temporal) · base de dados otimizada para leituras com timestamp.
• OTA (over the air) · atualização remota de firmware através da rede.
• PWM · modulação por largura de impulso, usada para controlo proporcional de atuadores.

Síntese

Um sistema de automação integrado com IoT segue sempre o mesmo fluxo: perceção (sensores e atuadores, escolhidos com o sistema operativo e a plataforma de desenvolvimento certos) → firmware que lê, decide e atua → rede e protocolo (Wi-Fi/LoRa/4G com MQTT, HTTP ou Modbus/OPC UA no lado industrial) → plataforma cloud que regista e analisa os dados → back-end/front-end que os entrega ao utilizador → segurança transversal a todo o percurso → integração cuidada com PLC/SCADA, pensada desde o início para eficiência, escalabilidade e manutenção. Domina este fluxo completo e serás capaz de projetar, implementar e defender qualquer sistema de automação com IoT que te seja pedido.

Exercícios resolvidos

1. Classifica por camadas: um sistema com um sensor de vibração num motor, ligação 4G a uma plataforma cloud, e um dashboard que mostra alertas de manutenção.

Resolução: Perceção · sensor de vibração; Rede · 4G; Processamento · plataforma cloud, que guarda e analisa as leituras; Aplicação · dashboard com alertas de manutenção preditiva.

2. Um dispositivo a bateria envia uma leitura a cada 15 minutos, durante 2 anos, num campo isolado. Que rede e que protocolo escolhes, e porquê?

Resolução: LoRaWAN (longo alcance, consumo muito baixo) com MQTT (protocolo leve). HTTP ficaria descartado por gastar bateria a mais em cada envio para tão pouca informação.

3. Porque é que se deve evitar delay() longos dentro do loop() do firmware?

Resolução: porque bloqueiam o dispositivo, impedindo-o de reagir a outros eventos (novas leituras, comandos de rede, atuação de emergência) durante esse tempo. Em alternativa, usam-se técnicas não bloqueantes (ex.: comparar o tempo decorrido com millis()).

4. Um colega quer ligar diretamente um motor de 12V a um pino do ESP32. Está correto? O que falta?

Resolução: não está correto. O pino do microcontrolador não tem corrente nem tensão suficiente para acionar um motor de potência e pode danificar-se. Falta um relé ou um driver de motor entre o microcontrolador e o motor.

5. Que prática de segurança evita que um dispositivo IoT comprometido comprometa toda a rede da empresa?

Resolução: a segmentação de rede, isolando a rede de dispositivos IoT da rede administrativa/de gestão, para que um dispositivo comprometido não alcance sistemas críticos.

6. Porque continua o Modbus tão usado na indústria, apesar de ser um protocolo antigo?

Resolução: pela simplicidade, robustez e pelo enorme parque instalado de equipamento que já o suporta; substituí-lo em massa implicaria um custo elevado, e continua a cumprir bem a função de comunicação com PLCs e sensores industriais.

7. Um sistema de rega automática recebe uma ordem "regar" vinda da cloud. Antes de atuar a eletroválvula, que verificação de segurança deve fazer localmente?

Resolução: confirmar localmente o estado do sistema (ex.: sensor de chuva, nível de água disponível) antes de atuar, porque a decisão automática vinda da cloud não deve substituir a segurança e a lógica de proteção do dispositivo no terreno.