CoCoSim, a code generation framework for control/command applications An overview of CoCoSim for multi-periodic discrete Simulink models Hamza Bourbouh, Pierre-Loïc Garoche, Thomas Loquen Eric Noulard, Claire Pagetti Abstract [8] or Signal [38] have been defined to help their de- sign. Scade [12] is an industrial and DO 178C qual- We present CoCoSim, a framework to support ified Lustre-based framework that provides strong the design, code generation and analysis of dis- guarantees and proofs well appreciated, in particu- crete dataflow model expressed in Simulink. In lar for certification. this work, we specifically focus on the analysis and Offering frameworks linking Simulink and syn- code generation of multi-periodic systems. For chronous approaches is thus appealing. CoCoSim that CoCoSim provides two complementary ap- belongs to this category as it is an open source tool proaches: the first amounts to encode the multi- that translates Simulink specification in Lustre periodic semantics in a pure-synchronous one – à while preserving semantics and providing many as- la Lustre–, enabling the use of model checker for sociated traceability or test capabilities. In this pa- verifying properties. The second provides a faith- per, we describe an extension of CoCoSim to al- ful code generation into multiple communicating low the safe translation and verification from multi- (mono)synchronous components – à la Prelude– periodic systems to Lustre/Prelude programs. that can be then simulated or embedded in the fi- nal platform with any real-time scheduler. These 1.2 Contributions approaches have been experimented in various set- tings. The CoCoSim approach to deal with multi- periodic systems is highlighted in the Fig. 1. 1 Introduction Multi-periodic system in 1.1 Context Simulink Safety-critical systems design requires a thorough ok/ko development process including formal verification Lustre Lustre/Prelude and correct by construction behaviour. In that translation translation area, Model-Based Design has been widely used for software development. Such an approach of- fers the refinement of a system from High Level Re- quirements down to the embedded code while hav- verification C code ing an executable model at different stages. Mat- + execution model lab/Simulink1 from MathWorks, is a de facto model-based design standard in industry, offering Figure 1: overview verification and code generation means. CoCoSim Nonetheless, other development frameworks are used in addition in some industries, such as aero- First, we need to define precisely the semantics nautic, railways or space. Indeed, control/com- of multi-periodic systems in Simulink and con- mand applications have received a particular atten- nect it to the one of synchronous programming. In tion over the years and several synchronous pro- synchronous languages, execution time is neglected gramming languages such as Esterel [2], Lustre while each computation is performed repetitively, e.g., every ts seconds. In Simulink, most discrete 1https://www.mathworks.com/products/simulink.html subsets of blocks are fitted with a synchronous se- 1 mantics, but the case of multi-periodic systems is more complex and requires an analysis of the inter- nal semantics. Once the semantics has been defined, the sec- ond contribution is the extension of CoCoSim cur- rent Lustre translation in order to encode the multi-periodic communication with classical Lus- tre over- and sub-sample operators (left hand side of Fig. 1). This amounts to express the whole sys- tem on a base clock. This Lustre model is then used to perform formal analysis using SMT-based Figure 2: framework model-checking. While required to properly ana- CoCoSim lyze the full system, this encoding is not efficient for execution. 2.1 Formal semantic Once the verification is valid, the last step is the efficient code generation (right hand side of Fig. CoCoSim provides a formal semantic of a well 1). Each synchronous component is translated as defined subset of Simulink/Stateflow blocks. a Lustre model which will eventually be compiled This formal representation will permit the use of into C code, while aggregating nodes, mixing differ- formal verification methods and code generation. ent clocks or execution rates are expressed as Pre- CoCoSim starts first by simplifying some com- lude programs. Prelude [30] is a synchronous plex blocks into a set of basic blocks. Then an language that has been defined to program multi- internal representation of the model is generated periodic applications. From a Prelude program, containing all information needed for code genera- the compiler generates a set of classical real-time tion. Based on the work of Caspi et al. [7], Gene- tasks and many predictable implementations have Auto [33, 39] and P [4] projects, CoCoSim trans- been proposed for multi- and many-core architec- lates modularly the pre-processed mono-periodic tures [32]. Simulink model into an equivalent Lustre model. The translator is developed using a visitor pattern, each Simulink Subsystem is translated into a Lus- 1.3 Outline tre node, each instance of a Subsystem is trans- lated into a Lustre node call and each Simulink We start by presenting an overview of CoCoSim atomic block is represented by a local Lustre equa- framework (Section 2) for mono-periodic discrete tion defining the semantic of the block. The gener- Simulink models. We then define the specifica- ated Lustre model has the same hierarchy as the tion of multi-periodic applications with Simulink original Simulink model and preserves the initial (Section 3). We detail the multi-periodic exten- semantic. sion of CoCoSim (Section 4). Last, Section 5 CoCoSim is customizable and configurable. presents some experiments settings and two detailed Indeed, it supports most of frequently used use cases. Simulink blocks libraries (around 100 blocks) and new blocks can be easily supported. 2 Overview of mono-periodic 2.2 Supported analyses CoCoSim Once a formal representation of Simulink model is generated, CoCoSim is connected to a set of ex- CoCoSim is a highly automated frame- ternal tools to provide code generation, formal ver- work for verification and code generation of ification or test case generation. The toolchain is Simulink/Stateflow models. It consists of highly automated as all the steps of verification an open architecture, allowing the integration of or code generation are automated. different analyses. CoCoSim is structured as a The goal of the CoCoSim framework is to ease compiler, sequencing a series of translation steps the application of formal methods and analysis of leading, eventually to either the production of Simulink-based systems. The external tools are source code, or to the call to a verification tool. introduced and linked to the platform in a very By design, each phase is highly parametrizable generic way. While CoCoSim is built mainly through an API and could then be used for different around a specified set of tools, additional ones can purposes depending on the customization. The be easily locally linked or even distributed as exten- Figure 2 outlines the different steps. sions. A set of Matlab functions libraries are pro- 2 vided by CoCoSim to ease the integration of tools CoCoSpec [9, 13]. LustreC also provides modular analysis results. Eg. displaying the counterexample compilation with multiple source files, call to exter- at the Simulink level, importing test harness as a nal C libraries or externally defined C functions. Signal builder or create a new test-harness model, Kind2 [10] is, first of all, a model checker but it is generating HTML reports or other helpful support capable of producing Rust code from the provided functions. models. All CoCoSim analyses are performed on the compiled artifact and the results are expressed back at Simulink level thanks to traceability informa- 2.5 Test cases generation: tion. We sketch here the features of the connected LustreT [17] is based on some compilation stages of tools. At the current moment all tools are open- LustreC [20]. It provides two different methods to source and freely available. It scales well with perform test case generation [18]. large models, therefore various verification tech- In the first case a coverage criteria such as MC- niques and compositional reasoning can be used. DC is expressed as a reachability problem. For ex- ample, an atom of a boolean predicate has to be true 2.3 Formal Verification: SMT-based at some point. Then we check the validity of the model checking negation of that property. Model checker such as Kind2 or Zustre will then perform bounded-model Once requirements have been expressed using Co- checking or, possibly, exhibit a counter-example; CoSim library and attached to the Simulink that is, a test case activating that specific criteria. model, different tools can perform SMT-based A MC-DC criteria will then be mapped to a large model checking and check their validity. In case set of such predicates. The test generation process the property supplied is falsified, CoCoSim pro- will populate a set of test cases activating each of vides means to simulate the counterexample trace in these conditions. the Simulink environment. Currently, CoCoSim The second approach relies on the notion of mu- is connected to three verifiers. tants. Usually, mutants are used to evaluate the First, Kind2 [10] is a powerful tool that imple- quality of a test suite. We generate a set of mutant ment multiple algorithms including k-induction [36] programs and apply different test suites. A good and IC3/PDR [5] as well as on-the-fly invariant gen- test suite distinguishes valid program from mutants. eration. All of these can be performed with various Here the approach is different. After generating SMT solvers: CVC4, Z3, Yices. mutants, we use the same bounded-model checking Second, Zustre [21] relies on the LustreC [20] tools to build a test case that will distinguish them. modular compiler.