Tema 18 · Bloque F · Sistemas automáticos

Tema 18. Automatización programada de procesos, supervisión y telemetría

Cómo se automatiza un proceso con una placa programable y cómo se vigila y se registra su funcionamiento a distancia.

Este es el tema donde el KR-1 se convierte de verdad en un sistema automático. El Tema 17 dio el vocabulario y la ley de control; aquí se escribe el programa completo, con una estructura —la máquina de estados— que permite algo que un montón de if no permite: demostrar que el sistema no puede hacer lo que no debe. Y se le añade lo que el currículo llama supervisión y telemetría: la capacidad de vigilarlo y registrarlo desde lejos.

Antes de empezar: «he probado el programa y funciona» no es una demostración. Funciona con las condiciones que has probado. Un automatismo que va a estar tres semanas solo necesita algo más fuerte: una estructura en la que los estados posibles estén enumerados y las transiciones prohibidas, simplemente, no existan.
Al terminar serás capaz de…
  • pasar de un requisito de proceso a la especificación de un automatismo;
  • clasificar las señales de un sistema en entradas y salidas, digitales y analógicas;
  • explicar qué es una máquina de estados y por qué estructura mejor que una cadena de condicionales;
  • escribir un automatismo con estados, transiciones y temporizaciones en MicroPython;
  • identificar los enclavamientos de seguridad de un proceso y programarlos;
  • explicar qué es un SCADA, sus cuatro componentes y sus ventajas;
  • distinguir telemetría de monitorización y diseñar la cadencia de envío de datos;
  • definir alarmas útiles y un registro que permita reconstruir lo ocurrido;
  • verificar un sistema automatizado y documentarlo para que otro equipo lo mantenga.

1. Del requisito al automatismo

Automatizar un proceso es conseguir que se ejecute sin intervención humana. El criterio 5.1 pide diseñar, programar, construir y simular o montar ese proceso, y el trabajo empieza por escribir con precisión lo que tiene que ocurrir.

Especificación del automatismo del KR-1
TipoRequisito
FuncionalMedir la humedad del sustrato cada 15 min y regar 30 s si está por debajo del umbral.
FuncionalRegar solo entre las 7:00 y las 10:00, para reducir la evaporación.
FuncionalPublicar el estado cada 15 min y ante cada suceso relevante.
De seguridadNunca mantener la válvula abierta más de 60 s seguidos, por ninguna causa.
De seguridadNo más de 4 riegos al día.
De seguridadSi una lectura es imposible, no regar y pasar a fallo.
De seguridadSi tras regar la humedad no sube en dos ciclos, pasar a fallo: fuga o depósito vacío.
De disponibilidadFuncionar sin red: se riega igual y se registra en local.
De disponibilidadTras un corte de alimentación, arrancar con la válvula cerrada.
Los requisitos de seguridad se escriben aparte, y no se negocianFíjate en la diferencia de redacción: los funcionales dicen qué hace el sistema; los de seguridad dicen qué no puede hacer nunca, y llevan las palabras «nunca», «por ninguna causa» y «no más de». Se escriben aparte porque su tratamiento es distinto: un requisito funcional se puede renegociar si falta tiempo; uno de seguridad, no. Y porque cada uno de ellos se convertirá en una comprobación explícita del programa, no en una confianza.
Y hay un requisito que casi siempre se olvida: qué hace el sistema al arrancar. Tras un corte de luz, la placa se reinicia y no sabe nada de lo anterior. Si el programa no fija explícitamente el estado inicial, el comportamiento depende de cómo quede el hardware, lo que en el caso de una electroválvula significa un huerto inundado. De ahí la elección de válvula normalmente cerrada del Tema 8: la seguridad empieza en el mecanismo, y el programa la confirma.

2. Entradas y salidas, digitales y analógicas

Un automatismo se comunica con el proceso por sus señales. Clasificarlas es el primer paso del diseño, y se hace en una tabla que después sirve de índice del cableado y del programa.

Tabla de entradas y salidas del KR-1
SeñalTipoPinMargenElemento
Humedad del sustratoEntrada analógicaGPIO 340–4095 cuentasSonda capacitiva
Nivel del depósitoEntrada digitalGPIO 180 = vacíoInterruptor de flotador
Pulsador de riego manualEntrada digitalGPIO 190 = pulsadoPulsador con pull-up
ElectroválvulaSalida digitalGPIO 261 = abiertaMOSFET del Tema 11
Indicador de estadoSalida digitalGPIO 231 = encendidoLED con su resistencia
La tabla de entradas y salidas es el contrato entre el hardware y el programaEs el documento que evita el error más frecuente de un montaje: que el esquema diga GPIO 26 y el programa use el 25. Se escribe antes de programar, se pega junto a la placa y forma parte de la documentación del Tema 4. Y cuando un pin cambia, se cambia en la tabla y en el bloque de constantes del programa, en ese orden. En un automatismo industrial esta tabla se llama lista de señales y puede tener miles de filas; la lógica es idéntica.
Una entrada digital más de lo previsto. El nivel del depósito no estaba en el proyecto inicial y aparece aquí: es el requisito de seguridad «si tras regar la humedad no sube, pasar a fallo» resuelto por la vía directa. Detectar la causa —depósito vacío— es mejor que inferirla de un síntoma, y cuesta un interruptor de flotador de tres euros. A veces el problema de programación más difícil se resuelve añadiendo un sensor.

3. Máquinas de estados

Un automatismo no es una función matemática: su respuesta no depende solo de lo que mide ahora, sino de lo que estaba haciendo. Ya lo vimos en la histéresis del Tema 17, cuya decisión dependía de si la válvula estaba abierta. Esa memoria, organizada, es una máquina de estados.

Cinco estados: reposo, midiendo, regando, espera y fallo. Desde reposo se pasa a midiendo cada quince minutos; de midiendo a regando si está seco y en horario, o a espera si está húmedo; de regando a espera al cumplirse los treinta segundos; de espera a reposo al terminar el ciclo. Dos transiciones llevan al fallo: lectura imposible y tiempo máximo excedido. Del fallo no se sale sin intervención.
Todo lo que el KR-1 puede hacer está en este dibujo. Lo que no está dibujado no puede ocurrir, y eso es lo que convierte el automatismo en algo demostrable.
Los cuatro conceptos
ConceptoQué esEn el KR-1
EstadoSituación en la que el sistema puede encontrarse. Solo puede estar en uno a la vez.REPOSO, MIDIENDO, REGANDO, ESPERA, FALLO.
TransiciónCambio de un estado a otro.De MIDIENDO a REGANDO.
Condición de transiciónLo que tiene que cumplirse para que el cambio ocurra.Sustrato seco y hora entre 7 y 10.
AcciónLo que se hace al entrar en un estado o mientras se está en él.Al entrar en REGANDO: abrir la válvula y anotar la hora.
Por qué una máquina de estados y no veinte ifCon condicionales sueltos, el comportamiento del sistema está repartido por todo el programa y nadie puede afirmar qué combinaciones son posibles. Con una máquina de estados, los estados están enumerados y las transiciones dibujadas, de modo que se pueden responder por escrito tres preguntas que un tribunal —o una inspección industrial— hará: ¿en qué estados puede estar el sistema? ¿Cómo se llega a cada uno? ¿Se puede llegar a un estado peligroso? Eso es demostrable; «lo he probado y funciona», no.
Es la misma idea del árbol de levas del Tema 8. Una máquina automática antigua se programaba tallando levas: el perfil imponía la secuencia, ciclo tras ciclo, y ninguna otra secuencia era mecánicamente posible. Una máquina de estados hace lo mismo con software: enumera la secuencia y hace imposible lo demás. La diferencia es que la leva hay que llevarla al torno y el programa se cambia en un minuto.

4. El automatismo del KR-1, escrito

La máquina de estados se implementa con una variable que guarda el estado y una estructura que, en cada vuelta del bucle principal, decide si hay transición. Es el patrón estándar y cabe en una página.

"""Automatismo del KR-1. Máquina de estados de cinco estados.
Requisitos de seguridad implementados: tiempo máximo de válvula,
número máximo de riegos diarios, lectura plausible y fallo persistente.
"""
from machine import Pin, ADC
import time

# --- Tabla de entradas y salidas (Tema 18, sección 2) ---
sonda = ADC(Pin(34)); sonda.atten(ADC.ATTN_11DB)
deposito = Pin(18, Pin.IN, Pin.PULL_UP)
valvula = Pin(26, Pin.OUT)
led = Pin(23, Pin.OUT)

# --- Constantes de configuración ---
UMBRAL_PCT = 30
DURACION_RIEGO_S = 30
TIEMPO_MAX_VALVULA_S = 60     # requisito de seguridad
RIEGOS_MAX_DIA = 4            # requisito de seguridad
PERIODO_CICLO_S = 900
HORA_INICIO, HORA_FIN = 7, 10
CUENTAS_MIN, CUENTAS_MAX = 200, 4000   # fuera de esto, lectura imposible

# --- Estado ---
estado = "REPOSO"
t_estado = time.time()        # instante de entrada en el estado
riegos_hoy = 0

def cerrar_valvula():
    valvula.value(0)

def entrar(nuevo):
    """Cambia de estado, cierra la válvula por defecto y anota el instante."""
    global estado, t_estado
    cerrar_valvula()
    estado = nuevo
    t_estado = time.time()
    registrar_evento(nuevo)

def en_estado_s():
    return time.time() - t_estado
La función entrar() es la clave de todoCierra la válvula en cada cambio de estado, sea cual sea. Eso significa que la válvula solo puede estar abierta si algo la abre activamente dentro del estado REGANDO: cualquier transición, prevista o no, la cierra. Es una decisión de diseño que convierte un requisito de seguridad en una propiedad estructural del programa, en lugar de en una comprobación que alguien podría olvidar. Lo seguro tiene que ser lo que ocurre por omisión.
# --- Bucle principal: una vuelta, una decisión ---
entrar("REPOSO")

while True:
    lectura = leer_cuentas()
    plausible = CUENTAS_MIN <= lectura <= CUENTAS_MAX
    humedad = cuentas_a_porcentaje(lectura) if plausible else None
    hora = hora_actual()

    if estado == "REPOSO":
        led.value(0)
        if en_estado_s() >= PERIODO_CICLO_S:
            entrar("MIDIENDO")

    elif estado == "MIDIENDO":
        if not plausible:
            entrar("FALLO")
        elif deposito.value() == 0:
            entrar("FALLO")
        elif (humedad < UMBRAL_PCT
              and HORA_INICIO <= hora < HORA_FIN
              and riegos_hoy < RIEGOS_MAX_DIA):
            entrar("REGANDO")
            valvula.value(1)
            riegos_hoy += 1
        else:
            entrar("ESPERA")

    elif estado == "REGANDO":
        led.value(1)
        if en_estado_s() >= TIEMPO_MAX_VALVULA_S:
            entrar("FALLO")                    # seguridad: manda siempre
        elif en_estado_s() >= DURACION_RIEGO_S:
            entrar("ESPERA")
        elif not plausible or deposito.value() == 0:
            entrar("FALLO")

    elif estado == "ESPERA":
        if en_estado_s() >= 5:
            entrar("REPOSO")

    elif estado == "FALLO":
        cerrar_valvula()
        led.value(1 if int(time.time()) % 2 else 0)   # parpadeo de aviso
        publicar_alarma()

    publicar_estado(estado, humedad, valvula.value())
    time.sleep(1)
Fíjate en el orden de las comprobaciones dentro de REGANDO. El tiempo máximo de seguridad se comprueba antes que la duración normal de riego. No es indiferente: si estuviera después y alguien cambiara la duración normal a 90 s por error, el límite de 60 s no llegaría a evaluarse nunca. En un automatismo, las comprobaciones de seguridad van primero, para que ninguna modificación posterior las pueda dejar inalcanzables.
Un bucle de control no debe bloquearse nuncaObserva que no hay ningún time.sleep(30) para esperar el riego: se comprueba el tiempo transcurrido en cada vuelta. La diferencia es esencial. Con una espera bloqueante de 30 s, el programa estaría treinta segundos ciego: no vería vaciarse el depósito, no atendería una orden remota y no podría cerrar la válvula. Con el bucle de un segundo, cada vuelta reevalúa todo. Se mide el tiempo, no se duerme.

5. Enclavamientos y condiciones de seguridad

Un enclavamiento es una condición que impide una acción mientras no se cumpla algo, independientemente de lo que pida la lógica normal. Son las barreras del automatismo, y se diseñan enumerando qué puede ir mal.

Qué puede ir mal y qué lo impide
FalloConsecuencia sin protecciónEnclavamientoDónde vive
Sonda desconectadaLee «seco» y riega sin parar.Lectura plausible obligatoria antes de decidir.Programa
Programa colgado con válvula abiertaHuerto inundado.Válvula normalmente cerrada, más watchdog.Mecanismo y hardware
Corte de alimentación durante el riegoLa válvula quedaría abierta.Válvula normalmente cerrada: cierra por muelle.Mecanismo (Tema 8)
Depósito vacíoLa bomba trabaja en seco y se destruye.Interruptor de flotador: sin agua no se riega.Sensor y programa
Orden remota errónea o maliciosaRiego indefinido.El límite de tiempo y el de riegos diarios no se pueden anular por red.Programa (Tema 16)
Fuga en la líneaSe gasta el depósito sin humedecer nada.Si tras regar la humedad no sube en dos ciclos, fallo.Programa
Rebote del pulsador manualRiegos múltiples con una pulsación.Antirrebote del Tema 14 y límite diario.Programa
La seguridad se reparte en tres capas, y ninguna basta sola1. Mecánica: la válvula normalmente cerrada actúa aunque no haya electricidad ni programa. 2. Hardware: el watchdog reinicia la placa si el programa deja de responder; el fusible limita el daño de un cortocircuito. 3. Programa: los límites de tiempo, los de cantidad y la comprobación de plausibilidad. La capa mecánica es la más fiable porque no depende de nada, y la de programa la más flexible. Un requisito de seguridad importante se implementa en más de una capa.
El watchdog: el vigilante del programa. Es un temporizador del propio microcontrolador que reinicia la placa si el programa no lo «tranquiliza» periódicamente. Si el bucle principal se cuelga —un bucle infinito por error, una espera que no termina— el watchdog salta y reinicia, y como el arranque deja la válvula cerrada, el sistema queda seguro. En MicroPython son dos líneas, y para un automatismo que va a estar solo tres semanas son las dos líneas más rentables del programa.

6. Sistemas de supervisión SCADA

SCADA son las siglas de Supervisory Control And Data Acquisition: supervisión, control y adquisición de datos. Es el conjunto de software y equipos que permite a una persona vigilar y gobernar un proceso automatizado desde un puesto de control, sin estar junto a la máquina.

Los cuatro componentes de un SCADA
ComponenteFunciónEn el KR-1
AdquisiciónTomar las medidas y los estados del proceso.El ESP32 leyendo la sonda y el flotador.
ComunicaciónLlevar esos datos al puesto de supervisión y las órdenes de vuelta.Wi-Fi y MQTT del Tema 16.
Base de datos históricaGuardar la evolución para poder consultarla después.El archivo CSV del Tema 15 y la base del servidor.
Interfaz de operadorMostrar el estado, las gráficas y las alarmas, y permitir mandar.El panel web y el móvil.

Las ventajas que el currículo pide enumerar

Visión de conjunto

Una sola pantalla muestra el estado de decenas de equipos repartidos. Nadie tiene que recorrer la instalación para saber si algo va mal.

Reacción rápida

Las alarmas llegan al instante y el operador puede actuar sin desplazarse, lo que reduce el tiempo de parada.

Histórico y trazabilidad

Se puede reconstruir qué pasó y cuándo: el Tema 2 aplicado al funcionamiento, no solo a la fabricación.

Optimización

Con los datos de meses se detectan consumos anómalos y se ajusta el proceso. Sin datos, solo hay opiniones.

Supervisión no es controlLa distinción es la razón de ser del SCADA y se olvida constantemente. El control —el lazo cerrado del Tema 17— ocurre en el propio equipo, en milisegundos o segundos, y debe seguir funcionando sin el SCADA. La supervisión ocurre en el puesto de operador, en segundos o minutos, y sirve para vigilar, ajustar consignas y atender alarmas. Un sistema en el que el lazo de control se cierra a través de la red es un sistema frágil: si se corta la red, se para el proceso. Es exactamente la razón por la que el KR-1 riega sin internet.
Y a esta escala, un SCADA es un panel web. Un SCADA industrial gobierna una planta entera con miles de señales, redundancia y registro auditable. El del KR-1 es un panel con tres números, una gráfica y un botón, y tiene exactamente los cuatro componentes de la tabla. Lo que se aprende no es el producto, es la arquitectura: adquirir, comunicar, guardar y presentar. Con esa arquitectura entendida, cualquier SCADA comercial resulta reconocible.

7. Telemetría y monitorización

Telemetría

La transmisión de medidas a distancia. Es un problema de comunicación: qué se envía, en qué formato, cada cuánto y con qué fiabilidad. Es el Tema 16.

Monitorización

La vigilancia continua del proceso a partir de esos datos: representarlos, compararlos con límites y avisar. Es un problema de interpretación.

Diseñar la cadencia es diseñar el sistemaLa pregunta «¿cada cuánto envío datos?» parece menor y decide el consumo, el coste y la utilidad. Enviar cada segundo gasta batería y produce ocho millones de puntos al verano que nadie mirará. Enviar cada hora deja ciegos los riegos, que duran treinta segundos. La solución es cadencia fija más eventos: un dato cada quince minutos para la gráfica, y un mensaje inmediato cada vez que ocurre algo —empieza a regar, termina, entra en fallo—. Con eso, el histórico es manejable y ningún suceso relevante se pierde.
Las variables que se monitorizan y por qué
VariableCadenciaPara qué sirve
Humedad del sustrato15 minLa variable controlada: es el objeto del sistema.
Estado de la máquinaCada cambioSaber qué está haciendo y reconstruir la secuencia.
Riegos acumulados hoyCada riegoComprobar el límite diario y estimar el agua usada.
Nivel del depósitoCada cambioAvisar antes de que se agote.
Tensión de la batería1 hPredecir un fallo de alimentación antes de que ocurra.
Señal Wi-Fi y reconexiones1 hDiagnosticar problemas de cobertura sin ir al huerto.
Las dos últimas variables no son del proceso: son del propio sistema. La tensión de la batería y el número de reconexiones no le importan a la planta, y son las que permiten mantenimiento predictivo: ver que la batería baja cada día un poco más y cambiarla antes de que falle, en lugar de descubrirlo cuando el huerto ya se ha secado. Monitorizar el estado del propio sistema, y no solo el del proceso, es una de las diferencias entre un montaje escolar y una instalación seria.

8. Alarmas y registro

Una alarma es un aviso de que algo requiere atención. Diseñarlas mal tiene una consecuencia muy conocida en la industria: si hay demasiadas, se ignoran todas.

Alarmas del KR-1, con su prioridad
PrioridadAlarmaQué exige
CríticaEstado de FALLO: lectura imposible o tiempo de válvula excedido.Ir al huerto. El riego está detenido.
AltaDepósito vacío.Rellenar en las próximas horas.
AltaSin mensajes del nodo en 45 min.Comprobar alimentación o cobertura.
MediaBatería por debajo del 20 %.Revisar el panel solar esta semana.
BajaLímite de riegos diarios alcanzado.Informativa: revisar el umbral o el clima.
La inundación de alarmasEs un problema documentado en accidentes industriales graves: un sistema que genera cientos de avisos al día entrena a los operadores para ignorarlos, y cuando llega el importante nadie lo atiende. Las reglas para evitarlo son tres: una alarma solo si alguien tiene que hacer algo; prioridad explícita, porque «todo es urgente» equivale a «nada lo es»; y ninguna alarma repetida mientras la causa persista. Si la sonda está desconectada, se avisa una vez, no cada segundo.
La alarma más útil es la ausencia de mensajesUn sistema averiado no siempre puede avisar: si se queda sin batería, sin red o con el programa colgado, se calla. Por eso la vigilancia no puede consistir solo en esperar avisos: el panel tiene que detectar que el nodo ha dejado de hablar. MQTT ofrece el mensaje de última voluntad, que el broker publica automáticamente cuando un cliente desaparece. Vigilar el silencio es más fiable que confiar en el aviso.

El registro de sucesos

# Cada cambio de estado y cada alarma, al registro local y a la red
def registrar_evento(nuevo_estado):
    linea = f"{marca_de_tiempo()};{nuevo_estado};{riegos_hoy}\n"
    with open("eventos.csv", "a") as f:
        f.write(linea)
    if hay_red():
        publicar_evento(nuevo_estado)
El registro tiene que servir para reconstruir, no solo para constatar. «Falló» no es información. «A las 8:15 pasó de MIDIENDO a REGANDO; a las 8:16, de REGANDO a FALLO por tiempo excedido, con 2 riegos ese día y una lectura de 4095 cuentas» permite deducir qué ocurrió sin haber estado allí. Es el mismo criterio del registro de cambios del Tema 1 y de la trazabilidad del Tema 2: se registra el suceso con su contexto, porque quien lo lea en septiembre no recordará nada.

9. Verificar y documentar el automatismo

Verificar un automatismo no es comprobar que riega. Es comprobar, uno a uno, que cada requisito —y sobre todo cada requisito de seguridad— se cumple. Y eso exige provocar los fallos a propósito.

Plan de pruebas: cómo se provoca cada fallo
RequisitoCómo se pruebaResultado esperado
Riega si está seco y en horarioSonda al aire con la hora simulada a las 8:00.Pasa a REGANDO 30 s y vuelve a ESPERA.
No riega fuera de horarioLo mismo con la hora a las 15:00.Pasa a ESPERA sin abrir la válvula.
Tiempo máximo de válvulaForzar DURACION_RIEGO_S = 120.A los 60 s pasa a FALLO y cierra.
Lectura imposibleDesconectar la sonda en marcha.Pasa a FALLO sin regar.
Depósito vacíoAbrir el interruptor de flotador.No riega; alarma de depósito.
Límite de riegos diariosForzar riegos_hoy = 4.No riega aunque esté seco.
Corte de alimentaciónDesenchufar durante el riego.La válvula cierra; al volver, arranca en REPOSO.
Pérdida de redApagar el router.Sigue riegando y registrando en local.
Programa colgadoIntroducir un bucle infinito a propósito.El watchdog reinicia y la válvula queda cerrada.
Un requisito de seguridad no verificado no existeEstá escrito en la especificación, está implementado en el código y nadie ha comprobado que actúe. La experiencia dice que una parte de esas protecciones no funciona: un signo invertido, una comparación que nunca se alcanza, un límite en la unidad equivocada. La única forma de saberlo es provocar el fallo, y hay que hacerlo en el aula, con el depósito sobre un cubo, no en el huerto en agosto. Es el mismo principio del Tema 9: medir para encontrar lo que no sabías.
Qué documentar del automatismo. Cinco cosas, todas del Tema 4: la tabla de entradas y salidas; el diagrama de estados; la lista de requisitos de seguridad con su prueba y su resultado; las constantes de configuración con su significado y su valor; y un procedimiento de puesta en marcha y de parada que pueda seguir alguien que no programó el sistema. Sin ese último documento, el KR-1 solo lo puede mantener quien lo hizo, y eso es un defecto de diseño, no una virtud.

Comprueba lo que has aprendido

Este tema se demuestra con un automatismo que sobrevive a los fallos que le provoques y con un panel que te permita verlo desde casa.

Qué debería mostrar tu trabajo
AspectoQué debes demostrarEvidencias posibles
EspecificarQue separas los requisitos funcionales de los de seguridad.Tabla de requisitos con las dos categorías y el comportamiento al arrancar definido.
SeñalesQue la tabla de entradas y salidas coincide con el esquema y con el programa.Tabla pegada junto a la placa y bloque de constantes que la reproduce.
Máquina de estadosQue el automatismo está estructurado en estados y transiciones dibujadas.Diagrama de estados y el código con un solo punto de cambio de estado.
SeguridadQue los enclavamientos están en más de una capa y se comprueban primero.Tabla de fallos y enclavamientos, válvula normalmente cerrada y watchdog activo.
SupervisiónQue tienes los cuatro componentes de un SCADA y que el control funciona sin la red.Panel con estado, gráfica y alarmas; prueba con el router apagado.
VerificaciónQue has provocado cada fallo y anotado el resultado.Plan de pruebas cumplimentado con las nueve filas y el registro de sucesos de cada ensayo.

Prueba que lo demuestra todo: dale el sistema a otro equipo con la especificación y el procedimiento de puesta en marcha, y que intenten romperlo. Cada fallo que encuentren y tu programa no contemple es un requisito de seguridad que faltaba.

Glosario del tema

Alarma
Aviso de que una situación requiere la atención de una persona.
Automatizar
Conseguir que un proceso se ejecute sin intervención humana.
Cadencia
Intervalo con el que se toman o se envían las medidas.
Enclavamiento
Condición que impide una acción mientras no se cumpla un requisito, al margen de la lógica normal.
Estado
Situación en la que puede encontrarse un automatismo; solo una a la vez.
Inundación de alarmas
Situación en la que el exceso de avisos hace que se ignoren todos.
Lista de señales
Tabla que relaciona cada entrada y salida con su tipo, su pin y su elemento físico.
Mantenimiento predictivo
Intervención anticipada basada en la evolución de variables del propio sistema.
Máquina de estados
Modelo de automatismo formado por estados, transiciones, condiciones y acciones.
Mensaje de última voluntad
Aviso que el broker publica automáticamente cuando un cliente desaparece de la red.
Monitorización
Vigilancia continua de un proceso a partir de los datos recibidos.
SCADA
Sistema de supervisión, control y adquisición de datos de un proceso automatizado.
Telemetría
Transmisión de medidas a distancia.
Transición
Cambio de un estado a otro, sujeto a una condición.
Watchdog
Temporizador del microcontrolador que reinicia la placa si el programa deja de responder.

Resumen esencial

  1. Los requisitos de seguridad se escriben aparte de los funcionales, con las palabras «nunca» y «no más de», y no se renegocian.
  2. Todo automatismo necesita un requisito sobre qué hace al arrancar, porque tras un corte de luz no recuerda nada.
  3. La tabla de entradas y salidas es el contrato entre el hardware y el programa, y se escribe antes de programar.
  4. A veces el problema de programación más difícil se resuelve añadiendo un sensor.
  5. Un automatismo tiene memoria: su respuesta depende del estado en que se encuentra, no solo de lo que mide.
  6. Una máquina de estados enumera los estados y dibuja las transiciones, de modo que lo no dibujado no puede ocurrir: eso es demostrable.
  7. Si el cambio de estado cierra la válvula por omisión, la seguridad deja de ser una comprobación y pasa a ser una propiedad estructural.
  8. Las comprobaciones de seguridad se evalúan antes que la lógica normal, para que ninguna modificación posterior las deje inalcanzables.
  9. Un bucle de control mide el tiempo transcurrido; no se duerme, porque dormido está ciego.
  10. La seguridad se reparte en tres capas —mecánica, hardware y programa— y un requisito importante se implementa en más de una.
  11. Un SCADA tiene cuatro componentes: adquisición, comunicación, base de datos histórica e interfaz de operador.
  12. Supervisión no es control: el lazo de control vive en el equipo y debe funcionar sin el SCADA.
  13. La cadencia se diseña: un dato fijo cada cierto tiempo para la gráfica y un mensaje inmediato ante cada suceso.
  14. Monitorizar el propio sistema —batería, reconexiones— es lo que permite el mantenimiento predictivo.
  15. Una alarma solo existe si alguien tiene que hacer algo; sin prioridades y sin evitar repeticiones, se ignoran todas.
  16. La alarma más fiable es detectar que el nodo ha dejado de hablar, porque un sistema averiado no siempre puede avisar.
  17. Un requisito de seguridad que no se ha verificado provocando el fallo, no existe.

Fuentes y recursos fiables