Exercicis d'aplicacions mòbils i Internet de les coses — Tecnologia i Digitalització 4t ESO

Nativa: es programa per a un sistema concret (Android o iOS) i s'instal·la des d'una botiga. Avantatge: aprofita millor el maquinari (càmera, sensors) i va més fluida.
Web: s'executa al navegador i s'obre amb una adreça. Avantatge: no cal instal·lar-la i funciona en qualsevol dispositiu.
Híbrida: es programa una vegada amb tecnologies web i s'empaqueta com a aplicació instal·lable. Avantatge: un sol codi per a diversos sistemes.
El perquè: tria el tipus segons el que necessites: rendiment, abast o rapidesa de desenvolupament.

És la xarxa d'objectes físics que tenen sensors, un petit processador i connexió a Internet, i que intercanvien dades sense la intervenció contínua d'una persona.
Exemples: un termòstat que s'ajusta des del mòbil, un rellotge intel·ligent que mesura el son i una bombeta que s'encén amb la veu.
Error típic: pensar que només hi ha IoT als ordinadors; el que importa és que l'objecte capta, comunica i, de vegades, actua.

Sensor: el d'humitat; actuador: la bomba; controlador: la placa ESP32.
Quan la terra és seca (humitat per sota d'un llindar), el controlador activa la bomba; quan la humitat torna a ser prou alta, l'atura.
El perquè: tot sistema de control té una entrada (sensor), una decisió (controlador) i una sortida (actuador).

(a) amb 2; (b) amb 4; (c) amb 1; (d) amb 3.
El perquè: cada sensor mesura una magnitud física diferent (moviment, posició, distància a un objecte i il·luminació) i les aplicacions la fan servir.

Esdeveniment: fer clic al Botó1. Acció: posar un valor a l'etiqueta. Propietat modificada: el Text de l'Etiqueta1, que passa a ser «Hola».
El perquè: la programació d'aplicacions funciona per esdeveniments: el programa espera que l'usuari faci alguna cosa i respon.

No és raonable: una llanterna només necessita controlar el flaix. Demanar contactes i ubicació pot indicar que recull dades per a altres usos.
El principi és el del mínim privilegi: una aplicació només ha de tenir els permisos que necessita per fer la seva funció.
Els permisos es poden revisar i retirar a la configuració del telèfon, i convé desinstal·lar les aplicacions poc fiables.

Ordre: (b) sensor, (d) passarel·la, (c) núvol, (a) aplicació.
El sensor capta la dada, la passarel·la la transmet a Internet, el núvol l'emmagatzema i la processa, i l'aplicació la mostra a l'usuari.

(a) Bluetooth de baix consum: curt abast, poca energia, ideal per a un accessori del mòbil.
(b) LoRa: llarg abast (quilòmetres) amb molt baix consum i pocs bits; ve bé quan només cal enviar mesures petites de tant en tant.
(c) Wi-Fi (o 4G/5G si no hi ha xarxa local): cal una velocitat alta per al vídeo.
Error típic: triar només per la velocitat; en IoT també compten el consum i l'abast.

Cada pulsació canvia l'estat: apagat → encès (1a pulsació) → apagat (2a) → encès (3a).
Hi ha 3 pulsacions: queda encès i ha canviat 3 vegades.
El perquè: el microcontrolador guarda una variable d'estat que s'inverteix amb cada esdeveniment; és la base de l'interruptor «toggle».

Riscos: 1) pot enregistrar converses que no estaven destinades a ell i enviar-les a un servidor; 2) algú podria accedir al compte i escoltar els enregistraments.
Precaucions: 1) revisar i esborrar l'historial d'enregistraments, i desactivar el micròfon quan no sigui necessari; 2) protegir el compte amb una contrasenya forta i verificació en dos passos, i mantenir actualitzat el dispositiu.

Lectures per sensor i dia: 24 · $\tfrac{3600}{30} = 2880$; per als 50 sensors: 144 000.
Dades al dia = 144 000 · 20 B = 2 880 000 B = 2,88 MB.
A l'any: 2,88 · 365 = 1051 MB, aproximadament 1,05 GB.
Conclusió: les dades de sensors són petites però acumulades; per això convé pensar quanta informació cal guardar.

Cada minut: I_mitjà = (80 · 2 + 0,01 · 58) / 60 = 2,68 mA; durada = 2000 / 2,68 = 747 h, uns 31 dies.
Cada 10 min: I_mitjà = (80 · 2 + 0,01 · 598) / 600 = 0,277 mA; durada = 2000 / 0,277 = 7230 h, uns 301 dies.
Transmetre 10 vegades menys sovint multiplica la durada gairebé per 10: gairebé tot el consum és de la transmissió, per això en IoT es dorm el màxim possible (deep sleep).

v = 50 / 3,6 = 13,9 m/s.
Núvol: t = 120 + 30 + 120 = 270 ms; d = 13,9 · 0,270 = 3,8 m.
A bord: d = 13,9 · 0,005 = 0,07 m.
Demostra que les decisions urgents s'han de prendre a prop del sensor (edge computing) i el núvol s'ha de deixar per a tasques que toleren retard.

El primer rep el missatge, perquè «+» coincideix amb «saló». El segon també, perquè «#» agafa tots els temes que comencen per «casa/». El tercer no, perquè és un altre tema (cuina, no saló).
El perquè: en MQTT els emissors i els receptors no es coneixen; el corredor (broker) reenvia cada missatge als subscriptors del tema, i això facilita afegir dispositius.

Amb «i» (AND): (30, sí) encès; (30, no) apagat; (26, sí) apagat; (22, no) apagat. Només s'encén quan es compleixen totes dues condicions.
Amb «o» (OR): (30, sí) encès; (30, no) encès; (26, sí) encès; (22, no) apagat. S'encén si es compleix alguna de les dues.
El perquè: la regla amb «o» gasta energia en una habitació buida, per això en domòtica s'escull el connector lògic amb cura.

1 µs: d = 3,0·$10^{8}$ · 10⁻⁶ = 300 m. 0,1 µs: 30 m.
Els satèl·lits porten rellotges atòmics molt precisos. El rellotge del mòbil no és tan bo, i aquest error es tracta com una incògnita addicional: amb tres satèl·lits resoldríem la posició (x, y, z), però cal un quart per calcular també l'error del rellotge del receptor.
Per això el GPS necessita com a mínim quatre satèl·lits visibles.

Raó = 2¹²⁸ / 2³² = 2⁹⁶ = 7,92·10²⁸.
2¹²⁸ = 3,40·10³⁸; per persona: 3,40·10³⁸ / 8,0·10⁹ = 4,3·10²⁸ adreces.
Amb IPv4 (uns 4.300 milions d'adreces) no n'hi ha per a milers de milions d'objectes connectats. IPv6 permet donar una adreça pròpia a cada sensor, sense haver de compartir-les.

Vibració: 1.000 · 3 · 2 = 6000 B/s; al dia = 6000 · 86.400 = 518,4 MB.
Temperatura: 6 missatges per hora · 24 = 144 al dia; 144 · 20 = 2880 B.
Relació: 180 000 vegades més per al sensor de vibració.
Implica que el sensor de vibració no pot enviar-ho tot al núvol per una xarxa de baixa velocitat: cal processar a prop (edge), calcular resums, o només enviar alertes.

Cal buscar els creuaments ascendents del llindar de 1,2 g: 1,0 → 1,3 (1r pas); 0,9 → 1,0 → 1,4 (2n pas; el 1,6 següent ja és per sobre i no compta); 0,8 → 1,0 → 1,35 (3r pas).
Total: 3 passos. Els valors 1,2 que apareixen després de 1,6 no són un creuament ascendent, perquè ja venien de sobre del llindar.
Falsos positius: sacsejar el mòbil amb la mà, anar en un autobús amb moviment brusc o aplaudir. Els comptadors reals combinen el llindar amb un filtre de freqüència i un temps mínim entre passos.

Qualsevol persona o programa que escanegi Internet pot provar les credencials per defecte i controlar el dispositiu. Molts dispositius infectats així s'han unit en xarxes (botnets) per llançar atacs.
Mesures: 1) canviar la contrasenya per una de llarga i única en instal·lar-lo; 2) mantenir el microprogramari actualitzat; 3) posar els dispositius IoT en una xarxa Wi-Fi separada (de convidats) i desactivar els serveis que no calen.
Error típic: pensar que un endoll no pot ser un risc; pot ser la porta d'entrada a la resta de la xarxa.

Wi-Fi: E = 0,300 W · 3 s = 0,90 J. LoRa: 0,100 W · 1,5 s = 0,15 J.
Bateria: 2,0 · 3,7 · 3.600 = 26 640 J.
Missatges: Wi-Fi 29 600; LoRa 177 600.
Dies: Wi-Fi 29 $\tfrac{600}{96} = 308$ dies; LoRa 177 $\tfrac{600}{96} = 1850$ dies (uns 5,1 anys).
LoRa permet 6 vegades més missatges amb la mateixa bateria. A la pràctica el consum en repòs ho reduiria, però la proporció s'hi manté.

(a) 100 · 2 = 200 Mbps = 25 MB/s; al dia: 25 · 86.400 = 2,16 TB.
(b) Només l'1 %: 21,6 GB al dia, o sigui 100 vegades menys.
Avantatges: menys ample de banda, menys cost d'emmagatzematge i millor privacitat (la majoria de les imatges no surten de la càmera). Inconvenient: les càmeres necessiten més capacitat de càlcul i el seu programa s'ha de mantenir i actualitzar.

99,9 %: 0,001 · 8.760 = 8,76 h (uns 8 h i 46 min). 99,99 %: 0,0001 · 8.760 · 60 = 52,6 min.
En sèrie: 0,999 · 0,999 = 0,998001, o sigui 99,80 %. Aturada = (1 − 0,998001) · 8.760 = 17,5 h.
Cada dependència addicional redueix la disponibilitat. Per això els sistemes crítics tenen redundància i un mode de funcionament local quan es perd la connexió.

Volum per reg: 20 · 5 = 100 L; temps = 100 / 20 = 5 min.
Setmana: 3 reg = 300 L i 15 min de bomba. En 4 setmanes: 1200 L (1,2 m³).
Dades útils: previsió de pluja a hores vista, temperatura i vent (evaporació), tipus de planta i mesures d'humitat a diverses profunditats; també un comptador d'aigua per comprovar el resultat.

10 bits: 2¹⁰ = 1.024 nivells; resolució = 3.300 mV / 1.024 = 3,22 mV, o sigui 0,32 °C.
12 bits: 2¹² = 4.096 nivells; resolució = 3.300 / 4.096 = 0,81 mV, o sigui 0,08 °C.
Per a un termòmetre mèdic, que ha de distingir dècimes de grau, és millor el de 12 bits (o més) i un sensor més precís; per a un termòstat de casa n'hi ha prou amb 10 bits.
Compte: la resolució de l'ADC no és la precisió del sensor, que també depèn del calibratge i del soroll.

Ordre: (b) requisits, (d) prototip, (e) programar, (a) provar, (c) publicar, (f) mantenir.
Probabilitat que cap dels cinc el trobi: $0{,}7^{5}$ = 0,168. Que algú el trobi: 1 − 0,168 = 0,832, és a dir, un 83 %.
Amb 10 usuaris seria 1 − $0{,}7^{10}$ = 0,972. Com més testers, més probable és de trobar errors abans de publicar.
Error típic: considerar que provar és una fase final única; en un desenvolupament àgil es prova en cada versió.

De 2 m a 8 m la distància es multiplica per 4: pèrdua = 20 · log₁₀ 4 = 12 dB, per tant −72 dBm.
A 16 m: 20 · log₁₀ 8 = 18 dB, per tant −78 dBm.
Per arribar a −85 dBm: pèrdua de 25 dB → 20 · log₁₀($\tfrac{d}{2}$) = 25 → $\tfrac{d}{2} = 10$^1,25 = 17,8 → d ≈ 36 m.
A la realitat, parets i mobles atenuen més el senyal i el límit és més curt que a l'espai lliure.

Pot deduir hàbits: l'hora d'aixecar-se (consum nocturn bàsic), que algú ha fet servir un aparell de molta potència, com un torrador o un bullidor (el pic breu de 1.500 W), i que a partir de les 8:15 probablement la casa és buida (consum de 90 W, només aparells en espera).
És un problema perquè aquestes dades permeten saber quan hi ha algú i quan no, i es poden fer servir per robar o per fer perfils comercials.
Es pot reduir limitant la resolució temporal (dades diàries o mensuals per a tercers), exigint consentiment, xifrant les dades i guardant-les només el temps necessari (minimització de dades, RGPD).

Un sensor: 1,5·$10^{6}$ · 8 = 1,2·$10^{7}$ bits; t = 1,2·$\tfrac{10^{7}}{250}$.000 = 48 s.
Tots seguits: 1.000 · 48 = 48 000 s = 13,3 h. Cinquanta alhora: 960 s = 16 min.
L'OTA permet corregir errors i tancar vulnerabilitats sense anar a cada dispositiu. Cal que sigui segura (signatura del fitxer) i amb la possibilitat de tornar enrere si falla.

Emissió total: 25 · 0,004 = 0,10 L/s. Volum: 150 m³ = 150.000 L.
Increment = 0,100 / 150.000 · 10⁶ = 0,67 ppm/s, o sigui 40 ppm/min.
Fins a 1.000 ppm: (1.000 − 420) / 0,67 = 870 s ≈ 14,5 min. Fins a 1.500 ppm: 27,0 min.
Sistema: sensor de CO₂ (entrada), microcontrolador que compara amb el llindar (control), motor de la finestra i panell de llum (actuadors), connexió Wi-Fi al servidor per guardar l'historial, i una aplicació per veure'l.
Per evitar que la finestra s'obri i es tanqui contínuament s'afegeix una histèresi (per exemple, tancar a 800 ppm).