Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX040.
flowchart TD
N0["14.1 Medidores de calor revelam vidas"]
N1["14.2 Minimização e finalidade"]
N2["14.3 Agregação como controle"]
N3["14.4 A linha de base de IoT de consumo"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX040"]
Desenho lógico
flowchart LR
N0["14.1 Medidores de calor revelam vidas"]
N1["14.2 Minimização e finalidade"]
N2["14.3 Agregação como controle"]
N3["14.4 A linha de base de IoT de consumo"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]
[14.1 Medidores de calor revelam vidas]
|
v
[14.2 Minimização e finalidade]
|
v
[14.3 Agregação como controle]
|
v
[14.4 A linha de base de IoT de consumo]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX040]
Objetivos de aprendizagem
Você vai (1) reconhecer dados pessoais em fluxos de medidores inteligentes e de automação predial; (2) aplicar minimização de dados e limitação de finalidade; (3) escolher intervalos de agregação que atendam à operação sem revelar o comportamento das residências; e (4) relacionar privacidade com a provisão 5.8 da ETSI EN 303 645.
14.1 Medidores de calor revelam vidas
Os medidores IoT da LDHP informam o consumo de calor de cada residência. Leituras horárias mostram quando os moradores acordam, cozinham, viajam ou estão fora — o mesmo problema de inferência que tornou controversos os medidores inteligentes de eletricidade. Em muitas jurisdições, essas leituras são dados pessoais, porque se referem a uma residência identificável. Um perfil horário de um único medidor da LDHP pode mostrar uma residência que deixa de aquecer por dez dias em fevereiro, o que diz a qualquer pessoa que o leia que a casa está vazia. O faturamento não precisa de nada disso. É por isso que o pedido da equipe de análise de dados por leituras domiciliares a cada cinco minutos, no caso de Maya, encontrou resistência: nessa resolução, os dados mostram rotinas diárias, e não apenas consumo.
14.2 Minimização e finalidade
O faturamento precisa de um total mensal. O balanceamento da rede precisa da vazão por bairro, não de detalhes casa a casa. A detecção de falhas pode precisar de leituras individuais, mas talvez diárias e guardadas por semanas, não por anos. Escrever a finalidade ao lado de cada fluxo de dados força a pergunta "precisamos desta granularidade?". A resposta de Maya ao pedido da equipe de análise por dados domiciliares a cada cinco minutos pôs uma finalidade ao lado de cada fluxo: totais mensais para o faturamento, leituras diárias por residência guardadas por 60 dias para detecção de vazamentos e agregados horários por rua para o balanceamento. Os dados de cinco minutos simplesmente não foram coletados, porque nenhuma finalidade havia sido definida.
14.3 Agregação como controle
Agregar 40 residências de um trecho de rua antes que os dados saiam do gateway remove os padrões individuais e mantém o sinal operacional. A agregação não é perfeita: se uma moradia domina o trecho, o seu padrão continua visível, por isso os engenheiros verificam o tamanho mínimo do grupo. O desenho de Maya fixa o mínimo em 20 moradias por agregado para os dados de balanceamento. Um trecho de rua com menos moradias, ou com um grande edifício que usa a maior parte do calor, é fundido com o vizinho antes que o agregado horário saia do gateway, para que nenhum agregado seja, na prática, a leitura de uma única residência.
14.4 A linha de base de IoT de consumo
A provisão 5.8 da ETSI EN 303 645 pede que os dados pessoais em trânsito entre um dispositivo e os serviços associados sejam protegidos (por exemplo, criptografados), e a provisão 6 trata da proteção de dados de forma mais geral — informar os consumidores sobre quais dados são tratados e por quê. Um medidor de aquecimento distrital nem sempre é "IoT de consumo", mas as provisões são uma lista de verificação útil. Para os medidores da LDHP, a 5.8 aponta para o enlace de rádio e para o uplink do gateway, que carregam leituras domiciliares; a provisão 6 aponta para informar os moradores sobre o que é coletado e por quê, o que a lista de finalidades de Maya já faz.
Exemplo resolvido (LDHP sintética)
A equipe de análise pede leituras domiciliares a cada cinco minutos "para aprendizado de máquina no futuro". A resposta de Maya: totais mensais para o faturamento; leituras diárias por residência guardadas por 60 dias para detecção de vazamentos; agregados horários por rua (mínimo de 20 moradias) para o balanceamento; dados domiciliares de cinco minutos não coletados sem uma finalidade definida e uma avaliação de impacto à privacidade.
Caso sintético — Lakeside District Heating Plant. O pedido da equipe de análise e os prazos de retenção são exemplos inventados.
Erros e limites
Pseudonimizar os IDs dos medidores não os anonimiza se os endereços forem guardados em outro lugar. As leis de privacidade variam; este capítulo é orientação, não aconselhamento jurídico.
Exercícios
- EX040 — Inferindo ocupação. Dê duas coisas que um observador poderia inferir das leituras horárias de calor de um apartamento.
Mostrar critérios de avaliação
Rubrica: 3 = duas inferências plausíveis (ausência, rotina diária, número de moradores); 2 = uma; 1 = vago; 0 = nada. - EX041 — Granularidade por finalidade. Para detecção de vazamentos, proponha um intervalo de leitura e um prazo de retenção e justifique ambos.
Mostrar critérios de avaliação
Rubrica: 3 = diário (ou horário) com retenção na escala de semanas e justificativa; 2 = só os valores; 1 = guardar tudo; 0 = nada. - EX042 — Quando a agregação falha. Por que um trecho que contém uma grande escola e cinco apartamentos poderia falhar como agregado de privacidade?
Mostrar critérios de avaliação
Rubrica: 3 = a escola domina; os padrões dos apartamentos se perdem, mas o da escola é revelado / grupo pequeno demais; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Dados operacionais de IoT muitas vezes são dados pessoais; colete-os para uma finalidade, na granularidade mais grossa que ainda seja útil, e proteja-os em trânsito e em repouso.