Section: Research Program

Modelling Times

To make a sense and eventually formalize the semantcs of time in system design, we should most certainly rely on algebraic representations of time found in previous works and introduce the paradigm of "time systems" (type systems to represent time) in a way reminiscent to CCSL. Just as a type system abstracts data carried along operations in a program, a time system abstracts the causal interaction of that program module or hardware element with its environment, its pre and post conditions, its assumptions and guarantees, either logical or numerical, discrete or continuous. Some fundamental concepts of the time systems we envision are present in the clock calculi found in data-flow synchronous languages like Signal or Lustre, yet bound to a particular model of concurrency, hence time.

In particular, the principle of refinement type systems (Abstract Refinement Types. N. Vazou, P. Rondon, and R. Jhala. European Symposium on Programming. Springer, 2013.), is to associate information (data-types) inferred from programs and models with properties pertaining, for instance, to the algebraic domain on their value, or any algebraic property related to its computation: effect, memory usage (Region-based memory management. Tofte, M., Talpin, J.-P. Information and Computation, 1997.), pre-post condition, value-range, cost, speed, time, temporal logic (LTL types FRP. A. Jeffrey. PLPV'12.).

Being grounded on type and domain theories, a time system should naturally be equipped with program analysis techniques based on type inference (for data-type inference) or abstract interpretation (for program properties inference) to help establish formal relations between heterogeneous component “types”. Just as a time calculus may formally abstract timed concurrent behaviours of system components, timed relations (abstraction and refinement) represent interaction among components.

Scalability and compositionality dictates the use of assume-guarantee reasoning to represent them, and to facilitate composition by behavioural sub-typing, in the spirit of the (static) contract-based formalism proposed by Passerone et al. (A contract-based formalism for the specification of heterogeneous systems. L. Benvenistu, A. Ferrari, L. Mangeruca, E. Mazzi, R. Passerone, C. Sofronis. Forum on design languages, 2008). Verification problems encompassing heterogeneously timed specifications are common and of great variety: checking correctness between abstract and concrete time models relates to desynchronisation (from synchrony to asynchrony) and scheduling analysis (from synchrony to hardware). More generally, they can be perceived from heterogeneous timing viewpoints (e.g. mapping a synchronous-time software on a real-time middleware or hardware).

This perspective demands capabilities not only to inject time models one into the other (by abstract interpretation, using refinement calculi), to compare time abstractions one another (using simulation, refinement, bisimulation, equivalence relations) but also to prove more specific properties (synchronisation, determinism, endochrony).

To check conformance between heterogeneously timed specifications, we will consider variants of the abstract interpretation framework proposed by Bertrane et al. (Temporal Abstract Domains. J. Bertrane. International Conference on Engineering of Complex Computer Systems. IEEE, 2011) to inject properties from one time domain into another, continuous (Abstract Interpretation of the Physical Inputs of Embedded Programs. O. Bouissou, M. Martel. Verification, Model Checking, and Abstract Interpretation. LNCS 4905, Springer, 2008) or discrete (Proving the Properties of Communicating Imperfectly-Clocked Synchronous Systems. J. Bertrane. Static Analysis Symposium. Springer, 2006).

All this formalisation effort will allow to effectively perform the tooled validation of common cross-domain properties (e.g. cost v.s. power v.s. performance v.s. software mapping) and tackle equally common yet though case studies such as these linking battery capacity, to onboard CPU performance, to static software schedulability, to logical software correctness and plant controllability: the choice of the right sampling period across the system components.