En general, si algo está mal con un sistema en tiempo real, se producirá un error al producirse un evento de activación. Por ejemplo, Knight Capital tenía un sistema de negociación de acciones que respondía a circunstancias específicas mediante la compra de acciones, cuando el sistema fue retirado sin En pruebas, gastó todo su dinero, provocando fluctuaciones en los precios y la empresa quiebra.
Como resultado, las pruebas de corrección del sistema son realmente importantes, mientras que con un sistema que no es de tiempo real, a menudo hay formas de compensar los problemas (quizás pueda revertir la base de datos y rehacer las transacciones si encuentra un error) ), ese no es siempre el caso de los sistemas en tiempo real, especialmente aquellos con un impacto en el mundo real.
Considere los sistemas que controlan los semáforos o las implementaciones de vuelo por cable en aviones. En estos sistemas, una falla que no se detecte de antemano puede causar lesiones o la muerte y, lo que es peor, puede ser desencadenada por una situación imprevista: ¿puede su sistema fly-by-wire manejar el fallo de los sistemas de satélites GPS? ¿Qué pasa con la aparición repentina de una cantidad de señales GPS erróneas de un agente malicioso?
Esto significa que el desarrollo y las pruebas de sistemas en tiempo real tienden a ser mucho más estrictos que para otros programas. No es infrecuente que se produzcan vastas franjas de datos de casos de seguridad, lo que garantiza que cualquier falla potencial resulte en un estado seguro, que depende del sistema en cuestión: para Knight, habría sido un gasto máximo, por ejemplo. Para Boeing, podría ser que el avión avise a los pilotos humanos sobre un requisito para hacerse cargo. Para una planta de energía nuclear, podría implicar un cierre controlado.