Framework refines timing uncertainty from design to operation
Refining Timing Uncertainty from Logical Time Specification to Operation
Logic in Computer Science
Summary
Timing in real-time systems—like those in cars or robots—can be uncertain and change as design progresses. The authors designed a way to add and update timing details step-by-step without rebuilding the entire system model. They built this on an existing timing language, allowing new timing info, including randomness, to be added progressively. This makes it easier to improve system timing from abstract plans to real-world operation.
What this means in practice
- •For embedded system engineers: Incrementally improve and verify timing models during development of real-time software for vehicles and machinery.
- •For automotive control teams: Integrate measured timing data into system models step-by-step to refine timing guarantees for software-defined vehicles.
Authors
Pavlo Tokariev, Julien Deantoni
Abstract
Real-time and cyber-physical systems are developed through successive refinements from abstract requirements to platform deployments. While timing knowledge evolves throughout this process, existing stochastic real-time formalisms typically require uncertainty to be embedded from the outset or necessitate model reconstruction when new timing information becomes available, hindering iterative timing engineering. This paper presents a refinement-oriented timing specification framework built upon the Clock Constraint Specification Language (CCSL). It supports the progressive introduction of timing knowledge across three levels: logical timing relations, quantitative real-time constraints, and stochastic timing models. Instead of altering behavioural semantics, stochastic information is attached directly to timing quantities as a refinement. This enables implementation measurements and operational observations to be incorporated incrementally within a unified declarative framework. We implement our approach in an OCaml-based simulation tool and evaluate it on a simplified but representative Software-Defined Vehicle use case.