SYS-ADR-007 — Sistema de monitoreo, no de control¶
| Estado | Aceptada |
| Decisión | de origen, sostenida desde el anteproyecto |
| Registrada | 2026-09-30 |
| Relacionadas | SYS-ADR-001, SYS-ADR-005 |
Contexto¶
El sistema se conecta a una máquina embolsadora industrial en producción. Un PLC controla esa máquina, y el protocolo que se usa para hablarle —Modbus TCP— permite leer y escribir registros con la misma facilidad. Escribir uno mueve equipamiento físico.
La pregunta, entonces, no era si se podía, sino si el alcance del sistema incluía actuar sobre la máquina o solo observarla.
Decisión¶
Solo observar. El sistema no escribe nunca en el PLC.
No es una convención ni una guía de estilo: no existe un camino de escritura en el código. El lector de Modbus del historian implementa exclusivamente operaciones de lectura, y ninguna otra pieza del sistema habla Modbus.
La consecuencia de alcance es directa: las alarmas que el sistema contempla son avisos a una persona, no disparadores de una acción sobre la máquina. La persona decide y actúa por los medios de siempre.
Alternativas consideradas¶
| Alternativa | Por qué no |
|---|---|
| Control bidireccional, con comandos desde el dashboard | Cambia por completo el perfil de riesgo: una falla de software, o un acceso indebido, pasarían a tener consecuencias físicas. Fuera del alcance del proyecto |
| Escritura acotada a un paro de emergencia remoto | Descartada por la misma razón, agravada: la función de seguridad más crítica de la máquina no debe depender de una cadena que incluye internet, una nube y un dashboard |
| Escritura de parámetros de configuración, sin control de movimiento | Sería el primer paso de una eventual revisión, y merecería su propia ADR |
Consecuencias¶
A favor:
- Ningún fallo del software puede mover la máquina. Es la propiedad de seguridad más fuerte
del sistema, y la que permite aceptar varios riesgos que en un sistema de control serían
inaceptables. La ausencia de autenticación en la lectura del PLC —inherente a Modbus TCP— y
la de
SYS-ADR-005se apoyan las dos en esta decisión. - La superficie de ataque con consecuencia física es nula por construcción, no por configuración. No hay un permiso mal puesto que la habilite.
- El sistema se puede instalar en una máquina en producción sin certificación funcional de seguridad.
En contra:
- El valor del sistema queda limitado a informar. Una condición peligrosa se detecta y se notifica; nadie la corrige automáticamente.
- El objetivo académico referido a alarmas queda a medio camino: la decisión acota qué puede hacer una alarma, y de todos modos el motor que las evalúa no está implementado. Que el alcance sea "solo avisar" no explica que hoy no avise.
Acotar las alarmas no es lo mismo que no tenerlas¶
Son dos cosas distintas y conviene no confundirlas. Esta decisión dice que una alarma notifica y no actúa. Que no exista ningún motor que evalúe reglas es otra: hay tablas de reglas y de notificaciones en la base, y un índice preparado para que un motor lea lo reciente, pero ninguna lógica que las evalúe. Ver visión y alcance.
Evidencia¶
- Ausencia total de camino de escritura Modbus: el lector del historian implementa solo
read_coilsyread_holding_registers. Búsqueda de operaciones de escritura ensrc/historian/modbus_reader.pyysrc/historian/main.py, sin resultados - Ninguna otra pieza habla Modbus: búsqueda en los cinco repositorios
- La superficie inbound del Edge es de solo lectura:
internal/routes/url_mappings.go - Tablas de reglas de alarma y notificaciones sin motor que las evalúe:
migrations/README.mdy búsqueda exhaustiva eninternal/del Cloud - Índice preparado para un futuro motor de alarmas:
internal/repo/mongo/measurements/repository.go