## Section: New Results

### The Zelus Language

Participants : Timothy Bourke, Ismail Lakhim-Bennani, Marc Pouzet.

Zelus is our laboratory to experiment our research on programming languages for hybrid systems. It is devoted to the design and implementation of systems that may mix discrete-time/continuous-time signals and systems between those signals. It is essentially a synchronous language reminiscent of Lustre and Lucid Synchrone but with the ability to define functions that manipulate continuous-time signals defined by Ordinary Differential Equations (ODEs). The language is functional in the sense that a system is a function from signals to signals (not a relation). It provides some features from ML languages like higher-order and parametric polymorphism as well as dedicated static analyses.

This year, we have pursued our work on the design, semantics and implementation of hybrid modeling language, in particular the treatment of Differential Algebraic Equations (DAEs) [23].

#### Compiler Internals: Static Typing and Compiler Organisation

The distribution with manual and examples is distributed at http://zelus.di.ens.fr (only Version 1, in binary form). Version 2 (the current active branch) is available in source form on Inria GitLab https://gitlab.inria.fr/parkas/zelus, on simple demand.

Several new experimentations have been done this year, in particular on the type system and an extensive rewritting of some compilation internals to simplify the code and make the generated code more shorter (in size) and more efficient.

#### Co-simulation as Function Lifting

Hybrid models in Zelus (that is, programs that mix discrete and continuous-time signals) are simulated using a single ODE and zero-crossing solvers only. All hybrid modeling languages (e.g., Simulink, Modelica, Ptolemy) act the same way, at least, single solver simulation is the default mechanism.

Its weaknesses are well known: any change of the dynamic, even local, calls for a global reset of the solver, making it slower for that later steps; the mix of a slow and fast signals slows down the whole simulation. Co-simulation is about running several solvers (or instances of the same) at the same time.

We proposed a limited (but useful) manner, by
proving a way to internalize the solver to obtain, from a
continuous-time function, a synchronous stream function. A
preliminary experiment done this year was surprisingly and
pleasingly simple to implement in Zelus. It consisted in defining a
(higher-order) function *solve* that, given a continuous-time
function *f* returns a stream function *solve f*. Given
an input stream *x* and an increasing stream of time horizons *h*,
*solve f(x, t)* returns the stream of approximated values. This
function internalizes the ODE solver and the zero-crossing
detection mechanism. The overall model is then a purely
discrete-time, synchronous model. In particular, classical
synchronization protocols between solvers can be programmed in the
language itself, hence benefiting from the static checks that track
typing, causality and initialization errors, properties that would
be more difficult to ensure if programmed directly in C, for
example. We think that it is even possible to write a formal
synchronous specification of the simulation engine itself, that is,
to program the function solve directly in Zelus. This experiment on
co-simulation gives new insight on the semantics based on non
standard analysis that we proposed and, more interestingly, to
relate it to the proven and more classical semantics based on
super-dense time studied and exploited by Edward Lee.

#### QSS-based Simulation

Quantized State Systems simulation (QSS) was introduced in the early 2000’s by F. Cellier and E. Kofman as an alternative to time-based simulation, which is the dominant approach to ODE/DAE systems simulation.

Rather than linking QSS to Discrete Event Simulation, we have made a preliminary experiment to relate it to Synchronous Programming and its continuous time extension Zelus. Zelus is used to give a formal description of the QSS method that can be executed. We have described the very basic scheme called QSS (or QSS1) for which we can give a Zelus (hence executable) specification. Higher order schemes QSS2, 3, etc. can also be given an Zelus specification. Implicit schemes were also proposed by Kofman for a better handling of stiff systems. Higher order versions of BQSS are nontrivial; they are called LIQSS1, 2, 3, etc. and they can also be specified in Zelus. This preliminary work is done in collaboration with Albert Benveniste (Inria Hycomes, Rennes) and funded by the Modeliscale FUI project.

#### Property Based Testing of Hybrid Programs

Property-based program testing involves checking an executable specification by running many tests. We build on the work of Georgios Fainekos and Alexandre Donzé, and take inspiration from earlier work by Nicolas Halbwachs, to write a Zélus library of synchronous observers with a quantitative semantics that can be used to specify properties of a system under test. We implemented several optimization algorithms for producing test cases, some of which are gradient-based. To compute the gradients, we use Automatic Differentiation (AD) of the system under test and its specification. Together with François Bidet, we ported the well-known FADBAD++ library for AD written by Ole Stauning in 1997 to OCaml—the target language of Zélus. Our port is called FADBADml and is now released under an Inria license (https://fadbadml-dev.github.io/FADBADml/) and is available on opam.