NOTAS DO PROFESSOR
- Enfatizar que IoT não é um produto, é um paradigma: qualquer "coisa" com sensor + ligação + lógica é IoT.
- Erro comum: confundir IoT com "ter Wi-Fi". A ligação é só uma das três peças; sem sensor e sem lógica não há IoT.
- Analogia: um termómetro na parede é um objeto; um termómetro que envia a leitura para uma app é IoT.
NOTAS DO PROFESSOR
- Ligar cada exemplo ao contexto de trabalho da UC: empresas de automação, controlo industrial e empresas industriais.
- Pergunta à turma: numa fábrica que já conhecem (estágio, visita), onde poria sensores IoT primeiro?
- Erro comum: achar que IIoT substitui o PLC. Na prática complementa-o, acrescentando visibilidade e dados.
NOTAS DO PROFESSOR
- Desenhar o diagrama das quatro camadas no quadro e ir preenchendo com exemplos da turma.
- Erro comum: misturar "rede" e "processamento" como se fossem a mesma coisa. São responsabilidades distintas.
- Exemplo: um sensor de humidade (perceção) → LoRa (rede) → gateway/cloud (processamento) → app do agricultor (aplicação).
NOTAS DO PROFESSOR
- Fazer a turma classificar objetos do dia a dia como sensor, atuador, ou os dois (ex.: um termostato tem sensor + atuador).
- Erro comum: chamar "sensor" a um dispositivo inteiro. O sensor é só o componente de leitura.
- Exemplo prático: um sensor DHT22 (temperatura/humidade) e um relé a ligar uma ventoinha, no mesmo Arduino.
NOTAS DO PROFESSOR
- Comparar diretamente: Arduino Uno (bare-metal) vs Raspberry Pi (Linux) vs ESP32 com FreeRTOS.
- Erro comum: usar Linux embutido num projeto simples só "porque é mais poderoso". Nem sempre compensa o consumo e a complexidade.
- Pergunta: um dispositivo a bateria, a ler um sensor de 5 em 5 minutos, precisa de RTOS? Normalmente não.
NOTAS DO PROFESSOR
- Demonstrar, se possível, o acesso SSH a um Raspberry Pi e comandos básicos de diagnóstico.
- Erro comum: atualizar firmware em produção sem plano de recuperação (falha de energia a meio = dispositivo "brickado").
- Analogia: o SO do dispositivo IoT é como o SO de um computador, só que otimizado para recursos limitados.
NOTAS DO PROFESSOR
- Fazer a turma escolher a rede certa para 3 cenários: sensor num campo agrícola, pulseira, e máquina de fábrica ligada à corrente.
- Erro comum: escolher sempre Wi-Fi "porque é o que se conhece". Alcance e consumo mandam na escolha real.
- Explicar a troca fundamental: mais alcance e menos consumo = menos largura de banda (LoRa envia poucos bytes, não vídeo).
NOTAS DO PROFESSOR
- Ligar explicitamente ao critério de desempenho "garantindo envio e receção de dados sem falhas e em segurança".
- Erro comum: testar só em laboratório, perto do router, e o dispositivo falhar no local final de instalação (mais distante, com obstáculos).
- Exercício: medir o RSSI (força de sinal) de um Wi-Fi em vários pontos da sala com o telemóvel.
NOTAS DO PROFESSOR
- Desenhar o fluxo MQTT no quadro: broker no centro, dispositivos a publicar, dashboard a subscrever.
- Erro comum: usar HTTP para enviar uma leitura a cada segundo num dispositivo a bateria; o overhead esgota a bateria depressa.
- Exemplo: um sensor de temperatura publica em `casa/sala/temperatura`; a app subscreve esse tópico e recebe cada atualização.
NOTAS DO PROFESSOR
- Ligar à aptidão "utilizar protocolos de comunicação industrial" do referencial.
- Erro comum: pensar que basta ligar o PLC diretamente à internet. Normalmente há um gateway a fazer a tradução de protocolo.
- Pergunta: porque é que o Modbus continua tão usado, apesar de antigo? (simplicidade, robustez, parque instalado enorme).
NOTAS DO PROFESSOR
- Mostrar fisicamente (ou em foto) um Arduino, um ESP32 e um PLC lado a lado, e discutir diferenças.
- Erro comum: escolher sempre o Arduino "porque é o que se conhece", mesmo quando o projeto pede Wi-Fi (ESP32 resolve isso nativamente).
- Recursos da UC: Kit Arduino e similares, autómatos, módulos compatíveis, consolas gráficas · mostrar o que está disponível no laboratório.
NOTAS DO PROFESSOR
- Demonstrar ao vivo o fluxo completo: escrever um sketch simples, compilar, carregar e ver o resultado no monitor série.
- Erro comum: esquecer de selecionar a placa e a porta certas no IDE antes de carregar o código.
- Exercício rápido: pedir à turma para instalar uma biblioteca de um sensor e correr o exemplo que vem com ela.
NOTAS DO PROFESSOR
- Percorrer o pseudocódigo com a turma e mapear cada linha para uma função real (ex.: `dht.readTemperature()`).
- Erro comum: bloquear o `loop()` com `delay()` longos, o que impede o dispositivo de reagir a outros eventos.
- Analogia: `setup()` é "vestir e preparar-se de manhã"; `loop()` é "o dia a repetir-se" até o dispositivo desligar.
NOTAS DO PROFESSOR
- Comparar um trecho equivalente em C++ (Arduino) e MicroPython para o mesmo sensor, mostrando a diferença de sintaxe.
- Erro comum: copiar código de um tutorial sem adaptar os pinos ou o modelo exato do sensor usado na aula.
- Ligar à atitude "rigor": o firmware que "quase funciona" não é aceitável num sistema real.
NOTAS DO PROFESSOR
- Mostrar a diferença entre ler um pino digital e um pino analógico no código (digitalRead vs analogRead).
- Erro comum: não validar o valor lido (ex.: -127°C de um sensor desligado) e deixá-lo propagar para o dashboard.
- Exemplo: calcular a média de 5 leituras seguidas de um sensor de luz para suavizar o ruído.
NOTAS DO PROFESSOR
- Demonstrar PWM a variar o brilho de um LED, ligando o conceito a "duty cycle".
- Erro comum: ligar diretamente um atuador de potência (motor) ao pino do microcontrolador sem driver/relé, danificando o dispositivo.
- Pergunta: porque é que um sistema de rega automática deve verificar o sensor de chuva antes de atuar? (evitar rega desnecessária/dano).
NOTAS DO PROFESSOR
- Explicar porque o timestamp deve idealmente vir do dispositivo (ou ser corrigido no servidor) e não só da chegada ao servidor.
- Erro comum: perder dados quando a rede cai, por não implementar nenhum buffer local.
- Exercício: a turma desenha o JSON de leitura de um sensor de humidade do solo com 3 campos.
NOTAS DO PROFESSOR
- Mostrar um gráfico de série temporal simples (ex.: temperatura ao longo de um dia) e discutir o que se pode concluir dele.
- Erro comum: guardar tudo numa única tabela sem estrutura, tornando a consulta e a análise lentas e difíceis.
- Ligar ao critério "garantindo a funcionalidade e sincronização": os dados têm de chegar coerentes e na ordem certa.
NOTAS DO PROFESSOR
- Mostrar (ou simular) o painel de uma plataforma cloud com um dispositivo "online" a enviar dados.
- Erro comum: usar credenciais partilhadas por todos os dispositivos em vez de uma identidade única por dispositivo.
- Ligar à aptidão "instalar e configurar dispositivos IoT em plataformas na cloud".
NOTAS DO PROFESSOR
- Percorrer o fluxo completo com um exemplo concreto: sensor de temperatura → MQTT → ThingsBoard → dashboard com alerta.
- Erro comum: esquecer de testar o cenário de falha (dispositivo offline) e ver como a plataforma reage.
- Pergunta: que vantagem tem usar uma plataforma cloud em vez de guardar tudo só localmente? (acesso remoto, escala, integração).
NOTAS DO PROFESSOR
- Desenhar o diagrama completo: dispositivo → broker MQTT → back-end → base de dados → API → front-end.
- Erro comum: o front-end ligar-se diretamente ao dispositivo em vez de passar pelo back-end/plataforma, perdendo segurança e escala.
- Exemplo: um dashboard simples com Node-RED que mostra a temperatura recebida por MQTT em tempo real.
NOTAS DO PROFESSOR
- Passar este fluxo passo a passo no quadro antes de qualquer exercício prático; é o "esqueleto" de quase todos os projetos da UC.
- Erro comum: pôr a lógica de alerta no firmware do dispositivo em vez do back-end, dificultando alterações futuras ao limite.
- Perguntar: e se quisermos mudar o limite de 30°C para 32°C sem reprogramar o dispositivo? (fazer essa lógica no back-end/cloud).
NOTAS DO PROFESSOR
- Dar um exemplo real (sem entrar em detalhes técnicos de exploração) de um ataque famoso a dispositivos IoT (ex.: botnet Mirai).
- Erro comum: achar que "é só um sensor, não interessa a ninguém atacá-lo". Um dispositivo fraco é porta de entrada para a rede inteira.
- Ligar à atitude "responsabilidade pelas suas ações": más práticas de segurança têm consequências reais.
NOTAS DO PROFESSOR
- Percorrer a lista e pedir exemplos concretos de cada prática aplicados a um projeto da turma.
- Erro comum: deixar a porta de configuração do dispositivo (ex.: interface web) acessível sem password.
- Exercício rápido: dado um cenário de projeto, a turma identifica 3 riscos de segurança e a mitigação de cada um.
NOTAS DO PROFESSOR
- Mostrar a hierarquia clássica da automação industrial: campo (sensores/atuadores) → PLC → SCADA → agora também IoT/cloud.
- Erro comum: achar que o IoT "substitui" o PLC no controlo crítico. O PLC continua a garantir a segurança e o tempo real; o IoT acrescenta visibilidade.
- Ligar aos recursos da UC: autómatos, módulos compatíveis, consolas gráficas para o autómato selecionado.
NOTAS DO PROFESSOR
- Sublinhar que "vem da cloud" não dispensa as normas de segurança de máquinas industriais; são complementares, não substitutas.
- Erro comum: permitir que um comando remoto atue diretamente num robô sem validação local de segurança.
- Pergunta: porque é que uma paragem de emergência tem de funcionar mesmo sem ligação à internet? (segurança não pode depender da rede).
NOTAS DO PROFESSOR
- Pedir à turma exemplos de decisões que passaram a ser "baseadas em dados" graças a sensores (manutenção, energia, qualidade).
- Erro comum: implementar sensores sem definir antes que decisão os dados vão suportar; recolher dados "porque sim" não gera valor.
- Ligar ao conhecimento "integração dos sistemas de automação com IoT, benefícios e desafios".
NOTAS DO PROFESSOR
- Pedir à turma que identifique, num projeto proposto, um risco de escalabilidade (ex.: 500 dispositivos em vez de 5).
- Erro comum: projetar só para o protótipo de 2 sensores e o sistema não aguentar quando cresce para produção.
- Ligar à atitude "sentido de organização" e "sentido crítico" na fase de design.
NOTAS DO PROFESSOR
- Ler os quatro critérios em voz alta e pedir à turma para os ligar a exemplos concretos vistos nos blocos anteriores.
- Erro comum: tratar segurança e normas como "extra opcional" em vez de critério de avaliação real.
- Anunciar as fichas e o projeto: vão aplicar estes critérios num sistema de automação com IoT construído de raiz.