Section: Research Program

State of the Art

System design based on the “synchronous paradigm” has focused the attention of many academic and industrial actors on abstracting non-functional implementation details from system design. This design abstraction focuses on the logic of interaction in reactive programs rather than their timed behaviour, allowing to secure functional correctness while remaining an intuitive programming model for embedded systems.

Maintaining the “synchronous hypothesis” on software at runtime, however, demands a quasi-synchronous model of execution (hardware or middleware) in order to be effectively implemented (A protocol for loosely time-triggered architectures. A. Benveniste et al. Embedded Software Conference. ACM, 2002). Strong software constraints to ensure functional correctness imply strong runtime restrictions and simple hardware. If we look at recent features found in synchronous programming languages such as Quartz (The Averest System http://www.averest.org .), Lucid (Lucid synchrone http://www.di.ens.fr/~pouzet/lucid-synchrone .) departing from the simpler semantics of Esterel (The Esterel synchronous programming language. G. Berry, G. Gonthier. Science of Computer Programming, v. 19(2). Elsevier, 1992.) and Lustre (The synchronous data flow programming language Lustre. Halbwachs, N., Caspi, P., Raymond, P., Pilaud, D. Proceedings of the IEEE v. 79(9), 1991.), we observe that all try to cope in a way or another with the availability of more general execution architectures: clock domains (A formal semantics of clock refinement in imperative synchronous languages. Gemünde, M., Brandt, J., Schneider, K. Application of Concurrency to System Design. IEEE Press, 2010.), pipelining (Parallelism with futures in Lustre. Cohen, A., Gérard, L., Pouzet, M. Embedded Software Conference. ACM, 2012.), streaming (N-synchronous Kahn networks. Cohen, A., et al. Principles of Programming Languages. ACM, 2006.). Unfortunately, attempts to scale the simple "typed programming language" approach of the 90's (A. Benveniste et al. The Synchronous Languages Twelve Years Later. Proceedings of the IEEE v. 91(1), 2003.) to the above purpose hit inherent computational complexity limits. For example, a periodic clock operation like $0^{(1920*(1080-480\left)\right)}{\left\{0^{1200}{1}^{720}\right\}}^{480}$ in Lucy-n ($0^n$ means $n$ zeros) yields an exponentially larger term (http://www.di.ens.fr/~guatto/slides_parkas_14_05_12.pdf , page 15.). This explains why team TEA opts for focusing on the semantics of time and concurrency in system design and on implementing the implied design methodologies using program analysis and abstract interpretation.

By contrast with a synchronous hypothesis, the polychronous MoCC implemented in the specification language Signal, available in the Eclipse project POP (Polychrony on POLARSYS (POP), an Eclipse project in the POLARSYS Industry Working Group, 2013. https://www.POLARSYS.org/projects/POLARSYS.pop ) and in the CCSL standard (Clock Constraints in UML/MARTE CCSL. C. André, F. Mallet. Technical Report RR-6540. Inria, 2008. http://hal.inria.fr/inria-00280941 ), is inherently capable of describing circuits and systems with multiple clocks.

The Eclipse project POP provides a tooled infrastructure to refine high-level specifications into real-time streaming applications or locally synchronous and globally asynchronous systems, through a series of model analysis and synthesis libraries. These tool-supported refinement and transformation techniques can assist the system engineer from the earliest design stages of requirement specification to the latest stages of synthesis, scheduling and deployment. These characteristics make polychrony much closer to the required semantic for compositional, refinement-based, architecture-driven, system design.