Simulación y verificación de sistemas de control

Explica qué es un simulador de circuitos o de robótica y da dos ventajas de probar en él antes de hacer el montaje real.

Explica la diferencia entre simular un circuito en el computador y montarlo en una protoboard real: qué se gana y qué se pierde con cada método.

Algunos simuladores permiten «acelerar el tiempo». Explica qué ventaja tiene eso para probar el comportamiento de un termostato durante un día completo.

En el simulador tu programa funciona perfectamente, pero en el montaje real el motor no gira. Da tres causas posibles que un simulador no detecta y explica cómo comprobarías cada una en la mesa de trabajo.

En la simulación, el LED parpadea con ritmo perfecto, pero en el montaje real parpadea de forma irregular. Da dos causas eléctricas que el simulador idealiza (tolerancia de las resistencias, contactos flojos de la protoboard) y cómo acotar cada una.

Escribe dos casos de prueba para un programa que hace sonar una alarma cuando se abre una puerta: qué entrada se simula y qué salida se espera en cada caso.

Un programa debe encender un ventilador cuando la temperatura supere los $26\ ^\circ\text{C}$. Define tres casos de prueba (dato de entrada y resultado esperado) para verificarlo, incluyendo el valor límite de $26\ ^\circ\text{C}$, y justifica por qué ese último caso es importante.

Explica qué es un «caso límite» al verificar un programa y por qué son tan importantes. Pon un ejemplo con un programa que decide si una nota es aprobatoria a partir de 5.

Un programa cuenta las personas que entran en una sala (sensor A) y las que salen (sensor B). Diseña tres casos de prueba pensados para cazar errores típicos: dos personas juntas, una que entra y sale seguida y un sensor que dispara dos veces por el rebote del contacto.

Explica qué es una «prueba de estrés» de un sistema de control y propón una para el programa de un parqueadero: qué condiciones extremas simularías y qué comportamiento correcto esperas.

Un equipo verifica su programa solo en el «camino feliz», es decir, cuando todo sale bien. Explica qué son los casos de error y escribe dos para un cajero automático de juguete (tarjeta no válida, saldo insuficiente).

Diseña una tabla de verificación para un semáforo peatonal: estados (rojo, verde, ámbar intermitente), entradas (botón presionado, tiempo transcurrido) y la salida esperada en cada transición entre estados.

Un robot móvil utiliza un sensor de ultrasonido frontal (rango útil: 2,0 cm a 400,0 cm) y debe detenerse y girar si detecta un obstáculo a menos de 20,0 cm. Diseña una matriz de pruebas para verificar el código en el simulador antes de transferirlo al robot real. Tu plan debe contener al menos 4 casos de prueba distintos que incluyan valores frontera y anomalías de lectura. Para cada caso debes indicar: valor numérico simulado de entrada, comportamiento esperado de los motores y justificación técnica de por qué es imprescindible comprobar ese caso concreto.

Un invernadero cuenta con dos zonas de riego independientes (Zona A: semillero delicado; Zona B: cultivo general) gestionadas por un microcontrolador que recibe datos de dos sensores de humedad del suelo, un sensor digital de lluvia y un sensor de caudal en la tubería general. Diseña un plan de verificación para simular el sistema antes de su puesta en marcha. Debes definir 5 casos de prueba exhaustivos que incluyan situaciones de conflicto de prioridades y fallos de suministro. Para cada caso detalla: entradas simuladas exactas, estado previsto de las electroválvulas y de las alarmas, y qué daño material o agronómico previene esa prueba.

El diagrama de flujo de la figura controla una luz automática que depende de un sensor (LDR), pero falta el contenido de un bloque. Indica qué debería hacer ese bloque y describe qué hace el sistema cuando la lectura del sensor es 150 y cuando es 800.

¿Qué es un «fallo» o bug en un programa de control? Pon dos ejemplos sencillos (una condición escrita al revés, un umbral mal puesto) y el efecto que tendría cada uno.

En la simulación de un sistema de riego para una huerta escolar, has programado este bucle de control:

REPETIR SIEMPRE:

humedad = leer_sensor()

SI humedad < 30 % ENTONCES:

activar_electroválvula()

esperar(10 segundos)

desactivar_electroválvula()

FIN REPETIR

Al ejecutarlo en un simulador que modela la absorción física del agua con un retardo de infiltración de 2 minutos, la electroválvula se abre y cierra sin parar durante decenas de ciclos seguidos, encharcando el terreno.

1. a) Justifica por qué el programa genera este comportamiento en la simulación a pesar de incluir una instrucción explícita de desactivación.
2. b) Rediseña el algoritmo (en pseudocódigo o diagrama de flujo) para solucionar el problema sin suprimir la lectura del sensor ni cambiar la electroválvula.

El sensor de luz de una persiana automática registra estos valores en un tramo de 6 minutos durante una tarde con nubes y claros:

• t = 0 min: 780 lx

• t = 1 min: 805 lx

• t = 2 min: 795 lx

• t = 3 min: 812 lx

• t = 4 min: 798 lx

• t = 5 min: 815 lx

• t = 6 min: 820 lx

El sistema tiene programada la regla simple: «Si luz ≥ 800 lx, bajar persiana; si luz < 800 lx, subir persiana».

1. a) Determina cuántas órdenes de movimiento recibe el motor en ese intervalo y justifica qué consecuencias mecánicas y energéticas tiene este funcionamiento.
2. b) Diseña una solución basada en doble umbral (histéresis) definiendo valores numéricos concretos para la orden de bajada y de subida, y demuestra paso a paso cómo responde tu solución frente a la misma serie de datos.

Explica con tus palabras qué significa verificar un programa y en qué se diferencia de «probarlo un poco a ver si funciona».

Un equipo simula un robot seguidor de línea negra: en pantalla el algoritmo reacciona en 0,02 s, los motores responden de forma instantánea y el robot completa el circuito a 1,2 m/s sin ningún fallo. Sin embargo, al cargar el mismo programa en el robot real con los mismos sensores, este oscila bruscamente de lado a lado y acaba perdiendo la línea en la primera curva.

1. a) Identifica y justifica tres factores del mundo físico que el simulador ha omitido o idealizado y que explican esta discrepancia.
2. b) Propón dos modificaciones técnicas (una en los parámetros del software de control y otra en el montaje físico) para compensar esos efectos reales sin sustituir los sensores.

Un equipo programa un robot transportador para una bodega. Al ejecutar el plan de pruebas en el simulador, el robot esquiva el 100 % de los obstáculos y frena ante cualquier persona, pero el algoritmo siempre resuelve las esquivas realizando la maniobra en reversa, recorriendo los pasillos en sentido contrario al flujo de trabajo de la bodega. El profesor afirma: «El software está perfectamente verificado, pero el sistema no está validado».

1. a) Justifica técnicamente la afirmación del profesor aplicando las definiciones operativas de verificación y validación a este caso concreto.
2. b) Reformula el pliego de requisitos técnicos del robot para garantizar que una futura verificación asegure también su correcta validación en el entorno de trabajo.

Explica qué significa depurar un programa y nombra una técnica sencilla para hacerlo en un simulador (ejecutar paso a paso, observar el valor de las variables).

Un robot rastreador se detiene de forma errática tras funcionar correctamente durante unos cinco minutos. Para diagnosticar el fallo, se activa el registro por puerto serial (log) y se extraen estas líneas clave antes de la parada:

• t = 295,0 s | Distancia: 35,0 cm | Temp_driver: 50,0 °C | V_batería: 7,4 V | Estado: AVANZAR

• t = 298,5 s | Distancia: 34,0 cm | Temp_driver: 78,0 °C | V_batería: 7,2 V | Estado: AVANZAR

• t = 300,0 s | Distancia: 35,0 cm | Temp_driver: 92,0 °C | V_batería: 6,1 V | Estado: PARADA_EMERGENCIA

1. a) Interpreta los datos del registro para determinar la causa física del fallo, rebatiendo el informe inicial del equipo que afirmaba que el fallo se debía a un defecto del sensor de ultrasonido.
2. b) Diseña qué variables adicionales o condiciones de alerta temprana deberías incluir en el registro y en el código de control para manejar este problema de forma progresiva sin llegar a la desconexión abrupta.