Traceability and Evidence of Correctness of EDSL Abstractions Martin Sulzmann Hochschule Karlsruhe - Technik und Wirtschaft martin.sulzmann@hs-karlsruhe.de J¨ urgen Nicklisch-Franken ICS AG juergen.nicklisch@ics-ag.de Axel Zechner ICS AG axel.zechner@ics-ag.de Abstract One of the main advantages of an EDSL (embedded domain- specific language) is that new abstractions can be coded quickly and easily in the EDSL’s host language and are automatically trans- formed to the basic EDSL primitives. In the context of formal software certification, it is paramount that evidence for the correct- ness of these abstractions are provided and that the low-level code resulting from the EDSL primitives can be traced to some higher- level artifacts, i.e. some concrete programming abstractions, soft- ware requirements etc. We have built an EDSL-based tool-chain for implementing and testing mission critical applications which supports measures to guarantee traceability and provides evidence of correctness of EDSL abstractions. We give an overview of our EDSL approach and practical experiences applying them in the industrial context. Categories and Subject Descriptors D.2.2 [Software Engineer- ing]: Design Tools and Techniques—Software libraries; D.2.5 [Software Engineering]: Testing and Debugging—Tracing Keywords EDSL, Abstractions, Traceability, Correctness 1. Introduction The application domain of our EDSLs are mission critical embed- ded control and simulation software for reactive systems. The func- tionality of these systems increasingly relies on software which must meet high safety standards to guarantee their correct func- tioning. To ensure predictable performance and memory consump- tion, such systems are often implemented by following the syn- chronous execution paradigm. That is, given some input values the application shall produce some output values in every cycle. The cycle time is fixed, so that it needs to work within some predictable amount of time. The EDSLs we describe here have emerged out of a software project in the Aerospace& Defense area. In the following, we have a quick run through the various aspects of our EDSLs. EDSL Technology Our design decision was to use a rule-based language, in essence guarded actions, where in each cycle every rule is tried sequentially. If the guard of a rule is satisfied the rule’s action will be executed. The rule-based language, referred to as Rules EDSL, is embed- ded in Haskell. We chose Haskell because of familiarity with the [Copyright notice will appear here once ’preprint’ option is removed.] language and Haskell’s well-known ability to be a good host for embedded languages. The architecture and compilation of the basic Rules EDSL to simple if-then statements in C is straightforward. We apply a deep embedding where running the program generates an abstract syn- tax tree (AST) which can then be processed further in several ways (i.e. generate code, generate documentation, check for correctness). We use singleton types together with phantom types to reflect the AST at the level of types. Technically, we follow [1] and repre- sent constructors of our EDSL via values (type class methods). The meaning of programs is then specified by defining the appropriate type class instances. Thus, we obtain a strongly typed EDSL lan- guage. EDSL Abstractions The Rules EDSL offers additional type- safety compared to C but programming in the bare Rules EDSL is still very low level. So far we have built various abstractions us- ing Haskell as our macro language. For standard signal processing we provide operations like detection of rising and falling edges, basic counter operations, temporal primitives such as a duration, primitive delays for switch-on and switch-off operations etc. We also offer various kinds of state machines to better capture the semantics of the problem domain. The state machine abstractions range from simple cases to timed state-machines, hierarchical state- machines and state machines with parallel branches. Traceability For us, the EDSL and its abstraction are only a means to an end. Ultimately, we are only interested in the resulting C code. In our largest industrial application, we find about 2000 primitive rules. Of course, by looking at the resulting C code we hardly can recognize the structure which is present at the higher EDSL level. However, in the context of mission-critical applica- tions which are typically regulated by safety standards, every single line of code needs to be justified and traced back to some higher- level artifact. The approach pursued by commercial tools such as SCADE is to have a qualified code generator [3]. The upshot of this approach is that the final C code doesn’t need to be inspected anymore. It suffices to inspect the software models out of which the C code is generated. For us this is not a viable option. Firstly, formal software qualification [6] is very costly. Secondly, our language model, that is the EDSL abstractions, can change rapidly depending on the problem domain. But this then would require re-qualification. Our approach is to attach meta data to each rule which explains why this rule was generated. For example, modeMachine transi- tions are translated to rules which maintain the link to the original construct. Testing and Verification To ensure the correctness of EDSL ab- stractions we make use of an expressive test and verification sys- tem which we have integrated into our framework. At its core we find a Test EDSL which consists of a temporal property language to specify the expected outcome of a test and another language to set the inputs of the (synchronous) system under test. Both languages share the sensor signal language with the Rule EDSL. Our interest 1 2012/11/12