‹ Cultura 3.14 · Qué nos preguntamos
Pregunta · Inteligencia Física
¿Qué enseña la robótica sobre los fallos silenciosos del software?
La robótica lleva décadas asumiendo que un componente puede funcionar y aun así producir un resultado ausente; el software de gestión aún lo descubre caso a caso.
Por qué importa
Escribimos software que actúa sobre ERPs, procesos y, últimamente, máquinas. En los tres casos aparece el mismo fallo: la ejecución fue correcta y el efecto no ocurrió. Un sistema no falla solo cuando un componente se rompe; también falla cuando cada componente cumple su contrato y el conjunto produce un resultado que nadie quería.
La robótica lleva décadas dando eso por supuesto y diseñando en consecuencia. Leveson lo formula como un problema de control y de restricciones ausentes; Thrun, Burgard y Fox parten de que el estado del mundo se estima y nunca se lee. En el software de gestión seguimos descubriéndolo proyecto a proyecto.
Qué sabemos hasta ahora
Hemos dejado de tratar el registro de una acción como prueba de su efecto. Distinguimos ejecutado, confirmado y observado, y cuando no existe señal independiente lo declaramos como límite en lugar de dar la acción por comprobada.
La transferencia desde la robótica tiene una condición. Un robot opera en un entorno que puede instrumentar con sensores propios; un proceso sobre un ERP depende de sistemas de terceros que no siempre ofrecen una señal de verificación. Copiar el método sin esa posibilidad produce una falsa sensación de rigor.
Qué continúa abierto
Queda abierto qué parte del método robótico —estimación de estado, restricciones explícitas, verificación independiente— puede sostenerse cuando la señal debe crearse a propósito y cuesta más que la propia acción.
Y hasta dónde llega la analogía en procesos que atraviesan varias aplicaciones, donde el estado del mundo es la suma de registros que ninguna parte del sistema observa entera.