El tiempo de ejecución en el peor de los casos ( WCET ) de una tarea computacional es el tiempo máximo que la tarea podría tardar en ejecutarse en una plataforma de hardware específica.
El tiempo de ejecución en el peor de los casos se usa típicamente en sistemas confiables en tiempo real , donde la comprensión del comportamiento de tiempo del software en el peor de los casos es importante para la confiabilidad o el comportamiento funcional correcto.
Como ejemplo, un sistema informático que controla el comportamiento de un motor en un vehículo puede necesitar responder a las entradas dentro de un período de tiempo específico. Un componente que constituye el tiempo de respuesta es el tiempo dedicado a ejecutar el software; por lo tanto, si se puede determinar el tiempo de ejecución del peor de los casos, el diseñador del sistema puede utilizarlo con otras técnicas, como el análisis de programabilidad, para garantizar que el sistema responda. suficientemente rapido.
Si bien WCET es potencialmente aplicable a muchos sistemas en tiempo real, en la práctica, la garantía de WCET se utiliza principalmente en sistemas en tiempo real que están relacionados con una alta confiabilidad o seguridad. Por ejemplo, en el software aerotransportado, la sección 6.3.4 de DO178C requiere cierta atención al software . El uso cada vez mayor de software en los sistemas automotrices también está impulsando la necesidad de utilizar el análisis de software WCET.
En el diseño de algunos sistemas, WCET se usa a menudo como entrada para el análisis de programabilidad , aunque un uso mucho más común de WCET en sistemas críticos es garantizar que los presupuestos de tiempo preasignados en un sistema programado de partición como ARINC 653 sean no violado.
Ambas técnicas tienen limitaciones. Las mediciones de extremo a extremo imponen una gran carga a las pruebas de software para lograr el camino más largo; Las instrucciones de conteo solo se aplican a software y hardware simples. En ambos casos, a menudo se utiliza un margen de error para tener en cuenta el código no probado, las aproximaciones de rendimiento del hardware o los errores. A menudo se utiliza un margen del 20%, aunque se utiliza muy poca justificación para esta cifra, salvo por la confianza histórica ("funcionó la última vez").