Mini-Projecto · Sistema de automação industrial integrado com IoT
Contexto
A "Metalfrio", uma pequena fábrica de componentes metálicos, quer monitorizar remotamente uma linha de produção: temperatura de um motor, vibração de um rolamento e o estado (ligado/desligado) de uma máquina controlada por um autómato (PLC) já existente. Foste contratado/a para desenvolver um sistema de automação integrado com IoT que leia estes dados, os envie com segurança para uma plataforma cloud, e apresente um dashboard com alertas de manutenção preditiva.
Trabalhas individualmente ou em grupo, com kit Arduino/ESP32 (ou similar) e/ou autómato, e entregas o sistema a funcionar mais um pequeno dossiê técnico (arquitetura, configuração de rede, protocolos usados e decisões de segurança).
Requisitos
Funcionais
- Firmware que lê pelo menos dois sensores (ex.: temperatura e vibração/luminosidade, conforme o hardware disponível) e publica os dados periodicamente.
- Rede de comunicação configurada e testada (Wi-Fi, ou outra disponível), com envio e receção de dados sem falhas.
- Protocolo de dados IoT (MQTT ou HTTP) a transportar as leituras até uma plataforma cloud ou local (ex.: Node-RED, ThingsBoard).
- Simulação de integração com PLC/SCADA: pelo menos um estado (ligado/desligado, ou um valor Modbus simulado) representando a máquina do autómato, integrado no mesmo fluxo de dados.
- Dashboard que mostra as leituras em tempo real e um histórico simples (gráfico ou tabela).
- Alerta automático quando um valor ultrapassa um limite definido (ex.: temperatura acima de X °C).
- Atuador de teste: pelo menos um atuador (LED, relé ou buzina) acionado a partir de uma decisão do sistema (manual ou automática).
Não-funcionais
- Segurança: credenciais próprias do dispositivo (não partilhadas), e ligação cifrada sempre que a plataforma o permitir.
- Resiliência: o firmware deve tentar reconectar-se automaticamente se a rede cair.
- Documentação: arquitetura em camadas, endereços de rede e protocolos usados, para manutenção futura.
- Cumprimento das normas em vigor aplicáveis à instalação elétrica e de segurança dos componentes usados.
Fases
Fase 1 · Arquitetura e planeamento (2h) Desenhar o diagrama de camadas (perceção, rede, processamento, aplicação) do sistema a construir. Escolher a plataforma de desenvolvimento, a rede e o protocolo, com justificação.
Fase 2 · Sistema operativo e ambiente de desenvolvimento (2h) Preparar o dispositivo (Arduino/ESP32 ou similar), instalar o IDE e as bibliotecas necessárias, confirmar upload de um sketch de teste e leitura no monitor série.
Fase 3 · Firmware: sensores e atuador (4h) Programar a leitura dos sensores escolhidos, com filtragem básica de valores absurdos, e o controlo do atuador de teste.
Fase 4 · Rede e protocolo (3h) Configurar a rede de comunicação, testar envio e receção sem falhas, e implementar a publicação dos dados por MQTT ou HTTP, em formato estruturado (JSON) com timestamp.
Fase 5 · Integração cloud e PLC/SCADA (4h) Registar o dispositivo na plataforma cloud/local, ligar o fluxo de dados, e integrar o estado simulado do PLC/autómato no mesmo painel.
Fase 6 · Dashboard, alertas e segurança (3h) Construir o dashboard com histórico, configurar o alerta automático, e aplicar as medidas de segurança (credenciais próprias, cifra, reconexão automática).
Fase 7 · Apresentação (2h) Demonstrar o sistema completo à turma: sensor a ler, dado a chegar à cloud, alerta a disparar, e explicar as decisões de arquitetura e segurança do dossiê.
Critérios de avaliação
| Critério | Peso |
|---|---|
| Arquitetura e escolhas justificadas (rede, protocolo, plataforma) | 15% |
| Firmware: sensores, atuador e resiliência | 20% |
| Rede e comunicação sem falhas | 15% |
| Integração cloud + PLC/SCADA simulado | 20% |
| Dashboard, alertas e segurança | 20% |
| Dossiê e apresentação | 10% |
Erros comuns
- Escolher Wi-Fi ou MQTT "por hábito" sem justificar face ao cenário real da fábrica.
- Bloquear o
loop()comdelay()longos, atrasando a reação do sistema. - Enviar dados sem timestamp, impossibilitando reconstruir o histórico correto.
- Ligar o atuador de teste diretamente ao pino do microcontrolador sem relé, arriscando danificar o hardware.
- Tratar a integração com o PLC como decorativa, sem pensar na fronteira de segurança (o PLC continua a garantir o controlo crítico).
- Esquecer a reconexão automática: uma queda de rede de 10 segundos deixa o sistema "cego" para sempre.
- Deixar credenciais e passwords visíveis no código-fonte partilhado.
Bónus (opcional)
- Implementar cifra TLS na ligação MQTT (MQTTS).
- Adicionar um segundo atuador com controlo proporcional (PWM), por exemplo uma ventoinha de arrefecimento.
- Simular a tradução Modbus → MQTT com um pequeno script, em vez de publicar o estado do PLC diretamente.
- Guardar o histórico numa base de dados de série temporal (ex.: InfluxDB) em vez de só no dashboard.
Reflexão
No dossiê final, responde: porque é que a paragem de emergência ou o controlo crítico de uma máquina nunca deve depender apenas da ligação à cloud? E que duas medidas de segurança aplicaste para proteger o teu sistema de um acesso indevido?