formal analysis and verification of embedded systems for … · experience as an instructor. i am...

Formal analysis and verification of embedded systems forhealthcareCitation for published version (APA):Keshishzadeh, S. (2016). Formal analysis and verification of embedded systems for healthcare. TechnischeUniversiteit Eindhoven.

Document status and date:Published: 24/03/2016

Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:[email protected] details and we will investigate your claim.

Download date: 17. Oct. 2020

https://research.tue.nl/en/publications/formal-analysis-and-verification-of-embedded-systems-for-healthcare(b5c23edc-66e2-4729-a706-e8e073067540).html

Formal Analysis and Verificationof Embedded Systems for

Healthcare

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan de Technische UniversiteitEindhoven, op gezag van de rector magnificus prof.dr.ir. F.P.T. Baaijens,

voor een commissie aangewezen door het College voor Promoties, in hetopenbaar te verdedigen op donderdag 24 maart 2016 om 14:00 uur

door

Sarmen Keshishzadeh

geboren te Teheran, Iran

Dit proefschrift is goedgekeurd door de promotoren en de samenstelling vande promotiecommissie is als volgt:

voorzitter: prof.dr. J. de Vlieg1e promotor: prof.dr.ir. J.F Groote2e promotor: prof.dr. J.J.M. Hooman (Radboud Universiteit Nijmegen &

Embedded Systems Innovation by TNO)copromotor: dr.ir. A.J. Mooij (Embedded Systems Innovation by TNO)leden: prof.dr. J.A. Bergstra (Universiteit van Amsterdam)

prof.dr.ir. K.H. van Berkelprof.dr. W.J. Fokkinkprof.dr. A.W. Roscoe FREng. (University of Oxford)

Het onderzoek of ontwerp dat in dit proefschrift wordt beschreven is uitgevoerd inovereenstemming met de TU/e Gedragscode Wetenschapsbeoefening.

Formal Analysis and Verificationof Embedded Systems for

Healthcare

Sarmen Keshishzadeh

Copyright ©2016 by Sarmen KeshishzadehAll rights reserved. Reproduction in whole or in part is prohibited without the writtenconsent of the copyright owner.

A catalogue record is available from Eindhoven University of Technology LibraryISBN: 978-90-386-4039-6

IPA Dissertation Series 2016-04

Typeset with LATEX (TEXLive 2012)Cover design by: Proefschriftmaken.nl || Uitgeverij BOXPressPrinted by: Proefschriftmaken.nl || Uitgeverij BOXPressPublished by: Uitgeverij BOXPress, ’s-Hertogenbosch

The work in this thesis has been carried out under the auspices of the research schoolIPA (Institute for Programming research and Algorithmics) and supported by the Dutchnational COMMIT program under the Allegio project. The author was working at Eind-hoven University of Technology.

Contents

Preface v

1 Introduction 11.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Outline and Origin of the Chapters . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Suggested Method of Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Semantic Correctness of a DSL Transformation 132.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Data Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Process Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Application: a Clinical X-ray Generator . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.2 DSL for Pedal Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Abstract Syntax and Semantics of the DSL . . . . . . . . . . . . . . . . . . . . 192.4.1 Data Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.2 Process Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.3 Validating DSL Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5 Obtaining Simulation Models from DSL Models . . . . . . . . . . . . . . . . 242.5.1 An Overview of POOSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5.2 A Transformation from the DSL to POOSL . . . . . . . . . . . . . . . 28

2.6 Validating the Industrial Implementation by Model-based Testing . . . . . 332.6.1 An Overview of AML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.6.2 A Transformation from the DSL to AML . . . . . . . . . . . . . . . . . 352.6.3 Interpreting the Results of Model-based Testing . . . . . . . . . . . . 402.6.4 Practical Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.7 Checking the Correctness of Generated Models through Redundancy . . . 412.7.1 Checking the Behavioral Equivalence between Artifacts . . . . . . . 422.7.2 Model-based Testing of Executable Models . . . . . . . . . . . . . . . 43

2.8 Experiences with Model Transformations . . . . . . . . . . . . . . . . . . . . 432.9 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

i

CONTENTS

2.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3 Consistency between Multiple DSL Transformations 473.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 General Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1 Semantics versus Implementation Details . . . . . . . . . . . . . . . . 503.2.2 Conformance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.3 Application: a Movement Controller . . . . . . . . . . . . . . . . . . . . . . . 523.3.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.2 DSL for Collision Prevention . . . . . . . . . . . . . . . . . . . . . . . . 533.3.3 Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.5 Formalizing the Semantics of the DSL . . . . . . . . . . . . . . . . . . . . . . . 57

3.5.1 External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.5.2 Expressions and Conditions . . . . . . . . . . . . . . . . . . . . . . . . 583.5.3 State-based Semantic Module for Determining Active Restrictions . 593.5.4 Function-based Semantic Module for Computing Output Speed Re-

quests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.5.5 Semantics of a DSL Model . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6 Formalizing Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . 643.6.1 Module for Time-Consuming Operations of Restrictions . . . . . . . 653.6.2 Time-consuming Operations Performed by a DSL Model . . . . . . . 67

3.7 Conformance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.7.1 Testing Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.7.2 Conformance Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.7.3 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.7.4 Coverage Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.8 Practical Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.8.1 Implementation Code of the Safety Layer . . . . . . . . . . . . . . . . 743.8.2 Performance Model of the Safety Layer . . . . . . . . . . . . . . . . . 743.8.3 Test Case Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.9 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.9.1 Mathematically Undefined Operations . . . . . . . . . . . . . . . . . . 763.9.2 Semantics of Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . 773.9.3 Computation Accuracies . . . . . . . . . . . . . . . . . . . . . . . . . . 783.9.4 Symmetric Distance Queries . . . . . . . . . . . . . . . . . . . . . . . . 783.9.5 Lazy Evaluation for Conditions . . . . . . . . . . . . . . . . . . . . . . 78

3.10 Afterthought: Towards a Modular Semantics for DSLs . . . . . . . . . . . . . 793.11 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

ii

CONTENTS

4 Validation of Domain-Specific Models 834.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.2 Restricting the Collision Prevention DSL . . . . . . . . . . . . . . . . . . . . . 85

4.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.2.2 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.3 Basic Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.4 Advanced Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.4.1 Well-definedness of Conditions and Expressions . . . . . . . . . . . . 894.4.2 Ranges for Speed Limits and Deadlock-Freedom . . . . . . . . . . . 904.4.3 Feasibility of SMT Solving . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.5 Automated Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.5.1 Fault Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.5.2 Procedure to Locate a Single Pivotal Restriction . . . . . . . . . . . . 934.5.3 Masked Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.6 Integration with DSL Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5 Reliable Algorithms for Calculating with Real Numbers 995.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.2 Computable Real Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.3 Real Numbers: Representation and Operations . . . . . . . . . . . . . . . . . 1035.4 Sensitivity of Operations to Perturbations in the Arguments . . . . . . . . . 104

5.4.1 Perturbation Analysis for Unary Functions . . . . . . . . . . . . . . . 1045.4.2 Perturbation Analysis for Binary Functions . . . . . . . . . . . . . . . 104

5.5 Approximating Algebraic Operations . . . . . . . . . . . . . . . . . . . . . . . 1055.5.1 Unary Negation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.5.2 Multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.5.3 Inverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.5.4 Addition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.5.5 Square Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.6 Approximating Transcendental Functions by Riemann Sums . . . . . . . . . 1175.6.1 Exponential Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.6.2 Natural Logarithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245.6.3 Arctangent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.7 Approximating Transcendental Functions by Taylor Expansions . . . . . . . 1355.7.1 Approximating Functions in the Base Interval . . . . . . . . . . . . . 1355.7.2 Extending Base Interval Approximations . . . . . . . . . . . . . . . . 143

5.8 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495.9 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1525.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6 Conclusions 1556.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

iii

CONTENTS

A Validation Properties for Pedal Handling 161

B Propositions and Lemmas for Chapter 5 163

Bibliography 167

Summary 177

Curriculum Vitae 179

iv

Preface

Writing this thesis gave me the opportunity to revisit the work I have been doing in thepast three and half years. The most remarkable part for me was to see how the style ofmy work has improved throughout these years. Below I want to mention a few names towhom I feel indebted for their help in this journey.

My thanks go to professors Jan Friso Groote and Jozef Hooman for giving me theopportunity to work in the Allegio project. Jan Friso has great enthusiasm in his workand as a group leader knows exactly how to invigorate the ones around him. Despite hisbusy schedule, he has always been there when I needed his help. I gratefully thank himfor his supervision and support. Jozef Hooman is acknowledged for his great commitmentto the project. Applying research in industrial practice is not trivial and without Jozef’shelp I could not bring my research to a state that is also useful for our industrial partner.

Arjan Mooij was my daily supervisor and another member of the Allegio project. Arjanwas very instrumental in helping me organize my thoughts. Thanks to Arjan I managedto substantially improve my writing and presentation skills. I highly appreciate the timehe put for our weekly discussions.

I also thank Jan Friso, Jozef, and Arjan for carefully reading different parts of thisthesis and for providing insightful comments that improved the contents of the thesis.

Thanks also to Jan Bergstra, Kees van Berkel, Wan Fokkink, and Bill Roscoe for ac-cepting the invitation to join the thesis committee. I appreciate your valuable feedbackon the manuscript.

I would like to express my gratitude towards my colleagues in the Allegio project.Thanks to Dave Watts, everything was always running smoothly in the project and wecould properly present our work to the outside world. Freek van den Berg, NicolasDintzner, and Steven Haveman, it was fun to work with you and I enjoyed all our discus-sions.

Marco Blom and Alex de Cock from Philips iXR are thanked for their technical contri-bution to my work. I would also like to thank Rob Albers, Gernot Eggen, Robert Huis in'tVeld, and Dirk Jan Swagerman for their trust and enthusiasm in the work being carriedout in our project.

In the Allegio project, I also collaborated with the model-based testing company Axini.Working with Machiel van der Bijl, Vincent de Bruijn, Menno Jonkers, and Lennart Tangewas a great experience.

During my time as a PhD student, I also had the opportunity to gain some teachingexperience as an instructor. I am grateful to MohammadReza Mousavi and Alexander

v

Preface

Serebrenik for giving me this opportunity. Kees Huizing, Ulyana Tikhonova, and AntonWijs, it was a pleasure working with you and I learned a lot from each one of you.

My sincere thanks to the Formal System Analysis group for providing a pleasantworking environment. Tim Willemse is acknowledged for organizing very interestingIPA events. Wieger Wesselink is thanked for organizing a nice excursion in Kampina.Erik de Vink is the most careful reviewer of scientific papers I have seen. I thank himfor his valuable comments on some of my articles. MohammadReza Mousavi deservesa special thanks for his help at the beginning of my PhD studies. I would also like tothank Julien Schmaltz and Bas Luttik for our chats at the coffee corner. Dragan Bosnackifrom the Software Engineering and Technology group is thanked for pointing me to a fewinteresting articles.

Tineke van den Bosch and Margje Mommers-Lenders kindly arranged all the admin-istrative issues. Thanks to them, these issues were handled in a very efficient way.

Special thanks to my officemates for tolerating me in the past few years. AmmarOsaiweran kindly helped me when I was new in Eindhoven. It was always helpful tohave a discussion with Sjoerd Cranen when I was fairly stuck at my work. Fei Yangis thanked for being generous with the apples and oranges, Sebastiaan Joosten for hismagic tricks, Mahmoud Talebi for being a good officemate in Sharif and TU/e, NathalieKerstens for organizing a nice office night out, and Petra van den Helder for putting upwith a group of strange people in the office.

I would also like to thank some other PhD students for our informal meetings and so-cial events. I would like to thank Önder Babur for appreciating Armenian music, Sanderde Putter and Josh Mengerink for all the fun we had at our post-meeting drinks, Ana-Maria Sutii and Ulyana Tikhonova for organizing the PhD meetings, Yanja Dajsuren forkeeping everybody posted on the latest gossips, Yaping Luo and Dana Zhang for theircrash courses on the Chinese language.

My sincere thanks to my friends for their support and the much appreciated distrac-tions they provided. I always enjoyed the company of Mahmoud Talebi, Ali Mehrabi,Mehran Mehr, Mikkel Abrahamsen, and Arash Khabbaz Saberi. Alexandar Markovic isthanked for organizing the movie nights.

Thanks to the teachers from the language center at TU/e, I managed to learn moreabout the Dutch language and culture. I would like to thank Elly Arkesteijn and PaulineNekeman for their efforts and for creating a friendly environment in which I could im-prove my language skills.

I also have to thank my friends in Iran for our occasional meets. Special thanks tomy former university professor Raman Ramsin who has always been helpful in providingassistance and advice.

Last but not least, I would like to thank my family for their unconditional love andsupport throughout these years. Words cannot express the extent to which I feel indebtedto them.

Sarmen Keshishzadeh, January 2016

vi

Chapter 1

Introduction

Trends in Software Engineering A systematic approach to software development is theclassical life cycle or the linear sequential model. Since software is always part of a largersystem, its development process starts by allocating responsibilities to the software andidentifying its requirements. This phase is followed by determining a structural organi-zation for the software (i.e., architecture) that meets the identified requirements. In thedesign phase, various components of the architecture are identified and a specificationof their behavior is produced to facilitate the development of an implementation in thenext phase. After producing an implementation, a set of testing activities are plannedand conducted to assess the correctness of the source code. Testing starts with low-leveltests on small segments of the code (module testing) and scales up to high-level tests thatvalidate major system functionalities against the requirements (system testing) [Pre05].

In classical software engineering, designs are typically described in terms of informaldrawings or documents. Moreover, implementations are created manually based on the(informal) design. In this setting, there is no strong relationship between the design andimplementation. Moreover, the design documentation is often not updated after makingchanges in the implementation. Thus, the implementation and design documents arerarely in sync.

Developing a safety-critical component using this classical approach can cause variousproblems in late stages of the development process. Having informal design documentsthat are not in sync with the implementation implies that a long testing phase is necessaryto gain confidence in the correctness of the software [MSB11; EJ09]. Moreover, detect-ing mistakes and repairing them in the testing phase is time-consuming. This classicaldevelopment process is depicted in Fig. 1.1(a) in terms of a V-model [Boe84].

The increasing complexity of software systems and the desire to deliver innovativeproducts in a short period of time have motivated researchers and practitioners to createtechniques that alleviate the complexity of the underlying computing environments andthat enable early fault detection in the development process. Model-Driven SoftwareEngineering (MDSE) [Béz06; Sch06] addresses these issues by focusing on models as thekey elements in the development process.

MDSE approaches promote the use of formal models and model transformations

1

Introduction

Requirements

Implementation

System Testing

Architecture

Design

(informal documents)

Subsystem Testing

Module Testing

(a) Classical Approach

Requirements

Implementation

System Testing

Architecture

Design

(formal models)

Subsystem Testing

Module Testingformal analysis

code generation

(b) MDSE Approach

Figure 1.1: Trends in Software Engineering

[MG06] for software development. The idea is to use models for precisely describingthe behavior of a software component at a higher level of abstraction compared to imple-mentation code and to automatically generate source code from models; see [Moz+08]for an MDSE approach based on Mathlab/Simulink [Mat] models.

Describing the behavior of software in terms of models introduces formality in earlydevelopment phases. Abstract models have the potential to be analyzed using variousformal techniques (e.g., verification) and to be inspected by domain experts using light-weight techniques (e.g., simulation). This facilitates early fault detection [Hol96] andreduces the rate of costly repairs in the test and integration phase [BB01].

An automated transformation to implementation code is of great value in practice andencourages the domain experts to spend more effort on developing adequate models forthe software. This investment in modeling activities pays off quickly by obtaining sourcecode from the code generator [FL07]. Furthermore, code generators use structured ways(e.g., code templates) to translate abstract models to implementations and are likely to

2

produce more reliable implementations compared to the manual construction of softwarefrom design models; see Fig. 1.1(b). By introducing formality in early developmentphases in the approach of Fig. 1.1(b), the time to produce the first implementation maybecome longer compared to the classical approach. However, due to early fault detectionmechanisms the overall development process is likely to become shorter.

The focus of software development tasks in MDSE approaches is also different com-pared to classical approaches. In MDSE approaches the technical tasks are divided be-tween three groups of people:

• modelers that describe the domain logic in terms of abstract models;

• developers that create an environment to enable automatic generation of imple-mentation code and analysis models;

• experts that perform formal analysis on abstract models.

Applying MDSE Approaches on Realistic Systems Various authors have reported ontheir experiences with applying model-based techniques in different industrial contexts.For instance, in [Osa12] the author describes the development of certain parts of a medi-cal system using a formal model-based approach (Fig. 1.1(b)) called Analytical SoftwareDesign (ASD) [BB03; Bro05]. First, formal models are created for the studied compo-nents. Afterwards, these models are analyzed and used for code generation.

As another example, in [Cra12] formal models for the startup phase of a FlexRaynetwork are specified using the micro Common Representation Language 2 (mCRL2)[GM14]. Various properties are verified against the extracted models using the mCRL2toolset [Mcr]. A similar approach is applied in [Red14] to analyze the behavior of twodifferent components of a medical system.

Model-based approaches have also been used to test realistic software systems. In[Asa+11] the authors report on a case study in applying model-based testing [Tre08]on an electronic fund transfer switch. As another example, in [Vis+12] model-basedtesting is applied to extend the conventional testing procedures of the image detectioncomponent of an X-ray system.

The studies in [Cra12; Red14; Asa+11; Vis+12] are focused on analyzing existingcomponents; code generation from models was not considered by the authors.

Generally speaking, the results obtained in the mentioned studies show the potentialof MDSE approaches for the construction of correct software. In particular, in [Osa12]the author provides detailed discussions and evaluations about the impact of the appliedmodel-based approach on the quality of the software, productivity of the developers, andunderstanding of the implemented behaviors.

Using Domain-Specific Languages for Model-based Development Each of the above-mentioned approaches is focused on a particular type of analysis, e.g., ASD enables re-finement checking. Moreover, using these approaches requires the user to write modelsin a general-purpose modeling language. Such languages are designed to be applicablein various application domains. Hence, it is not always easy to use a general-purposelanguage and construct models that follow the natural structure of a particular domain.

3

Introduction

Instead, it would be more convenient to use an MDSE approach based on a modelinglanguage that:

• is defined in terms of the essential concepts in the domain;

• allows automatic generation of source code;

• supports analysis using various formal techniques (e.g., simulation, verification,model-based testing).

A Domain-Specific Language (DSL) [DKV00; Voe13] is aligned with the essential con-cepts in a specific problem domain, and abstracts from low-level implementation details.By combining DSLs and model transformations [MG06], we can obtain implementationcode and various analysis models from domain-specific models. Fig. 1.2 depicts a model-based approach that meets the three requirements mentioned above. In this thesis wefocus on different challenges in DSL approaches.

The model-based approach of Fig. 1.2 is centered around models in a domain-specificlanguage and hence facilitates the involvement of domain experts in writing specifica-tions. Having multiple transformations from a DSL allows us to obtain various artifactsfrom the same single source. Implementation code is automatically generated from DSLmodels and domain experts can benefit from the insights obtained from a wide range ofanalysis techniques. Formal analysis enables early fault detection and shortens the testand integration phase [Osa12; HMW12]. As an additional benefit, by using DSL modelsas starting point, we spare the domain experts from learning multiple formal languages.

Realizing the approach of Fig. 1.2, requires an extra investment in defining a DSL andimplementing automated transformations to implementation code and analysis models.The development of a DSL is mainly based on the following separation of domain content[Voe13]:

• Language, providing an abstraction for describing the variability in a specific classof systems.

• Target platform, providing a technical environment in which the class of systemsmust be run.

• Code generator, transforming a specification expressed in the language into codefor the target platform.

The language does not aim to address all kinds of computational problems. By focusingon a limited domain, a DSL abstracts from the characteristics shared between a set ofrelated systems and is very expressive in describing the variations between the elementsof this set [Vis08]. As depicted in Fig. 1.2, the three main components discussed above(language, target platform, and code generator) can be extended with transformationsto analysis models.

To develop reliable software using a DSL approach, certain problems need to be ad-dressed. We discuss these problems in Section 1.1.

4

1.1. Problem Statement

DSL Model

Generate

Generate

Generate

Implementation Code

Verification Model

Simulation Model

Test Model

Generate

Performance Analysis

ModelGenerate

Figure 1.2: Domain-Specific Language and Transformations

1.1 Problem Statement

Modern implementation technologies such as EMF [Ste+08], Spoofax [KV10], and Xtext[Xteb] allow language designers to define their languages and develop the desired trans-formations. This seems to boost the applicability of DSLs in industrial practice, as wit-nessed by reports like [NM12; Ver+13; MHA13; Moo+15]. The development of DSLsusually centers around the grammar and transformations to implementation code andanalysis models. However, in order to develop reliable software from abstract models,certain challenges should be addressed. In this thesis, we focus on the following:

1. Semantic Correctness of a DSL Transformation: Generating implementationcode and analysis models from DSL specifications is valuable, but the generatedartifacts are only useful if they are “correct”. Correctness of the generated artifactshas two aspects: whether they are syntactically correct, and whether they conformto the semantics of the DSL.

Transformations from a DSL typically generate artifacts in general-purpose model-ing/programming languages. Such languages are widely used and available toolsfor them allow us to check for syntactic correctness.

The second aspect of correctness is more challenging. Various authors [ABE12;EE08] have argued that semantic correctness should be established by proving thecorrectness of transformations. However, experience reports such as [Ler09] sug-gest that for a realistic transformation this approach can be very costly in termsof time and the required expertise. Thus, proving transformations should only beconsidered for well-established languages and transformations. For a young DSL,code generators are improved regularly, and hence proving their correctness maynot be effective. Alternative approaches are essential to address this problem.

5

Introduction

2. Consistency between Multiple DSL Transformations: A DSL provides an ab-straction that is aligned with the way domain experts reason about problems of thedomain. However, a code generator produces implementations that are at a lowerlevel of abstraction than DSL models. In addition to implementing the semantics,a code generator introduces implementation details to produce an adequate imple-mentation that is executable on the target platform. These implementation detailsmay concern the use of specific data structures, coding standards, computationstrategies, etc.

Suppose there are multiple code generators from a DSL, each designed for a spe-cific target platform. Each code generator may introduce a different set of imple-mentation details, whereas the semantics of the DSL should be realized in exactlythe same way by all generators. Thus, implementation details are specific to codegenerators and are not part of the semantics. However, they may have a majorimpact on various aspects of the generated implementation, e.g., the run-time per-formance. When performance analysis models are generated from DSL models,they should be coupled with a specific code generator and follow the relevant im-plementation details as introduced by the code generator. Thus, in a setting withmultiple transformations, establishing semantic correctness for the transformationsmay not be adequate. It is also essential to validate the consistency of the transfor-mations with respect to certain implementation details. As far as we are aware, thisdistinction between semantics and implementation details and consistency check-ing based on them are not addressed in the literature.

3. Validation of Domain-Specific Models: DSL models are the starting point in theapproach of Fig. 1.2. Thus, early validation of DSL models is as essential as the cor-rectness and consistency of the transformations. Language implementation tech-nologies such as Xtext support basic types of validation (e.g., syntax checking).However, for specifications of a safety-critical component, we need validation thatgoes beyond these basic checks.

Since DSL models are expressed in terms of the concepts of their respective do-mains, they have a lot of potential for analysis using various formal techniques.The main benefit is that unlike program verification techniques [ADBO10] we donot need abstraction methods to facilitate formal analysis.

To avoid cascading modeling mistakes from DSL models to the generated imple-mentations, it makes sense to introduce verification techniques at the abstractionlevel of the DSL and detect mistakes in DSL models before generating any code. In-tegration of verification techniques and DSLs has been studied by various authors[RDV09; Rat+12]. However, these approaches demand a certain level of expertiseas the user should interact with verification tools to apply the analysis and inter-pret the results. To make the use of state-of-the-art verification techniques morefeasible in industrial practice, it is essential to hide their complexities from the userand provide feedback from the analysis in a way that is easy to understand.

4. Reliable Algorithms for Calculating with Real Numbers: The behavior of manysafety-critical systems is influenced by data values from various domains, e.g., real

6

1.1. Problem Statement

numbers. Typically, languages designed for behavioral specification rely on suchdata types and allow the user to describe the way data values impact the courseof actions in a system. Since real numbers are infinite objects, reasoning aboutspecifications that depend on real numbers is a challenging task. We would liketo have analysis methods that rely on valid computations and that produce correctresults. However, conventional numerical methods that approximate real numberswith floating point numbers are not suitable for formal analysis. Round-off errorsin such methods can potentially build up into catastrophic errors and result inapproximations that are totally unrelated to the correct answer.

There is a need to develop rigorous numerical methods that enable reasoning aboutthe behavior of safety-critical systems. Such techniques should guarantee the cor-rectness of the calculated results. Numerous applications, such as synthesis andverification of systems, test data generation and validation of outputs during test-ing, can benefit from a theory that supports rigorous numerical computations.

Various rigorous numerical methods have been studied in the literature [Pot98;CNR11; GL00; Mül01]. Each method proposes a specific representation for realnumbers and sketches procedures for computing various arithmetic operations.However, a precise description of these algorithms and proofs of correctness forthem are lacking.

Industrial Research Context The work described in this thesis was conducted withinthe Allegio project [All] supported by the Dutch national program COMMIT [Com] andis concerned with various aspects of model-based development of software in industrialpractice. We refer the interested reader to Steven Haveman’s Ph.D. thesis [Hav15] onmodel-based techniques that support design decisions and trade-off analysis, Freek vanden Berg’s research [Ber+15; BRH15] on performance analysis, and Nicolas Dintzner’sresearch [Din+14; Din15] on evolvability.

Philips Healthcare, a leading healthcare technology company, participated in theAllegio project as the industrial partner. Philips Healthcare produces various medicalequipments including interventional X-ray systems (see Fig. 1.3). In the past few years,practitioners at Philips Healthcare have shown an interest in applying various formalapproaches to improve the quality of the developed code, shorten the time to market,and increase the rate of innovation in the products. For instance, the studies in [Osa12;Red14; Vis+12] (discussed earlier in this chapter) report on the investigation of differentmodel-based approaches in Philips Healthcare.

In the Allegio project, we have investigated the DSL approach of Fig. 1.2 on twosafety-critical components of the interventional X-ray system of Fig. 1.3. In what follows,we briefly describe these two components.

Interventional X-ray systems are used for minimally invasive cardiac, vascular, andneurological procedures. During a medical procedure, the surgeon is guided by the im-ages on the monitors, for instance, to position a catheter inside the patient. To obtainthese images, the surgeon sends X-ray requests using the pedals. The X-ray system ofFig. 1.3 consists of two planes and includes a component called Pedal Handling thatmakes decisions about the amount of X-ray that should be generated in the tube of each

7

Introduction

Tube

Pedals

Monitors

Table

CArm

Figure 1.3: Interventional X-Ray

plane.To capture optimal images, various parts of the interventional system can be moved

during a procedure. For example, the table can be moved horizontally and each CArm canbe rotated around the table. A component called Safety Layer controls the movementsof these heavy objects to prevent collisions between the objects and humans (e.g., thepatient and the medical team).

The DSLs used for specifying the components mentioned above are designed in col-laboration with domain experts from Philips Healthcare. These languages are designedand improved iteratively. For each language, we started from a small number of con-structs that support basic specifications for the corresponding component and extendedthem to support realistic models. The results reported in this thesis are based on realisticmodels (i.e., describing the desired behavior of the studied components) in the DSLs andimplementations that are executable on the physical hardware. However, at the timeof writing, the use of these languages is not integrated in the development process ofinterventional X-ray systems.

1.2 Research Questions

To capture the essence of the problems discussed in Section 1.1, we formulate a fewresearch questions in this section. Note that the research questions are in one-to-onecorrespondence with the problems discussed in Section 1.1.

Current DSL approaches are mainly focused on defining the syntax of the languageand implementing transformations to implementation code and analysis models. Littleattention is given to validating the correctness of the transformations in a practical way.In search for ways to validate transformations, we have formulated the following researchquestion:

RQ1: How can we validate the semantic correctness of the transformationsfrom a DSL in a practical way?

8

1.3. Outline and Origin of the Chapters

Typically, there is a wide gap between the abstraction level of DSL models and im-plementations that are executable on the target platform. To bridge this gap, a codegenerator can realize the semantics of the DSL by introducing various implementationdetails. Typically such implementation details are tailored for a specific platform; codegenerators for two different platforms may introduce different implementation details.Implementation details introduced by a code generator may also be relevant for certaintypes of analysis models generated from DSL models. To obtain results from such modelsthat are valid for a specific platform, the code generator and transformations to analy-sis models should follow the same implementation details. To highlight the impact ofimplementation details, we have formulated the following research question:

RQ2: How can we validate the consistency between multiple transformationswhen certain platform-specific implementation details introduced by a code gen-erator are relevant for other transformations?

Research questions RQ1 and RQ2 are aimed at validating the correctness and consis-tency of the transformations from a DSL. However, if due to modeling mistakes a DSLmodel does not satisfy certain desired properties, the same mistakes will be cascaded tothe generated implementation. The following research question is aimed at validatingDSL models as the starting point of a model-based approach:

RQ3: How can we integrate state-of-the-art formal analysis techniques withDSLs?

Regarding research questions RQ1, RQ2, and RQ3, our approach is to study a few realisticDSLs and investigate techniques that address these questions and that have the potentialto be applicable in industrial practice.

General-purpose or domain-specific languages typically rely on various data types,such as real numbers. This allows the user of languages to specify the way a componentmanipulates data items and exchanges messages containing data items with its environ-ment. Analyzing models that rely on real numbers is a challenging task and requiresnumerical methods that guarantee the correctness of computations. To underline the im-portance of rigorous numerical methods in formal analysis of critical systems, we haveformulated the following research question:

RQ4: How to develop rigorous numerical methods to support formal analysistechniques?

1.3 Outline and Origin of the Chapters

In what follows, we give a brief overview of the remainder of this thesis. The origin ofeach chapter is also given.

9

Introduction

Chapter 2 In this chapter, we address research question RQ1. We show that a formalsemantics is essential for checking the correctness of the transformations from a DSL. Weexploit the semantics and use formal techniques based on equivalence checking [Gla93]and model-based testing [Tre08] for validating the correctness of transformations withrespect to the semantics. We illustrate our approach in the context of a DSL used fordescribing the behavior of Pedal Handling. This chapter is based on the following publi-cation:

[KMH15] S. Keshishzadeh, A.J. Mooij, and J. Hooman, Industrial Experi-ences with a Formal DSL Semantics to Check Correctness of DSL Transforma-tions, arXiv preprint: 1511.08049, 2015.

Chapter 3 In this chapter, we address research question RQ2. We use a DSL for describ-ing the Safety Layer to illustrate the distinction between the semantics of a language andthe implementation details introduced by a code generator. We show that in the presenceof multiple transformations, certain implementation details are also relevant for consis-tency checking between the transformations. As the implementation details are boundto a specific code generator, we consider independent formalizations for the semanticsand implementation details. We formally define a notion of consistency between the gen-erated models and implementations. Test cases are derived based on this definition tovalidate the consistency between the generated code and analysis models. This chapteris based on the following publications:

[KM14] S. Keshishzadeh and A.J. Mooij, Formalizing DSL semantics for rea-soning and conformance testing, In Proceedings of SEFM’14, LNCS, Vol.8702, pp. 81-95, Springer, 2014.

[KM16] S. Keshishzadeh and A.J. Mooij, Formalizing and Testing the Con-sistency of DSL Transformations, In Formal Aspects of Computing (in press),2016.

Chapter 4 In this chapter, we address research question RQ3 by introducing a range ofvalidation techniques at the level of DSL models. We propose techniques that validatea wide range of properties, classified into basic and advanced. Basic validation includessyntax checking, reference checking, and type checking. Advanced validation concernsdesired properties for the behavior specified in DSL models. For user feedback, we extendthe verification with automated debugging, which pinpoints a potential cause for each vi-olated property and traces it back to the syntactic constructs of the DSL. We illustrate ourapproach using the industrial DSL from Chapter 3. Chapter 4 is based on the followingpublication:

[KMM13] S. Keshishzadeh, A.J. Mooij, and M.R. Mousavi, Early Fault Detec-tion in DSLs using SMT Solving and Automated Debugging, In Proceedingsof SEFM’13, LNCS, Vol. 8137, pp. 182-196, Springer, 2013.

10

1.4. Suggested Method of Reading

Chapter 5 Research question RQ4 is addressed in this chapter. A controller is a softwarecomponent that reacts to inputs received from a continuously evolving environment.Reasoning about the behavior of such systems requires thorough mathematical modelsand methods that give a high level of certainty in their correctness. In this chapter, weaim to develop techniques that support such analysis.

Numerical computations [BF01; KC02] play a central role in different types of for-mal analysis (e.g., verification of hybrid systems [Bre+15]). To enable analysis basedon correct numerical calculations, we propose a top-down exact real arithmetic [YD95]approach to approximate various algebraic and transcendental operations with arbitraryprecision. Detailed algorithms and proofs are provided to guarantee the correctness ofthe approximations. Moreover, we develop and apply a perturbation analysis method toshow that our approximation procedures only recompute expressions when unavoidable.This chapter is based on the following publication:

[KG15] S. Keshishzadeh and J.F. Groote, Exact Real Arithmetic with Perturba-tion Analysis and Proof of Correctness, Eindhoven University of Technology,Technical Report 15-05, 2015.

Chapter 6 In the final chapter, we summarize the main contributions of this thesis andpropose directions for future research.

Appendix A This appendix contains a formulation of some example correctness prop-erties for the Pedal Handling component. These properties are expressed in a variant ofthe modal µ-calculus [Koz83]. We refer to this appendix in Chapter 2.

Appendix B This appendix contains some propositions and lemmas required for prov-ing the correctness of the approximations proposed for arithmetic operations in this the-sis. We refer to this appendix in Chapter 5.

1.4 Suggested Method of Reading

Chapter 2 and 5 are completely self-contained and can be read independently. Chap-ter 3 and 4 discuss consistency of transformations and validation of DSL models for theSafety Layer, respectively. It is recommended that Section 3.1-3.5 are read before readingChapter 4.

11

Chapter 2

Semantic Correctness of a DSLTransformation

2.1 Introduction

A modeling/programming language consists of two main ingredients [Voe13]: syntaxand semantics. Both syntax and semantics are decomposed into two parts.

Syntax is decomposed into concrete syntax and abstract syntax. The concrete syntaxof a language consists of all the visible notations of the language that can be used bylanguage users to express models/programs. This is typically specified in terms of agrammar. The abstract syntax (also known as meta-model) represents the main notionsof the language and the relations between them. This is typically specified in terms of amathematical structure, e.g., tree, that can be processed by dedicated tools.

Semantics is decomposed into static semantics and dynamic semantics. The static se-mantics defines a set of constraints to which a correct model/program should conform,e.g., checking that identifiers are properly declared before being used, or that expressionsare correctly typed. Various aspects of static semantics have been addressed in differentstudies. For instance, in [And+12] the authors use a rewrite rule style to describe therules for identifier resolution, scope resolution, and type resolution in the context ofa particular DSL. The dynamic semantics defines the behavior of models/programs inthe language once they are executed. The dynamic semantics of a language is specifiedin terms of a formal semantics using, for example, a Structural Operational Semantics(SOS) [Plo04], a denotational semantics [Mos91], or by means of a transformation to alanguage with a formal semantics [ABE11].

As indicated in [And+12], the static semantics can be considered as part of syntaxchecking or as a separate phase. In the rest of this thesis, we use the term semantics,without qualification, to refer to the dynamic semantics; we briefly discuss various as-pects of static semantics as part of syntax checking in Chapter 4.

In Chapter 1 we argued that the development of DSLs is usually centered arounddefining the syntax (concrete and/or abstract depending on the tools being used) and

13

Semantic Correctness of a DSL Transformation

DSL Model Generate

Generate

Generate

Implementation

Verification Model

Simulation Model

Figure 2.1: DSL and Transformations

transformations that generate implementation code or analysis models from DSL specifi-cations. Fig. 2.1 depicts a typical use of DSLs.

In such a setting, the main focus is on the transformation to implementation codewhich is very valuable in industrial practice. The generated analysis models allow usto reason about the behavior described in DSL models. For example, properties canbe verified against verification models or simulation models can be used to explore themodeled behavior interactively.

In DSL approaches, the semantics of the language is often defined implicitly and interms of the generated implementation. Although DSLs focus on the essential conceptsof their respective domains, the semantics of the language constructs are not alwaysobvious. The lack of a formal semantics can give rise to different interpretations and thiscan potentially cause inconsistencies between the transformations of Fig. 2.1.

Various authors [ABE11; Bod+05] have proposed to use a formal semantics to de-scribe the precise meaning of the language constructs. As indicated earlier, the semanticscan be formalized in terms of mathematical structures or by means of a transformation toa language with a formal semantics. The formalized semantics provides a single referencethat should be followed by all the transformations.

Implementing a transformation from a DSL to a programming/modeling language isnot a trivial task [BG13]. Having a formal semantics as a reference does not guaranteethe correctness of transformations from a DSL. The developer of a transformation shouldhave a deep understanding of the DSL and the target language and construct a trans-formation that does not deviate from the semantics of the DSL. In [BG13] the authorsindicate that such tasks are very error-prone and introducing redundancy is an effectiveway to reduce the rate of mistakes.

We propose to use the formal semantics of a DSL and introduce redundancy to vali-date the correctness of the generated artifacts using the following formal techniques:

• equivalence checking (by transforming models to a formalism that allows checkingequivalence of behaviors);

• model-based testing (by testing conformance of executable models to a test model).

Some authors [EE08] propose to formally prove the correctness of transformations.Since in practice transformations are improved regularly, we use automated techniques

14

2.2. Preliminaries

based on equivalence checking and model-based testing to validate the correctness of thegenerated implementation code and analysis models with respect to the semantics of theDSL, as opposed to formally validating the transformations themselves. This is especiallyimportant in an industrial context where there is no time for time-consuming proofs.

In this chapter, we report on our experiences with using equivalence checking andmodel-based testing in the context of an industrial DSL. The results obtained in theproject show that these formal techniques can effectively detect inconsistencies betweentransformations from a DSL. To hide the complexities of these techniques, we have de-veloped a push-button technology that allows industrial users to automatically performthese checks for the artifacts generated from a specification in the DSL.

Structure of this chapter We discuss preliminaries in Section 2.2. In Section 2.3 we de-scribe an industrial control component and informally introduce a DSL for describing itsbehavior; the abstract syntax and semantics of the language are discussed in Section 2.4.In Section 2.5 we consider the formalized semantics and construct a transformation fromDSL models to models that enable simulation. In Section 2.6 we generate test modelsfrom DSL specifications and apply model-based testing to assess the quality of an imple-mentation of the industrial component. The correctness of the used models with respectto the semantics is validated in Section 2.7. In Section 2.8 we discuss about our expe-riences with different types of model transformations. In Section 2.9 we discuss relatedwork. Section 2.10 contains conclusions and directions for future research.

2.2 Preliminaries

In this section we give an overview of the micro Common Representation Language 2(mCRL2) [GM14]. mCRL2 is a process algebra that extends the Algebra of Communicat-ing Processes (ACP) [BK84] with data and time. The mCRL2 language and its supportingtoolset [Mcr] can be used to specify and analyze the behavior of distributed systems andprotocols.

In this short overview, we focus on the language constructs that we need through-out this chapter. The interested reader can refer to [GM14] for a detailed explanationabout this process algebra. We first explain the way data types are defined and usedin mCRL2 (Section 2.2.1). Then, we describe behavioral specifications in the language(Section 2.2.2).

2.2.1 Data Specification

mCRL2 offers ways to specify data types (also known as sorts) and use their elements inspecifications. Standard data types such as natural numbers (N) and booleans (B) arepredefined in the language. Common operations on these data types are also available(e.g., ≈ denotes equality for N and B).

Besides the standard data types, the user can define new data types in a specifica-tion. One way to declare a new data type is to explicitly characterize its elements in a

15


structured data type. For instance, we can define a structured sort called Color with theelements Red, Green, and Blue as follows:

sort Color = struct Red | Green | Blue;

It is also possible to declare structured types that depend on other data types. For in-stance, a data type called Message that contains pairs of natural numbers can be definedas follows:

sort Message = struct Pair(fst:N, snd:N);

Elements of Message have the shape Pair(n1, n2) where n1, n2 ∈ N. The declaration ofMessage provides two projection functions, namely, fst and snd. These functions canextract the elements of Pair(n1, n2):

fst(Pair(n1, n2)) = n1 snd(Pair(n1, n2)) = n2

Functions can also be declared and used in the mCRL2 language. Given two datatypes A and B, the notation A→ B denotes the sort of functions from A to B. The mCRL2language includes a specific operator called function update for unary functions. For afunction f ∈ A→ B this operation is denoted by f [a → b]. The notation represents afunction that maps a to b and maps all the other elements of A like f does.

We can declare the sort of functions from N to N as follows:

sort NatFunc = N→ N;

We consider two examples of this sort:

• succ: given n ∈ N returns n+ 1;

• condsqr: given n ∈ N returns n2 when n> 10; otherwise, it returns n.

We declare these functions using the map keyword:

map succ, condsqr : NatFunc;

To define succ and condsqr, it is necessary to specify how calculations are performedin these functions. This is realized by introducing equations using the keyword eqn.Variables that are used in the equations are declared by the keyword var.

var n : N;eqn succ(n) = n+ 1;

condsqr(n) = if(n> 10, n2, n);

The conditional operation has the shape if(c, t, u). It evaluates to the term t if the condi-tion c holds and it evaluates to the term u if c does not hold.

Lists are also a built-in data-type in mCRL2. The set of lists where all elements arefrom a sort A are represented by List(A). Elements of List(A) are built with two con-structors: [] the empty list and a . ` which puts a (of type A) in front of list ` (of typeList(A)). A list can be defined explicitly by specifying its elements and putting thembetween square brackets. For example, [22,4] is a list of natural numbers.

16

2.3. Application: a Clinical X-ray Generator

// count(0) // count(1) // count(2) //

reset

jj

Figure 2.2: Behavior of Counter

2.2.2 Process Specification

The mCRL2 language allows us to specify behavior using a small set of primitives andoperators. We use a simple example to describe some basic constructs that can be usedto specify behavior in mCRL2. The example is a modulo 3 counter that starts countingfrom 0 and resets itself when it reaches 3.

In mCRL2, behavior is described in terms of processes. Actions are elementary pro-cesses and they represent observable atomic events. Actions can carry data parameters.In our simple example, count and reset can be considered as actions performed by thecounter. For example, count carries a data parameter to indicate the current number.These actions are declared as follows:

act count : N;reset;

Actions can be combined using different operators to form processes that specify morecomplex behavior. For instance, the non-deterministic choice between process p and q isdenoted by p+q. The sequential composition of p and q is denoted by p.q. The resultingprocess first performs the behavior of p and then behaves as q. Data values can alsoinfluence the course of actions. Suppose c is a boolean expression. The process c→ p � qbehaves as p if c holds and otherwise it behaves as q. The “else” part of the conditionaloperator can be omitted. If c does not hold in c→ p, deadlock will occur.

The following process expression specifies the modulo 3 counter. The process Countercarries a data parameter to keep track of the current number. The initial behavior isspecified by init, i.e., counting starts from 0.

proc Counter(n:N) = (n< 3)→ count(n).Counter(n+ 1)+ (n≈ 3)→ reset.Counter(0);

init Counter(0);

For any n ≤ 3 exactly one of the conditions n < 3 and n ≈ 3 will evaluate to true. Theprocess performs action count(n) when n< 3 and then behaves as Counter(n+1). Whenn ≈ 3, the process performs action reset and starts counting from 0. Fig. 2.2 depicts thelabeled transition system of the counter.

2.3 Application: a Clinical X-ray Generator

In this section we introduce an industrial control component that we use for reportingour experiences (Section 2.3.1). We also informally describe a DSL for specifying thebehavior of the component (Section 2.3.2).

17


Tube

Pedals

Monitors

(a) Interventional X-ray

Tubes

Pedal Handling

Pedals (User)

X-ray

Request

Condition Evaluators

Input

Actions

(b) Interfaces of Pedal Handling

Figure 2.3: Industrial Study Case

2.3.1 Platform

As indicated in Chapter 1, Philips Healthcare produces interventional X-ray systems (seeFig. 2.3(a)) which are used to perform minimally-invasive medical procedures. Dur-ing a procedure, the surgeon uses the images on the monitors as guidance. Images areconstructed for two projections. The X-ray system of Fig. 2.3(a) consists of two planes:frontal (top-down) and lateral (left-right). These planes can be used separately or to-gether (biplane).

The surgeon can send X-ray requests using the pedals. The interventional system ofFig. 2.3(a) includes a component called Pedal Handling that makes decisions about theamount of X-ray that should be generated in the tube of each plane (Fig. 2.3(b)). Fromeach plane the following types of X-ray can be generated:

• Fluoroscopy: low dose X-ray, for obtaining real-time images;

• SingleShot: high dose X-ray, for capturing a single image;

• Series: high dose X-ray, for recording a series of images.

Pedal Handling also takes into account conditions that should interrupt the X-ray, orthat should prevent the X-ray from starting. Condition Evaluators continuously evaluatethese conditions and notify Pedal Handling when changes occur.

2.3.2 DSL for Pedal Handling

To describe the behavior of Pedal Handling, domain experts mainly focus on the externalinterfaces of the component. Starting from the initial state, they think about input actionsreceived from Pedals and Condition Evaluators. Based on the received input, the compo-nent might change its current state; it also makes a decision about the output X-ray andsends a request to the tubes. This process continues by receiving the next input. Thus,from the domain expert’s point of view the behavior of Pedal Handling can be describedwith alternating sequences of input and output actions.

18

2.4. Abstract Syntax and Semantics of the DSL

To specify the behavior of Pedal Handling, we use a DSL that fits this way of reasoning.We have used Xtext [Xteb] to define the grammar (concrete syntax) of this DSL. Basedon the grammar a parser, an Eclipse-based editor, and a set of Java classes describing theconcepts in the abstract syntax of the language are automatically generated.

Fig. 2.4 depicts a simplified specification in the DSL1. A DSL model starts with declar-ing the input actions that can be received by Pedal Handling (InActions). Afterwards,it declares variables that keep track of the current state of the component (Booleanvariables and Plane variables) and their initial values (Init). Two not-explicitly-declared variables, i.e., OutputType and OutputPlane, determine the output of PedalHandling.

The internal logic of the component is described in terms of Rules. Each rule refersto an input action and consists of a guard and a do clause. The guard describes when theinput action is enabled and the do clause determines how the action influences the stateof the component and the output. A DSL model specifies exactly one rule for each inputaction. Multiple rules for an action are not supported.

Rules of the DSL use very simple constructs for describing behavior. However, theprecise meaning of some constructs is not immediately obvious. For instance, it is notobvious whether evaluating the do clause of an action can be interrupted by receiving anew input action. Since a do clause may contain multiple assignments to a variable, it isalso relevant to determine when a variable assignment takes effect.

In Section 2.4 we identify the main concepts in the DSL (abstract syntax) and givea formalization which clearly specifies the semantics of the language. For instance, oursemantics enforces that do clauses should be interpreted in an atomic way and eachassignment to a variable immediately changes its value such that the previous value isoverwritten.

2.4 Abstract Syntax and Semantics of the DSL

In Section 2.3.2 we informally introduced a DSL and motivated the need for a formalsemantics that describes the meaning of the language constructs. In this section, weidentify the main concepts of the language and give a precise meaning to them by meansof a transformation to a language, namely mCRL2, that has a formal semantics. Thesemantics of the mCRL2 language is defined in [GM14] using Structural OperationalSemantics (SOS) [Plo04].

We use the model from Fig. 2.4 as a running example to describe our transformationto mCRL2. Our choice of mCRL2 is motivated by the expressiveness of the language,the availability of a toolset [Mcr] that supports analysis of behavior, and our previousexperience [KSGK13] with the language and toolset.

We first discuss the required data specifications in Section 2.4.1. Then we use pro-cess expressions to describe the behavior specified by DSL models in Section 2.4.2. InSection 2.4.1 and 2.4.2, we have dedicated separate paragraphs to discuss the conceptsfrom the abstract syntax of the DSL. Bold text at the start of each paragraph indicates thename of the concepts.

1For confidentiality reasons, details have been changed in this example.

19


Figure 2.4: Snapshot of a DSL Model

Finally, in Section 2.4.3 we discuss a few correctness properties that we verify againstDSL models.

2.4.1 Data Specification

Plane, X-Ray Type As mentioned in Section 2.3.1, X-rays can be generated from threeplanes (frontal, lateral, and biplane). We define the data types Plane and XRay to describethe planes and the type of X-ray generated from them.

sort Plane = struct None | FR | LT | BI;XRay = struct Standby | Fluo | SingleShot | Series;

The combination of None and Standby describes a situation in which no X-ray is generatedfrom the planes.

State A DSL model declares a set of boolean and plane variables. The valuation of thesevariables and the two special variables OutputType and OutputPlane determine thestate of the transition system described by the DSL model.

To describe the notion of state in mCRL2, we create two structured data types B (forboolean variables) and P (for plane variables). The structure of these sorts corresponds

20


to the variable declarations of the DSL model. For the model of Fig. 2.4, B and P aredefined as follows:

sort B = struct FRFluoReq | FRFluoOK;P = struct FluoPlane;

To specify the valuations of boolean and plane variables, we declare the following datatypes:

sort BVals = B→ B;PVals = P→ Plane;

Finally, the notion of state can be formalized as follows:

sort PSt = struct St(bs:BVals, ps:PVals, outType:XRay, outPlane:Plane);

The projection functions outType and outPlane extract the values of OutputType andOutputPlane from states.

In a DSL model, the initial values of the boolean and plane variables are specified byInit. We declare bs0 ∈ BVals and ps0 ∈ PVals to specify the initial values in mCRL2. Wealso declare s0 ∈ PSt to describe the initial state.

map bs0 : BVals;ps0 : PVals;s0 : PSt;

eqn bs0(FRFluoReq) = false;bs0(FRFluoOK) = true;ps0(FluoPlane) = None;s0 = St(bs0, ps0, Standby, None);

The initial values of OutputType and OutputPlane cannot be specified by Init in theDSL. It is assumed that initially no X-ray is generated from the planes. Hence, we specifys0 such that:

outType(s0) = Standby outPlane(s0) = None

Guard, Do Clause, Rule A DSL model specifies one rule for each input action. Therule of an input action consists of a guard and a do clause. From Fig. 2.4 one can seethat a guard is a function from states to booleans. A do clause consists of a sequenceof assignments/conditionals that given the current state can change the values of thevariables and produce a new state. We describe guards, do clauses, and rules as follows:

sort Guard = PSt→ B;DCl = List(PSt→ PSt);Rule = struct R(gr:Guard, dc:DCl);

The projection functions gr and dc extract the guard and do clause element of a rule,respectively.

For the DSL model of Fig. 2.4 with 4 rules, we declare the guards, do clauses, andrules gi , di , ri for 1≤ i ≤ 4:

21


map g1, g2, g3, g4 : Guard;d1, d2, d3, d4 : DCl;r1, r2, r3, r4 : Rule;

The calculations of each guard can be described in terms of an equation. For instance,the guard of the first rule of Fig. 2.4 can be defined as follows:

var b : BVals;p : PVals;xr : XRay;pl : Plane;

eqn g1(St(b, p, xr, pl)) = (b(FRFluoReq)≈ false);

To describe do clauses, we specify assignments and conditionals in terms of equations.To explain this, we consider the do clause of the first rule from Fig. 2.4. This do clausecontains four assignments and one conditional.

We describe each assignment as a function that updates one of the components of astate St(b, p, xr, pl). We denote the assignments of the first rule by a1, a2, a3, a4 based ontheir order of appearance:

map a1, a2, a3, a4 : PSt→ PSt;eqn a1(St(b, p, xr, pl)) = St(b[FRFluoReq→ true], p, xr, pl);

a2(St(b, p, xr, pl)) = St(b, p[FluoPlane→ FR], xr, pl);a3(St(b, p, xr, pl)) = St(b, p, Fluo, pl);a4(St(b, p, xr, pl)) = St(b, p, xr, FR);

For example, the first assignment updates the values of boolean variables by settingFRFluoReq to true.

A conditional statement of a do clause is specified by a term of the shape if(c, t, u) inequations. The conditional in the first rule of Fig. 2.4 can be described as follows:

map cond : PSt→ PSt;eqn cond(St(b, p, xr, pl)) = if(b(FRFluoOK), Eval(condthen, St(b, p, xr, pl))

, St(b, p, xr, pl));

In this equation, Eval is a function that evaluates a sequence of assignments/conditionalsand condthen is the “then” part of the conditional (see below).

A do clause is described as a sequence of assignments/conditionals. For example, wedescribe the do clause of the first rule (d1) as a sequence of the assignments a1, a2 andthe conditional cond. The “then” part of a conditional is also specified as a sequence of itscomponents. The “then” part of the conditional in the first rule (condthen) is a sequenceof a3, a4:

map condthen : List(PSt→ PSt);eqn d1 = [a1, a2, cond];

condthen= [a3, a4];

Having sequences of assignments and conditionals, it is also essential to define afunction that applies a sequence of statements to a state and returns the resulting state.The following mCRL2 description defines Eval for this purpose:

22


map Eval : List(PSt→ PSt)× PSt→ PSt;var s : PSt;

f : PSt→ PSt;` : List(PSt→ PSt);

eqn Eval([], s) = s;Eval( f . `, s) = Eval(`, f (s));

The function Eval is defined by specifying its effect on terms of the shape [] and f . `(the constructors of List).

Finally, each rule consists of a guard and a do clause. For example, the first rule fromFig. 2.4 (declared as r1 above) can be defined as follows:

eqn r1 = R(g1, d1);

2.4.2 Process Specification

Action The Pedal Handling component performs two types of actions: input and out-put. A DSL model explicitly declares a set of input actions (from Pedals and ConditionEvaluators) by InActions. Pedal Handling also performs actions output(xr, p) to sendrequests for xr ∈ XRay to p ∈ Plane. This action is not explicitly declared in the DSL.Corresponding to the input actions and the output action we declare actions in mCRL2.For Fig. 2.4 we declare:

act FRFluoOn, FRFluoOff , StartCond, ResetStartCond;output : XRay× Plane;

In Section 2.3.2, we mentioned that domain experts describe the behavior of PedalHandling with alternating sequences of input and output actions. The semantics of theDSL is aligned with this intuition. We specify the semantics of the DSL model of Fig. 2.4in terms of the following processes:

proc PIn(s:PSt) = gr(r1)(s)→ (FRFluoOn.POut(Eval(dc(r1), s)))+ gr(r2)(s)→ (FRFluoOff .POut(Eval(dc(r2), s)))+ gr(r3)(s)→ (StartCond.POut(Eval(dc(r3), s)))+ gr(r4)(s)→ (ResetStartCond.POut(Eval(dc(r4), s)));

POut(s:PSt) = output(outType(s), outPlane(s)).PIn(s);init PIn(s0);

The process PIn describes the behavior of Pedal Handling when the component is readyto receive an input. It carries a data parameter that indicates the current state. Theprocess PIn uses a combination of choices and conditional operators for case distinction.The guards (extracted by gr(ri)) are used as conditions in the conditional operators todetermine enabled actions. Performing an input action updates the state based on thecorresponding do clause (extracted by dc(ri)).

The process POut describes the behavior of Pedal Handling when the component isready to produce an output. In this situation, output is performed and it carries the X-raytype and plane extracted from the current state. Performing the output action does notinfluence the state.

23


The processes PIn and POut enforce alternating execution of the input and outputactions. Do clauses are evaluated by Eval. Thus, new actions cannot be performed beforea do clause is completely evaluated. Moreover, assignments have an immediate effect.

2.4.3 Validating DSL Models

For a safety critical component, it is desired to use DSL models as a single source toautomatically obtain models that enable analysis using various formal techniques.

To facilitate formal analysis and verification, we have automated the transformationfrom the DSL to mCRL2. We have used the mCRL2 toolset to generate the state spacesof DSL models and to verify properties expressed in a variant of the modal µ-calculus[Koz83]. An actual DSL model declares 25 input actions and their effects in terms ofrules. The corresponding state space consists of approximately 45000 states and 350000transitions. We have verified some safety properties against this model, e.g., “deadlock-freedom”, “no X-ray is generated from the planes when there is no request from the user”.A formalization of some safety properties for the DSL model of Fig. 2.4 are included inAppendix A.

The mCRL2 formalization of the semantics can also be used as a reference to imple-ment transformations to formalisms that support other kinds of analysis. In Section 2.5and 2.6 we discuss automated transformations from the DSL to formalisms that enablesimulation and model-based testing, respectively. Fig. 2.5 depicts an overview of thetransformations from the DSL that we discuss throughout this chapter. We have usedXtend [Xtea] to develop these transformations.

Using the DSL semantics as guidance for implementing such transformations does notgive a robust connection between the generated models. However, it helps to avoid ob-vious inconsistencies between them. In Section 2.7, we formally validate the consistencybetween the generated models.

A proposed implementation for Pedal Handling is already available. Thus, at themoment we do not generate implementation code from the DSL.

2.5 Obtaining Simulation Models from DSL Models

In this section we use the semantics of Section 2.4 as a reference to construct a transfor-mation from the DSL to models that enable interactive simulation of behavior. We aimto use models in the parallel object-oriented specification language [The+07] (POOSL)for simulation. Tool support [POO] and our previous experience with the language mo-tivated our choice.

POOSL is a light-weight modeling language and its formal semantics is expressed interms of timed probabilistic labeled transition systems [Bok02]. The tools available forPOOSL allow us to simulate models in the POOSL language and discuss the modeledbehavior with domain experts. To facilitate simulation for specifications in the DSL, it isdesired to have an automated transformation that generates simulation models from DSLmodels.

24

2.5. Obtaining Simulation Models from DSL Models

DSL Model Generate

Generate

Generate

Verification Model

(mCRL2)

Simulation Model

(POOSL)

Test Model

(AML)

Figure 2.5: Generated Artifacts for Pedal Handling

In this section we first provide a brief overview of the POOSL language (Section 2.5.1).Afterwards, we discuss our transformation from the Pedal Handling DSL to simulationmodels in POOSL (Section 2.5.2).

2.5.1 An Overview of POOSL

In this section we discuss a few constructs of the POOSL language; our focus is on thesyntactic constructs that we need for realizing the semantics of Section 2.4 in POOSL.The interested reader can refer to [Bok02] and [POO] for more details about the lan-guage and some instructive examples. Note that understanding the semantics of certainadvanced POOSL features and relating them to the implementations of the tools may notbe trivial. Hence, we have chosen to use a set of basic POOSL features to realize thesemantics of Section 2.4; for this set there is a clear correspondence between the for-mal semantics of [Bok02] and the user experience with the tools. We use the modulo 3counter from Section 2.2 to illustrate this set of constructs from POOSL.

In POOSL behavior is described in terms of process classes. Process classes need to beinstantiated to obtain concrete instances that are executable. Each process class declaresa set of communication ports that are available to its instances for sending/receiving mes-sages. Process classes also define the signature of messages that can be communicatedthrough the declared ports. For instance, Fig. 2.6 depicts a process class called Counterwith two ports, namely, cin and cout. The message declarations indicate that messagescount and reset can be communicated through the ports cout and cin, respectively.The message count carries an integer parameter to indicate the current number.

Message declarations in POOSL also specify the direction of communication, whereasin mCRL2 we do not explicitly define this for actions. The symbols ! (message send) and? (message receive) in POOSL denote the direction of communication for each message.For our simple example, we choose to declare count as a message sent by Counter andreset as a message that can be received by Counter.

Process classes also consist of variables. Variables of a process are only accessibleby the process itself and keep track of data items that are relevant for describing thebehavior of the process. Declaring a variable involves specifying a name and its datatype. The process Counter in Fig. 2.6 declares variable n of type integer; this variable is

25


Figure 2.6: A Modulo 3 Counter in POOSL

used to store the current number.The behavior of a process class is specified in terms of its methods. Each process

has an initial method specified by init. Generally speaking, the behavior defined by amethod is specified by the following syntax:

m(i1:di1,...,ik:dik)(o1:do1,...,om:dom) |l1:dl1,...,ln:dln|S

where ij (for 1≤ j ≤ k), oj (for 1≤ j ≤ m), and lj (for 1≤ j ≤ n) are the input, output,and local parameters of the method, respectively. For each parameter, the correspondingdata type is also specified.

The body of a method (denoted by S in the example above) is composed of differenttypes of statements. In what follows, we discuss a few types of statements that canappear inside a method. Suppose x is a process variable, E is an expression, p is a port,S,S1,S2 are statements, and C is a boolean expression. The statement x:=E evaluatesthe expression E and assigns its value to x. Here we assume that E is a well-definedexpression in terms of process variables, constants from standard data types (such asnatural numbers and booleans), and common operations on these data types (such asaddition for integers); see [Bok02] for a detailed description of POOSL’s data layer andthe syntax of expressions.

The statement p!m denotes a message m being sent to the port p. In POOSL commu-nication is synchronous, i.e., a send statement p!m is blocked until a matching receive

26


Figure 2.7: A Process Specification for Communicating with Instances of Counter

statement q?m can be executed such that the ports p and q are connected via a channel;see the description below about connecting ports with channels.

The basic statements mentioned above can be combined in different ways to obtainmore complex behaviors. The non-deterministic choice between S1 and S2 is denoted bysel S1 or S2 les. The notation S1;S2 denotes the sequential composition of S1 andS2.

The guarded command [C]S evaluates the condition C and only if C evaluates to truethe statement S is allowed to execute. Otherwise, the guarded command blocks. Thestatement if C then S1 else S2 fi results in executing S1 if C evaluates to trueand otherwise it executes the statement S2.

The process specification in Fig. 2.6 declares two methods, namely, initializeand countMethod; instances of Counter initially behave as initialize. The methodinitialize sets n to zero and calls countMethod. A combination of non-deterministicchoices and guarded commands are used for case distinction in countMethod. If n<3holds, the process sends a count message that carries the current number. Afterwards, itincrements the current number by one and calls countMethod to continue the counting.If n==3 holds, the process receives reset and resets the current number to zero. Themethod countMethod is called to restart the counting.

As indicated earlier, sending and receiving messages in POOSL should be performedin a synchronous way. For instance, in our example, cout!count(n) is only executable,if another process is ready to execute a complementary message, e.g., uin?count(X),such that uin is connected to cout via a channel. By synchronizing these two messagesthe value of n is bound to X. Similarly, executing cin?reset require a complementarysend message from another process. To this end, we specify a process class called User(see Fig. 2.7) to exchange messages with Counter.

The behavior of User is described in terms a method called observeMethod. The

27


non-deterministic choice in observeMethod allows instances of the process to receivecount and send reset when the complementary messages are available.

Finally, to obtain an executable model for the modulo 3 counter, we need concreteinstances of Counter and User which are connected via suitable channels. The systemspecification from Fig. 2.8 instantiates the defined process classes and creates two com-munication channels between the instances by connecting their ports. Fig. 2.9 illustratesa sequence diagram obtained by simulating the resulting model; the diagram consists oftwo lifelines (for the instances c and u of the process classes) and depicts the first fivesteps of their communication.

2.5.2 A Transformation from the DSL to POOSL

In this section we describe our transformation scheme for generating POOSL modelsfrom DSL models. Similar to the example model from Section 2.5.1, simulation modelsgenerated from the DSL consist of two process classes:

• DecisionClass: receives the inputs declared in the DSL model and makes deci-sions about the output X-ray based on the rules specified in the DSL model;

• User: sends the inputs declared in the DSL model to DecisionClass and ob-serves the produced outputs.

In Section 2.5.1, we specified a simple process class for observing the behavior performedby instances of Counter. A similar structure can be used to specify the process classUser to observe the behavior described by a given DSL model. Since DecisionClassis specified based on the semantics of the DSL, in this section we focus on the way weobtain this process class from a given DSL model. We use the DSL model from Fig. 2.4 toillustrate the way the domain concepts identified in Section 2.4 are described in POOSL.

Action In our transformation, port and message declarations of DecisionClass arebased on the distinction between the inputs and outputs of Pedal Handling. We declaretwo ports, namely, in (for receiving inputs) and out (for sending outputs); see the portand message declarations of Fig. 2.10 for the DSL model from Fig. 2.4.

Messages that are communicated through the port in correspond to the input actionsdeclared by InActions in a DSL model. For the DSL model from Fig. 2.4 we declare

Figure 2.8: Creating a Communication Channel between Instances of Counter and User

28


c:Counter u:User

count(0)

count(1)

count(2)

reset

count(0)

Figure 2.9: Simulating the Interactions between a Counter and User

Figure 2.10: Declaring Input and Output Messages in POOSL for the Example DSL Model

FRFluoOn,FRFluoOff,StartCond,ResetStartCond as messages that are commu-nicated through the port in; see Fig. 2.10.

As indicated earlier, the output actions of Pedal Handling are not explicitly declaredin the DSL. The process DecisionClass sends Output on the port out to model theoutputs performed by Pedal Handling. In comparison with the mCRL2 formalization ofSection 2.4, we do not use custom data types in POOSL to describe the types of X-ray andthe planes; see the declaration of XRay and Plane in Section 2.4. Since POOSL does notsupport enumerations, we declare Output as an action with two string parameters (seeFig. 2.10); performing Output("Fluo","FR") indicates a request for X-ray type Fluoto plane FR. This restricted way of using string parameters allows us to have models withmessages that are easily understandable for the domain expert.

29


Plane Integer ValueNone 1FR 2LT 3BI 4

X-ray Type Integer ValueStandby 5

Fluo 6SingleShot 7

Series 8

Figure 2.11: Representing Planes and X-ray Types in POOSL

Plane, X-Ray Type In Section 2.4 we defined custom data types to describe the planes(i.e, None, FR, LT, BI) and the X-ray types (i.e., Standby, Fluo, SingleShot, Series). As men-tioned above, for communicating outputs, we use strings to represent these elements inan accessible way for the domain experts. Since in object-oriented languages performingbasic operations on strings, e.g., “equality checking”, often leads to different interpreta-tions such as “checking equality of values” and “checking equality of referenced objects”,we prefer to have a simple way of representing the planes and X-ray types in the internalcomputations of DSL rules. Due to lack of support for enumerations in POOSL, we rep-resent the elements of these two domain concepts by the sets {1,2, 3,4} and {5, 6,7,8},respectively. Fig. 2.11 depicts the mapping we apply for representing the planes andX-ray types.

To represent this mapping in POOSL, we declare an integer variable for each elementdepicted in the tables of Fig. 2.11; see the variable declarations of Fig. 2.12. Thesevariables are initialized based on the defined mapping; the initial values are specified bythe method initialize in Fig. 2.12.

To ensure that the mapping is correctly used, the values of these variables are notchanged by the methods of the process class after initialization.

State As discussed in Section 2.4, the notion of state in the DSL is defined based onthe set of variables declared in a DSL model (boolean and plane variables) and the twonot-explicitly declared output variables (OutputType and OutputPlane). The decla-ration of boolean variables in POOSL corresponds to the boolean variables of the DSLmodel; see the declarations of boolean variables in Fig. 2.12 for the DSL model fromFig. 2.4. Plane variables and the non-explicitly declared output variables (OutputTypeand OutputPlane) are denoted by integer variables in POOSL; see the declarations ofinteger variables in Fig. 2.12 for the DSL model from Fig. 2.4.

The initial values of the boolean and plane variables are specified in the initializemethod and correspond to the initial values described in the DSL model. The output vari-ables are initialized based on the assumption that in the initial state no X-ray is generatedfrom the planes.

Guard, Do Clause, Rule A DSL rule refers to an input action and consists of a guard(specifying when the action is active) and a do clause (specifying the effects of performingthe input action). We describe each rule by a guarded command [C]S where C is theguard of the DSL rule and S describes the do clause. Fig. 2.13 depicts a specification ofthe first rule from Fig. 2.4.

30


Figure 2.12: Declaring State Variables in POOSL for the Example DSL Model

Figure 2.13: Describing a Rule from the Example DSL Model in POOSL

31


Figure 2.14: POOSL Methods for Receiving Inputs and Producing Outputs

32

2.6. Validating the Industrial Implementation by Model-based Testing

The do clause of a DSL rule is a sequence of assignments/conditionals. As discussed inSection 2.5.1, x:=E and if C then S1 else S2 fi are among the statement typesthat can appear in the body of a POOSL method. Thus, we use these constructs tospecify do clauses in POOSL. The do clause of the first rule from Fig. 2.4 is trans-lated to four assignments and one conditional in POOSL; see the statements guardedby [(FRFluoReq==false)] in Fig. 2.13.

We repeat this transformation scheme for all the rules of a DSL model and specify amethod called inputMethod that describes the way input actions are received by PedalHandling. Fig. 2.14 depicts this transformation for the DSL model from Fig. 2.4. The bodyof inputMethod consists of a non-deterministic choice between the guarded commandsthat describe the DSL rules. Note that in Fig. 2.14 we have folded the descriptions of thelast three rules.

Observe that in Fig. 2.14 we have extended the description of Fig. 2.13 for the firstrule of the DSL model. A sequential composition of the do clause and outputMethod isused to show that after computing the effects of the action, Pedal Handling is ready to pro-duce an output. Each folded specification block also consists of a sequential compositionof the corresponding do clause and outputMethod.

The method outputMethod describes the behavior of Pedal Handling when the com-ponent is ready to perform an output action. A combination of non-deterministic choicesand guarded commands are applied to transform the integer values of OutputTypeand OutputPlane into string parameters for the action Output (see the mapping fromFig. 2.11). After performing an output action the method inputMethod is called andthe model can receive the next input.

Similar to the process PIn and POut in the mCRL2 formalization, we use the methodsinputMethod and outputMethod to enforce alternative execution of the input andoutput actions.

2.6 Validating the Industrial Implementation byModel-based Testing

In industry, the implementation is considered to be the most valuable artifact that isproduced for a component. When behavioral models of a component are also available,it is relevant to check whether the implementation complies to the modeled behavior.Validating the compliance of implementations to DSL models adds a level of redundancythat can reveal discrepancies between the developed DSL models and implementations.

We use model-based testing to validate the correctness of an implementation withrespect to a DSL model. Model-based testing uses a model that describes the behavior ofa system under test and enables both automatic generation and execution of test caseson the implementation.

The semantics of the pedal handling DSL is described in terms of labeled transitionsystems and hence we use the theory of input-output conformance (ioco) testing forlabeled transition systems [Tre08] to automatically derive test cases from the behaviordescribed in the DSL and execute them on the implementation.

33


In the ioco theory, correctness of implementations with respect to specifications isexpressed in terms of the binary relation of ioco. The ioco theory provides an algorithmthat derives a set of test cases from a given specification such that executing this set of testcases on an implementation determines whether the specification and implementationare related by the conformance relation.

The model-based testing tool of Axini [Axi] is based on the ioco theory. In this tool,specifications are described using the Axini Modeling Language (AML). In order to facil-itate model-based testing on implementations of the Pedal Handling component, we aimto develop an automated transformation from the DSL to AML (Fig. 2.5).

In this section first we introduce the AML language (Section 2.6.1) and describe ourtransformation from the DSL to AML (Section 2.6.2). Then we discuss about model-based testing of the industrial implementation using the generated models and inter-preting the obtained results (Section 2.6.3). Finally, we discuss some practical remarks(Section 2.6.4).

2.6.1 An Overview of AML

AML is a modeling language that allows the modeler to formally specify the behavior ofa system that communicates with its environment through sending and receiving actions.Symbolic labeled transition systems is the formalism used by Axini for giving semanticsto the language constructs. In what follows, we give a brief overview of the syntax ofAML2; our focus is on the language constructs that we need throughout this chapterfor constructing test models from specifications in the Pedal Handling DSL. We use themodulo 3 counter from Section 2.4 as a running example to discuss the constructs ofAML.

In AML behavior is described in terms of processes. An AML process starts by declar-ing the inputs actions (stimuli) that it can accept and the observable output actions(responses) that it can produce. For instance, the following AML statements declare astimulus (called reset) and a response (called count) for the modulo 3 counter:

stimulus 'reset'response 'count' , 'curr' => :integer

For each action, the direction of communication should be denoted by indicating thekeyword stimulus (input) or response (output). Actions can carry data parameters.For instance, in the example above count carries an integer parameter called curr toindicate the current number.

Action declarations in AML processes are followed by declaring state variables. Statevariables of a process are data items that determine the current state of the process andcan influence the course of actions. AML supports various data types for variables, e.g.,booleans, integer numbers, strings. A variable declaration in AML consists of a name,a data type, and the initial value of the variable. For the modulo 3 counter, we declarean integer variable called n to keep track of the current number. The following AMLstatement declares this variable and initializes it to zero:

2AML is a modeling language designed by Axini and is only available as part of their commercial model-based testing toolset. For confidentiality reasons, we use a modified version of the language in this chapter.

34


var 'n', :integer, 0

Assigning values to state variables and receiving/sending actions are among the basicoperations that can be performed by a process. The following list provides examples ofthese basic operations for the modulo 3 counter:

• update 'n=0': resetting the state variable n to zero;

• receive 'reset': receiving the reset action from the environment;

• send 'count', constraint: 'curr==n': sending the count action to re-port the current number to the environment.

The send example shows that for actions carrying data parameters we can specify aconstraint, which is a boolean expression, to describe the desired values that arecommunicated with the environment.

AML also provides operators that combine the basic operations and allow us to specifymore complex behaviors. Suppose S1,S2 are AML statements. The non-deterministicchoice between S1 and S2 is denoted as follows:

choice {o { S1 }o { S2 }

}

A specification that consist of S1 and S2 with a line break in between describes thesequential composition of S1 and S2.

The values of state variables in a process can also influence the course of actions inthe process. Suppose that S is an AML statement and C is a boolean expression definedin terms of the state variables of a process. The guarded statement guard 'C' S onlyallows the execution of S if the condition C hold. If C evaluates to false, the guardedstatement guard 'C' S will lead to a deadlock.

In Fig. 2.15, we apply the constructs discussed above to specify the modulo 3 counterin AML. Note that the behavioral description is enclosed in a block labeled by ready.This block consists of a non-deterministic choice between two disjoint cases, namely, n<3and n==3. In the first case, count is performed and the current number is incrementedby 1, whereas in the second case reset is performed and n becomes zero. In both cases,the goto statement allows us to repeat the behavior defined in the ready block.

For a given AML model, the toolset of Axini can generate a symbolic labeled transi-tion system that corresponds to the behavior described in the model. Fig. 2.16 depictsthe behavior of Counter in terms a symbolic labeled transition system; to distinguishbetween the guards and assignments, we put the guards between square brackets.

2.6.2 A Transformation from the DSL to AML

In this section we consider the domain concepts identified in Section 2.4 and discuss ourtransformation scheme for generating AML models from models in the Pedal HandlingDSL. We use the DSL model from Fig. 2.4 to describe our transformation.

35


process('Counter') {

stimulus 'reset'response 'count','curr' => :integer

var 'n', :integer, 0

label 'ready'choice {o {

guard 'n<3'send 'count', constraint: 'curr==n'update 'n=n+1'goto 'ready'

}o {

guard 'n==3'receive 'reset'update 'n=0'goto 'ready'

}}

}

Figure 2.15: A Process Specification of the Modulo 3 Counter in AML

��n=n+1

((count(n)

oo[n<3]

oo[n==3]

//reset

//

n=0

vv

Figure 2.16: A Symbolic Labeled Transition System Describing the Behavior of Counter

36


Action For a given DSL model, we declare two types of actions in AML:

• stimuli (input actions), correspond to the actions declared by InActions in theDSL model;

• response (output action), an action carrying two string parameters that indicate anX-ray request for a specific plane.

For instance, for the DSL model from Fig. 2.4, this leads to the following action declara-tions:

stimulus 'FRFluoOn','FRFluoOff','StartCond','ResetStartCond'response 'Output','xraytype'=>:string,'xraychannel' =>:string

When sending the action Output, we can use the parameter names xraytype andxraychannel to specify constraints on the data values that are sent through this ac-tion.

Plane, X-Ray Type In Section 2.4 we used custom data types to describe the planesand X-ray types. Although the non-disclosed parts of AML allow us to define custom datatypes, we have decided to use a limited set of constructs from AML and to represent thesetwo domain concepts with strings.

Strings are a predefined data type in AML. Since AML is not an object-oriented lan-guage, accessing strings by reference is not a relevant issue in the language. All opera-tions on strings directly manipulate the values. Thus, we use:

• "None", "FR", "LT", "BI" to represent the planes;

• "Standby", "Fluo", "SingleShot", "Series" to represent the X-ray types.

State For a given DSL model, the notion of state is defined based on the declaredboolean variables, plane variables, and the two non-explicitly declared output variables(OutputType and OutputPlane). In AML this notion of state is described in termsof booleans (representing the boolean variables of the DSL model) and string variables(representing the plain and output variables of the DSL model).

For the DSL model from Fig. 2.4 with two boolean variables (i.e., FRFluoReq andFRFluoOK) and one plane variable (i.e., FluoPlane), we use the following declarationsin AML (statements preceded by # are comments):

#boolean variablesvar 'FRFluoReq', :boolean, falsevar 'FRFluoOK', :boolean, true

#plane variablesvar 'FluoPlane', :string, "None"

#output variablesvar 'OutputChannel', :string, "None"var 'OutputType', :string, "Standby"

37


The declared variables are also initialized; the initialization of the boolean and plane vari-ables are based on the initial values specified by init in the DSL model (see Fig. 2.4).The initial values of OutputChannel and OutputType are based on the domain as-sumption that initially no X-ray is generated from the planes.

Guard, Do Clause, Rule A DSL model specifies one rule for each input action to indi-cate when the action is executable (i.e., guard of the rule) and the way performing theaction influences the current state (i.e., do clause of the rule). We transform each ruleto a guarded statement guard 'C' S in AML such that C is the guard of the rule and Sdescribes the do clause.

Since do clauses consist of assignments and conditionals, we have to provide trans-formation schemes for these two constructs. Assignments are transformed to updatestatements in AML. A conditional statement if C then S fi from the DSL is trans-formed to a non-deterministic choice with two options as follows:

choice {o { guard 'C' S}o { guard '!C' }

}

The first option allows the execution of S, if C evaluates to true. The second option is aguarded statement with an empty body (i.e., skip) and gets executed if !C holds.

The following AML statements describe the first rule of the DSL example from Fig. 2.4:

guard '(FRFluoReq == false)'receive 'FRFluoOn'update 'FRFluoReq=true' # do clause assignmentupdate 'FluoPlane="FR"' # do clause assignmentchoice { # do clause conditional

o {guard 'FRFluoOK' # then part of conditional

update 'OutputType="Fluo"' # do clause assignmentupdate 'OutputChannel="FR"' # do clause assignment

}o {

guard '!(FRFluoOK)'}

}

The do clause of the first rule from Fig. 2.4 consists of four assignments and one condi-tional statement. As illustrated above, the assignments are transformed to updates andthe conditional statement is described in terms of a choice in AML.

For a given DSL model, we apply this transformation scheme to each rule of the modeland use the obtained AML fragments to construct a process specification that describesthe behavior specified in the DSL model. Fig. 2.17 depicts the process specification thatwe obtain by applying our transformation to the DSL model from Fig. 2.4; we have foldedthe specification blocks of the last three rules.

38


process('DecisionProcess') {stimulus 'FRFluoOn','FRFluoOff','StartCond','ResetStartCond'response 'Output','xraytype'=>:string,'xraychannel' =>:string

#boolean variablesvar 'FRFluoReq', :boolean, falsevar 'FRFluoOK', :boolean, true

#plane variablesvar 'FluoPlane', :string, "None"

#output variablesvar 'OutputChannel', :string, "None"var 'OutputType', :string, "Standby"

label 'ready'choice {o { #Rule 1

guard '(FRFluoReq == false)'receive 'FRFluoOn'update 'FRFluoReq=true' # do clause assignmentupdate 'FluoPlane="FR"' # do clause assignmentchoice { # do clause conditional

o {guard 'FRFluoOK' # then part of conditionalupdate 'OutputType="Fluo"' # do clause assignmentupdate 'OutputChannel="FR"' # do clause assignment

}o {guard '!(FRFluoOK)'

}

# performing output actionsend 'Output', constraint: 'xraytype==OutputType &&

xraychannel==OutputChannel'#return to 'ready'goto 'ready'

}

o { #Rule 2 }o { #Rule 3 }o { #Rule 4 }

}}

Figure 2.17: An AML Process Specification for the Example DSL Model39


abstract output

abstract input

concrete output

concrete input

Test Model

(AML)

Model-based

Testing Tool Adapter Implementation

Figure 2.18: Model-based Testing

In Fig. 2.17 the behavioral specification is enclosed in a block labeled by 'ready'.This block consists of a non-deterministic choice between the rules of the DSL model.The guarded statement inside each option describes a rule and only allows the rule to bechosen if it is active (i.e. the guard evaluates to true).

The first option in the non-deterministic choice describes the first rule from Fig. 2.4.Observe that we have extended the specification of the first rule with two sequential com-positions. This indicates that after evaluating the do clause an output action is performedand then the behavior of the 'ready' block is repeated. The folded blocks also havethese sequential compositions as their last steps. This enforces the alternating executionof the input and output actions as specified by the processes PIn and POut in Section 2.4.

2.6.3 Interpreting the Results of Model-based Testing

Validating the compliance of an implementation to a DSL model by model-based testingrequires extra care to interpret the results correctly. A failed test case shows a discrepancybetween the behavior described by the test model and the behavior implemented in theimplementation. This can have three different reasons:

• a mistake in the transformation from the DSL to the test models;

• a failure in the implementation;

• a modeling mistake in the DSL model, which is cascaded to the test model.

The transformation from the DSL to test models should preserve the semantics of theDSL. A mistake in realizing the semantics may result in failed test cases. In Section 2.7we introduce an approach to gain more confidence in the correctness of the generatedmodels in Fig. 2.5. When there is sufficient confidence in the correctness of test models,a failed test case may indicate a failure of the implementation.

The last item mentioned above is particularly relevant if implementations are notgenerated from the DSL. In such cases, failed test cases could also indicate a mistake inDSL models; the intended behavior is not correctly described in the DSL (and the samemodeling mistakes are cascaded to the test model) but the implementation has correctlyrealized the behavior.

40

2.7. Checking the Correctness of Generated Models through Redundancy

2.6.4 Practical Remarks

Fig. 2.18 depicts the environment we have developed for model-based testing. The toolof Axini uses an on-the-fly algorithm for test case generation and execution. This meansthat in each step of a test case the tool can do one of the following:

• send an input action allowed by the model to the implementation;

• wait for an output from the implementation and check that the produced output isallowed by the model.

The adapter in Fig. 2.18 translates the abstract actions from the model to concretecommands for the implementation and maps the concrete outputs produced by the im-plementation to abstract output actions for the model.

Results In our model-based testing experiments, we encountered failed test cases thatindicated a failure in a not-yet-released implementation which is not generated from theDSL. For example, one of the requirements of Pedal Handling indicates that high-doseX-ray requests have priority over low-dose X-ray requests. A design mistake in realizingthis requirement led to a failed test case. The failed test case was part of an unlikelyscenario where three different pedals must be pressed at the same time.

Model-based testing revealed that certain modeling choices taken in our DSL modelsare implemented differently in the implementation. Unlike stopping Fluo (modeled byFRFluoOff in the example of Fig. 2.4), stopping Series requires performing two actionsin a specific order. The output specified for the first step of stopping Series was differentfrom the output produced by the implementation. This observation led to minor changesin our DSL models.

2.7 Checking the Correctness of Generated Modelsthrough Redundancy

Transformations from a DSL to analysis models allow the user to apply various formaltechniques and reason about DSL models. Analysis models can also be used to assess thecorrectness of other artifacts available for a component (see Section 2.6). However, theresults obtained from analysis models are only valuable if the corresponding transforma-tions correctly realize the semantics of the language.

Developing a transformation from a DSL to a modeling language requires a deepunderstanding of the semantics of the DSL and the target language. Moreover, the trans-formation should not deviate from the semantics of the DSL. Introducing redundancy isa very effective way to reduce the rate of mistakes in such error-prone tasks [BG13].

We introduce redundancy to validate the correctness of the transformations depictedin Fig. 2.5 in two ways: equivalence checking (Section 2.7.1) and model-based testing(Section 2.7.2).

41


Generate

Generate

Generate

Generate

Equivalence Checking

(Section 2.6.1)

Model-based

Testing Against

(Section 2.5)

Model-based Testing Against

(Section 2.6.2)

DSL Model

Verification Model

(mCRL2)

Simulation Model

(POOSL)

Test Model

(AML)Implementation

(mCRL2)

Figure 2.19: Validation of Artifacts

2.7.1 Checking the Behavioral Equivalence between Artifacts

The verification and simulation models in Fig. 2.19 have an underlying labeled transitionsystem. To get confidence in the correctness of simulation models with respect to theformalized semantics (transformation to verification models), we can investigate whetherthe labeled transition systems described by the simulation and verification models arerelated by an equivalence relation, e.g., strong bisimulation. This may require to developtransformations from analysis models to a formalism that enables state space generationand comparison.

We have used the mCRL2 toolset for state space generation and comparison. Toenable state space generation for simulation models, we have used a previously imple-mented transformation3 from POOSL to mCRL2; see Section 2.8 for some observationsregarding this transformation.

When comparing behaviors, the internal steps performed by them are not relevant;we focus on the observable behaviors. Hence, we check whether the state spaces areequivalent modulo branching bisimulation. Fig. 2.19 depicts equivalence checking be-tween mCRL2 and POOSL models and the automated transformation from POOSL tomCRL2 that enables this check.

Results For actual DSL models, the behaviors described in mCRL2 and POOSL wereequivalent modulo branching bisimulation. Models generated from three transforma-tions (DSL to mCRL2, DSL to POOSL, and POOSL to mCRL2) are involved in equiva-lence checking between simulation and verification models. Each transformation is im-plemented by a different person. This reduces the probability of identical mistakes in thetransformations and makes the redundancy introduced by equivalence checking morevaluable.

3The transformation from POOSL to mCRL2 is based on the formal semantics of POOSL represented in[Bok02] and only supports the syntactic constructs discussed in Section 2.5. The transformation is implementedby Arjan J. Mooij.

42

2.8. Experiences with Model Transformations

2.7.2 Model-based Testing of Executable Models

In Section 2.6 we used model-based testing to validate the correctness of an implementa-tion. Executable analysis models can also be treated as black-boxes that interact via theirinterfaces; we can supply inputs to an executable model and observe its output. Thus, ex-ecutable models can be tested against the test model generated from a DSL specificationusing model-based testing. Failed test cases reveal mistakes in the transformations.

In our case study, we have applied model-based testing to POOSL models; see Fig. 2.19.To this end, we have developed the environment of Fig. 2.18 with a dedicated adapterfor POOSL models.

Results We did not encounter any failed test cases in our model-based testing experi-ments against POOSL models. Similar to Section 2.7.1, the transformations to simulationmodels (POOSL) and test models (AML) are implemented by different people. This givesmore confidence that the semantics of the DSL is realized correctly in these models.

2.8 Experiences with Model Transformations

The approach of Fig. 2.19 deploys model transformations to enable the use of multipleformal techniques and to introduce redundant mechanisms for assessing the correctnessof different artifacts with respect to the formalized semantics. This approach relies on twotypes of transformation: transformations from the DSL to a general-purpose modelinglanguage (from the DSL to mCRL2, POOSL, and AML), and transformations betweengeneral-purpose modeling languages (from POOSL to mCRL2). In this section we reporton our experiences with these two types of transformations.

General-purpose modeling languages originate from different disciplines and are ap-plicable to a wide range of problems. For instance, POOSL is designed to be applicable forsimulation and performance analysis, whereas mCRL2 is focused on formal verification.In our experience, making transformations between two general-purpose formalisms isnot a trivial task. There are usually language constructs from the source language thatare difficult or even impossible to translate to the target language.

For example, the data layer of POOSL is object-oriented. Each data class describes itsvariables and methods. Moreover, instances of certain data structures (e.g., strings, lists)are accessed using pointers. On the other hand, mCRL2 is not object-oriented and doesnot support pointers. Hence, transforming data classes or pointers from POOSL wouldrequire complex mechanisms in mCRL2 models which in turn would increase the rate ofmistakes in the transformation.

Similarities between the source and target languages may suggest a direct mappingbetween certain constructs. However, similar constructs in two formalisms may havesubtly different semantics. For instance, one would expect the conditional statementif c then p else q fi of POOSL to be trace equivalent to c → p � q in mCRL2.Based on the formal semantics of POOSL, if c then p else q fi first performs aninternal step (τ transition) to evaluate the condition. Then it behaves as p if c holds

43


and otherwise it behaves as q. However, in mCRL2 no internal action is performed forevaluating c and hence the two conditional statements are not trace equivalent.

As another example, we consider [c]p in POOSL and c→ p in mCRL2. In both cases,the condition c is evaluated without performing an internal step. For both [c]p andc→ p, if the condition evaluates to true, p is executed and hence [true]p and true→ pare trace equivalent. If the condition evaluates to false, a deadlock occurs in c → p,whereas [c]p blocks until c evaluates to true. These examples of similar constructsfrom POOSL and mCRL2 reiterate the importance of formal semantics in transformationsbetween languages.

In the literature, some authors have reported similar experiences about transforma-tions between general-purpose modeling languages. A partial transformation from thehybrid modeling formalism Chi 2.0 [Bee+08] to mCRL2 is proposed in [Sta12]. Theintention is to enable formal verification on models in Chi 2.0. Semantic differencesbetween Chi 2.0 and mCRL2 make the transformation complex and hard to maintain.The generated models are also complex and sometimes difficult to analyze by tools. In[Hoo+08] the authors use a model checker and a theorem prover for verification of UMLdiagrams. Representing the semantics of UML diagrams in these tools and the consistencyof these representations are among the main challenges in this work.

As a general conclusion, it may be stated that a transformation between two general-purpose modeling languages is effective and can be constructed with a reasonable amountof effort, if it does not aim to bridge wide semantic gaps between the source and targetlanguage.

The Pedal Handling DSL is defined for a narrow domain and its semantics is less elab-orate compared with POOSL, mCRL2, and AML. Thus, it requires less effort to constructthe transformations from the DSL to different analysis models.

2.9 Related Work

In [ABE11] the authors prototype the semantics of a DSL called SLCO. The core seman-tics is described in terms of a transformation to an intermediate language called CS.Afterwards, CS models are transformed to labeled transition systems and are inspectedmanually or analyzed by existing tools. During the development of SLCO, the authorshave implemented a number of transformations, including transformations from SLCOto SLCO models with equivalent behaviors. The authors suggest that the prototype se-mantics can be used to compare the underlying labeled transition systems of the sourceand target models.

The B method [AAH05] has been used in [Bod+05] to develop process schedulersbased on specifications in a DSL. The information given by a DSL model is taken intoaccount at several refinement steps in B machines. The authors also introduce a decid-able logic for expressing proof obligations of the refinement steps. This allows them toautomatically prove the refinements.

The mentioned studies focus on validating refinement steps. In contrast, we offervarious formal techniques to assess the semantic correctness of different types of artifacts.

In [Sij+14] a combination of model-based techniques is used to develop a software

44

2.10. Conclusions

bus in a two-phase process. In the first phase, an mCRL2 model of the component iscreated and validated through simulation. After developing the component, the mCRL2model is used for model-based testing of the implementation. In the second phase, dif-ferent properties are verified against the mCRL2 model. The model is improved based onthe results and is used for model-based testing against a second implementation. In com-parison, our approach is centered around domain-specific models and artifacts generatedfrom them.

In [HMW12] the POOSL language is used to create a requirements model and a pre-liminary design model for Pedal Handling. These models are translated to CSP [Ros10]and compared using the refinement checker FDR2 [Ltd10]. In [HMW12] it is assumedthat Pedal Handling consists of an input buffer with certain scheduling rules and a com-ponent that processes the inputs from the buffer to make decisions about X-ray requeststo the tubes. Hence, the scope of the models is wider compared to the work presented inthis chapter. As a result, refinement checking is not always feasible. In contrast, specifi-cations in the Pedal Handling DSL focus on the decision making aspect of the component.This reduces the complexity of the models and makes it feasible to compare behaviors byequivalence checking.

In Section 2.6, we have used model-based testing to validate an implementation of aDSL model. As an alternative, one can use a model learning approach. Model learningtechniques extract an automaton model for an implementation by systematically perform-ing tests on it and observing its behavior [Ang87]. The extracted model can be comparedwith the labeled transition system described by a DSL model.

2.10 Conclusions

A DSL allows us to use models that are naturally aligned with the way domain expertsreason about a software component. Existing tools enable language designers to de-fine DSLs and to construct transformations to implementation code and analysis models.However, the semantic correctness of the generated artifacts is usually overlooked.

To resolve conflicting interpretations of a DSL, we use a formal semantics of the lan-guage. We also propose to have additional mechanisms to validate the correctness of thegenerated artifacts with respect to the semantics of the DSL.

Introducing redundancy for validating the correctness of the generated artifacts re-quires extra effort to develop techniques that enable these checks and to analyze theresults. However, these redundant mechanisms can effectively detect mistakes in theartifacts. Discovering mistakes through redundant mechanisms raises awareness aboutthe potential inconsistencies between transformations from a DSL and induces search forother forms of redundancy to increase the reliability of the generated artifacts.

We have experimented with this approach as preparation for the redesign of a clinicalX-ray generator. We plan to extract models from the existing implementation using modellearning techniques. A learned model can give insight in the implemented behavior, andcan be compared with the labeled transition system described by a DSL model.

45

Chapter 3

Consistency between MultipleDSL Transformations

3.1 Introduction

In the previous chapter we discussed about semantic correctness of transformations froma domain-specific language (DSL). We highlighted the importance of a formal semanticsfor resolving conflicting interpretations of a language and proposed practical solutionsfor validating the correctness of transformations with respect to the formal semantics.In this chapter we argue that certain desired properties of transformations may imposeadditional requirements, besides correct realization of the DSL semantics, for consistencybetween transformations.

As indicated in Chapter 1, the development of a DSL is based on the following sepa-ration of domain content [Voe13]:

• Language, providing an abstraction for describing the variability in a specific classof systems.

• Target platform, providing a technical environment in which the class of systemsmust be run.

• Code generator, transforming a specification expressed in the language into codefor the target platform.

The language component abstracts from the characteristics shared between a set of re-lated systems and is very expressive in describing the variations between the elements ofthis set [Vis08]. The code generator transforms DSL specifications into implementationsthat are executable on the target platform.

Fig. 3.1 illustrates a typical use of DSLs. A system specification is first formalized usinga DSL model, which is afterwards used to generate implementation code. As depictedin Fig. 3.1, the traditional use of DSLs (based on language, target platform, and codegenerator) can be extended with transformations from the DSL to analysis models.

47

Consistency between Multiple DSL Transformations

DSL Model

Implementation Code

Generate

Analysis Model

Generate

Figure 3.1: Domain-Specific Language and Transformations

The development of DSLs usually centers around the grammar of the language and acode generator, possibly extended with transformations to analysis models. Typically, lit-tle attention is given to the formal semantics of the language, and to the implementationdetails introduced by a particular code generator that are also relevant for some of theanalysis models.

In this chapter we focus on the distinction between a formal semantics for a DSL andthe low-level implementation details that are specific to a code generator. We also inves-tigate the impact of these two elements on the consistency between the transformationsfrom a DSL. We propose practical solutions for three questions, and illustrate them on anindustrial DSL. The first two questions were also discussed in Chapter 2. However, wereiterate them in this chapter to highlight their subtle difference with the third question.

1. What is the precise meaning of the language elements?

2. How to validate the correctness of each generated artifact?

3. How to validate the consistency between generated artifacts?

The first question is about the semantics of the DSL: “It is great that DSLs focus ondomain concepts, but what do we model exactly?” In the literature, many approachescan be found for giving a formal semantics to a language [ABE11; Sta+12]. These ap-proaches describe the formalized semantics in terms of mathematical structures or bymeans of a transformation to a language with a formal semantics. In practice, DSLs aretypically designed incrementally, starting with a small set of constructs with a transfor-mation to a programming language (e.g., C++) and extending these components withmore advanced features. As one would anyhow implement a code generator, an im-plicit semantics for the DSL comes for free. However, this implicit semantics becomesincreasingly problematic as the DSL grows; it requires understanding the formal seman-tics of the target programming language, whereas available semantics descriptions forprogramming languages may not match the desired level of rigor. Moreover, the implicitsemantics provided by a code generator is entangled with low-level implementation de-tails and requires the user of the language to understand them. This contradicts thepurpose of using DSLs. To avoid such a low-level and implicit description, we describethe semantics independently of code generators.

48

3.1. Introduction

The second question is about the correctness of each generated artifact: “Generatingimplementation code and analysis models is valuable, but how do we know that theseartifacts are semantically correct?” For a well-established DSL, one can prove the cor-rectness of the transformations. However, this approach is time-consuming and requireshuman ingenuity [Ler09]. On the other hand, young DSLs and their code generators areimproved regularly, and hence it is desired to have lightweight methods that can detectmistakes in the generated artifacts. In this chapter, we describe the use of conformancetesting for validating the semantic correctness of the implementations/analysis modelsgenerated from a DSL.

The third question is about the consistency between generated code and analysismodels: “Generating all kinds of models is useful for analyzing different aspects of aDSL model, but how do we know that the analysis results are valid for the generatedcode?” A DSL is defined in terms of the main concepts from its respective domain. By ab-stracting from implementation details, DSL models can provide condense descriptions fora set of related systems. A code generator for a DSL should realize the semantics of thelanguage and produce implementations that are executable on the target platform. Codegenerators bridge the gap between abstract DSL models and executable implementationsby introducing certain implementation details. Such details are bound to a specific codegenerator but they may influence certain aspects of the generated code, e.g., the run-time performance. If performance analysis models are also generated from the DSL, therelevant implementation details should be considered in these models. As the imple-mentation details are bound to a specific code generator, we do not clutter the formalsemantics with such implementation decisions. We formalize the implementation detailsindependently of the semantics. We use the formalizations to validate the consistencybetween the implementation code and impacted analysis models.

We extensively illustrate this general approach using specific formalizations for anindustrial DSL on collision prevention. We do not aim for a generic semantic model forany DSL, but this specific DSL indicates the potential of a modular semantics to facilitatereuse among DSLs.

Structure of this chapter Our approach to addressing the questions of Section 3.1is discussed in Section 3.2. In Section 3.3 we introduce an industrial component andinformally describe a DSL for specifying its behavior. The syntax of our industrial DSL isdescribed formally in Section 3.4. In Section 3.5 we focus on formalizing the semantics ofthe DSL in a modular way. In Section 3.6 we formally describe the implementation detailsintroduced by a code generator and their impact on the computations performed in aDSL model. Section 3.5 and 3.6 form the basis of the conformance testing as discussedin Section 3.7. In Section 3.8 and 3.9 we provide details about the way we applied ourapproach in practice and the results obtained from the formalization and testing. InSection 3.10 we argue that studying formal semantics in a modular way can improvereusability between languages. In Section 3.11 we discuss related work. Section 3.12contains some concluding remarks and suggestions for future research.

49


3.2 General Approach

Transformations from a DSL to implementation code and analysis models are very valu-able in industrial practice. However, the development of such transformations requiresa deep understanding of the DSL, the target language, and the target platform. More-over, the transformations should correctly realize the semantics of the DSL. As reportedin [BG13], such software engineering tasks are very error-prone, and adding redundancyis an effective way to decrease the rate of mistakes in these tasks. In this section we de-scribe the steps we have taken to address the questions from Section 3.1. In particular,reviewing and testing are the redundant mechanisms that we introduce to validate thegenerated artifacts for a DSL.

3.2.1 Semantics versus Implementation Details

A DSL is defined in terms of the essential concepts in a domain, and it abstracts fromimplementation details. A formal semantics for the DSL gives a precise meaning to thelanguage constructs and it is not concerned with the concrete way that the semantics willbe realized and executed on the target platform. A code generator, on the other hand,is a transformation that realizes the semantics and introduces additional implementationdetails that are specific for a target platform.

Such implementation details include implementation decisions (such as internal in-terfaces within the software design, internal data structures, and computation strategies),but they can also follow directly from the target platform (such as the used frameworksand technical details of the prescribed interfaces). In addition, there may be all kinds oftarget language specifics, coding standards, monitoring facilities, etc. Such implementa-tion details are needed, but they clutter the view on the core semantics; so we prefer aformal semantics independent of code generators.

Some implementation details, however, have a major impact on certain aspects of thegenerated code, such as the run-time performance. Since generated analysis models areused to study various aspects of the generated code, they should be aligned with boththe semantics and the relevant implementation details. In our approach, we explicitlydistinguish between the semantics and some of the relevant implementation details ofthe generated code. We formalize them separately, and use them to check the consistencyof the various generated artifacts.

Formalizing the semantics and the implementation details typically triggers discus-sions among the language designers and the developers of the model transformations.As a result, the developers have to review the choices they have made and make theirassumptions explicit. This reviewing mechanism adds a level of redundancy; it can re-veal subtle differences in interpretation of the semantics and the implementation detailsthat could otherwise remain undetected. It may also be useful for end users to be awareof some implementation details, for example, because slightly rewriting a DSL modelmay have an impact on the run-time performance, whereas the performed functionalityremains unchanged with respect to the semantics.

50

3.2. General Approach

DSL Model

Implementation Code

Performance

Analysis ModelGenerate

Generate

(Section 3.7.4)

Generate

Execute Against

Execute Against

Execute Against

Test Cases Based on

Semantics

(Section 3.7.2)

Test Cases Based on

Implementation Details

(Section 3.7.2)

Generate

Generate

Generate

(Section 3.7.4)

Description of


(Section 3.6)

Semantics

(Section 3.5)

Figure 3.2: Overview of the Approach

3.2.2 Conformance Testing

Model transformations generate artifacts that are typically expressed in different mod-eling and programming languages. We consider generated artifacts that are executable,and treat them as black-boxes that interact with their environment via their external in-terfaces. To validate their consistency, we use conformance testing. Testing adds a levelof redundancy to the approach of Fig. 3.1 and it can detect inconsistencies between theartifacts.

To apply conformance testing, we need to define a formal relation between DSL mod-els and generated artifacts. We follow the approach taken by several testing theories[Gau95; Tre08]. We abstract from the internal structure of the generated artifacts, andassume that the behavior of each generated artifact can be described by a formal model.This assumption is called the testing hypothesis. The use of the testing hypothesis onlysuggests the existence of a model in a particular formalism and does not imply that theformal model of an artifact is known.

Overview of the Approach Our approach for validating the consistency of the gener-ated artifacts is based on the following steps:

1. formalize the semantics of the DSL (Section 3.5) and the relevant implementationdetails (Section 3.6);

2. define conformance relations based on these formalizations (Section 3.7.2);

51



CArm

Table

Detector

(b) Geometry

Motors

Safety Layer

Geometric

Models

Sensors

User Interface

Speed

Request

Speed

Request

(c) Interfaces of Safety Layer

Figure 3.3: Industrial Case

3. generate test cases based on the conformance relations (Section 3.7.4);

Fig. 3.2 summarizes these steps for our case study, where the DSL models are used togenerate implementation code and performance analysis models. Our approach givesa better understanding of the semantics of the DSL and formally describes the imple-mentation details that are introduced by the code generator and that are relevant foranalysis models. Moreover, we gain more confidence in the validity and consistency ofthe generated artifacts.

3.3 Application: a Movement Controller

In this section, we describe an industrial component that we use for illustrating ourapproach. First, we briefly describe the target platform (Section 3.3.1). Then, we give aninformal introduction to a DSL that we use for specifying the behavior of the component(Section 3.3.2). Finally, some challenges regarding the DSL and its artifacts are discussed(Section 3.3.3).

3.3.1 Platform

Fig. 3.3(a) depicts an interventional X-ray scanner produced by Philips Healthcare. Thesesystems consist of several moving objects as sketched in Fig. 3.3(b). For example, theTable can be moved horizontally, the Detector can be moved vertically, and the CArm canbe rotated around its center.

The software architecture of these systems includes a dedicated Safety Layer to pre-vent collisions between these heavy objects; Fig. 3.3(c) contains a simplified descriptionof the architecture. User speed requests for object movements should pass the SafetyLayer. The Safety Layer receives the sensor data as so-called ‘geometric models’, whichstore the shortest distance between each pair of objects. These values are computed basedon the static shapes of the objects that form the X-ray scanner and the rotation/transla-tion movements detected by the sensors. The distance values stored in geometric modelsare used in the Safety Layer for making decisions about user requests and determiningthe speed requests that should be applied to the motors.

52

3.3. Application: a Movement Controller

3.3.2 DSL for Collision Prevention

In collaboration with Philips Healthcare, we have developed a DSL [MHA14] to describethe behavior of the Safety Layer. Since in the Safety Layer we are dealing with movingobjects that have complex shapes, an obvious approach for designing such a DSL wouldbe to rely on ideas from computer games and animation for detecting intersecting ob-jects. Such approaches [MW88; Ber97] typically consider concrete geometries in theirreasoning and calculate object intersections based on different types of approximation forthe shapes of the objects, e.g., considering bounding boxes around the objects, triangula-tion. On the other hand, one of the primary goals of the collision prevention DSL was tohave a level of abstraction for specifying behavior that is accessible for domain experts.Hence, the designed language abstracts away from the complexities of the geometry andprovides a simple way to describe collision prevention rules.

Fig. 3.4 depicts a specification in the collision prevention DSL1. A DSL model startswith declaring the physical objects in the system. For instance, the object declarationsin Fig. 3.4 corresponds to the system depicted in Fig. 3.3(b) with three objects, namely,Table, CArm, and Detector. The shapes of the objects are not specified in the DSL. A DSLmodel also declares the geometric models that store the distance between each pair ofobjects. For example, the declarations of Fig. 3.4 imply that distance values are storedin models with the names Actuals and LookAhead. Each geometric model is associatedwith one of the following types:

• predefined: stores the shortest distance between each pair of objects, as given bythe sensors;

• user-dependent: stores predicted shortest distance between each pair of objects;predicted distance values describe a possible future state of the objects based onthe current distance values and user request.

In Fig. 3.4 Actuals is a predefined geometric model and LookAhead is a user-dependentgeometric model. A DSL model may declare multiple models of each type. Details of thecomputations performed to obtain the predicted values in a user-dependent model arenot described in the DSL.

The behavior of the Safety Layer is described in terms of restrictions in the DSL.Each restriction has a name and consists of an activation condition, a deactivation con-dition, and a set of effects. The example of Fig. 3.4 consists of two restrictions, namely,ApproachingTableAndCArm and ApproachingTableAndDetector. As a syntacticshorthand, the activation or deactivation conditions can be omitted from a restriction; insuch cases the omitted condition is assumed to be true.

The activation and deactivation conditions of a restriction specify when the restric-tion is active. The effects of a restriction describe speed limitations for specific objectmovements and are only applicable when the restriction is active.

1For confidentiality reasons, numbers and details have been changed in this example.

53



3.3.3 Challenge

By giving several demonstrations of this DSL, we have observed that most of its featuresare understood quickly. Some advanced features (such as when both the activation anddeactivation conditions hold; see Section 3.5.3), however, always need quite a bit ofexplanation. Detailed discussions about the DSL have revealed that some features can beinterpreted in subtly different ways. These observations motivate the need for a precisedescription of the DSL semantics.

For this collision prevention DSL, we have developed multiple model transforma-tions, namely, for early validation (such as verification of safety properties [KMM13]and performance analysis [Ber+13]), and the generation and run-time monitoring ofimplementation code [MHA13]. Although generating implementation code was valuablein practice and analysis models were useful for reasoning about DSL models, we weregetting increasingly concerned about how to determine that the corresponding transfor-mations are consistent.

In this chapter we focus on the following two artifacts generated from the collisionprevention DSL:

• source code [MHA13] in the general-purpose programming language C++;

• analysis model for performance [Ber+13] in the parallel object-oriented specifica-tion language (POOSL) [POO; The+07];

54

3.4. Syntax

The implementation code implements the full semantics of the DSL, whereas the POOSLmodel only considers the parts relevant for performance. In particular, the POOSL modelfocuses on computing time-consuming operations and does not actually compute speedrequests that should be applied to the motors.

From a functional point-of-view, the geometric models store the (actual/predicted)shortest distances between each pair of objects. Fig. 3.4 illustrates that activation condi-tions, deactivation conditions, and effects can refer to the distance values stored in thegeometric models. As mentioned in [Ber+13], computing these distance values are by farthe most time-consuming operations in a DSL model. The code generator from [MHA13]aims to reduce the number of performed distance queries in the generated implemen-tations while still adhering to the semantics of the DSL. Informally, the code generatorintroduces the following implementation details in the generated code:

D1 the activation and deactivation conditions are evaluated from left to right usinglazy evaluation.

D2 the effects of a restriction are only computed if the restriction is active.

These implementation details are specific to the code generator of [MHA13]. Thus, wedo not consider them as part of the semantics of the DSL. However, D1 and D2 arerelevant for the generated performance analysis models. Additionally, it may also beuseful for end users to be aware of some of these implementation details, for example,because rewriting a DSL model in a different way may have an impact on the run-timeperformance, although the performed functionality remains the same. For instance, aconsequence of D1 is that swapping the two operands of a conjunction or disjunctionmay influence the performance.

3.4 Syntax

A DSL model describes the behavior of a component in terms of concepts that are es-sential in its respective domain. As a first step in understanding such a model, we focuson its underlying syntax. This is common practice when developing DSLs. Studying thesyntax of a DSL gives us consensus about the level of abstraction in DSL models, thefundamental concepts of the domain, and the relationships between them.

In this section we first introduce the domain concepts that appear in the abstractsyntax of the collision prevention DSL and that are essential for describing the internallogic of the Safety Layer. For each domain concept, we refer to the example of Fig. 3.4to show its concrete representation in the language. At some places we provide parts ofthe grammar. After introducing the domain concepts, we describe the structure of a DSLmodel.

Object, Geometric Model A DSL model starts with declaring a set of objects and aset of geometric models; see the objects and geometric models declared by object andmodel in Fig. 3.4. We use the following notations in our formalization:

• Obj, the set of declared objects;

55


• Modp, the set of predefined geometric models;

• Modu, the set of user-dependent geometric model.

We denote the set of all geometric models by Mod = Modp ∪Modu. For example, forthe DSL model of Fig. 3.4 we have Obj = {Table, CArm, Detector}, Modp = {Actuals},Modu = {LookAhead}, and Mod= {Actuals, LookAhead}.

Each geometric model mod ∈ Mod consists of the distances between each pair of ob-jects. In the DSL syntax, Distance[mod](obj1, obj2) denotes the distance between objectsobj1 and obj2 stored in geometric model mod.

For a given DSL model, we assume Obj, Modp, Modu, and Mod as context and do notmention them as subscripts in the rest of the formalization.

Expression, Condition In the DSL syntax, expressions and conditions are defined bythe following grammars:

E ::= rn | Distance[mod](obj1, obj2) | E arithop E | unaryop E. (3.1)

C ::= false | true | ¬C | C ∨ C | C ∧ C | E compop E. (3.2)

where arithop ∈ {+,−,∗,/, mod,b, max, min}, unaryop ∈ {+,−}, compop ∈ {==, ! =,≥,>,≤,<}, and rn ∈ R, mod ∈ Mod, obj1, obj2 ∈ Obj. We use the notations ES and CS todenote the sets of all possible expressions and conditions constructed by grammar (3.1)and (3.2), respectively.

The constant rn in an expression can be annotated by measurement units (e.g., cm,dgps); we assume that all constants are transformed to a default unit and do not considerthis any further.

Effect There are two types of effects, namely, absolute and relative speed limits. Weuse the data type LimType to describe the type of effects:

LimType := {Abs, Rel}

Effects have an impact on a specific object and a specific type of movements, namely,rotation or translation. We use the data type MovType to describe the movement types:

MovType := {Rotation, Translation}

Note that the LimType and MovType are fixed sets that are not specified in the DSL model.The notation Eff denotes the set of all possible effects for Obj and Mod. An effect is a

tuple (lt, om, e) ∈ Eff where:

• lt ∈ LimType is a limit type;

• om ∈ P (Obj×MovType) is a finite set of object movements;

• e ∈ ES is an expression constructed by grammar (3.1).

For a set A, the powerset notation P (A) denotes the set of all subsets of A.

56

3.5. Formalizing the Semantics of the DSL

Restriction From Fig. 3.4, one can see that each restriction consists of three parts. Weuse Restr to denote the set of all possible restrictions for Obj and Mod. A restriction is atuple (act, deact, eff ) ∈ Restr where:

• act ∈ CS is an activation condition constructed by grammar (3.2);

• deact ∈ CS is a deactivation condition constructed by grammar (3.2);

• eff ∈ P (Eff ) is a finite set of effects over the sets Obj and Mod.

Finally, the general structure of a DSL model is as follows:

DSL Model A DSL model is a tuple DM= ⟨Obj, Modp, Modu, R⟩ where:

• Obj is a finite set of objects;

• Modp is a finite set of predefined geometric models;

• Modu is a finite set of user-dependent geometric models;

• R ∈ P (Restr) is a finite set of restrictions over the sets Obj and Mod.

As mentioned above, Mod denotes the set of all geometric models, i.e., Mod = Modp ∪Modu.

3.5 Formalizing the Semantics of the DSL

Studying the syntax of a DSL gives insight into the concepts of the respective domain.In practice, the meaning of the domain concepts used in a DSL is defined implicitly andin terms of a transformation to a programming language. To avoid the complexitiesand ambiguities of such a low-level description, we specify the semantics independentlyof code generators. We also advocate the use of a modular approach for formalizingthe semantics; see the formalized modules in Section 3.5.3 and 3.5.4. Section 3.10contains further discussions in this direction. Additionally, in Section 3.7 we use theformal semantics for validating the semantic correctness of the generated artifacts.

Models in the collision prevention DSL determine how the speed request to the motorsis computed given a speed request from the user and geometric models from the sensors;see Fig. 3.3(c). To understand such a model, we first focus on the external interfaces ofthe component described by the DSL (Section 3.5.1). We also discuss the way two basictypes of constructs, namely, expressions and conditions, are interpreted in the language(Section 3.5.2). Afterwards, we split the semantics of the collision prevention DSL intwo modules. The first module is a symbolic transition system that determines the activerestrictions (Section 3.5.3). The second module is a set of functions that compute theoutput speed requests (Section 3.5.4). Afterwards, we discuss the relation between thesemodules and introduce the notion of trace (Section 3.5.5).

57


3.5.1 External Interfaces

The external interfaces of the Safety Layer in the architecture of Fig. 3.3(c) use twoconcepts: speed request and geometric models. In what follows, we precisely describethe meaning of these domain concepts. We use the set of objects and geometric modelsdeclared in a DSL model to define these concepts.

Each speed request contains for each object and movement type a 3D vector. We usethe data type SpReq to describe speed requests:

SpReq := Obj×MovType → R3

Note that the DSL specifies speed restrictions based on the geometric models only, andhence there is no language construct for speed requests.

In Section 3.4 we discussed geometric models and introduced the syntax for referringto the distance values they contain. We interpret each geometric model mod ∈ Mod as adistance function [[mod]] : Obj×Obj → R+0 such that (for all obj1, obj2 ∈ Obj):

• [[mod]](obj1, obj1) = 0;

• [[mod]](obj1, obj2) = [[mod]](obj2, obj1).

We use Dist to denote the set of distance functions for Obj. As depicted in Fig. 3.3(b), theobjects have shapes. Each distance value refers to the shortest distance between a pairof objects, i.e., the distance between the closest pair of points from these objects. Thetriangle inequality does not apply in terms of the 3D objects, i.e., [[mod]](obj1, obj2) +[[mod]](obj2, obj3) ≥ [[mod]](obj1, obj3) is not necessarily valid for obj1, obj2, obj3 ∈ Objand mod ∈ Mod. By extending this interpretation to the set of geometric models, wedescribe the set Mod as a function of type GeoVal := Mod → Dist, i.e., each geometricmodel in Mod is interpreted as a distance function.

Note that in our interpretation of geometric models we focus on the elements thatare relevant for the Safety Layer, i.e., distance values. On the other hand, to describethe internal computations of geometric models, one would expect to have a functionthat computes current distance values based on the previous state of the objects and theperformed movements. Such a function should naturally satisfy additional properties,e.g., a Lipschitz condition that enforces some requirements on the computed distancevalues after performing a translation or rotation movement.

Communications between the Safety Layer and its interfacing components take placeat fixed intervals of time; see Fig. 3.3(c). Starting from the initial state, in each round ofexecution the Safety Layer collects the current speed requests from the user and geometricmodels from the sensors and computes output speed requests that are sent to the motors;we formalize this notion of execution for the Safety Layer in Section 3.5.5.

3.5.2 Expressions and Conditions

In Section 3.4 we discussed the syntax of expressions and conditions in the collisionprevention DSL; we also introduced their use for specifying effects and restrictions. In

58


what follows, we formalize the semantics of expressions and conditions. This will be abasis for Section 3.5.3 where we discuss the semantics of effects and restrictions.

We interpret an expression e ∈ ES constructed by grammar (3.1) as a function [[e]] :GeoVal → R. This interpretation is defined inductively as follows (g ∈ GeoVal is thecurrent value of geometric models):

• [[rn]](g) = rn

• [[Distance[mod](obj1, obj2)]](g) = g(mod)(obj1, obj2)

• [[e1 arithop e2]](g) = [[e1]](g) arithop [[e2]](g)

• [[unaryop e]](g) = unaryop [[e]](g)

where rn ∈ R, mod ∈ Mod, obj1, obj2 ∈ Obj and e, e1, e2 ∈ ES are expressions constructedby grammar (3.1).

Similarly, we interpret a condition c ∈ CS constructed by grammar (3.2) as a function[[c]] : GeoVal→ Bool. This semantics is defined inductively as follows (g ∈ GeoVal is thecurrent value of geometric models):

• [[false]](g) = false

• [[true]](g) = true

• [[¬c]](g) = ¬[[c]](g)

• [[c1 ∨ c2]](g) = [[c1]](g)∨ [[c2]](g)

• [[c1 ∧ c2]](g) = [[c1]](g)∧ [[c2]](g)

• [[e1 compop e2]](g) = [[e1]](g) compop [[e2]](g)

where c, c1, c2 ∈ CS are conditions constructed by grammar (3.2) and e1, e2 ∈ ES areexpressions constructed by grammar (3.1).

3.5.3 State-based Semantic Module for Determining Active Restric-tions

We start our formalization of the DSL semantics by introducing a semantic module thatdetermines the active restrictions. This module considers only one of the inputs to theSafety Layer, namely, the geometric models. We first consider a single restriction andafterwards extend it to a set of restrictions.

A single restriction r = (actr , deactr , effr) can be in two states: active or passive.Initially, each restriction r is passive. The current state of r depends on its previous stateand the current value of the geometric models. Let p ∈ B be the previous state of r, andg ∈ GeoVal the current geometric models. The current state of r is active if:

• the activation condition evaluates to true (i.e., [[actr]](g)), or

59


// r 7→ fact r ,,

¬act r

��r 7→ t

¬act r ∧ deact r

mm

act r ∨ ¬deact r

��

Figure 3.5: A Symbolic Transition System for R= {r}

• it was active in the previous state and the deactivation condition evaluates to false(i.e., p ∧¬[[deactr]](g))

It follows from the discussion above that if both the activation and the deactivation con-ditions evaluate to true, the current state is active.

Fig. 3.5 illustrates these rules as a symbolic transition system; state labels r 7→ f andr 7→ t denote “r is passive” and “r is active”, respectively. The transition relation can beformalized by the following propositional formula:

CurrActr := actr ∨ (pb∧¬deactr)

where pb symbolically represent the previous state of r. In Fig. 3.5, the initial state isdepicted by an incoming arrow. It is assumed that r is passive in the initial state.

The idea of Fig. 3.5 for one restriction can be extended to the set of restrictions Rin DM = ⟨Obj, Modp, Modu, R⟩. This induces an augmented symbolic transition system.Each state of this transition system is a function of type R → B which describes theactive/passive restrictions. Similar to Fig. 3.5, the initial state is q : R → B such thatq(r) = false for r ∈ R, i.e., independent of the DSL model, we choose all restrictions tobe passive in the initial state. Each transition is defined based on CurrActr for all r ∈ Rand symbolically represents the geometric models values that enable the move from thesource state to the target state.

Fig. 3.6 depicts the symbolic transition system for R= {r1, r2}where r1 = (act1, deact1,eff1) and r2 = (act2, deact2, eff2). Each state is represented by a function that specifies thestate of r1 and r2. Propositional formulas ci for 1 ≤ i ≤ 16 are specified based onCurrActr1

and CurrActr2.

Formally, the set of restrictions R in DM= ⟨Obj, Modp, Modu, R⟩ induces an augmentedsymbolic transition system ASTSR = ⟨Q, q, T ⟩ such that:

• Q := R→ B is the set of states;

• q ∈Q is the initial state and q(r) = false for all r ∈ R;

• T ⊆Q× CS×Q is a transition relation such that:

T = {(q1, c, q2) | c =∧

r∈R

�

�

¬q2(r) ∨ CurrActr[pb := q1(r)]�

∧

�

¬CurrActr[pb := q1(r)] ∨ q2(r)�

�

}

60


where CurrActr[pb := q1(r)] replaces the symbol pb in CurrActr with the state of restric-tion r in the source, i.e., q1(r). Note that condition c is equivalent to

∧

r∈R(q2(r)⇔CurrActr[pb := q1(r)]); we have rewritten c to make it derivable from grammar (3.2).

In the construction of the semantic model, we choose each restriction r ∈ R to bepassive in the initial state. Note that unreachable states and unsatisfiable transitions arenot discarded by this description.

The transition system of DM is deterministic, i.e., the outgoing transitions of eachstate are labeled with disjoint conditions. Moreover, for each state q1 ∈ Q the set Tconsiders all combinations of active restrictions that are conceivable from q1. Thus, foreach q1 and g ∈ GeoVal there is exactly one transition (q1, c, q2) such that [[c]](g) is valid.

3.5.4 Function-based Semantic Module for Computing Output SpeedRequests

Output speed request computation is the second module of the semantics. This moduleconsiders both inputs of the Safety Layer, namely, the geometric models and the speedrequests. In addition, it uses the state of the restrictions determined by the first module.

Speed requests from the user are 3D vectors. To determine the output speed vectors,we first compute the length of the vector that should be applied to the motors. After-wards, we determine the direction and compute the output vector. We first describe theeffect of a single restriction on output computation and afterwards extend it to a set ofrestrictions.

The effects of a restriction r = (actr , deactr , effr) is only considered in output computa-tion when r is active. Thus, we describe the influence of effr in the context of b ∈ B whichdenotes the current state of r. When r is active, effr specifies speed limitations for specificobject movements. The function [[effr]]b : Obj×MovType× LimType× GeoVal → P (R)specifies the active limits of r for each object movement, limit type, and the currentgeometric models value:

[[effr]]b(obj, m,`, g) = {v | b ∧ ∃om ∈ P (Obj×MovType), e ∈ ES.

(`, om, e) ∈ effr ∧ (obj, m) ∈ om ∧ [[e]](g) = v}

When r is active, for each object movement the most restrictive relative and absolutelimits are considered as the effects of r. Formally, we interpret r as a partial function[[r]]b : Obj×MovType× LimType×GeoVal9R such that:

[[r]]b(obj, m,`, g) =min([[effr]]b(obj, m,`, g)) if [[effr]]b(obj, m,`, g) 6= ;

Now we discuss the effects of the set of restrictions R. For each object movement,multiple active restrictions from R can specify absolute and relative limits. The mostrestrictive limits are considered for each object movement, i.e., the minimum of the ab-solute limits and the minimum of the relative limits. Formally, the set of restrictions R isinterpreted in the context of B : R → B, which denotes the current state of the restric-tions. The set R is interpreted as [[R]]B : Obj×MovType× LimType× GeoVal → R. The

61


// r1 7→ fr2 7→ f

c2--

c3

��

c1

��

c4

��

r1 7→ fr2 7→ t

c8

mm

c5

c6

yy

c7

r1 7→ tr2 7→ f

c11--

c9

JJ

c10

QQ

c12

99

r1 7→ tr2 7→ t

c14

mm

c13

TT

c15

MM

c16

__

c1 := ¬act1 ∧¬act2

c2 := ¬act1 ∧ act2

c3 := act1 ∧ act2

c4 := act1 ∧¬act2

c5 := ¬act1 ∧ (act2 ∨¬deact2)c6 := act1 ∧ (¬act2 ∧ deact2)c7 := act1 ∧ (act2 ∨¬deact2)c8 := ¬act1 ∧ (¬act2 ∧ deact2)c9 := (act1 ∨¬deact1)∧¬act2

c10 := (¬act1 ∧ deact1)∧¬act2

c11 := (act1 ∨¬deact1)∧ act2

c12 := (¬act1 ∧ deact1)∧ act2

c13 := (act1 ∨¬deact1)∧ (act2 ∨¬deact2)c14 := (act1 ∨¬deact1)∧ (¬act2 ∧ deact2)c15 := (¬act1 ∧ deact1)∧ (act2 ∨¬deact2)c16 := (¬act1 ∧ deact1)∧ (¬act2 ∧ deact2)

Figure 3.6: A Symbolic Transition System for R= {r1, r2}

62


notation R denotes the two point compactification of real numbers: R= R∪{−∞,+∞}.

[[R]]B(obj, m,`, g) =¨

min{[[r]]B(r)(obj, m,`, g) | r ∈ R} if (∃r ∈ R. (obj, m,`, g) ∈ dom([[r]]b))DefLim (`) if ¬(∃r ∈ R. (obj, m,`, g) ∈ dom([[r]]b))

where dom([[r]]b) extracts the domain of r. If R does not specify a limit, an appropriatedefault value specified by DefLim : LimType→ R is returned, i.e., DefLim (Abs) = +∞ andDefLim (Rel) = 1. An absolute limit specifies a maximum speed that may be requested tothe motors and a relative limit indicates the maximum percentage of the requested speedthat may be applied to the motors. Thus, we choose +∞ and 1 as default values for Absand Rel, respectively.

The effects of R are real numbers, whereas (user/output) speed requests are 3Dvectors. The length of the speed requests to the motors are computed based on themost restrictive absolute and relative limits specified by R. The function [[outSpeedR]]B :Obj×MovType×GeoVal×SpReq→ R describes this computation for the set of restrictionsR in the context of B as follows:

[[outSpeedR]]B(obj, m, g, ur) =min{[[R]]B(obj, m, Abs, g),[[R]]B(obj, m, Rel, g)× norm(ur(obj, m))}

where ur ∈ SpReq is the current speed request from the user and norm : R3 → R isdefined as norm((x , y, z)) =

p

x2 + y2 + z2. In the definition above, “min” refers to thedefinition of the minimum function for R. Since the relative limits and norm of vectorsare real numbers, the computed speed is a real number (not −∞ or +∞).

Now, we can proceed by computing the 3D speed vectors that should be applied tothe motors. We describe this computation by [[outputR]]B : GeoVal× SpReq → SpReq asfollows:

[[outputR]]B(g, ur)(obj, m) =(

ur(obj,m)norm(ur(obj,m))

× [[outSpeedR]]B(obj, m, g, ur) if ur(obj, m) 6= (0,0, 0)

(0, 0,0) otherwise

It follows from the definition that the direction of the output is determined by computinga unit vector from the user request. The norm of the output is determined by the valuecomputed by the DSL model, i.e., outSpeedR.

3.5.5 Semantics of a DSL Model

Finally, the semantics of a DSL model combines two modules: one that determines theactive restrictions and one that computes the output speed requests:

Definition 3.1 (Semantics of a Model). Let DM = ⟨Obj, Modp, Modu, R⟩ be a DSL model.The semantics of DM is the pair (ASTSR, outputR).

63


// B1(g1,ur1,or1) // B2

(g2,ur2,or2) // B3

Figure 3.7: An Example Run for (ASTSR, outputR)

In the following definition, we formalize the notion of execution for a DSL model andshow the way the two modules of the semantics are linked. These definitions are guidedby the manner in which the Safety Layer communicates with its interfacing components(Fig. 3.3(c)). The Safety Layer reads the geometric models and the speed request fromthe user simultaneously at fixed intervals of time, and then produces a speed request tothe motors.

Definition 3.2 (Trace in (ASTSR, outputR)). Let DM = ⟨Obj, Modp, Modu, R⟩ be a DSLmodel, c ∈ CS, g ∈ GeoVal, and ur, or ∈ SpReq. The set of traces for a state p ∈ Q ofASTSR is denoted by TracesI(p) and is the minimal set satisfying:

1. empty trace ε ∈ TracesI(p);

2. non-empty trace (g, ur, or)σ ∈ TracesI(p), if there exists p′ ∈ Q such that [[c]](g)is valid and (p, c, p′) ∈ T , or = [[outputR]]p′(g, ur), and σ ∈ TracesI(p′).

The set of traces for (ASTSR, outputR) is TracesI(DM) = TracesI(q) where q ∈ Q is theinitial state of ASTSR.

Based on the definition of ASTSR (see Section 3.5.3), for a state p ∈Q and g ∈ GeoVal,there is exactly one transition (p, c, p′) such that c(g) is valid. Thus, each non-empty trace(g1, ur1, or1) . . . (gn, urn, orn) corresponds to a unique run q(g1, ur1, or1)q1 . . . qn−1(gn,urn, orn)qn in (ASTSR, outputR). The set of runs for (ASTSR, outputR) is denoted by thenotation RunI(DM). A run registers a sequence of states and tuples of (gi; uri; ori) wheregi is the concrete values of geometric models that enable the transition from qi−1 to qi ,uri is a speed request from the user, and ori is the computed output speed request. Thetrace corresponding to a run does not register the encountered states.

Fig. 3.7 depicts a run of (ASTSR, outputR) where the state labels Bi : R→ B describethe active restrictions in three different states. It is assumed that B1, B2 and B3 are distinctfunctions.

3.6 Formalizing Implementation Details

In Section 3.2.1 we distinguished between the DSL semantics and the implementationdetails introduced by a code generator. We discussed that implementation details arespecific to a code generator but they may be relevant for multiple artifacts generatedfrom the DSL. To have an explicit description of the relevant implementation details, wepropose to specify them independently of the semantics. Moreover, we use the formalizedimplementation details to validate the consistency of the impacted artifacts.

To illustrate the significance of the implementation details, we consider the codegenerator from [MHA13] for the collision prevention DSL. In Section 3.3.3 we discussed

64

3.6. Formalizing Implementation Details

that computing distance values are by far the most time-consuming operations of a DSLmodel. Moreover, we informally described the implementation details introduced bythe code generator for minimizing the number of distance queries. In this section, weformalize the impact of the implementation details on time-consuming operations of aDSL model in terms of two modules. The first module is again the symbolic transitionsystem from Section 3.5.3. The second module is a set of functions that compute the setof distance queries required for evaluating restrictions (Section 3.6.1). Afterwards, wecombine these modules to describe the time-consuming operations of a DSL model, andintroduce the notion of a trace (Section 3.6.2).

3.6.1 Module for Time-Consuming Operations of Restrictions

In this section, we apply the semantics of the DSL and the implementation details de-scribed in D1 and D2 (see Section 3.3.3) to mathematically specify the set of distancequeries required for evaluating the restrictions of a model DM.

The semantics described in Section 3.5 shows that distance queries are required forcomputing:

• the set of active restrictions (i.e., computing the current state of ASTSR as discussedin Section 3.5.3), and

• the effects of active restrictions (i.e., computing [[r]]b for an active restriction asdiscussed in Section 3.5.4)

The speed request from the user does not influence the computation of active restrictionsand their effects. Moreover, [[outputR]]B is computed based on the current state and[[r]]b for all active restrictions r ∈ R and hence no further distance queries are requiredto compute the output speed requests.

We first focus on computing the set of distance queries required for evaluating a givenexpression (e ∈ ES) and condition (c ∈ CS) and then compute the set of distance queriesrequired for evaluating restrictions. In what follows, we use the data type DistQuery todescribe distance queries:

DistQuery := Mod×Obj×Obj

Evaluating Expressions and Conditions

We consider grammar (3.1) for expressions (Section 3.4) and specify ExprQuery : ES→P (DistQuery) to calculate the set of distance queries required for evaluating an expres-sion. The computation rules for ExprQuery are as follows:

1. ExprQuery(rn) = ;

2. ExprQuery(Distance[mod](obj1, obj2)) = {(mod, obj1, obj2)}

3. ExprQuery(e1 arithop e2) = ExprQuery(e1)∪ ExprQuery(e2)

4. ExprQuery(unaryop e) = ExprQuery(e)

65


where rn ∈ R, e, e1, e2 ∈ ES, mod ∈Mod, obj1, obj2 ∈ Obj.The production rules of grammar 3.2 (Section 3.4) imply that conditions can also

refer to the distance values of geometric models. The implementation detail described inD1 (Section 3.3.3) is introduced by the code generator to reduce the number of distancequeries required for evaluating conditions. We formalize the impact of D1 using the func-tion CondQuery : CS×GeoVal→P (DistQuery)which given the current value of geometricmodels computes the set of distance queries required for evaluating a condition:

1. CondQuery(false, g) = CondQuery(true, g) = ;

2. CondQuery(¬c, g) = CondQuery(c, g)

3. CondQuery(c1 ∨ c2, g) =

¨

CondQuery(c1, g) if [[c1]](g)CondQuery(c1, g)∪ CondQuery(c2, g) if ¬[[c1]](g)

4. CondQuery(c1 ∧ c2, g) =

¨

CondQuery(c1, g) if ¬[[c1]](g)CondQuery(c1, g)∪ CondQuery(c2, g) if [[c1]](g)

5. CondQuery(e1 compop e2, g) = ExprQuery(e1)∪ ExprQuery(e2)

where c, c1, c2 ∈ CS, g ∈ GeoVal, e1, e2 ∈ ES. Rule 3 and 4 show the effect of D1 on thecomputation of distance queries (i.e., lazy evaluation for c1 ∨ c2 and c1 ∧ c2).

Evaluating Restrictions

Let r = (actr , deactr , effr) ∈ R be a restriction. Evaluating r requires:

• determining the current state of r (evaluating CurrActr based on the previous stateof r and the current geometric models value);

• calculating the effects of r if r is currently active.

In the previous paragraph we formalized the impact of D1 on evaluating conditions.We use this formalization to describe distance queries required for evaluating active re-strictions. Our description should also reflect the impact of D2 on distance computa-tions. The set of distance queries required for evaluating restriction r can be specified by[[Queryr]]ps : GeoVal→P (DistQuery) where ps ∈ B is the previous state of r:

[[Queryr]]ps(g) =

CondQuery(CurrActr[pb := ps], g) ∪ if [[CurrActr[pb := ps]]](g)(⋃

(lt,om,e)∈effrExprQuery(e))

CondQuery(CurrActr[pb := ps], g) if ¬[[CurrActr[pb := ps]]](g)

The definition of Queryr shows that D2 is applied to avoid additional distance queries forpassive restrictions.

66

3.6. Formalizing Implementation Details

Distance computations for r can be extended to the set of restrictions R in a DSLmodel. We describe the set of distance queries required for evaluating R by the function[[QueryR]]PS : GeoVal→ P (DistQuery) where PS : R→ B specifies the previous state ofthe restrictions.

[[QueryR]]PS(g) =⋃

r∈R

[[Queryr]]PS(r)(g)

The function QueryR computes the set of distance queries required for evaluating restric-tions and hence in each state and for each geometric models value duplicate distancequeries are considered only once.

3.6.2 Time-consuming Operations Performed by a DSL Model

The time-consuming operations performed by a DSL model can be described by twomodules: one that determines the active restrictions and one that computes the distancequeries required for evaluating the restrictions:

Definition 3.3 (Distance Queries of a Model). Let DM = ⟨Obj, Modp, Modu, R⟩ be a DSLmodel. The set of distance queries required for realizing the semantics of DM with re-spect to the implementation details D1 and D2 introduced by the code generator can bedescribed by the pair (ASTSR, QueryR).

Definition 3.1 and 3.3 describe two different aspects of DM = ⟨Obj, Modp, Modu, R⟩.The pair (ASTSR, outputR) specifies the relation between the inputs and the computedspeed requests to the motors, whereas (ASTSR, QueryR) specifies the relation between theinputs and the required set of distance queries.

Similar to Definition 3.2, we define the notion of trace for (ASTSR, QueryR) to formal-ize the way the modules ASTSR and QueryR are linked:

Definition 3.4 (Trace in (ASTSR, QueryR)). Let DM = ⟨Obj, Modp, Modu, R⟩ be a DSLmodel, c ∈ CS, g ∈ GeoVal, ur ∈ SpReq, and dq ∈ P (DistQuery). The set of traces fora state p ∈Q of ASTSR is denoted by TracesP(p) and is the minimal set satisfying:

1. empty trace ε ∈ TracesP(p);

2. non-empty trace (g, ur, dq)σ ∈ TracesP(p), if there exists p′ ∈ Q such that [[c]](g)is valid and (p, c, p′) ∈ T , dq= [[QueryR]]p(g), and σ ∈ TracesP(p′).

The set of traces for (ASTSR, QueryR) is TracesP(DM) = TracesP(q) where q ∈ Q is theinitial state of ASTSR.

For each state p ∈ Q of ASTSR and g ∈ GeoVal, there is exactly one transition(p, c, p′) ∈ T such that [[c]](g) is valid (see the definition of ASTSR in Section 3.5.3).Thus, each non-empty trace (g1, ur1, dq1) . . . (gn, urn, dqn) corresponds to a unique runq(g1, ur1, dq1)q1 . . . qn−1(gn, urn, dqn)qn in (ASTSR, QueryR). The set of runs for (ASTSR,QueryR) is denoted by RunP(DM).

Traces from TracesI and TracesP differ in the last element they specify in each step;see Definition 3.2 and 3.4. Traces from TracesI are sequences of (gi , uri , ori) where ori

67


is the output speed request computed for inputs gi , uri in step i. On the other hand,traces from TracesP are sequences of (gi , uri , dqi) where dqi is the set of distance queriesrequired for computing the output request in step i.

3.7 Conformance Testing

In this section we define what it means for a generated implementation/analysis model(see Fig. 3.1) to comply to a DSL model DM. To define conformance relations between thegenerated artifacts and DSL models, we use the approach applied by various model-basedtesting theories. We first introduce a formalism for describing the behavior of artifacts.This formalism is described in Section 3.7.1. In Section 3.7.2 we define the conformanceof an artifact to a DSL model and formalize a notion of consistency between two artifacts.In Section 3.7.3 we use the conformance relations and define the notions of test case andtest case execution for validating the correctness and consistency of the artifacts. Finally,in Section 3.7.4 we address the test selection problem in our testing approach.

In what follows, we refer to finite sequences over a given set A by seq(A) such that:

seq(A) = { f : N9 A | ∃n ∈ N . dom( f ) = {1, . . . , n}}

We write [a, b, c] to denote the sequence {1 7→ a, 2 7→ b, 3 7→ c}.

3.7.1 Testing Hypothesis

In our testing approach, an artifact is treated as a black-box that interacts with its envi-ronment via its interfaces. To define conformance relations between DSL models (formalmodels) and generated artifacts (physical entities), we need objects that describe thebehavior of the artifacts and are suitable for formal reasoning. Similar to several model-based testing approaches [Gau95; Tre08], we assume that the behavior of an artifact canbe described with a particular formalism (testing hypothesis). Testing hypothesis onlyrequires the existence of a formalism for describing the behavior of artifacts and it doesnot imply that the formal model of an artifact is available.

Let Obj be a set of objects and Mod be a set of geometric models. We assume thatany implementation or performance analysis model of the Safety Layer that controls themovements of Obj based on the distance values in Mod can be described as artifact =(STS, compute). In this model, STS= ⟨Q, q, T ⟩ is a symbolic transition system where:

• Q is a set of states;

• q ∈Q is the initial state;

• T ⊆Q× CS×Q is a transition relation.

The function [[compute]]h : GeoVal × SpReq → Output considers the execution historyh ∈ seq(GeoVal) and calculates an output. The output set is Output = SpReq if artifactcomputes speed requests (artifact is an implementation) and Output = P (DistQuery) ifartifact computes sets of distance queries (artifact is a performance analysis model).

68

3.7. Conformance Testing

For Obj and Mod, the set of all formal models for implementations and performancemodels of the Safety Layer are denoted by Imp and Perf, respectively. We assume thatartifacts are deterministic, e.g., for each state, geometric models, and user speed requestan implementation imp ∈ Imp produces exactly one speed request.

For a state p ∈ Q of imp = (STS, compute) ∈ Imp the set of traces is denoted byTracesI(p) and is the minimal set satisfying:

1. empty trace ε ∈ TracesI(p)

2. non-empty trace (g, ur, or)σ ∈ TracesI(p), if there exists p′ ∈ Q such that [[c]](g)is valid and (p, c, p′) ∈ T, or = [[compute]]h(g, ur),σ ∈ TracesI(p′) and h is thesequence of geometric models extracted from (g, ur, or)σ.

The set of traces for imp= (STS, compute) is TracesI(imp) = TracesI(q) where q ∈Q is theinitial state of STS.

The set of traces for a performance model perf ∈ Perf is defined similarly to tracesof imp ∈ Imp. Each non-empty trace (g1, ur1, dq1) . . . (gn, urn, dqn) of perf registers asequence of (gi , uri , dqi) where dqi ∈ P (DistQuery) is the required set of distance queriesin step i. The notation TracesP(perf) denotes the set of traces for perf ∈ Perf.

3.7.2 Conformance Relations

The formalisms of Section 3.7.1 allow us to define formal relations to describe the com-pliance of an artifact to a DSL model. From Section 3.5 and 3.6, one can see that a DSLmodel specifies:

• exactly one output request for any state, geometric models value, and user request.

• exactly one set of distance queries for any state, geometric models value, and userrequest.

In many conformance testing theories, an implementation is considered to be compliantto a specification if for any experiment derived from the specification, the implementationproduces an output that is foreseen by the specification. In other words, the outputproduced by the implementation should belong to the set of outputs allowed by thespecification.

In our setting, specifications (DSL models) compute output speed requests and re-quired distance queries in a deterministic way and hence trace equivalence is a naturalway of describing conformance. Thus, an artifact conforms to a DSL model if there is noway of telling them apart through observation of finite traces of arbitrary length.

Definition 3.5. Let DM= ⟨Obj, Modp, Modu, R⟩ be a DSL model:

1. an artifact described by imp ∈ Imp conforms to DM if and only if TracesI(DM) =TracesI(imp).

2. an artifact described by perf ∈ Perf conforms to DM with respect to the implemen-tation details D1 and D2 if and only if TracesP(DM) = TracesP(perf).

69


Definition 3.5 allows us to validate implementations and performance models withrespect to DSL models. To assess the consistency between an implementation and aperformance model generated from a DSL model, we need to define what it means forthese two artifacts to be consistent.

The formalisms of the testing hypothesis show that implementations and performancemodels differ in their external interfaces, i.e., an implementation computes speed re-quests, whereas a performance model computes sets of required distance queries. How-ever, the implementation also performs distance queries to compute output speed re-quests. Hence, it is possible to create an interface for implementations such that it pro-duces the set of performed distance queries. In other words, with the new interface animplementation can be modeled as imp ∈ Perf, i.e., we can treat the implementation as ablack-box that can be described by (STS, compute) where [[compute]]h : GeoVal×SpReq→P (DistQuery).

In this way, we can relate implementations to DSL models using the second confor-mance relation from Definition 3.5. An implementation (described by imp ∈ Perf) and aperformance model (described by perf ∈ Perf) of DM are consistent (with respect to the se-mantics and implementation details) if and only if the sets TracesP(imp) and TracesP(perf)are equivalent to TracesP(DM).

3.7.3 Test Cases

A test case for an artifact is an experiment where in each step we supply geometric modelsand a user speed request to the artifact and observe its output. Formally speaking, a testcase for artifact ∈ Imp∪Perf is an element of seq(GeoVal×SpReq×Output) where Outputis SpReq or P (DistQuery).

In addition to the notion of test case, we should provide a mechanism for executingtest cases from seq(GeoVal×SpReq×Output) on artifacts such that a suitable verdict (passor fail) is assigned after test case execution. A test case terminates with pass if in eachstep of the test case the output generated by the artifact corresponds to the expectedoutput. On the other hand, any deviation from the expected outputs leads to fail.

Let t ∈ seq(GeoVal × SpReq × Output) be a test case for artifact = (STS, compute).Execution of t on artifact can be described by Exec : (Imp∪ Perf)× seq(GeoVal× SpReq×Output)→ {pass, fail} such that:

Exec((STS, [[compute]]h), t) =

pass if (t = []) ∨(t = [(g1, ur1, o1), . . . , (gn, urn, on)] ∧(∀k.1≤ k ≤ n.[[compute]][g1,...,gk](gk, urk) = ok))

fail otherwise

From Definition 3.5, it follows that to establish the conformance of an artifact to DM,the relevant set of traces (TracesI(DM) for an implementation or TracesP(DM) for a per-formance model) should be executed on the artifact. Similarly, consistency checking be-tween an implementation and performance model for DM requires executing TracesP(DM)on the artifacts.

70

3.7. Conformance Testing

3.7.4 Coverage Criteria

In Section 3.7.3 we discussed about testing conformance of an artifact to a DSL modeland testing consistency between the artifacts by executing test cases from TracesI(DM)and TracesP(DM). Such test cases are sequences of type seq(GeoVal× SpReq× Output);the inputs are chosen from the infinite data types GeoVal and SpReq. Since we cannottest with all traces from TracesI(DM) and TracesP(DM), we use coverage criteria to selecta finite number of test cases based on specific test selection requirements. The intentionis to define test requirements that examine various behaviors of the artifacts and that areexpected to expose faults.

We define coverage criteria in two ways:

• reformulate existing criteria from the literature that are relevant to the modulesASTSR, outputR, and QueryR;

• define new criteria that test certain DSL-specific aspects.

In what follows, we use AT = {I , P} to denote the type of runs/traces. The functionStateDM : (

⋃

j∈AT Traces j(DM))→ (R→ B) is used to compute the current state of ASTSR

after executing a trace t ∈⋃

j∈AT Traces j(DM):

StateDM(t) =

qm if t = (g1, ur1, o1) . . . (gm, urm, om) ∈ Traces j(DM) ∧q(g1, ur1, o1) . . . (gm, urm, om)qm ∈ Runs j(DM)

q if t = ε

As indicated in Section 3.5 and 3.6, each non-empty trace from the sets TracesI(DM) andTracesP(DM) corresponds to a unique run. Hence, StateDM can compute the current stateof ASTSR after executing a trace.

In [AO08] the authors define an exhaustive list of coverage criteria for source code,specifications, etc. These coverage criteria are typically defined based on common math-ematical structures (e.g., transition systems, boolean expressions) and hence they canbe reformulated for different contexts. For instance, for a DSL model DM the symbolictransition system ASTSR is a key element for computing speed requests and required dis-tance queries. One can define a criterion that requires test cases to visit each state p ∈Qof ASTSR. This is related to the idea of node coverage in [AO08]. In what follows, weformulate this for the collision prevention DSL.

Definition 3.6 (Coverage Criterion 1 (CC1)). Let DM = ⟨Obj, Modp, Modu, R⟩ be a DSLmodel and j ∈ AT . A test suite T j ⊆ Traces j(DM) satisfies the criterion CC1 for DM if:

∀p ∈Q ∃[(g1, ur1, o1), . . . , (gn, urn, on)] ∈ T j , 1≤ i ≤ n.

StateDM((g1, ur1, o1), . . . , (gi , uri , oi)) = p

The criterion CC1 does not enforce any requirements on user speed requests; in eachstate arbitrary user requests are considered for each object movement.

As an alternative, we can define coverage criteria based on activation and deactiva-tion conditions of restrictions in a DSL model. As we discussed in Section 3.5 and 3.6,

71


activation and deactivation conditions influence output computations by determining ac-tive restrictions. Thus, test cases that examine different truth assignments of conditionscan potentially cause the artifacts under test to exhibit different behaviors. This can inturn increase the likelihood of detecting mistakes (but still not guaranteeing to find allthe mistakes) in the artifacts. In [AO08] the authors refer to this idea as logic coverage.They also discuss various coverage criteria to capture different possibilities for examiningtruth assignments of boolean expressions.

We follow the terminology used in [AO08] and reformulate a logic coverage criterioncalled “combinatorial coverage” for the collision prevention DSL. We call a conditioncond ∈ CS a clause if it does not contain any logical operators. In other words, clauseshave the shape e1 compop e2. We use the notation Clcond to denote the set of clausesin cond ∈ CS. One way to examine different truth assignments of cond is to enforcetest requirements for clauses in Clcond to evaluate to each possible combination of truthassignments. For instance, we consider the following condition:

Distance[m](o1,o2)<10 && Distance[m](o2,o3)>20

It has two clauses with 4 possible truth assignments and hence combinatorial coveragerequires test cases for examining these 4 truth assignments.

For a DSL model DM = ⟨Obj, Modp, Modu, R⟩, we would like to have test cases forexamining all combinations of truth assignments for the clauses in the activation and de-activation conditions. Thus, we formulate combinatorial coverage at the level of DM. Weuse the notation ClDM =

⋃

r∈R(Clactr∪ Cldeactr

) to denote the set of clauses in the activa-tion and deactivation conditions. The following criterion describes the test requirementsof combinatorial coverage for the conditions of a DSL model. This criterion can be usefulfor validating the computations of QueryR that are based on lazy evaluation of conditions.


∀ f : ClDM→ B ∃[(g1, ur1, o1), . . . , (gn, urn, on)] ∈ T j , 1≤ i ≤ n

∀[[c]] ∈ ClDM. c(gi) = f (c)

Functions f : ClDM → B in Definition 3.7 are used to denote truth assignments ofclauses in ClDM.

In addition to reformulating existing criteria for the DSL, new coverage criteria canalso be formulated in terms of language-specific features. For instance, for the collisionprevention DSL, it is relevant to test the influence of absolute and relative speed limits onoutput speed computations (see the definition of outSpeedR and outputR in Section 3.5).Thus, we would like to have a set of test cases to test whether in each state the mostrestrictive absolute and relative limit determine the output request to the motors. To thisend, we define a criterion to test the artifacts by enforcing two test requirements in eachstate (p ∈Q) for each object (obj ∈ Obj) and movement (m ∈MovType):

• the output speed request should be determined by the relative limit for m of obj;

• the output speed request should be determined by the absolute limit for m of obj.

72

3.8. Practical Remarks

Hence, the specification of this criterion refers to ASTSR and outputR.


∀p ∈Q, obj ∈ Obj, m ∈MovType

∃[(g1, ur1, o1), . . . , (gk, urk, ok)], [(g′1, ur ′1, o′1), . . . , (g ′`, ur ′`, o′`)] ∈ T j

∃1≤ s ≤ k, 1≤ t ≤ ` . [[outSpeedR]]p(obj, m, gs, urs) = [[R]]p(obj, m, Abs, gs) ∧[[outSpeedR]]p(obj, m, g ′t , ur ′t) = [[R]]p(obj, m, Rel, g ′t)× norm(ur ′t(obj, m)) ∧[[R]]p(obj, m, Abs, gs) 6= [[R]]p(obj, m, Rel, g ′t)× norm(ur ′t(obj, m)) ∧p = StateDM((g1, ur1, o1), . . . , (gs, urs, os)) ∧p = StateDM((g

′1, ur ′1, o′1), . . . , (g ′t , ur ′t , o′t))

The formalization of CC3 indicates that for each state p, object obj, and movement mtwo traces are required such that:

• p is visited in step s of the first trace (Line 6) where the output speed for movementm of obj is determined by its absolute limit (Line 3);

• p is visited in step t of the second trace (Line 7) where the output speed for move-ment m of obj is determined by its relative limit (Line 4).

The outputs calculated based on absolute and relative limits for movement m of obj instate p must be different (Line 5).

The criteria from Definition 3.6-3.8 may describe test requirements that cannot besatisfied for certain DSL models. As an example, we consider a DSL model DM suchthat Distance[m](o1,o2)>10,Distance[m](o1,o2)<5 ∈ ClDM. For this model, it isnot possible to satisfy test requirements of CC2 that enforce Distance[m](o1,o2)>10and Distance[m](o1,o2)<5 to evaluate to true. Such test requirements are calledinfeasible. We assume that infeasible test requirements are eliminated in a practical wayin test case generators and do not consider them as part of the definitions of the coveragecriteria.

In this section, we first defined what it means for an artifact to be compliant to a DSLmodel. Afterwards, we formalized a relation to describe the consistency of two artifactsof a DSL model with respect to the semantics of the DSL and a set of relevant implemen-tation details. The notion of test case is also formalized and a mechanism for assigningverdicts (pass or fail) after test case execution is introduced. Various coverage criteriaare formalized to enable effective test case selection from an infinite set of candidate testcases. In Section 3.8 we discuss about applying these ingredients in practice for testingthe artifacts generated from the collision prevention DSL. In Section 3.9 we discuss theresults we have obtained by applying our approach in practice.

3.8 Practical Remarks

In this section we describe the environments that we have created for performing testexperiments on the implementations generated by the code generator from [MHA13]

73


DSL

ComputationsScenarios

Query

Execution

Evaluation Stimulus Delegated Query

End of ExecutionEnd of Evaluation

Figure 3.8: Performance Model for the Safety Layer

(Section 3.8.1) and the performance analysis models of [Ber+13] (Section 3.8.2). Themain challenge is to create a test environment based on the level of abstraction estab-lished in Section 3.7.3. An important decision is the interface that is used for test caseexecution. For our specific case, we see two possible options:

• use a test interface that consumes geometric models, and computes distances fromthem;

• use a test interface that consumes distance values.

We have chosen for the second option, because it simplifies the derivation of the testcases. Moreover, it allows the tests to focus on the required distance values instead of theinternal logic of geometric models which is beyond the scope of the Safety Layer.

Afterwards, we discuss the procedure that we use for generating test cases based onthe test selection criteria (Section 3.8.3). Test data selection from infinite domains isaddressed by symbolically representing the test requirements specified by the coveragecriteria and by using solvers to find concrete values that satisfy these requirements.

3.8.1 Implementation Code of the Safety Layer

Our tests on the implementation code are based on the code generator from [MHA13].In addition, we have developed test stubs for the external interfaces. In particular, wehave developed two test environments to observe:

• the computed speed requests (testing conformance to DSL models);

• the required distance queries (validating consistency with performance models).

In both environments, we have replaced the component in the real system that computesdistance values by a stub that returns the distance values provided by the generatedtest cases. This stub repeatedly provides new input values to the generated code. Foreach environment, we have developed a specific stub that produces the required type ofoutput, i.e., the computed speed requests or the set of performed distance queries.

3.8.2 Performance Model of the Safety Layer

Our tests on the performance analysis model are based on the model generator from[Ber+13]. For a given DSL model, the generated performance model consists of thefollowing components (see Fig. 3.8):

74

3.8. Practical Remarks

• Scenarios: describes a set of execution scenarios;

• DSL Computations: describes the distance queries required for evaluating the re-strictions;

• Query Execution: models the way distance queries are performed in the system.

The component Scenarios contains execution scenarios. Each step of a scenario mimics aninteraction of the Safety Layer with the sensors. In each step, the Scenarios component de-termines the fragments of the DSL model (i.e., clauses from the conditions and the effectexpressions) that need to be evaluated based on some probability distributions. Then, itsends stimuli to DSL Computations to trigger the evaluation of the required fragments.The DSL Computations component receives the stimuli from Scenarios and evaluates thecorresponding clauses/expressions of the DSL model. Required distance queries are del-egated to Query Execution. The component Query Execution consists of subcomponentsthat model the behavior of the cache and a sampling method that estimates the execu-tion time for distance queries that are not available in the cache. In [Ber+13] the authorsperform simulations on this model for different scenarios. Using the obtained executiontimes, they estimate the execution time of the Safety Layer described by the DSL model.

For a given DSL model, the component DSL Computations is generated automaticallyusing a transformation to POOSL and the other components are constructed independentof DSL models. Our approach aims to validate the DSL Computations component of theperformance model. Hence we replace:

• the Query Execution component by a stub that reports the performed queries;

• the Scenarios component by a stub that indicates which fragments of the DSL modelshould be evaluated based on the test cases.

Our approach validates only the set of time-consuming operations described by theperformance models from [Ber+13]. The authors of [Ber+13] have also measured theexecution time of these operations, and compared the performance predictions from theanalysis models with real observations on the implementation code.

3.8.3 Test Case Generation

Let DM= ⟨Obj, Modp, Modu, R⟩ be a DSL model. To generate test cases satisfying a cover-age criterion CC for an artifact described by (STS, compute), we automatically extract:

• outputR (the function module from Section 3.5) if compute : GeoVal × SpReq →SpReq;

• QueryR (the function module from Section 3.6) if compute : GeoVal × SpReq →P (DistQuery).

For actual DSL models, ASTSR contains a large number of transitions. Therefore, we donot explicitly generate ASTSR. For each coverage criterion, the corresponding test casegenerator uses the activation and deactivation conditions of the restrictions to exploreASTSR in an on-the-fly manner.

75


The computations in ASTSR, outputR, and QueryR are influenced by values from theinfinite domains SpReq and Dist. Our test case generation procedures treat data itemsfrom these domains symbolically. For a given coverage criterion CC, we start exploringASTSR from the initial state. In each state, we symbolically build a condition in termsof geometric model values and user speed requests that refer to the requirements of CC.We use a solver to find a satisfiable assignment for the constructed condition. If thecondition is satisfiable, we compute the next state and the expected output. Otherwise,the requirement is not satisfiable. We repeat the same procedure until all requirementsfor CC are satisfied or known to be infeasible. Generating minimal sets of test cases foreach criterion is outside the scope of this article.

Using a state-of-the-art SMT solver, e.g., Z3 [DMB08], as the back-end solver is anoption. However, most SMT solvers provide limited support for solving non-linear ex-pressions. In our realistic DSL models, exponentiation is used to specify smooth brakepatterns. Thus, we have decided to use Mathematica [Wol] as the back-end solver.

3.9 Results

By formalizing the semantics and the relevant implementation details, and by testingthe generated artifacts from [MHA13] and [Ber+13] for a realistic DSL model, we haveencountered five main issues. These give an indication of what can go wrong in modeltransformations. In order to test the artifacts, we have implemented (non-optimized) testcase generators based on the coverage criteria CC1 and CC3. For the considered realisticDSL model (consisting of 5 objects, 6 geometric models, and 9 restrictions), we havegenerated approximately 10, 000 test cases for each artifact based on CC1 and CC3. Testcase generation takes approximately one hour per artifact. Generated test cases wereexecuted in less than 5 minutes.

The discovered issues show that formalizing the semantics and implementation de-tails, and conformance testing based on them, provide effective ways for reasoning aboutthe DSL and validating the generated artifacts. The redundancy introduced by thesemechanisms can reduce the potential for mistakes.

3.9.1 Mathematically Undefined Operations

The syntax of the collision prevention DSL allows arithmetic operations inside conditionsand effects. Some operations may not be mathematically defined, for example, becauseof a division by zero, or a square root of a negative number. Thus we should provide asemantics for interpreting undefined operations. For the collision prevention DSL, thisissue can be encountered with respect to conditions and expressions. We assume thatconditions return the value false for undefined cases, although actual DSL models did notinclude conditions with undefined operations. In the case of effect expressions, we seetwo interpretations:

• “ignore the effect”: this is a general solution. It requires expr in Section 3.5.2 tobe a partial function. In turn, the semantics in Section 3.5.4 should be extended inorder to take the partiality into account;

76

3.9. Results

• “assume the effect to have value 0 for undefined cases”: this is a specific solutionfor the collision prevention DSL which conservatively attempts to stop the objectsaffected by the undefined effect. It only requires a change in the way that elementsof ES are interpreted.

We have defined the semantics for both interpretations. The code generator introducedin [MHA13] uses the second interpretation. In our experiments the test cases based onthe first interpretation fail, whereas the test cases based on the second interpretationpass. This was discovered by test cases satisfying criterion CC1; perhaps random testingcould also identify this difference.

Time consuming operations of a DSL model depend on the distance queries requiredfor determining the state of the restrictions and for evaluating the effect expressions foractive restrictions. Thus, the formalization of Section 3.6.1 is affected by the interpreta-tion of undefined conditions. The two interpretations of expressions (mentioned above)evaluate effect expressions for active restrictions and only differ in the final value theyproduce after evaluation. Hence, the interpretation of undefined expressions does notaffect the formalization of the implementation details.

3.9.2 Semantics of Restrictions

From the example of Fig. 3.4 one can see that a restriction may not specify any effects fora limit type lt ∈ LimType of a movement m ∈ MovType for obj ∈ Obj. The semantics fromSection 3.5.4 resolves limits that are not specified by any r ∈ R in the context of the setof all restrictions R by returning default values specified by DefLim. However, the codegenerator from [MHA13] resolves unspecified limits in the context of a single restrictionr by returning default values from DefLim; hence, restrictions are interpreted as totalfunctions. This makes a difference for certain DSL models.

For instance, let DM= ⟨{obj}, Modp, Modu, {r1, r2}⟩ be a DSL model where:

• r1 = (act1, deact1, eff1) and r2 = (act2, deact2, eff2);

• r1 does not specify a relative limit for rotation of obj;

• r2 has an effect (Rel, om, e) such that (obj, Rot) ∈ om and [[e]](g) > 1 for g ∈GeoVal.

As discussed in Section 3.5, a relative limit specifies the maximum percentage of thelength of the user speed request that may be applied to the motors. The code generatorfrom [MHA13] interprets r1 as a total function that returns 1 (the default value) for theunspecified relative limit for rotation of obj. Since the value 1 is more restrictive than[[e]](g), the relative limit described by DM is 1 for g. On the other hand, the semanticsof Section 3.5.4 interprets r1 as a partial function without any effect on the relative limitand hence [[e]](g) is the relative limit described by DM for g.

Actual DSL models did not include effects above 1 for relative limits. However, wediscovered this mismatch by formalizing the semantics. This issue affects the computa-tion of effect expressions in the restrictions and it is only relevant for the semantics. Onecan also formulate a criterion to detect this mismatch by testing.

77


3.9.3 Computation Accuracies

Some test cases on the implementation fail because of very small differences in the com-puted speed request to the motors. This is due to differences in computation accura-cies between the test case generator and the generated code. To address this issue in apractical way, we have used an acceptance threshold for comparing expected and actualoutputs. We consider the expected and actual speed requests (ex , ey , ez), (ax , ay , az) ∈ R3

for an object to be equal if |ex − ax | ≤ 1 ∧ |ey − ay | ≤ 1 ∧ |ez − az | ≤ 1. This solutionmay not apply when individual rounding errors lead to large propagation errors.

3.9.4 Symmetric Distance Queries

According to the semantics of Section 3.5.1, distance functions are symmetric. In otherwords, replacing the distance query Distance[m](o1,o2)with Distance[m](o2,o1)in a DSL model does not influence the output speed request that is applied to the motors.On the other hand, the formalization of Section 3.6.1 implies that Distance[m](o1,o2)and Distance[m](o2,o1) are distinct distance queries. Thus, although the order ofthe objects in symmetric queries does not influence output speed requests, it can affectthe number of queries that the Safety Layer performs.

We discovered this discrepancy by writing the formalization of Section 3.6. It is use-ful to make such assumptions explicit and to make users aware of their impact. As analternative, we could ensure that the generated artifacts unify such symmetric distancequeries based on some fixed ordering on the objects.

3.9.5 Lazy Evaluation for Conditions

With respect to the implementation detail described in D1, we have discovered a fewissues. While writing the formalization of Section 3.6, we realized that D1 can be in-terpreted in two subtly different ways. D1 could be applied to the individual activation(actr) and deactivation (deactr) conditions, or to the combined condition CurrActr :=actr ∨ (pb∧¬deactr). For the performance, the combined condition can be beneficial dueto the lazy evaluation rule of disjunction, but it turns out that the prototype generatorsfrom [MHA13] and [Ber+13] only apply it to the individual conditions.

By reviewing the implementation of lazy evaluation in the prototype generators from[MHA13] and [Ber+13], we have also noticed that the generator from [Ber+13] forperformance models only considers D1 for conjunctions, which is adequate for the DSLmodels considered. The code generator from [MHA13] considers both conjunctions anddisjunctions.

By providing DSL models that include disjunctions in the activation/deactivation con-ditions, these issues can also be detected by test cases generated based on the coveragecriterion CC2.

78

3.10. Afterthought: Towards a Modular Semantics for DSLs

3.10 Afterthought: Towards a Modular Semantics forDSLs

The formal semantics of a DSL can also be used by language developers as a meansto characterize the main features of the language and their expressiveness. During theformalization of the semantics of the collision prevention DSL, we have observed thatits semantics can naturally be split in two modules, focusing on the state-based andfunction-based aspects, respectively. We formalized the connection of these two aspectsin the definition of trace (see Definition 3.2) where the label of the current state affectsthe output computation. This modularity helped us to consider variants of the languageby changing the way the history of execution affects output computation. In particular,the simpler version of this DSL as discussed in Chapter 4 is stateless, and hence could bedescribed using only a (modified) function-based module.

Although DSLs usually focus on a narrow domain, they typically share some generalsemantic concepts. Ideally, this would enable the reuse of semantic modules (not nec-essarily their syntax). A similar direction is sketched in [Rat+12]. The authors considera set of primary modules with well-defined semantics shared among different DSLs asanalysis DSLs (e.g., expressions language module). Formalizing the semantics of DSLscan facilitate the reusability of more complex semantic modules.

The separation in semantic modules can help us by selecting appropriate analysistools for DSLs with known semantics. Since the function-based aspect is dominant in thecollision prevention DSL, the use of solvers is very effective for various types of analy-sis. For example, in Chapter 4 we consider a variant of the collision prevention DSL anduse solvers for verifying properties such as deadlock freedom against DSL models. Simi-larly, in Section 3.8.3 we have used solvers for generating test cases. Studying semanticsin a modular way has the potential to further reduce the required effort for develop-ing DSLs and their tool infrastructure such as code generators and analysis techniques.In [Rat+12] the authors use analysis tools to perform certain checks on the identifiedprimary modules (e.g., completeness of a set of boolean conditions).

By identifying semantic modules in DSLs, language designers can obtain more insightinto the features of languages. Moreover, reuse of semantic modules together with ap-propriate tool-support for analysis of DSLs can improve the feasibility of DSL approachesin industry.

3.11 Related Work

Various authors have formalized the semantics of DSLs to enable formal verification or tobuild simulators:

• A method for prototyping visual interpreters and debugging facilities for DSLs isproposed in [SW08]. The approach is illustrated by a DSL for Petri net models.They extend the meta model of the language with the concept of configuration anduse QVT (Query/View/Transformation) relations to describe the semantics.

79


• In [Sta+12] the authors formalize the semantics of an industrial DSL. First, theconcrete syntax of the language is projected onto an abstract and compositionallanguage consisting of process terms. Then, structural operational semantics (SOS)[Plo04] is used to assign semantics to the obtained process terms. The SOS rulesare used for state space generation and model validation.

• A translational approach for prototyping the semantics of a DSL named SLCO isstudied in [ABE11]. SLCO is used in a setting with a number of transformations,e.g., to implementation code, or to restricted SLCO models with equivalent ob-servable behavior. The semantics of the DSL is captured by a transformation toan intermediate language called CS. They also introduce a straightforward trans-formation from CS to labeled transition systems. The labeled transition systemsobtained from SLCO models are analyzed by existing tools. The authors suggestthat the correctness of transformations from SLCO to SLCO can be assessed by com-paring the underlying labeled transition systems of the source and target models.

• In [RDV09] the authors propose an approach for formalizing DSLs using Maude.The approach is described using a DSL for production systems. Maude is used todescribe the meta-model of the language and DSL models. The semantics of theDSL is described using rewrite rules. They use the available tools for Maude toperform simulation, reachability analysis, and model checking.

The DSLs studied in the mentioned works provide domain-specific abstractions for tran-sition systems. In contrast, the dominating aspect of the collision prevention DSL is thefunction module. Moreover, we have used the semantics to test the generated artifacts.

For establishing the correctness of generated code for a particular DSL model, also[Voe13] focuses on testing. However, he focuses on manually writing unit tests, either atthe level of the implementation language, or at the level of the DSL.

A testing approach based on formal models in the Prototype Verification System (PVS)[ORS92] is studied in [Dut+15]. The authors have constructed a PVS model for a soft-ware component used for trajectory generation. The model is used to prove theoremsabout the desired behavior of the component and to generate implementation code. Ran-dom testing and input space partitioning is used to generate test cases from the modelfor evaluating the implementation. For each test case, the computations performed inthe implementation is compared against the corresponding symbolic evaluations of theformal model. In contrast, our approach is centered around domain-specific models. Weprovide formalizations for the semantics and the implementation details that are relevantfor multiple transformations. These formalizations are used for assessing the consistencyof the generated artifacts.

Instead of validating the generated artifacts, various authors have proposed to assessthe correctness of transformations using a test set that consists of multiple models in thesource language:

• In [MMJ15], the authors validate transformations from B specifications [AAH05]to C and LLVM [LA04] implementations. First, grammar-based testing is used tocheck whether syntactically correct code is generated for a test set that consists of

80

3.12. Conclusions

various B specifications. Afterwards, test cases are derived from the B specificationsto evaluate the compliance of the generated implementations to their respective Bmodels.

• In [Fio+10], for a model transformation it is tested whether, given source modelssatisfying the precondition, the transformation produces target models satisfyingthe postcondition. It is assumed that the meta-models of the source and targetlanguages, and the precondition and postcondition of the transformation are en-coded in a constructive logic. A set of predefined criteria is used to generate sourcemodels as test data.

Instead of testing the code generator, we test the generated code/analysis model for aparticular DSL model. Our approach can be extended to test the transformations with aset of DSL models that are generated based on certain criteria.

3.12 Conclusions

In Chapter 2 we discussed about the importance of a formal semantics for a DSL andvalidating the semantic correctness of transformations from a language. In particular,we argued that the semantics of a language can be specified by means of a transforma-tion to a language with a formal semantics. Redundant mechanisms were introduced tovalidate different transformations with respect to the defined semantics. In this chapterwe discussed about an alternative way for describing the semantics of a DSL, namely, adescription independent of transformations. Moreover, we studied cases in which certainimplementation details specific to a code generator are also relevant for the consistencybetween the transformations.

Our approach for formalizing and testing the correctness and consistency of DSLtransformations is based on explicitly distinguishing:

• semantics: specific for a DSL, but independent of any code generator;

• implementation details: specific for a particular code generator, and relevant forsome analysis models.

This difference is particularly important in a context where code generators may changeover time, or multiple code generators (for different platforms) are present. A codegenerator may introduce a wide range of implementation details to realize the semanticsof the DSL, e.g., coding standards, internal data structures. We focus on formalizingimplementation details that are relevant for the specific analysis models generated fromthe DSL.

To assess the validity of the DSL transformations in a practical way, we derive testcases for checking:

• compliance of each generated artifact to the semantics of the DSL;

• consistency between the generated artifacts with respect to the relevant implemen-tation details.

81


We have extensively illustrated our general approach on an industrial case study re-garding a DSL for collision prevention. We have made the following observations on thisapplication of our approach:

• Discovery of inconsistencies: the formalization and testing reveals a surprisingnumber of subtle inconsistencies, which were not discovered before. Our approachhelped to detect them, and solve them.

• Selection of analysis tools: the modular semantics explains the effectiveness ofsolvers and state-based analysis techniques for particular parts of this DSL.

In this chapter we have focused on testing the generated code and analysis modelsfor a given DSL model. This could be extended to testing the model transformationsthemselves, based on a test set that consists of several DSL models. This is related tothe idea of compiler testing [BS82] and would be relevant as a regression test whengenerators are optimized or extended.

Introducing DSLs in industrial practice involves a shift in the software developmentprocess. On the one hand, a DSL provides an accessible way for domain experts todescribe their systems using a domain-specific abstraction. On the other hand, devel-oping and maintaining a DSL and its code generators and validating the correctness ofthe generated artifacts requires substantial efforts. Studying the semantics of DSLs in amodular way would enable the language designers to reuse existing modules in differ-ent languages. This can potentially reduce the effort required for developing analysistechniques for DSLs.

82

Chapter 4

Validation of Domain-SpecificModels

4.1 Introduction

In the previous chapters we discussed various techniques to validate the correctness andconsistency of the transformations from a DSL. The results obtained in the two industrialprojects show that these techniques can effectively detect subtle inconsistencies betweenthe transformations from a DSL. On the other hand, due to the scope of these formal ap-proaches, they cannot detect mistakes that are originated in DSL models. If the desiredbehavior is not correctly captured in a DSL model, the same deficiencies will be reflectedin the generated code. The goal of this chapter is to investigate ways to provide fault de-tection at the abstraction level of DSL models. In this way, we avoid cascading modelingmistakes to the generated code.

DSLs typically focus on a limited set of problems and abstract away from the char-acteristics shared between these problems. Languages that focus on a narrow domainusually provide a convenient abstraction for formal analysis; this allows us to refrainfrom developing abstraction techniques that are typically required in the context of pro-gram verification approaches [ADBO10]. Thus, we aim to integrate verification at thelevel of the DSL, i.e., before generating any code.

Validation techniques for DSLs usually focus on basic validation such as syntax check-ing, reference checking, and type checking. Modern implementation technologies such asXtext [Xteb] allow language designers to define a language and automatically generatean editor for it. The editor can be extended with the mentioned basic validations. In thischapter, we consider these basic validation techniques, introduce more advanced kindsof validation, and discuss their integration in the editor of a DSL.

Through our interaction with practitioners from industry, we have identified two im-portant user requirements for the integration of advanced validation in industrial DSLs.These have guided our selection of formal techniques.

The first requirement is to hide the validation techniques from the user of the DSL.

83

Validation of Domain-Specific Models

Verifier &

Debugger

System Specification

Formalize

DSL Model SMT Problem

ResultsReport Fault

LocationImplementation

Generate

SMT Solver

Advanced Validation

SMT Problem

Generator

Respond

System Properties

Formalize Property Patterns Execute

Basic Validator

Report Fault

Location

Figure 4.1: Overview of the Automated Approach

This implies that a push-button technology should be used, such as model checking[CGP99; BK08] or satisfiability checking [Bie+09]. It also implies that we should fa-cilitate the application of these formal techniques and the analysis of their outputs inindustrial practice. To this end, we mechanically generate the validation input from DSLmodels; this input includes both the verification model and the formal properties (gen-erated based on predefined patterns). In addition to validating properties against DSLmodels, we also translate any property violations back to the abstraction level of the DSL.We use an automated debugging technique called delta debugging [ZH02; CZ05; Zel09]to provide pointers to the syntactic constructs that can potentially cause the propertyviolations. The results of the debugging procedure are displayed in the DSL editor.

The second requirement is to provide feedback to the users in a short amount of time(in the order of seconds to minutes). Due to scalability issues, this often rules out modelchecking techniques based on explicit state space exploration, and generic numericalanalysis techniques for hybrid systems [Fre+11]. We aim to use existing tools as theyare, and therefore we refrain from developing ad-hoc abstraction techniques for a specificDSL. We have used Satisfiability Modulo Theories (SMT) [Bar+09; DMB11] solving. SMTsolvers check satisfiability of first order logic formulae with respect to a combination ofbackground theories, e.g., on integer arithmetic. In recent years, SMT solvers have beenextensively applied as an efficient means for program verification [DMB11].

Thus, we propose an integration of three techniques, namely, domain-specific lan-guages, SMT solving, and delta debugging. Fig. 4.1 gives an overview of our approach;we refer to it throughout this chapter. The traditional use of DSLs is depicted at theleft, starting with a system specification which is formalized as a DSL model. The DSLmodel is used for basic validation, and for generating implementation code in C++. Inaddition, we introduce advanced validation by automatically generating a set of SMTproblems that encode verification of some system properties for the DSL model. Finally,the verification results are linked back to the DSL model.

Although the SMT problems are generated from the DSL model, the verification re-

84

4.2. Restricting the Collision Prevention DSL


Motors

Safety Layer

Geometric

Models

Sensors

User Interface

Speed

Request

Speed

Request

(b) Interfaces of Safety Layer

Figure 4.2: Industrial Case

sults do not change the DSL model; so Fig. 4.1 is not a round-trip engineering envi-ronment. Instead, the verification results are displayed in the DSL editor. Automateddebugging is used to determine a potential fault location for a violated property.

We illustrate our approach using the DSL discussed in Chapter 3 for collision preven-tion. As indicated in Chapter 3, the interventional X-ray scanners produced by PhilipsHealthcare consist of various moving objects (see Fig. 4.2(a)). Safety Layer is a com-ponent in the architecture of these systems that controls the movements of these heavyobjects to prevent collision between the objects and humans (see Fig. 4.2(b)). Since cor-rect functioning is vital for the Safety Layer, the collision prevention DSL is an interestingstudy case for advanced validation.

Structure of this chapter In Section 4.2 we discuss a subset of the DSL introduced inChapter 3 and motivate the reasons we restrict models of the Safety Layer to this subset.Subsequently, we describe the types of validation that we apply on the DSL in Section 4.3and 4.4. Automated debugging for determining potential causes of property violationsis presented in Section 4.5, whereas the integration with the DSL editor is reported inSection 4.6. In Section 4.7 we discuss related work. In Section 4.8 we draw someconclusions and suggest directions for future research.

4.2 Restricting the Collision Prevention DSL

In Chapter 3 we discussed a DSL for specifying collision prevention rules and describedits semantics in a modular way. We argued that modular semantics helps us to easilyconsider variants of a language and guides us in tool selection for formal analysis. In thissection we exploit the modular semantics of Chapter 3 to obtain a restricted version of thelanguage. We first motivate the reasons for considering this restricted version of the DSL(Section 4.2.1). Afterwards, we describe the semantics of this variant (Section 4.2.2).

85


4.2.1 Motivation

As discussed in Chapter 3, in the collision prevention DSL the internal logic of the SafetyLayer is described in terms of restrictions. Each restriction is a tuple (actr , deactr , effr)where act is an activation condition, deact is a deactivation condition, and eff specifiesspeed limitations for object movements.

Writing various models for the Safety Layer revealed that actual specifications de-scribe the desired behavior in terms of restrictions of the shape (actr , true, effr), i.e., thedeactivation condition of all restrictions is set to true. Thus, deactivation conditions donot have any significance in actual specifications of the Safety Layer; from a syntacticpoint of view, the language can be simplified by removing deactivation conditions fromrestrictions. Fig. 4.3 depicts a specification in the restricted version of the DSL in whichdeactivation conditions are not supported.

This change motivated us to revisit the semantics of Chapter 3 and evaluate the im-pact of removing deactivation conditions on the language.

As indicated in Chapter 3, the semantics of a DSL model consists of two modules: asymbolic transition system (ASTSR in Definition 3.1) that determines active restrictionsand a function (outputR in Definition 3.1) that considers the current state of restrictionsand computes output speed requests. The symbolic transition system computes the cur-rent state of a restriction r = (actr , deactr , effr) by evaluating the propositional formulaCurrActr := actr ∨ (pb ∧ ¬deactr) for the current geometric models value (g ∈ GeoVal)where pb ∈ B is the previous state of r.

Observe that, if deactr = true, actr determines whether r is active for g ∈ GeoVal. Thehistory of execution (i.e., pb) does not influence the current state of r. Generalizing thisto the set of restrictions in a model implies that active restrictions are calculated directlybased on the current geometric models. Hence, by removing deactivation conditions fromrestrictions, the language becomes stateless; the semantics can be described in terms ofa single module of functions.

Restricting the syntax of restrictions means that the desired behavior of the SafetyLayer can be described in a more condensed way and the semantics becomes easier tounderstand for language users. Moreover, analyzing the behavior of the Safety Layer boilsdown to reasoning about the values computed by the function module.

4.2.2 Semantics

In this section we consider the restricted language introduced in Section 4.2.1 and brieflydiscuss the required modifications of the semantics (see Section 3.5) to accommodate theremoval of deactivation conditions from the syntax.

In the restricted DSL, the current state of a restriction r is determined by actr andoutput speed requests are computed by a function module. To describe the modifiedfunction module, we first specify the effects of a single restriction on output computa-tions. Afterwards, we extend it to the set of restrictions in a DSL model.

Let DM = ⟨Obj, Modp, Modu, R⟩ be a DSL model. A restriction r = (actr , effr) ∈ Rspecifies speed limitations for various movements of the objects. These limitations arespecified by effr and only considered when r is active. We describe the active speed limits

86

4.2. Restricting the Collision Prevention DSL


of r by effr : Obj×MovType× LimType×GeoVal→P (R) as follows:

effr(obj, m,`, g) = {v | [[actr]](g) ∧ ∃om ∈ P (Obj×MovType), e ∈ Expr.

(`, om, e) ∈ effr ∧ (obj, m) ∈ om ∧ [[e]](g) = v}

As opposed to the semantics of Section 3.5, the notion of state is not relevant; given thecurrent geometric models value g ∈ GeoVal, we evaluate actr to determine the activeeffects of r.

After calculating the active limits of r, the most restrictive relative and absolute limitsare considered as the effects of r. The effects of r are described by r : Obj×MovType×LimType×GeoVal9R:

r(obj, m,`, g) =min(effr(obj, m,`, g)) if effr(obj, m,`, g) 6= ;

Similar to the computations for a single restriction, the semantics of the set R shouldbe restricted to the stateless setting. The most restrictive relative and absolute limitsspecified by all r ∈ R are considered as the effects of R. We describe this by R : Obj×MovType× LimType×GeoVal→ R such that:

R(obj, m,`, g) =

¨

min{r(obj, m,`, g) | r ∈ R} if (∃r ∈ R. (obj, m,`, g) ∈ dom(r))DefLim (`) if ¬(∃r ∈ R. (obj, m,`, g) ∈ dom(r))

If the set R does not specify a limit ` for movement m of obj, a default value specified byDefLim is returned by R. In Chapter 3 we defined DefLim(Abs) = +∞ and DefLim(Rel) =1.

87


The most restrictive speed limits computed by R are used to calculate the length of thespeed requests to the motors. The function outSpeedR : Obj×MovType×GeoVal×SpReq→R describes this computation:

outSpeedR(obj, m, g, ur) =min{R(obj, m, Abs, g),

R(obj, m, Rel, g)× norm(ur(obj, m))}

Finally, we compute the speed vectors that are applied to the motors. The directionof the output vectors are determined based on the user request and the length of thevectors are computed based on the speed limits specified by the restrictions. The functionoutputR : GeoVal× SpReq→ SpReq describes the speed requests applied to the motors:

outputR(g, ur)(obj, m) =(

ur(obj,m)norm(ur(obj,m))

× outSpeedR(obj, m, g, ur) if ur(obj, m) 6= (0, 0,0)

(0,0, 0) otherwise

4.3 Basic Validation

As indicated in Chapter 3, we have used Xtext [Xteb] to define the syntax of the collisionprevention DSL. Based on the grammar an Eclipse-based editor is automatically gener-ated. Xtend [Xtea] offers some support to develop basic types of validation for DSLs.We have used these facilities to enable the following types of validation for the collisionprevention DSL:

• validation based on the language:

– parsing: syntactic constructs are in accordance with the DSL grammar;

• validation based on the parse tree:

– referencing: references refer to elements that have been defined;

– type checking: expressions have a well-defined type.

In addition, we have implemented mechanisms to give warnings for syntactically cor-rect fragments that are probably not intended, such as, reference to the distance betweenan object and itself in restrictions.

4.4 Advanced Validation

Our aim is to offer validation that goes beyond the basic validation of Section 4.3. Inthis section we consider properties focusing on collision prevention, which include well-definedness of conditions and expressions, value ranges for speed limits, and absenceof deadlocks. Given any DSL model, verification of these properties are mechanicallyinstantiated to a set of SMT problems in the common SMT-LIB format, which is supportedby various SMT solvers; see SMT Problem Generator in Fig. 4.1.

88

4.4. Advanced Validation

In Section 4.4.1 we focus on individual conditions and expressions and address theirwell-definedness. In Section 4.4.2 we address other properties, which need to take allrestrictions into account. Finally, in Section 4.4.3 we report on our experiences with SMTsolvers.

In our industrial case, verification of the properties mentioned above often requiresadditional knowledge about the environment, including the geometric models and thetiming. We try to keep these details to a minimum in order to make the verificationfeasible and to give quick feedback to the user. In our analyses this has an impact on thefollowing:

• distances: We only assume that distance values stored in a geometric model can bedescribed as a distance function d : Obj×Obj → R+0 such that (for all o1, o2 ∈ Obj):

– d(o1, o1) = 0;

– d(o1, o2) = d(o2, o1).

We ignore whether the distances are feasible in practice.

• timing: We ignore the acceleration characteristics of the physical objects, and anytime delays between sensing and acting.

However, this can result in false positive responses for well-definedness of condition-s/expressions and false positive/negative responses for deadlock. The challenge is tobalance the number of false positive/negative results with the number of additional de-tails that need to be provided. In what follows, we categorize the kind of checks thatcould be useful for our DSL users.

4.4.1 Well-definedness of Conditions and Expressions

Since users can specify complicated activation conditions or effect expressions, we pro-vide mechanisms to warn for mathematically undefined operations. As an example wefocus on potential divisions by zero, which can occur at two places. First, any divisions inthe activation conditions are checked in isolation. Second, divisions appearing in effectexpressions are checked under the assumption that the corresponding activation condi-tion holds.

Consider the following restriction which contains division at both locations:

restriction DivByZeroSampleactivation

1 / (1 + Distance[Actuals](Table, CArm)) > 0.5&& Distance[Actuals](Table, CArm) < 5

effectsabsolute limit CArm[Rotation] at

1 / (6 - Distance[Actuals](Table, CArm))

We perform the following checks to ensure that the activation condition and the effectexpression are well-defined for all possible geometric models values (g ∈ GeoVal):

89


1. ∀g ∈ GeoVal . 1+ g(Actuals)(Table, CArm) 6= 0

2. ∀g ∈ GeoVal .�

(1

1+ g(Actuals)(Table, CArm)> 0.5) ∧ (g(Actuals)(Table, CArm)< 5)

�

⇒�

6− g(Actuals)(Table, CArm) 6= 0�

Considering our definition for distance functions, both checks are satisfied in our exam-ple.

For the collision prevention DSL, we also check for a potential exponentiation re-sulting in a complex number. The SMT problem generator of Fig. 4.1 generates SMTexpressions that perform these types of checks for each condition and expression.

Similarly, for DSLs allowing for case analysis, one can extend our approach to checkwhether the cases are complete and non-overlapping. Such checks are more involvedthan basic type checking, because they involve the valuation of distance functions andarithmetic operations on them.

4.4.2 Ranges for Speed Limits and Deadlock-Freedom

The properties discussed in Section 4.4.1 focus on individual conditions and expressions.In this section we consider properties that need to take all restrictions into account. Weformulate properties about ranges of speed limits and deadlock-freedom.

To verify these properties against a DSL model, the SMT problem generator of Fig. 4.1generates SMT expressions that describe the semantics of the model; see Section 4.2.2.The properties discussed in this section are also automatically generated. The combi-nation of each property and the semantics of the DSL model is analyzed by the SMTsolver.

Ranges for Speed Limits

Given a DSL model DM= ⟨Obj, Modp, Modu, R⟩, the absolute limit specified for each objectmovement should be a non-negative real number for any geometric models value. Thisproperty can be described as follows:

∀obj ∈ Obj, m ∈MovType, g ∈ GeoVal . R(obj, m, Abs, g)≥ 0

Similarly, the relative limit of each object movement should be a real number between0 and 1. This property can be formalized as follows:

∀obj ∈ Obj, m ∈MovType, g ∈ GeoVal . 0≤ R(obj, m, Rel, g)≤ 1

Deadlock-Freedom

Sometimes objects can reach a deadlock position due to the restrictions specified in aDSL model. Consider for example restriction ApproachingTableAndCArm in Fig. 4.3.Suppose we move the Table and the CArm towards each other. As discussed in Chapter 3,

90

4.4. Advanced Validation

predefined geometric models such as Actuals store distance values as measured by thesensors. If the remaining distance between the Table and CArm is exactly 35 mm, thenthe speed of the CArm is limited to 0, independently of any (future) user request forthe CArm. Unless there is another way to move the CArm, this object has reached anindividual deadlock.

We aim to warn the DSL user for such situations, where certain sensor inputs (storedin a predefined geometric model) can stop an object independently of any future userrequest. As we abstract from the dependencies between distance parameters in differentgeometric models, our possibilities to formulate this property are limited. As indicatedin Chapter 3, a DSL model DM = ⟨Obj, Modp, Modu, R⟩ declares two types of geometricmodels:

• predefined models (Modp): store the shortest distance between each pair of objects,as given by the sensors;

• user-dependent models (Modu): store predicted shortest distance between eachpair of objects, based on sensor values and user requests.

We use this distinction between predefined and user-dependent geometric models toformulate deadlock freedom.

Informally, we describe it as “for each object movement, user request, and for eachvaluation of predefined geometric models, there is a valuation of user-dependent ge-ometric models, such that the object can move”. This property can be formulated asfollows:

∀p : Modp → Dist, obj ∈ Obj, m ∈MovType, ur ∈ SpReq

∃u : Modu→ Dist, g ∈ GeoVal .

(g|Modu= u) ∧ (g|Modp

= p) ∧ (outSpeedR(obj, m, g, ur) 6= 0)

In this formulation the notation f |X restricts the function f : A→ B to X where X ⊆ A.For any object obj, movement m, user request ur, and predefined geometric models p,we can construct a valuation g of geometric models that allows movement m of obj.The valuation g is obtained from a valuation u of user-dependent models that enablemovement m of obj and from the given predefined models p.

Since we do not consider the geometry of the system and the feasibility of dis-tance values, this formulation of the deadlock-freedom property can result in false posi-tive/negative responses. The false negative responses may sound serious in our context,but this check is still useful as a warning for typical domain errors.

4.4.3 Feasibility of SMT Solving

Validating these properties for actual DSL models has led to some observations. State-of-the-art SMT solvers have limited support for non-linear constraints. For example, there isno complete procedure for formulas containing basic operations such as multiplication,and advanced operations such as logarithms are not supported. Thus the occurrenceof complex non-linear expressions in a DSL specification may limit the analysis power of

91


our method. In our examples, exponentiation was mainly applied to model smooth brakepatterns. We have temporarily isolated these patterns from the rest of the DSL. Approx-imating non-linear constraints remains as one of the issues that can be investigated asfuture work.

4.5 Automated Debugging

The “verifier and debugger” component in Fig. 4.1 checks the validity of the propertiesdescribed in Section 4.4 by feeding the corresponding SMT problems to an SMT solver.Since we encode the DSL restrictions as SMT functions with distance parameters, forany violated property regarding movement m ∈ MovType of obj ∈ Obj, we can get acounterexample in terms of distance values from SMT solvers.

Giving counterexamples in terms of distance values requires the user of the languageto analyze the values and determine the potential mistakes in DSL models. We aim toassist the user in fault diagnosis and provide a debugger that for any property violationmechanically determines a potential fault location in the DSL model. In this section wefirst describe suitable locations to report faults for the different types of properties. Thenwe present a procedure to compute these locations. Finally, we discuss how to avoidcomputing masked restrictions as locations.

4.5.1 Fault Location

In case of any property violation in a DSL model DM = ⟨Obj, Modp, Modu, R⟩, we aim toindicate a potential fault location in the DSL model. We distinguish two kinds of locationsin the DSL:

Condition/Expression The well-definedness property from Section 4.4.1 is defined foreach condition or expression in isolation. In case of a violation, the fault locationis the condition or expression itself.

Restriction The properties from Section 4.4.2 are verified against the set of restrictionsR in a DSL model. In these cases the fault locations are the restrictions that can bepivotal in causing the violation. We define this as follows:

“A restriction r is a pivotal restriction for causing the violation of prop-erty P, if there exists a set of restrictions R′ ⊂ R that does not violateproperty P, but after adding restriction r to this set (i.e., R′ ∪ {r}) theproperty is violated.”

Debugging is only needed when restrictions should be identified as fault location. Inthe remainder of this section, we focus on computing fault locations for the propertiesfrom Section 4.4.2 that are violated by a DSL model.

92

4.5. Automated Debugging

Step 2.(a) Step 2.(b) Step 2.(c) Step 3Iteration R+ R− RM Status of RM Minimization Fault

1 {} {r1, r2} {r1} satisfies the property R+ := RM -2 {r1} {r1, r2} - - - r2

Figure 4.4: Isolating a pivotal restriction with delta debugging

4.5.2 Procedure to Locate a Single Pivotal Restriction

Our debugging procedure is based on the delta debugging approach of [Zel09]. In [Zel09]the delta debugging procedure is introduced for isolating the relevant part of a failure-inducing program input. We adapt this procedure to our setting to detect restrictions thatcause property violations. In particular, for a violated property we aim to find a pivotalrestriction by narrowing down the difference between sets of passing (satisfying the prop-erty) and failing (violating the property) restrictions. Our procedure can be summarizedas follows:

1. Choose a passing (R+) and a failing (R−) set, i.e., a set of restrictions that satisfiesthe property and a set that violates the property, such that R+ ⊂ R−. We choose R+

as the empty set, and R− as the set of all restrictions.

2. Repeatedly try to minimize the difference between sets R+ and R−:

(a) Select a set RM of restrictions such that R+ ⊂ RM ⊂ R−;

(b) Use the SMT solver to check whether RM satisfies the property;

(c) If set RM satisfies the property, then replace the passing set R+ by RM ,otherwise replace the failing set R− by RM .

3. The single restriction r that distinguishes the passing set R+ from the failing set R−

is a pivotal restriction for the property violation.

As an example, consider Fig. 4.3 where the relative limit for Detector translation canbe negative (due to the second restriction and for geometric models g ∈ GeoVal suchthat g(LookAhead)(Table, Detector) < 35mm). Fig. 4.4 illustrates the application of thisfault isolation procedure to detect a pivotal restriction. Restrictions r1 and r2 representthe first and second restriction in Fig. 4.3. In the second iteration, restriction r2, i.e.,ApproachingTableAndDetector, is identified as a pivotal restriction.

From the description of Step 2(a) one can easily deduce that the debugging procedureis non-deterministic. In the presence of multiple restrictions that violate the property,each execution of this procedure can identify a different restriction.

Regarding the performance, in the worst case the number of iterations of Step 2 islinear in the total number of restrictions. One can constrain the choice of RM in Step 2(a)to make it logarithmic.

93


0.0 0.5 1.0 1.5 2.0 2.5 3.0Distance HdL0.5

1.0

1.5

2.0

2.5

3.0Relative Limit

r1

r2

r3

(a) Effects of restrictions

0.0 0.5 1.0 1.5 2.0 2.5 3.0Distance HdL0.5

1.0

1.5

2.0

2.5

3.0Relative Limit

(b) Unmasked parts of restrictions

Figure 4.5: Masked restriction

4.5.3 Masked Restrictions

The procedure from Section 4.5.2 can also report restrictions as faults at points wheretheir effects are masked by other restrictions. To illustrate this, we consider the set ofrestrictions R = {r1, r2, r3} such that the activation conditions and effect expressions inr1, r2 and r3 are defined in terms of a single distance parameter. Fig. 4.5(a) representsthe individual relative limits specified by r1, r2 and r3 for a specific object movement interms of the distance parameter. The overall effect is defined as the minimum of theindividual effects, as depicted in Fig. 4.5(b); see the definition of R in Section 4.2.2 forcomputing the effects of the set of restrictions in a DSL model.

We say that the effect ` ∈ {Abs, Rel} of a restriction r ∈ R on movement m of ob-ject obj is masked for a given g ∈ GeoVal, if there exists at least one restriction r ′ ∈ Rwhich specifies a more restrictive limit on the object movement for the given g, i.e.,r ′(obj, m,`, g) < r(obj, m,`, g). In the example of Fig. 4.5, the effect of restriction r3 ismasked by another restriction for every distance value.

Considering the range property “relative limits should be at most 1”, restriction r3 inisolation violates this property, and hence the procedure from Section 4.5.2 can indicatethis masked restriction as a fault location. Masking is no issue for the verification, but itis undesired that debugging reports masked restrictions as fault location.

If the semantics of the DSL is correctly implemented throughout code generation,masked restrictions will never lead to failures and hence, are considered spurious by thedomain experts. To avoid reporting masked restrictions as fault locations, we replace allrestrictions by just their unmasked parts, as shown in Fig. 4.5(b). This requires a smallmodification of the effects of a restriction as described in Section 4.2.2. For example,we describe the effects of restriction r3 = (actr3

, effr3) by r3 : Obj×MovType× LimType×

94

4.6. Integration with DSL Editor

GeoVal9R as follows:

r3(obj, m,`, g) =min(effr3(obj, m,`, g))

if�

effr3(obj, m,`, g) 6= ;

�

∧�

effr1(obj, m,`, g) 6= ; ⇒

�

min(effr1(obj, m,`, g))≥min(effr3

(obj, m,`, g))�

�

∧�

effr2(obj, m,`, g) 6= ; ⇒

�

min(effr2(obj, m,`, g))≥min(effr3

(obj, m,`, g))�

�

In comparison with function r from Section 4.2.2, the condition in the definitionof the function is extended with two conjuncts indicating that the effects of r3 are notmasked by the effects of r1 nor by the effects of r2. We apply similar modifications torestrictions r1 and r2. In this way masked restrictions have no effect any more, andhence, they cannot be identified as fault location.

4.6 Integration with DSL Editor

We have implemented the introduced verification and debugging approach using theEclipse Modeling Framework (EMF) [Ste+08]. As indicated earlier, Xtext [Xteb] is theopen-source framework that we have applied to specify the grammar of the DSL. It isintegrated with Xtend [Xtea] for basic validation and code generation. Z3 [DMB08] isthe SMT solver that we have used in our experiments for verification and debugging.To hide all the verification and debugging strategies from the user, we provide the userwith a Python script that for a given DSL model verifies the set of predefined propertiesthrough a sequence of calls to Z3. For any violated property, the debugging procedure isautomatically invoked.

Basic validators are continuously executed while editing a DSL model. To avoid addi-tional delays while editing, we have decided not to perform continuous validation usingSMT solvers. We generate the SMT problems and the Python script using an Xtend codegenerator. The advanced validation can be initiated upon user request by invoking thePython script. The advanced validation results are stored, interpreted by a validator andshown back in the editor.

Figure 4.6: Debugging results displayed in the DSL editor

95


The user is notified about the validation results using “warnings”, which result in ayellow underlining of the problematic parts together with a textual message; see Fig. 4.6.We cannot use “errors”, because they block future executions of all code generators (in-cluding the SMT problem generator). We also warn the user about verification or de-bugging attempts for which the corresponding SMT problem is not decidable (e.g., as aresult of non-linear expressions).

4.7 Related Work

Delta debugging has initially been developed for debugging programs. We are awareof a few research works [Hwa+09; WBM12] that apply this technique to more abstractdomains. In this chapter, we have applied it to a declarative DSL.

Integrations of satisfiability checking and debugging have been studied in both hard-ware and software domains. [Smi+05] applies such an integration in the context of logiccircuits. In [JM11] the authors propose a method that given a C program with an assertstatement and a set of failing test cases, provides a list of potential fault locations in aninteractive process. This method analyzes a failure trace by encoding the definition anduse relation for program variables as MAX-SAT problems. Unlike C programs there isno definition-use relation among the statements of our DSL. Hence, this approach is notapplicable in our case.

An integration of verification techniques and DSLs is reported in [Rat+12]. Their goalis to maximize reusability among different DSLs. They extract commonalities sharedbetween different DSLs (e.g., a boolean expressions module) and encapsulate them asanalysis DSLs. Analysis tools, such as model checkers and SMT solvers, are applied tospecification in analysis DSLs. Their validation is limited to properties shared betweenvarious domains, e.g., completeness of a set of specified restrictions, and consistency ofsimultaneously activated restrictions.

4.8 Conclusions

We have used the collision prevention DSL to study ways to support early fault detectionin industrial applications. The goal is to add value to the use of DSLs beyond code gener-ation. In particular we have focused on validation types that are more advanced than theusual basic types of validation that can be found in modern programming environments.

For this industrial DSL, we have shown a useful set of advanced properties that canbe verified efficiently using the SMT solver Z3. For a DSL model (consisting of 5 objects,6 geometric models, and 9 restrictions) that describes the actual behavior of the SafetyLayer, our approach leads to 264 generated verification SMT problems. In case of 226violations, the whole advanced validation process takes about 2 minutes on a standarddesktop computer. This includes the generation of SMT problems and Python scriptsusing a non-optimized generator (22 sec.) and verification and debugging (105 sec.).The results are displayed at logical locations in the DSL editor. To this end, we have

96

4.8. Conclusions

integrated three techniques, namely, domain-specific languages, SMT solving and deltadebugging.

In the studied DSL, restrictions can sometimes be masked by other restrictions andhence they have no observable effect. In particular, we have shown how to ensure thatmasked restrictions are not reported as fault location.

We envisage some possible extensions of the present work. The debugging procedurecan be extended to detect all possible causes of a property violation. As discussed inSection 4.4, in our approach we abstract from certain details to support fast user feedbackand to make the verification feasible. This may result in false positive/negative responses.We aim to investigate other abstraction levels in order to rule out false positive/negativeresponses.

97

Chapter 5

Reliable Algorithms forCalculating with Real Numbers

5.1 Introduction

Various scientific disciplines use computations involving real numbers to model and rea-son about different phenomena in the world. Real numbers are typically approximatedby floating point numbers in scientific calculations. Round-off errors are inevitable insuch approximations and they might build up into catastrophic errors in some cases. InSection 3.9.3 we encountered this problem while comparing the outputs computed by animplementation with the expected outputs specified in a test case.

Exact real arithmetic approaches address this issue by devising computation proce-dures that given an expression and a precision requested by the user produce an outputthat is guaranteed to meet the precision requirement.

Several approaches [Mül01; Mpf] to exact real arithmetic are based on iterativebottom-up calculations. Given an expression and a desired precision, bottom-up ap-proaches typically start with calculating the inputs with an arbitrary precision higher thanthe requested precision. Then, the sub-expressions are evaluated in a bottom-up way. Af-ter evaluating the sub-expressions of each level, the guaranteed precision is passed to thehigher level. Fig. 5.1(a) depicts a bottom-up approach; arrows indicate the flow of guar-anteed precision from sub-expressions to parent expressions. These calculations proceeduntil the main expression is calculated and its guaranteed precision is determined. Ifthe precision obtained for the expression is not adequate, the computation restarts withincreased precisions for the inputs.

In contrast, various authors [GL00; MM05] have proposed top-down approachesto exact real arithmetic. In top-down approaches, the required precision of each sub-expression is determined based on the precision required for its immediate parent ex-pression. For certain types of expressions, the required precision of the sub-expressionscan be calculated immediately. However, some expressions (e.g., x · y in [GL00]) mayrequire to first obtain additional information about the magnitude of the values of their

99

Reliable Algorithms for Calculating with Real Numbers

e1x + ln(y)

e1x ln(y)

1x

y

x

(a) Bottom-up

e1x + ln(y)

e1x ln(y)

1x

y

x

(b) Top-down

Figure 5.1: Exact Real Arithmetic Approaches

sub-expressions before determining their required precision. Thus, in general, it mightbe necessary to recompute certain expressions. Fig. 5.1(b) depicts a top-down approach;arrows indicate the flow of required precision from expressions to their sub-expressions.

The main benefit of top-down approaches is that they exploit the structure of a givenexpression to estimate the required precision of the sub-expressions. In this context, onewould ideally like to have top-down approximations for algebraic (e.g., addition, mul-tiplication) and transcendental (e.g., exponential function, natural logarithm) functionssuch that:

1. the approximations are proven to be correct and

2. iterative calculations are avoided unless they are proven to be necessary.

In several top-down approaches [GL00; O’C08], proofs of correctness for algebraicoperations are available. However, the arguments about transcendental functions pro-vide little insight about the correctness of the approximations and the effect of theseoperations on precision. Taylor expansions are the most prominent way to approximatetranscendental functions. Calculations with Taylor expansions are typically restricted toa base interval; range reduction identities are used to extend the computations to thecomplete domain of a function. Proofs of correctness for transcendental functions arelimited to the base interval [GL00; O’C08; EH02], whereas little attention is given to thegeneral case where the computations introduced by range reduction identities influencethe output precision. For instance, in [EH02] ex is approximated in the interval [−1,1]using the following Taylor expansion:

ex =∞∑

i=0

1

i!x i

The authors repeatedly apply the following identity to bring an argument x 6∈ [−1,1]

100

5.2. Computable Real Functions

into the base interval:

ex = (ex2 )2

However, details about approximating the exponential function in the general case arelacking.

The second desired property for a top-down approach is related to the iterative natureof the computations. As discussed above, bottom-up and top-down approaches in the lit-erature rely on iterative computation schemes. However, no formal reasoning is providedto prove that such iterative calculations are essential in the approximation procedures.

In this chapter, we present a simple representation for real numbers and propose atop-down approach to approximate various algebraic and transcendental functions witharbitrary precision. For each operation, we describe an approximation procedure andrelate the precision of the inputs to the guaranteed precision for the output. One of themain contributions are the detailed proofs of correctness that we provide for the proposedapproximations.

As another contribution, we have developed a perturbation analysis method to iden-tify computational problems that require iterative calculations in our top-down approach.Our analysis describes the influence of errors in the inputs of a computational problemon the output precision. We apply perturbation analysis to show that our approximationprocedures only recompute expressions when this is unavoidable.

Structure of this chapter We discuss different approaches to defining computability offunctions in Section 5.2. In Section 5.3 we introduce a representation for real numbersand specify the syntax of the expressions that we consider in our computations. To ana-lyze computational problems in this setting, a perturbation analysis method is introducedin Section 5.4. In Section 5.5 we discuss our approximations of algebraic operations.We approximate transcendental functions using Riemann sums and Taylor expansions inSection 5.6 and 5.7, respectively. In Section 5.8 we perform experiments with some ofour proposed approximations. Section 5.9 contains discussions about related work. InSection 5.10 we draw some conclusions and suggest directions for future research.

5.2 Computable Real Functions

Real arithmetic is concerned with performing computations on real numbers. In order todo calculations with real numbers, it is necessary to define what it means for an operationto be computable. In this section we briefly discuss different approaches to definingcomputability.

Since real numbers are infinite objects, one can use infinite streams from a finitealphabet Σ to represent them. This gives rise to a definition of computability called Type-2 Theory of Effectivity (TTE, [Wei12]). In TTE computable operations are defined interms of functions f : Σω→ Σω that receive infinite words as input and produce infinitewords as output. An essential property of a Type-2 computable function is the finitenessproperty [Wei12]. This property indicates that for a computable function f , any finiteprefix of the output f (x) is computable by some finite portion of the input x .

101


An alternative definition of computability has been introduced by the Russian schoolof constructive analysis [Mar54; KL84]. In this definition, computable operations aredefined in terms of functions f : Σ∗→ Σ∗ that receive finite words as input and producefinite words as output. This approach is sometimes referred to as Type-1 computability.A function f is Type-1 computable if there is a Turing machine that transforms any finiteinput string x ∈ Σ∗ to the finite output strings f (x) ∈ Σ∗. Type-1 machines provide anatural way to define computability on, for instance, rational numbers and finite graphs.

In both Type-1 and Type-2 approaches, Σ depends on the concrete representationthat we use for input/output objects. For instance, one can use the binary signed-digitrepresentation to represent real numbers in the inputs/outputs of computations.

The relation between Type-1 and Type-2 computable functions has been investigatedin various studies. It is known that restricting the domain of a Type-2 computable func-tion to finite streams results in a Type-1 computable function [Her96; RW99]. However,not every Type-1 function can be obtained by restricting some Type-2 computable func-tion [RW99; KLS00]. To illustrate this, we consider a function f1 : {0,1}∗ → {0,1}∗defined as follows:

f1(s) =

¨

0 if s = 0k

1 if s = 0k1s′

where k ∈ N is the length of the longest prefix of zeros in s and s′ ∈ Σ∗ is a finite suffix ofs in the second case. The function f1 performs computations on finite strings and one canconstruct a Type-1 Turing machine to compute this function. By extending the domain off1 to infinite strings, we obtain f2 : Σω→ Σω such that:

f2(s) =

¨

0 if s = 0ω

1 if s = 0k1s′

The function f2 is not computable with a Type-2 Turing machine; it is not possible to write0 in the output after reading a finite prefix from the input. The interested reader can referto [Her96] for more details about the relation between Type-1 and Type-2 computablefunctions.

In addition to Type-1 and Type-2, one can also consider a third approach to defin-ing computability based on certain finite structures that provide precise descriptions forspecific classes of real numbers. For instance, Lagrange’s theorem on continued fractionsindicates that the real numbers whose continued fraction is periodic are the quadraticirrationals. Based on this observation, one can define computability in terms of func-tions f that given a finite and precise representation of x produce a finite and preciserepresentation of f (x).

The exact real arithmetic approach that we introduce in this chapter is based on Type-2 computability. In Section 5.3 we discuss a representation for real numbers in terms ofrational numbers that are coupled with a notion of precision. Our approximations forarithmetic operations rely on the finiteness property of computable functions. Thus, fora given computational problem, a desired precision for the output is obtained based onsufficiently good approximations of the inputs.

102

5.3. Real Numbers: Representation and Operations

5.3 Real Numbers: Representation and Operations

In this section we first discuss our representation of real numbers and then describe thesyntax of the expressions that we aim to calculate in our setting.

Since real numbers are infinite objects, a finite representation of an arbitrary realnumber x can only approximate x with a certain precision. In scientific measurementsand calculations, the amount of error that we commit in approximations is measured byan absolute or relative error. In practice, an absolute error is of little use. Since numberstend to have very different orders of magnitude, it is the relative error that shows thesignificance of the lost digits in measurements or calculations. Hence, in our setting weuse a representation based on the relative error.

Definition 5.1. A real number x is represented by a tuple (m, n, p) such that:

|x −m

n|< |

m

n|

1

2p

where m, n ∈ Z \ {0}, p ∈ N.

The representation (m, n, p) for x means that mn

approximates x and the relative error

of this approximation does not exceed 12p . Note that allowing m= 0 in the representation

would lead to the invalid inequality |x |< 0.We focus on calculating expressions that can be described with the following gram-

mar:

E ::= c | − E | E · E |1

E| E + E |

pE | eE |

ln(E) | arctan(E) | cos(E) | sin(E)(5.1)

where c represents a rational constant.The following identities show that other interesting operations can be described in

terms of the operations of this grammar:

tan(x) =sin(x)cos(x)

cot(x) =1

tan(x)

arcsin(x) = arctan(x

p

1− x2)

arccos(x) = arctan(

p

1− x2

x)

arccot(x) = arccos(x

p

1+ x2)

103


5.4 Sensitivity of Operations to Perturbations in the Ar-guments

Our goal is to develop a top-down exact real arithmetic approach based on the rep-resentation of Definition 5.1. Thus, for a given computational problem, it is essential toestimate the required precision of the inputs based on the desired precision in the output.Moreover, we would like to investigate to what extend the operations of grammar (5.1)can be calculated in a top-down manner without iterations.

To analyze the operations of grammar (5.1), we introduce a perturbation analysismethod for measuring the sensitivity of the operations to perturbations in their argu-ments. We consider two general cases in our analysis. First, we consider a function f (x)in one variable and show how errors in the input influence the output (Section 5.4.1).Then, we consider a function f (x , y) with two arguments and investigate the effect oferrors in the inputs on the output (Section 5.4.2).

5.4.1 Perturbation Analysis for Unary Functions

Let f (x) be a differentiable function that we want to calculate in point x = a. Supposethat ∆a is a perturbation in the argument a. The relative error in the calculation of f (a)caused by this perturbation is:

|f (a+∆a)− f (a)

f (a)|

We want to relate this relative error to the relative error of the argument, namely |∆aa|.

To this end, we use the following approximation of the function f in point x = a+∆a:

f (a+∆a)≈ f (a) + f ′(a)∆a

We can approximate the relative error of f as follows:

|f (a+∆a)− f (a)

f (a)| ≈ |

f ′(a)∆a

f (a)|= |

a f ′(a)f (a)

||∆a

a| (5.2)

From equality (5.2) one can see that the quantity | a f ′(a)f (a)| determines the effect of the

relative error |∆aa| on the output. In numerical analysis and linear algebra the quantity

| x f ′(x)f (x)| is usually referred to as the condition number of f (x) [Hig02; Hig08].

5.4.2 Perturbation Analysis for Binary Functions

Let f (x , y) be a differentiable function that we want to calculate in point (x , y) = (a, b).Suppose ∆a and ∆b are perturbations in the arguments a and b, respectively. Therelative error of f (a, b) caused by these perturbations can be calculated as follows:

|f (a+∆a, b+∆b)− f (a, b)

f (a, b)| (5.3)

104

5.5. Approximating Algebraic Operations

To find an upper-bound for (5.3), we use the following first-order approximation of thefunction f in point (x , y) = (a+∆a, b+∆b):

f (a+∆a, b+∆b)≈ f (a, b) + fx(a, b)∆a+ f y(a, b)∆b

where fx(a, b) and f y(a, b) are the partial derivatives of f with respect to x and y in(a, b), respectively. We relate the relative error in the calculation of f to the relativeerrors |∆a

a| and |∆b

b| as follows:

|f (a+∆a, b+∆b)− f (a, b)

f (a, b)| ≈ |

fx(a, b)∆a+ f y(a, b)∆b

f (a, b)| ≤

|a fx(a, b)f (a, b)

||∆a

a|+ |

b f y(a, b)

f (a, b)||∆b

b| ≤

(|a fx(a, b)f (a, b)

|+ |b f y(a, b)

f (a, b)|)max{|

∆a

a|, |∆b

b|} (5.4)

The quantity | a fx (a,b)f (a,b)

|+| b f y (a,b)f (a,b)

| determines the upper-bound calculated in inequality (5.4)and we use this quantity to measure the effect of erroneous arguments on the output. Itshould be noted that in inequality (5.4) we have considered |∆a

a| and |∆b

b| as indepen-

dent factors that can influence the relative error of f . This way of reasoning about thesensitivity of f (x , y) is related to componentwise analysis of perturbation in numericalanalysis and linear algebra [HD12], which we use in this chapter.

Another possibility is to relate the relative error of (5.3) to the quantity:

�

∆a∆b

�

�

ab

�

This type of analysis is usually referred to as normwise analysis of perturbation [HD12].In the following sections, we provide a top-down approach for approximating various

algebraic and transcendental functions. Perturbation analysis will be used to show thatin our approximations we only recompute expressions when essential.

5.5 Approximating Algebraic Operations

In this section we calculate the algebraic operations of grammar (5.1) using a top-downapproach. We formulate and prove theorems that allow us to calculate expressionsinvolving unary negation (Section 5.5.1), multiplication (Section 5.5.2), inverse (Sec-tion 5.5.3), addition (Section 5.5.4), and square root (Section 5.5.5). Based on the the-orems, we provide different implementations of COMPUTE(expr, p) to calculate algebraicoperations. These implementations receive an algebraic expression expr and a desiredprecision p and produce an output with the desired precision. In each case, we also applythe perturbation analysis of Section 5.4 and show that we avoid unnecessary iterationsin our approximations.

105


5.5.1 Unary Negation

Theorem 5.5.1. Let x be a real number represented by (m, n, p). Then −x can be repre-sented by (−m, n, p).

Proof. Since x is represented by (m, n, p) we can write:

m

n− |

m

n|

1

2p < x <m

n+ |

m

n|

1

2p

−m

n− |

m

n|

1

2p <−x <−m

n+ |

m

n|

1

2p

Thus, we can represent −x by (−m, n, p). ut

Algorithm 1 applies Theorem 5.5.1 and approximates −x based on a representation(m, n, p) of x . To confirm that −x can be approximated with arbitrary precision in onepass, we calculate | x f ′(x)

f (x)| for the function f (x) =−x:

|x f ′(x)f (x)

|= |(x)(−1)−x

|= 1

The quantity | x f ′(x)f (x)| is small and independent of the argument x and hence the amount

of precision that we lose in unary negation (which is 0 in the case of Theorem 5.5.1) canbe calculated independently of x .

Algorithm 1 Unary Negation

Require: expr has the shape −x1: procedure COMPUTE(expr, p)2: m

n← COMPUTE(x , p)

3: return −mn

5.5.2 Multiplication

Theorem 5.5.2. Let x and y be two real numbers represented by (m, n, p) and (m′, n′, p),respectively. Then x · y can be represented by (mm′, nn′, p− 2).

Proof. From Definition 5.1 we can write:

m

n− |

m

n|

1

2p < x <m

n+ |

m

n|

1

2p (5.5)

m′

n′− |

m′

n′|

1

2p < y <m′

n′+ |

m′

n′|

1

2p (5.6)

We consider three cases:

106


1. Suppose mm′

nn′> 0. We can multiply inequalities (5.5) and (5.6) as follows:

mm′

nn′(1−

1

2p )2 < x · y <

mm′

nn′(1+

1

2p )2

If x · y can be represented by (mm′, nn′, p− 2) then it must be the case that:

mm′

nn′(1−

1

2p−2 )< x · y <mm′

nn′(1+

1

2p−2 )

To see that this is valid, we need to show that:

mm′

nn′(1+

1

2p )2 ≤

mm′

nn′(1+

1

2p−2 )

mm′

nn′(1−

1

2p−2 )≤mm′

nn′(1−

1

2p )2

But mm′

nn′> 0 and from Proposition B.1 (see Appendix B) we know that both in-

equalities hold.

2. Suppose mn> 0, m′

n′< 0. We can rewrite inequalities (5.5) and (5.6) as follows:

m

n(1−

1

2p )< x <m

n(1+

1

2p ) (5.7)

m′

n′(1+

1

2p )< y <m′

n′(1−

1

2p ) (5.8)

Multiplying inequalities (5.7) and (5.8) we get:

mm′

nn′(1+

1

2p )2 < x · y <

mm′

nn′(1−

1

2p )2

If x · y is representable by (mm′, nn′, p− 2) then it must be the case that:

mm′

nn′(1+

1

2p−2 )< x · y <mm′

nn′(1−

1

2p−2 )

To show that this is valid, it suffices to prove that:

mm′

nn′(1−

1

2p )2 ≤

mm′

nn′(1−

1

2p−2 )

mm′

nn′(1+

1

2p−2 )≤mm′

nn′(1+

1

2p )2

But mm′

nn′< 0 and from Proposition B.1 (see Appendix B) we know that both in-

equalities hold.

3. Suppose mn< 0, m′

n′> 0. This case can be proved similarly to the second case.

107


Algorithm 2 Multiplication

Require: expr has the shape x · y1: procedure COMPUTE(expr, p)2: m

n← COMPUTE(x , p+ 2)

3: m′

n′← COMPUTE(y, p+ 2)

4: return mm′

nn′

ut

Algorithm 2 depicts an approximation of x · y based on Theorem 5.5.2. Given approx-imations of x and y , this algorithm approximates x · y in one pass; the loss of precisionis predictable without additional information about x and y . To confirm this claim, weapply the perturbation analysis of Section 5.4 on the function f (x , y) = x · y:

|x fx(x , y)f (x , y)

|+ |y f y(x , y)

f (x , y)|= |

x .y

x .y|+ |

y.x

x .y|= 2

The sensitivity measure is small and independent of the arguments. Thus, in a top-downapproach, x · y can be approximated in one pass without iterative computations of x andy .

5.5.3 Inverse

Theorem 5.5.3. Let x be a real number represented by (m, n, p). Then 1x

can be repre-sented by (n, m, p− 1).

Proof. We consider two cases:

1. Suppose mn> 0. Since x is represented by (m, n, p) we can write:

m

n(1−

1

2p )< x <m

n(1+

1

2p )

n

m(

2p

2p + 1)<

1

x<

n

m(

2p

2p − 1)

If 1x

is representable by (n, m, p− 1), then it must be the case that:

n

m(1−

1

2p−1 )<1

x<

n

m(1+

1

2p−1 )

To see that this is valid, it suffices to show:

n

m(

2p

2p − 1)≤

n

m(1+

1

2p−1 )

n

m(1−

1

2p−1 )≤n

m(

2p

2p + 1)

But nm> 0 and both inequalities follow from Proposition B.2 (see Appendix B).

108


2. Suppose mn< 0. Since x is representable by (m, n, p) we have:

m

n(1+

1

2p )< x <m

n(1−

1

2p )

n

m(

2p

2p − 1)<

1

x<

n

m(

2p

2p + 1)

If 1x

is representable by (n, m, p− 1) then it must be the case that:

n

m(1+

1

2p−1 )<1

x<

n

m(1−

1

2p−1 )

To see that this is valid, we need to show:

n

m(

2p

2p + 1)≤

n

m(1−

1

2p−1 )

n

m(1+

1

2p−1 )≤n

m(

2p

2p − 1)

But nm< 0 and hence the inequalities follow from Proposition B.2 (see Appendix B).

ut

Algorithm 3 Inverse

Require: expr has the shape 1x

1: procedure COMPUTE(expr, p)2: m


3: return nm

Algorithm 3 approximates 1x

with precision p based on Theorem 5.5.3. Given an ap-

proximation of x with precision p, the algorithm allows us to approximate 1x

in one pass.

We use perturbation analysis and calculate the quantity | x f ′(x)f (x)| for f (x) = 1

xto show that

loss of precision in the inverse can be estimated independently of the argument:

|x f ′(x)f (x)

|= |(x)(−1

x2 )

( 1x)|= 1

The quantity | x f ′(x)f (x)| is a constant and hence iterative computations can be avoided when

calculating the inverse.

5.5.4 Addition

Theorem 5.5.4. Let x and y be two real numbers represented by (m, n, p) and (m′, n′, p),respectively. The value of x + y can be approximated as follows:

109


i. If mm′

nn′> 0, then x + y can be represented by (mn′ +m′n, nn′, p).

ii. If mm′

nn′< 0 and i ∈ N+ is the smallest natural number such that i ≥ log2(

1+min(| mn |,|

m′n′|)

max(| mn |,|m′n′|)

1−min(| mn |,|

m′n′|)

max(| mn |,|m′n′|)

),

then x + y can be represented by (mn′ +m′n, nn′, p− i).

Proof.

i. For numbers x and y we can write:

m

n− |

m

n|

1

2p < x <m

n+ |

m

n|

1

2p (5.9)

m′

n′− |

m′

n′|

1

2p < y <m′

n′+ |

m′

n′|

1

2p (5.10)

From inequalities (5.9) and (5.10) we can write:

(m

n+

m′

n′)−

1

2p (|m

n|+ |

m′

n′|)< x + y < (

m

n+

m′

n′) +

1

2p (|m

n|+ |

m′

n′|) (5.11)

If x + y is representable by (mn′ +m′n, nn′, p), then it must be the case that:

(m

n+

m′

n′)−

1

2p |m

n+

m′

n′|< x + y < (

m

n+

m′

n′) +

1

2p |m

n+

m′

n′|

To show that this is valid, we need to prove that:

(m

n+

m′

n′) +

1

2p (|m

n|+ |

m′

n′|)≤ (

m

n+

m′

n′) +

1

2p |m

n+

m′

n′| (5.12)

(m

n+

m′

n′)−

1

2p |m

n+

m′

n′| ≤ (

m

n+

m′

n′)−

1

2p (|m

n|+ |

m′

n′|) (5.13)

The rational numbers mn

and m′

n′have the same sign. Therefore, |m

n+ m′

n′|= |m

n|+ |m

′

n′|

holds and inequalities (5.12) and (5.13) are valid.

ii. If x + y is representable by (mn′ +m′n, nn′, p− i), then it must be the case that:

(m

n+

m′

n′)−

1

2p−i |m

n+

m′

n′|< x + y < (

m

n+

m′

n′) +

1

2p−i |m

n+

m′

n′|

To show that this holds, we need to prove the following (see inequality (5.11)):

(m

n+

m′

n′) +

1

2p (|m

n|+ |

m′

n′|)≤ (

m

n+

m′

n′) +

1

2p−i |m

n+

m′

n′|

(m

n+

m′

n′)−

1

2p−i |m

n+

m′

n′| ≤ (

m

n+

m′

n′)−

1

2p (|m

n|+ |

m′

n′|)

110


For both inequalities, it boils down to proving the following:

1

2i (|m

n|+ |

m′

n′|)≤ |

m

n+

m′

n′| (5.14)

To prove inequality (5.14), we consider the following two cases:

1. Suppose mn> 0 and m′

n′< 0. We can rewrite inequality (5.14) as follows:

|m

n+

m′

n′| ≥

1

2i (m

n−

m′

n′)⇔(

m

n+

m′

n′)≥

1

2i (m

n−

m′

n′)∨

(m

n+

m′

n′)≤

1

2i (m′

n′−

m

n)

In other words, we should showmn

− m′n′≥ 2i+1

2i−1or− m′

n′mn

≥ 2i+12i−1

. Depending on the

values of |mn| and |m

′

n′|, both cases follow from

max(| mn|,| m

′

n′ |)

min(| mn|,| m

′n′ |)≥ 2i+1

2i−1. Equivalently, we

should have i ≥ log2(1+

min(| mn |,|m′n′|)

max(| mn |,|m′n′|)

1−min(| mn |,|

m′n′|)

max(| mn |,|m′n′|)

).

2. Suppose mn< 0 and m′

n′> 0. We can rewrite inequality (5.14) as follows:

|m

n+

m′

n′| ≥

1

2i (m′

n′−

m

n)⇔(

m

n+

m′

n′)≥

1

2i (m′

n′−

m

n)∨

(m

n+

m′

n′)≤

1

2i (m

n−

m′

n′)

In other word, we need to provem′

n′

− mn

≥ 2i+12i−1

or− m

nm′n′≥ 2i+1

2i−1. Depending on the

values of |mn| and |m

′

n′|, both cases follow from

max(| mn|,| m

′

n′ |)

min(| mn|,| m

′n′ |)≥ 2i+1

2i−1. Equivalently, we

should have i ≥ log2(1+

min(| mn |,|m′n′|)

max(| mn |,|m′n′|)

1−min(| mn |,|

m′n′|)

max(| mn |,|m′n′|)

).

ut

Algorithm 4 applies Theorem 5.5.4 to approximate x + y with precision p. If approx-imations m

nand m′

n′have the same sign, we do not lose precision by calculating x + y .

On the other hand, if mn

and m′

n′have different signs, the amount of precision that is lost

depends on the magnitude ofmin(| m

n|,| m

′

n′ |)

max(| mn|,| m

′n′ |)

. This indicates that if mm′

nn′< 0 and |m

n| ≈ |m

′

n′|, a

significant amount of precision can be lost in x+ y . Thus, if the guaranteed precision for

111


Algorithm 4 Addition

Require: expr has the shape x + y1: procedure COMPUTE(expr, p)2: dp← p3: repeat4: m

n← COMPUTE(x , dp)

5: m′

n′← COMPUTE(y, dp)

6: if mm′

nn′> 0 then . Theorem 5.5.4.i

7: return mn′+m′nnn′

8: else . Theorem 5.5.4.ii

9: i← dlog2(1+

min(| mn |,|m′n′|)

max(| mn |,|m′n′|)

1−min(| mn |,|

m′n′|)

max(| mn |,|m′n′|)

)e

10: if dp− i ≥ p then11: return mn′+m′n

nn′12: else13: dp← dp+ 114: until true

x + y (i.e., p − i) is not sufficient, x and y must be recomputed with higher precisions(see Line 3,13 in Algorithm 4).

To confirm this observation, we apply the perturbation analysis of Section 5.4 onf (x , y) = x + y:

|x fx(x , y)f (x , y)

|+ |y f y(x , y)

f (x , y)|= |

x

x + y|+ |

y

x + y|

The quantity | xx+y| + | y

x+y| is 1 when x y > 0. Thus, we can estimate the loss of

precision in x + y independently of the arguments when x y > 0.However, the quantity | x

x+y|+| y

x+y| can be arbitrarily large when x y < 0 and |x+ y| ≈

0. This confirms that a significant amount of precision can be lost in x + y .Perturbation analysis shows that in general, we cannot estimate the amount of pre-

cision that is lost in x + y independently of the arguments. Hence, if approximation mn

and m′

n′have different signs, recomputing x and y might be essential to obtain the de-

sired precision for x + y . Loss of precision in x + y is sometimes referred to as loss ofsignificance [KC02] or catastrophic cancellation [FT86].

It should be noted that Theorem 5.5.4 does not imply that x+ y is always fundamen-tally problematic when x y < 0 and |x + y| ≈ 0. In certain cases, the calculation can beadjusted in such a way that loss of significance can be avoided and the expression can becalculated in one pass.

Suppose we want to calculatep

x + 1−p

x for a relatively large x . Sincep

x + 1 ≈px , we will lose a significant amount of precision if we directly calculate

px + 1−

px .

112


However, we can change the calculation algorithm by rewriting the expression as follows:

p

x + 1−p

x = (p

x + 1−p

x)×p

x + 1+p

xp

x + 1+p

x=

1p

x + 1+p

x

In the new expression, all the operations can be approximated with a desired precisionin one pass (see Section 5.5.5 on calculating square root). Hence, we can approximatethe new expression without recomputing the sub-expressions with higher precisions. Ap-plying the perturbation analysis of Section 5.4 also shows that f (x) =

px + 1−

px is

not fundamentally problematic:

|x f ′(x)f (x)

|= |x( 1

2p

x+1− 1

2p

x)

px + 1−

px|=

1

2

Ç

x

x + 1<

1

2

Using perturbation analysis, we can identify instances of x + y where adjustmentsin the algorithm can avoid loss of significance. However, to our knowledge a generalscheme for making such adjustments does not exist.

5.5.5 Square Root

In this section, we calculatep

x by approximating the root of f (y) = y2 − x using theNewton-Raphson method [KC02]. The Newton-Raphson method starts with an initial ap-proximation y0 for

px and iteratively generates a sequence of approximations. Assuming

that the precise value of x is available, the sequence of approximations is generated by:

yn+1 =y2

n + x

2yn

In what follows, we prove a theorem for approximatingp

x by the Newton-Raphsonmethod when an approximation (m, n, p) of x is available.

Theorem 5.5.5. Let x be a real number represented by (m, n, p) such that:

m

n= 0.b1 b2 b3 . . .× 2a

where bi ∈ {0,1} for i ∈ N and b1 = 1, a ∈ Z. Thenp

x can be represented by (m′, n′, p−4N) where N = dlog2(log2(2

p+3 + 1))e + 1 and m′

n′is the N -th term of the following

sequence:

yn+1 =y2

n +mn

2yn, y0 = 2d

a2e+1

Proof. From Definition 5.1 we write:

m

n(1−

1

2p )< x <m

n(1+

1

2p )

113


To prove the theorem, it suffices to show:

|p

x − yN |<1

2p−4N |yN | (5.15)

We rewrite the left hand side of inequality (5.15):

|p

x − yN |= |p

x − zN + zN − yN | ≤ |p

x − zN |+ |zN − yN | (5.16)

In inequality (5.16), zN is the N -th term of the following sequence:

zn+1 =z2

n + x

2zn, z0 = 2d

a2e+1

To prove inequality (5.15), it suffices to show that the following inequalities hold:

|p

x − zN |<1

2p−4N+1 |yN | (5.17)

|zN − yN |<1

2p−4N+1 |yN | (5.18)

Proof for inequality (5.17): First, we show that yn >p

x2

for all n ∈ N:

yn −Ç

x

2=

y2n−1 +

mn

2yn−1−Ç

x

2>

y2n−1 +

mn

2yn−1−

r

m

2n(1+

1

2p )≥y2

n−1 +mn

2yn−1−Ç

m

n

=y2

n−1 +mn− 2yn−1

p

mn

2yn−1=(yn−1 −

p

mn)2

2yn−1≥ 0

Observe that as yn >p

x2, inequality (5.17) is valid, if the following inequality holds:

|p

x − zN |<1

2p−4N+ 32

px (5.19)

To prove inequality (5.19), we find N such that:

zN −p

x =1

2p+2

px (5.20)

We calculate the quantity zN+p

xzN−p

x:

zN +p

x

zN −p

x=

z2N−1+x

2zN−1+p

x

z2N−1+x

2zN−1−p

x=

z2N−1 + x + 2zN−1

px

z2N−1 + x − 2zN−1

px

=(zN−1 +

px

zN−1 −p

x)2 = . . .= (

z0 +p

x

z0 −p

x)2

N(5.21)

114


Suppose equality (5.20) holds for N . We can rewrite the right hand side of equality (5.21)as follows:

(z0 +

px

z0 −p

x)2

N=

zN +p

x

zN −p

x=(2+ 1

2p+2 )p

x

( 12p+2 )p

x= 2p+3 + 1 (5.22)

The index N that guarantees the required precision of equality (5.20) can be calculatedfrom equality (5.22):

2N log2(z0 +

px

z0 −p

x) = log2(2

p+3 + 1)

N = log2(log2(2p+3 + 1))− log2(log2(

z0 +p

x

z0 −p

x)) (5.23)

To guarantee that N is well-defined, we show that z0 >p

x . To prove the inequality, weuse the assumptions m

n= 0.b1 b2 b3 . . .× 2a, bi ∈ {0,1} for i ∈ N and b0 = 1, z0 = 2d

a2e+1:

px <

r

m

n(1+

1

2p )≤p

0.b1 b2 b3 . . .× 2a2 ×p

2< 2a2 ×p

2< z0

To obtain an estimation for N from equality (5.23), we calculate an upper bound for z0px:

z0px<

2da2e+1

Æ

mn(1− 1

2p )<

2a+1

2+1

p

0.b1 b2 b3 . . .× 2a2 ×Æ

12

≤2p

24p

2×Æ

12

=4

4p

2

In the worst case, the initial approximation z0 differs fromp

x by a factor 44p2

. We usethis estimation in equality (5.23) to calculate the number of iterations for the Newton-Raphson method:

N = log2(log2(2p+3 + 1))− log2(log2(

44p2+ 1

44p2− 1))

<dlog2(log2(2p+3 + 1))e+ 1 (5.24)

Proof for inequality (5.18): To prove inequality (5.18), we consider the calculations

in zN =z2

N−1+x

2zN−1and estimate the amount of error that we commit in the approximation

yN =y2

N−1+mn

2yN−1.

Let P(k) denote the amount of precision that we lose when we approximate zk by yk.Thus, we lose P(N − 1) units of precision if we approximate zN−1 by yN−1:

|zN−1 − yN−1|<1

2p−P(N−1)|yN−1|

115


The precision is reduced by 2 units when z2N−1 is approximated by y2

N−1 (see Theo-rem 5.5.2):

|z2N−1 − y2

N−1|<1

2p−P(N−1)−2|y2

N−1|

We approximate z2N−1 + x by y2

N−1 +mn

. We do not lose precision in this approximation(see Theorem 5.5.4.i):

|(z2N−1 + x)− (y2

N−1 +m

n)|<

1

2p−P(N−1)−2|y2

N−1 +m

n| (5.25)

Given the approximation yN−1 of zN−1, one unit of precision is lost in the approximationof 1

zN−1(see Theorem 5.5.3):

|1

zN−1−

1

yN−1|<

1

2p−P(N−1)−1|

1

yN−1|

|1

2zN−1−

1

2yN−1|<

1

2p−P(N−1)−1|

1

2yN−1| (5.26)

Finally, we approximatez2

N−1+x

2zN−1based on the approximations described in inequality (5.25)

and (5.26) (see Theorem 5.5.2):

|zN − yN |= |z2

N−1 + x

2zN−1−

y2N−1 +

mn

2yN−1|<

1

2p−P(N−1)−4|y2

N−1 +mn

2yN−1| (5.27)

From inequality (5.27) we obtain the following recursive formula:

P(N) = P(N − 1) + 4

Since y0 = z0 = 2da2e+1, we lose P(N) = P(0) + 4N = 4N units of precision in our

approximation of zN . We apply the number of iterations calculated in inequality (5.24)and obtain:

P(N) = 4N < 4dlog2(log2(2p+3 + 1))e+ 4

ut

Algorithm 5 applies Theorem 5.5.5 to approximatep

x with precision p. As indicatedin Theorem 5.5.5, loss of precision in the square root can be estimated independentlyof the argument x and hence Algorithm 5 approximates

px in one pass. We apply

perturbation analysis on f (x) =p

x to show this:

|x f ′(x)f (x)

|= |(x)( 1

2p

x)

px|=

1

2

The quantity | x f ′(x)f (x)| is a small constant. Thus, in our top down approach, we can ap-

proximatep

x without iterative computations.

116

5.6. Approximating Transcendental Functions by Riemann Sums

Algorithm 5 Square Root

Require: expr has the shapep

x1: procedure COMPUTE(expr, p)2: Choose px such that px ≥ p+ 4dlog2

�

log2(2px+3 + 1)

�

e+ 43: N ← dlog2

�

log2(2px+3 + 1)

�

e+ 14: m

n← COMPUTE(x , px)

5: if mn< 0 then

6: “Undefined operation”7: else8: . m

ncan be represented as 0.b1 b2 b3 . . .× 2a

9: . bi ∈ {0,1} for i ∈ N, b1 = 1 and a ∈ Z10: a← blog2(

mn)c+ 1

11: y0← 2da2e+1

12: for i = 1 to N do13: yi ←

y2i−1+

mn

2yi−1

14: m′

n′← yN

15: return m′

n′

5.6 Approximating Transcendental Functions by RiemannSums

In this section we introduce approximations for ex (Section 5.6.1), ln(x) (Section 5.6.2),and arctan(x) (Section 5.6.3). We use Riemann sums to approximate these functions.

The COMPUTE(expr, p) function introduced in Section 5.5 will be extended to allow theapproximation of ex , ln(x) and arctan(x) with a given precision p. Perturbation analysiswill also be used to identify computational problems in which iterative computations areunavoidable.

5.6.1 Exponential Function

To approximate the exponential function by Riemann sums, we first provide a simpleapproximation for ex where we assume that x is precise. Then we extend this calculationto approximate ex where x is represented by (m, n, p).

Suppose x > 0. To calculate ex we consider the curve y = et and calculate thearea enclosed by this curve and the t-axis between t = −x and t = x as follows (seeFig. 5.2(a)):

∫ x

−x

et d t = ex − e−x

We use Riemann sums to approximate this area; Fig. 5.2(b) shows two approximationsfrom above and below using rectangles. Thus, we get the following inequalities for N

117


−x x t

(a) y = et

−x x t

(b) Right & Left Riemann Sums

Figure 5.2: Approximating ex

rectangles:

N−1∑

i=0

2x

Ne−x+ 2x

Ni ≤ ex − e−x ≤

N∑

i=1

2x

Ne−x+ 2x

Ni (5.28)

We rewrite inequality (5.28) as follows:

N−1∑

i=0

(2x

N)e

2xN

i ≤ e2x − 1≤N∑

i=1

(2x

N)e

2xN

i

(2x

N)(

e2x − 1

e2xN − 1

)≤ e2x − 1≤ (2x

N)(

e2xN (e2x − 1)

e2xN − 1

)

2x

N≤ e

2xN − 1≤

2x

Ne

2xN (5.29)

We assume that N > 2x and calculate an upper bound and a lower bound for ex frominequality (5.29):

(1+2x

N)

N2 ≤ ex ≤ (

N

N − 2x)

N2 (5.30)

We can estimate the precision of the approximations calculated in inequality (5.30).For example, we can approximate ex by ( N

N−2x)

N2 and the absolute error of this approxi-

118


mation can be calculated as follows:

|(N

N − 2x)

N2 − ex | ≤ |(

N

N − 2x)

N2 − (1+

2x

N)

N2 |

= ((N

N − 2x)− (

N + 2x

N))

N2−1∑

i=0

(N

N − 2x)i(

N + 2x

N)

N2−i−1

=4x2

N(N − 2x)

N2−1∑

i=0

(N

N − 2x)i(

N + 2x

N)

N2−i−1

≤4x2

N(N − 2x)

N2−1∑

i=0

(N

N − 2x)

N2−1 =

2x2

N(

N

N − 2x)

N2 (5.31)

For the last inequality we apply NN−2x

≥ N+2xN

.In the discussion above, we have treated x as a precise value. In the following theo-

rem, we extend this calculation and describe an approximation of ex that relies on a rep-resentation (m, n, p) of x . To simplify our approximations, we first assume that |m

n| < 1.

Afterwards, we extend our approximations to an arbitrary (m, n, p).Theorem 5.6.1. Let x be a real number represented by (m, n, p) and |m

n| < 1. Suppose N

is a natural number such that N > 2p+11

3 . The value of ex can be approximated as follows:

i. If 0 < mn< 1 then ex can be represented by (m′, n′, p − 2dlog2(

N2)e − 3) where

m′

n′= ( N

N− 2mn

)N2 .

ii. If −1 < mn< 0 then ex can be represented by (m′, n′, p − 2dlog2(

N2)e − 4) where

m′

n′= 1

( NN+ 2m

n)

N2

.

Proof.

i. Suppose 0< mn< 1. Since x is represented by (m, n, p), we have:

0<m

n(1−

1

2p )< x <m

n(1+

1

2p )≤2m

n< 2 (5.32)

To prove the theorem, it suffices to show that:

|ex − (N

N − 2mn

)N2 |<

1

2p−2dlog2(N2)e−3|(

N

N − 2mn

)N2 | (5.33)

We rewrite the left hand side of inequality (5.33) as follows:

|ex − (N

N − 2mn

)N2 |= |ex − (

N

N − 2x)

N2 + (

N

N − 2x)

N2 − (

N

N − 2mn

)N2 |

≤ |ex − (N

N − 2x)

N2 |+ |(

N

N − 2x)

N2 − (

N

N − 2mn

)N2 |

119



|ex − (N

N − 2x)

N2 |<

1

2p−2dlog2(N2)e−2|(

N

N − 2mn

)N2 | (5.34)

|(N

N − 2x)

N2 − (

N

N − 2mn

)N2 |<

1

2p−2dlog2(N2)e−2|(

N

N − 2mn

)N2 | (5.35)

Proof for inequality (5.34): From inequality (5.31), we obtain an upper-bound forthe left hand side of inequality (5.34):

|ex − (N

N − 2x)

N2 | ≤

2x2

N(

N

N − 2x)

N2 (5.36)

To calculate an upper bound for the right hand side of inequality (5.36), we considerthe function f (x) = 2x2

N( N

N−2x)

N2 and calculate its derivative:

f ′(x) =4x

N(

N

N − 2x)

N2 + x2(

N

N − 2x)

N2−1(

2N

(N − 2x)2)

From inequality (5.32) we obtain x ∈ (0, 2). We choose:

N > 4> 2x (5.37)

to ensure that f (x) is increasing for x ∈ (0,2), i.e., f ′(x) > 0. We rewrite inequal-ity (5.36) as follows:

|ex − (N

N − 2x)

N2 | ≤ f (x)≤ f (2) = (

8

N)(

N

N − 4)

N2 (5.38)

We calculate a lower bound for the right hand side of inequality (5.34) as follows:

1

2p−2dlog2(N2)e−2|(

N

N − 2mn

)N2 |>

1

2p−2 log2(N2)−2

(5.39)

Thus, to prove inequality (5.34) it suffices to show that the following inequality holds(see inequality (5.38), (5.39)):

(8

N)(

N

N − 4)

N2 <

1

2p−2 log2(N2)−2

This is equivalent to the following:

3− log2(N) +N

2

�

log2(1+4

N − 4)�

<−p+ 2 log2(N

2) + 2 (5.40)

We choose N > 8 and apply Proposition B.3 (see Appendix B) to obtain an upperbound for log2(1+

4N−4):

log2(1+4

N − 4)<

4

(N − 4) ln(2)<

8

N − 4(5.41)

120


Based on inequality (5.40),(5.41), it is sufficient to find an N > 8 satisfying:

3− log2(N) + (N

2)(

8

N − 4)<−p+ 2 log2(

N

2) + 2 (5.42)

Inequality (5.42) is equivalent to the following:

− log2(N3

4) +

16

N − 4<−p− 5

From N > 8, we conclude 16N−4

< 4. Thus, we choose N such that N >max(2p+11

3 , 8) =

2p+11

3 .

Proof for inequality (5.35): To prove the inequality, we estimate the amount ofprecision that is lost when we approximate ( N

N−2x)

N2 by ( N

N− 2mn

)N2 .

The number x is represented by (m, n, p). Thus, we have:

|x −m

n|<

1

2p |m

n|

|2x −2m

n|<

1

2p |2m

n|

Since N > 8, one unit of precision is lost when we approximate N − 2x by N − 2mn

(see Theorem 5.5.4.ii):

|(N − 2x)− (N −2m

n)|<

1

2p−1 |N −2m

n|

Approximating 1N−2x

by 1N− 2m

n

reduces the precision by one unit (see Theorem 5.5.3):

|1

N − 2x−

1

N − 2mn

|<1

2p−2 |1

N − 2mn

|

|N

N − 2x−

N

N − 2mn

|<1

2p−2 |N

N − 2mn

|

Finally, approximating ( NN−2x

)N2 reduces the precision by 2dlog2(

N2)e units (Lemma B.9

in Appendix B):

|(N

N − 2x)

N2 − (

N

N − 2mn

)N2 |<

1

2p−2dlog2(N2)e−2|(

N

N − 2mn

)N2 |

ii. Suppose mn< 0. We use the following identity to calculate ex :

ex =1

e−x

We represent −x by (−m, n, p) (see Theorem 5.5.1). Then, we apply the first part ofthe theorem and Theorem 5.5.3 to approximate e−x and 1

e−x , respectively.

121


ut

In what follows, we extend the approximations of Theorem 5.6.1 and calculate theexponential function for x represented by (m, n, p) where |m

n| ≥ 1.

Theorem 5.6.2. Let x be a real number represented by (m, n, p) and |mn| ≥ 1. Suppose k

and N are natural numbers such that:

|m

2kn|< 1 , N > 2

p+113

The value of ex can be approximated as follows:

i. If mn> 0 then ex can be represented by (m′, n′, p − 2dlog2(

N2)e − 2k − 3) where

m′

n′= ( N

N− 2mn

)N ·2k−1

.

ii. If mn< 0 then ex can be represented by (m′, n′, p − 2dlog2(

N2)e − 2k − 4) where

m′

n′= 1( N

N+ 2mn)N ·2k−1 .

Proof. Since |mn| ≥ 1, we choose k ∈ N such that | m

2kn| < 1. We use the following identity

to calculate ex :

ex = (ex

2k )2k

(5.43)

We approximate x2k by m

2kn. Since 2k is a constant, we do not lose precision in this ap-

proximation. We apply Theorem 5.7.2 to approximate ex

2k . This approximation reducesthe precision by:

• 2dlog2(N2)e+ 3 units, if 0< m

2kn< 1;

• 2dlog2(N2)e+ 4 units, if −1< m

2kn< 0.

Suppose m′

n′is the approximation obtained for e

x2k from Theorem 5.6.1. We approximate

(ex

2k )2k

by (m′

n′)2

k; we lose 2k units of precision in this calculation (see Lemma B.9 in

Appendix B). ut

Algorithm 6 implements the approximations described by Theorem 5.6.1 and 5.6.2 tocalculate ex with arbitrary precision. Observe that when |m

n|< 1, ex can be approximated

in one pass. However, when |mn| ≥ 1, loss of precision depends on the magnitude of |m

n|.

Thus, recomputing x with higher precisions might be necessary to compensate for theloss of precision caused by applying equality (5.43) (see Line 4,23 in Algorithm 6).

To confirm that iterative computations are unavoidable, we apply perturbation anal-ysis on f (x) = ex :

|x f ′(x)f (x)

|= |xex

ex |= |x |

The quantity |x | can become arbitrarily large and hence approximating ex with precisionp in one pass is not always possible.

122


Algorithm 6 Exponential Function

Require: expr has the shape ex

1: procedure COMPUTE(expr, p)2: Choose N such that N > 2

p+113

3: px ← p+ 2dlog2(N2)e+ 4

4: repeat5: m


6: if 0< mn< 1 then . Theorem 5.6.1.i

7: m′

n′← ( N

N− 2mn

)N2

8: return m′

n′

9: else if −1< mn< 0 then . Theorem 5.6.1.ii

10: m′

n′← 1

( NN+ 2m

n)

N2

11: return m′

n′12: else13: Choose k ∈ N such that | m

2kn|< 1

14: if (mn> 0)∧ . Theorem 5.6.2.i

15: (px − 2dlog2(N2)e − 2k− 3≥ p) then

16: m′

n′← ( N

N− 2mn

)N ·2k−1

17: return m′

n′

18: else if (mn< 0)∧ . Theorem 5.6.2.ii

19: (px − 2dlog2(N2)e − 2k− 4≥ p) then

20: m′

n′← 1( N

N+ 2mn)N ·2k−1

21: return m′

n′22: else23: px ← px + 124: until true

123


1 x t

(a) y = 1t

1 x t


Figure 5.3: Approximating ln(x)

5.6.2 Natural Logarithm

In this section, we first discuss an approximation for ln(x) based on Riemann sums wherewe assume that x is precise. Then we extend this calculation to approximate ln(x) wherex is represented by (m, n, p).

Suppose x > 1 is a real number and we want to approximate ln(x). We consider thecurve y = 1

t(see Fig. 5.3(a)) and calculate the area enclosed by this curve and the t-axis

between t = 1 and t = x . This area can be calculated as follows:

∫ x

1

d t

t= ln(x)

We use Riemann sums to approximate this area; Fig. 5.3(b) shows how the area canbe approximated from below and above using rectangles. Thus, we get the followinginequalities for N rectangles:

x − 1

N

N∑

i=1

1

1+ iN(x − 1)

≤ ln(x)≤x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

This gives us an upper bound and a lower bound for ln(x) and by increasing N we getmore precise approximations.

We can estimate the precision of our approximations. For instance, if we approximate

124


ln(x) by x−1N

∑N−1i=0

11+ i

N(x−1)

the absolute error can be estimated as follows:

|x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

− ln(x)|

≤ |x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

−x − 1

N

N∑

i=1

1

1+ iN(x − 1)

|

=x − 1

N(1−

1

x) =(x − 1)2

N x(5.44)

Up to this point, we have assumed that the precise value of x is available. In whatfollows, we formulate a theorem to describe an approximation of ln(x) based on a rep-resentation (m, n, p) of x .

Theorem 5.6.3. Let x be a real number represented by (m, n, p) such that p ≥ 1.

i. If mn> 1, then ln(x) can be represented by (m′, n′, p− j− 4) where:

m′

n′=(m

n)− 1

N

N−1∑

i=0

1

1+ iN((m

n)− 1)

, N = d2p−2(m

n)2

mn− 1e

and j is the smallest natural number such that j ≥ log2(1+ n

m

1− nm

) holds.

ii. If 0 < mn< 1, then ln(x) can be represented by (m′, n′, p − j − 5) where m′

n′=

−( n

m)−1

N

∑N−1i=0

11+ i

N(( n

m)−1)

, N = d2p−2 (nm)2

nm−1e, and j is the smallest natural number such

that j ≥ log2(1+ m

n

1− mn

) holds.

Proof.

i. Suppose mn> 1. The number x is represented by (m, n, p) and hence we can write:

1

2<

m

2n≤

m

n(1−

1

2p )< x <m

n(1+

1

2p )≤3m

2n(5.45)

To prove the theorem, we need to prove the following inequality:

| ln(x)−mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|

<1

2p− j−4 |mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

| (5.46)

125



| ln(x)−mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|=

| ln(x)−x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

+x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

−mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

| ≤

| ln(x)−x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

|

+|x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

−mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|


| ln(x)−x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

|<1

2p− j−3 |mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

| (5.47)

|x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

−mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|

<1

2p− j−3 |mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

| (5.48)

Proof for inequality (5.47): We use inequality (5.44) and calculate an upper boundfor the left hand side of inequality (5.47):

| ln(x)−x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

| ≤(x − 1)2

N x(5.49)

To calculate an upper bound for (x−1)2

N x, we consider the function f (x) = (x−1)2

N xand

calculate its derivative:

f ′(x) =x2 − 1

N x2

From inequality (5.45) we conclude that x ∈ [ 12, 3m

2n]. The function f (x) is decreas-

ing ( f ′(x) ≤ 0) in the interval [ 12, 1] and increasing ( f ′(x) ≥ 0) in the interval

[1, 3m2n]. Thus, the maximum of f (x) for x ∈ [ 1

2, 3m

2n] is max( f ( 1

2), f ( 3m

2n)). We use

126


this to rewrite inequality (5.49):

| ln(x)−x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

| ≤ f (x)≤max( f (1

2), f (

3m

2n))

=max(1

2N,( 3m

2n− 1)2

N( 3m2n))

≤max(1

2N,( 3m

2n)2

N( 3m2n)) =

3m

2Nn(5.50)

We also calculate a lower bound for the right hand side of inequality (5.47):

1

2p− j−3 |mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|>1

2p−3 |(m

n− 1)

N

N−1∑

i=0

1

1+ (N−1N)(m

n− 1)

|

=1

2p−3 .(m

n− 1).

N

N + (N − 1)(mn− 1)

>1

2p−3 .(m

n− 1).

N

N(1+ mn− 1)

=(m

n− 1)

2p−3(mn)

(5.51)

To show that inequality (5.47) holds, it suffices to prove the following inequality (seeinequality (5.50),(5.51)):

3m

2Nn<(m

n− 1)

2p−3(mn)

Thus, it suffices to choose N ≥ 2p−2 (mn)2

mn−1

.

Proof for inequality (5.48): To prove inequality (5.48) we consider the calcula-tions in x−1

N

∑N−1i=0

11+ i

N(x−1)

and estimate the amount of precision that we lose in the

approximationmn−1

N

∑N−1i=0

11+ i

N( m

n−1)

.

From Theorem 5.5.4.ii we conclude that j units of precision is lost by subtracting 1

from x where j ≥ log2(1+ n

m

1− nm

). We obtain the following inequalities:

|(x − 1)− (m

n− 1)|<

1

2p− j |m

n− 1|

|i

N(x − 1)−

i

N(m

n− 1)|<

1

2p− j |i

N(m

n− 1)|

The approximation iN(m

n−1) of i

N(x−1) is positive. Hence, we do not lose precision

by adding iN(x − 1) and 1 (see Theorem 5.5.4.i).

|(1+i

N(x − 1))− (1+

i

N(m

n− 1))|<

1

2p− j |1+i

N(m

n− 1)|

127


By approximating 11+ i

N(x−1)

, we lose 1 unit of precision (see Theorem 5.5.3):

|1

1+ iN(x − 1)

−1

1+ iN(m

n− 1)

|<1

2p− j−1 |1

1+ iN(m

n− 1)

|

We lose 2 units of precision by multiplying x−1N

and 11+ i

N(x−1)

(see Theorem 5.5.2):

|x − 1

N.

1

1+ iN(x − 1)

−(m

n− 1)

N.

1

1+ iN(m

n− 1)

|

<1

2p− j−3 |(m

n− 1)

N.

1

1+ iN(m

n− 1)

|

The numbers x−1N

. 11+ i

N(x−1)

are approximated by the positive numbersmn−1

N. 1

1+ iN( m

n−1)

.

Hence, calculating the summation x−1N

∑N−1i=0

11+ i

N(x−1)

does not affect the precision:

|x − 1

N

N−1∑

i=0

1

1+ iN(x − 1)

−mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|

<1

2p− j−3 |mn− 1

N

N−1∑

i=0

1

1+ iN(m

n− 1)

|

ii. Suppose 0< mn< 1. We use the following identity to approximate ln(x):

ln(x) =− ln(1

x)

We approximate 1x

by (n, m, p−1) (see Theorem 5.5.3). Then, we apply the first part

of the theorem and Theorem 5.5.1 to approximate − ln( 1x).

ut

Algorithm 7 applies Theorem 5.6.3 to approximate ln(x) with arbitrary precision.Note that when the approximation m

nis close to 1 the amount of precision that we lose

in the calculations depends on the magnitude of mn

. Loss of precision for x ≈ 1 in Algo-

rithm 7 is due to our approximation formula, x−1N

∑N−1i=0

11+ i

N(x−1)

. We divide the interval

between 1 and x into N subintervals and approximate the area under the curve f (t) = 1t.

The length of the interval [1, x] is crucial in our approximation. Thus, recomputing xwith higher precisions is necessary when a significant amount of precision is lost in x−1(see Line 3,22 in Algorithm 7).

To show that approximating ln(x) for x ≈ 1 is fundamentally problematic we applyperturbation analysis on f (x) = ln(x):

|x f ′(x)f (x)

|= |x( 1

x)

ln(x)|= |

1

ln(x)|

128


Algorithm 7 Natural Logarithm

Require: expr has the shape ln(x)1: procedure COMPUTE(expr, p)2: px ← p+ 53: repeat4: m


5: if mn> 1 then

6: arg← mn

7: `← 48: else if 0< m

n< 1 then

9: arg← nm

10: `← 511: else12: “Undefined operation”

13: j← dlog2(1+ 1

arg

1− 1arg

)e

14: if px − j− `≥ p then15: N ← d2px−2 arg2

arg−1e

16: m′

n′← arg−1

N

∑N−1i=0

11+ i

N(arg−1)

17: if mn> 1 then

18: return m′

n′19: else20: return −m′

n′

21: else22: px ← px + 123: until true

129


x t

(a) y = 11+t2

x t


Figure 5.4: Approximating arctan(x)

When x ≈ 1 the quantity ln(x) is a small value and hence committing a small error inthe approximation of x causes a significant error in calculating ln(x). Thus, for x ≈ 1,iterative computations are unavoidable.

5.6.3 Arctangent

We first introduce an approximation of arctan(x) using Riemann sums. The assumptionis that the precise value of x is available. Afterwards, we extend our calculations tointroduce an approximation of arctan(x) based on a representation (m, n, p) of x .

Suppose that x > 0 is a real number and we want to approximate arctan(x). Weconsider the curve y = 1

1+t2 ; see Fig. 5.4(a). We calculate the area enclosed by this curveand the t-axis between t = 0 and t = x:

∫ x

0

d t

1+ t2 = arctan(x)

We approximate this area using Riemann sums. Fig. 5.4(b) shows approximations fromabove and below for the integral using rectangles. From Fig. 5.4(b) we can derive thefollowing inequalities for N rectangles:

x

N

N∑

i=1

1

1+ ( iN)2 x2

≤ arctan(x)≤x

N

N−1∑

i=0

1

1+ ( iN)2 x2

We want to estimate the precision of our approximations. Suppose we approximatearctan(x) by x

N

∑N−1i=0

11+( i

N)2 x2 . The absolute error of this approximation can be estimated

130


as follows:

|x

N

N−1∑

i=0

1

1+ ( iN)2 x2

− arctan(x)| ≤ |x

N

N−1∑

i=0

1

1+ ( iN)2 x2

−x

N

N∑

i=1

1

1+ ( iN)2 x2

|

=x

N(1−

1

1+ x2 ) =x3

N(1+ x2)(5.52)

Up to this point, we have assumed that x is precisely calculated. In what follows, weassume that x is approximated by (m, n, p). We extend the Riemann sum calculation tocompute arctan(x) using the given approximation of x .

Theorem 5.6.4. Let x be a real number represented by (m, n, p). Then arctan(x) can be

represented by (m′, n′, p− 6) where m′

n′=( m

n)

N

∑N−1i=0

11+( i

N)2( m

n)2

and N = 2p−2d(mn)2e.

Proof. We consider two cases:

1. Suppose mn> 0. Since x is represented by (m, n, p) we can write:

m

n(1−

1

2p )< x <m

n(1+

1

2p )≤2m

n(5.53)

To prove the theorem, we should show that:

|arctan(x)−(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|<

1

2p−6 |(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2| (5.54)


|arctan(x)−(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|=

|arctan(x)−x

N

N−1∑

i=0

1

1+ ( iN)2 x2

+x

N

N−1∑

i=0

1

1+ ( iN)2 x2

−(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2| ≤

|arctan(x)−x

N

N−1∑

i=0

1

1+ ( iN)2 x2

|

+ |x

N

N−1∑

i=0

1

1+ ( iN)2 x2

−(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|

131


Thus, to prove inequality (5.54), it suffices to prove the following inequalities:

|arctan(x)−x

N

N−1∑

i=0

1

1+ ( iN)2 x2

|<1

2p−5 |(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2| (5.55)

|x

N

N−1∑

i=0

1

1+ ( iN)2 x2

−(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|

<1

2p−5 |(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2| (5.56)

Proof for inequality (5.55): We first consider the left hand side of inequality (5.55)and calculate an upper bound for it. From inequality (5.52) we can write:

|arctan(x)−x

N

N−1∑

i=0

1

1+ ( iN)2 x2

| ≤x3

N(1+ x2)(5.57)

To obtain an upper-bound for x3

N(1+x2), we consider the function f (x) = x3

N(1+x2)and

calculate its derivative:

f ′(x) =3x2 + x4

N(1+ x2)2> 0

Thus, f (x) is an increasing function and its maximum occurs when x gets its max-imum value. Inequality (5.53) implies that 2m

nis an upper bound for x and hence

we can rewrite inequality (5.57) as follows:

|arctan(x)−x

N

N−1∑

i=0

1

1+ ( iN)2 x2

| ≤x3

N(1+ x2)≤

8(mn)3

N(1+ 4(mn)2)

<8(m

n)3

N(1+ (mn)2)

(5.58)

We also calculate a lower bound for the right hand side of inequality (5.55):

1

2p−5 |(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|>(

1

2p−5 )(m

n)

N

N−1∑

i=0

1

1+ (N−1N)2(m

n)2

=(1

2p−5 ).(m

n).(

N2

N2 + (N − 1)2(mn)2)

>(1

2p−5 ).(m

n).(

N2

N2(1+ (mn)2))

=(m

n)

2p−5(1+ (mn)2)

(5.59)

132


To prove inequality (5.55), it suffices to show that the following inequality holds(see inequality (5.58),(5.59)):

8(mn)3

N(1+ (mn)2)<

(mn)

2p−5(1+ (mn)2)

We divide all the components bymn

(1+( mn)2)

, obtaining:

8(mn)2

N<

1

2p−5

Thus, it suffices to take N = 2p−2d(mn)2e.

Proof for inequality (5.56): To prove the inequality, we consider the calculationsin x

N

∑N−1i=0

11+( i

N)2 x2 and estimate the amount of error that we commit in the ap-

proximation( m

n)

N

∑N−1i=0

11+( i

N)2( m

n)2

.

From Theorem 5.5.2 and inequality (5.53), we conclude that 2 units of precision islost by approximating x2 by (m

n)2 and hence we obtain:

|x2 − (m

n)2|<

1

2p−2 |(m

n)2|

|(i

N)2 x2 − (

i

N)2(

m

n)2|<

1

2p−2 |(i

N)2(

m

n)2|

The approximation ( iN)2(m

n)2 of ( i

N)2 x2 is positive. Thus, we do not lose precision

by adding ( iN)2 x2 and 1 (see Theorem 5.5.4.i):

|(1+ (i

N)2 x2)− (1+ (

i

N)2(

m

n)2)|<

1

2p−2 |1+ (i

N)2(

m

n)2|

We lose 1 unit of precision by approximating the inverse of 1+ ( iN)2 x2 (see Theo-

rem 5.5.3):

|1

1+ ( iN)2 x2

−1

1+ ( iN)2(m

n)2|<

1

2p−3 |1

1+ ( iN)2(m

n)2|

We lose 2 units of precision in the approximation of xN

. 11+( i

N)2 x2 (see Theorem 5.5.2):

|x

N.

1

1+ ( iN)2 x2

−(m

n)

N.

1

1+ ( iN)2(m

n)2|<

1

2p−5 |(m

n)

N.

1

1+ ( iN)2(m

n)2|

The approximationsmn

N. 1

1+( iN)2( m

n)2

are positive for 0 ≤ i ≤ N − 1. Thus, we do not

133


lose precision by calculating the summation xN

∑N−1i=0

11+( i

N)2 x2 (see Theorem 5.5.4.i):

|x

N

N−1∑

i=0

1

1+ ( iN)2 x2

−(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|

<1

2p−5 |(m

n)

N

N−1∑

i=0

1

1+ ( iN)2(m

n)2|

2. Suppose mn< 0. We can write:

m

n(1+

1

2p )< x <m

n(1−

1

2p )

Observe that x < 0; we can use the following identity for arctan(x):

arctan(x) =−arctan(−x)

where −x > 0. We first approximate arctan(−x) using the first part of the proof.Afterwards, we apply Theorem 5.5.1 to approximate−arctan(−x). Unary negationdoes not influence the precision.

ut

Algorithm 8 Arctangent

Require: expr has the shape arctan(x)1: procedure COMPUTE(expr, p)2: m


3: N ← 2p+4d(mn)2e

4: m′

n′←( m

n)

N

∑N−1i=0

11+( i

N)2( m

n)2

5: return m′

n′

Algorithm 8 applies Theorem 5.6.4 to approximate arctan(x) with arbitrary preci-sion. Note that Theorem 5.6.4 predicts the amount of precision that is lost by calculatingarctan(x) independently of the argument x and hence Algorithm 8 calculates arctan(x)in one pass.

To confirm that arctan(x) is computable in one pass, we apply perturbation analysisand calculate the quantity | x f ′(x)

f (x)| for f (x) = arctan(x):

|x f ′(x)f (x)

|= |x( 1

1+x2 )

arctan(x)|= |

x

(1+ x2)arctan(x)|

Proposition B.4 (see Appendix B) shows that | x(1+x2)arctan(x)

| < 1; iterative computationsare not required for approximating arctan(x).

134

5.7. Approximating Transcendental Functions by Taylor Expansions

5.7 Approximating Transcendental Functions by TaylorExpansions

In this section we first briefly discuss the basics of approximating functions using Taylorexpansions. Afterwards, we use Taylor expansions to approximate sin(x) and cos(x).

Suppose f : D→ R is a function and I = (a, b)⊆ D such that:

• f has n continuous derivatives on I (denoted by f (i)(x) for 1≤ i ≤ n);

• f (n+1) exists on I ;

• x0 ∈ I .

Taylor’s theorem states that for every x ∈ I there is a number cx between x and x0 suchthat f (x) = Pn(x) + Rn(x) where:

Pn(x) =n∑

i=0

f (i)(x0)i!

(x − x0)i , Rn(x) =

f (n+1)(cx)(n+ 1)!

(x − x0)n+1 (5.60)

The formula Rn(x) is called the Lagrange form of the remainder [Spi67].In the remaining of this section, we discuss approximations for sin(x) and cos(x). Our

approximations are based on the following Taylor expansions around the point x0 = 0:

sin(x) =∞∑

i=0

(−1)i

(2i+ 1)!x2i+1 (5.61)

cos(x) =∞∑

i=0

(−1)i

(2i)!x2i (5.62)

For each function, we first describe an approximation that is applicable to the baseinterval I = (−1, 1) (see Section 5.7.1). Afterwards, we extend our calculations to thecomplete domain of the functions using range reduction identities (see Section 5.7.2).Proof of correctness for the base and general cases are provided. Moreover, the COM-PUTE(expr, p) function is extended to approximate sin(x) and cos(x) with arbitrary pre-cision. We use perturbation analysis to confirm the observations obtained from the ap-proximations.

5.7.1 Approximating Functions in the Base Interval

Sine

In this section we use the Taylor expansion from equality (5.61) to approximate sin(x).We assume that the input argument x is represented by (m, n, p) and |m

n|< 1.

Theorem 5.7.1. Let x be a real number represented by (m, n, p) such that −1 < mn<

1. Then sin(x) can be represented by (m′, n′, p − 2dlog2(2N − 1)e − 3) where m′

n′=

∑Ni=0

(−1)i

(2i+1)!(m

n)2i+1 and N ∈ N is an odd number such that ( 5

6)( (2N+2)!(2N−1)2

22N )> 2p.

135


where sgn is the sign function. To prove inequality (5.65), it suffices to show that thefollowing inequality holds (see (5.67),(5.68)):

|mn|2N+222N+2

(2N + 2)!<

sgn(mn)

2p−2dlog2(2N−1)e−2

N∑

i=0

(−1)i

(2i+ 1)!(m

n)

2i+1

This is equivalent to:

sgn(mn)

2p−2dlog2(2N−1)e−2

N∑

i=0

(−1)i

(2i+ 1)!(m

n)

2i+1−|m

n|2N+222N+2

(2N + 2)!=

sgn(mn)

2p−2dlog2(2N−1)e−2

�

m

n− (

1

3!)(

m

n)3 +

N∑

i=2

(−1)i

(2i+ 1)!(m

n)

2i+1�

−|m

n|2N+222N+2

(2N + 2)!> 0 (5.69)

The quantity sgn(mn)∑N

i=2(−1)i

(2i+1)!(m

n)2i+1 is positive (see Proposition B.5 in Appendix B).

Moreover, the approximation mn

satisfies |mn|< 1. To prove inequality (5.69) it is sufficient

to show:

sgn(mn)

2p−2dlog2(2N−1)e−2(m

n− (

1

3!)(

m

n)3)−

|mn|2N+222N+2

(2N + 2)!>

sgn(mn)(2N − 1)2

2p−2 (m

n− (

1

3!)(

m

n)3)−

|mn|322N+2

(2N + 2)!> 0 (5.70)

Inequality (5.70) is equivalent to:

sgn(m

n)(

m

n)(1− (

1

3!)(

m

n)2 −

2p+2N

(2N + 2)!(2N − 1)2(m

n)2)> 0

Since sgn(mn)(m

n)> 0 and (m

n)2 < 1, we should choose an N such that:

1

6+

2p+2N−2dlog2(2N−1)e

(2N + 2)!(2N − 1)2< 1

Thus, N should satisfy ( 56) (2N+2)!(2N−1)2

22N > 2p.Proof for inequality (5.66): We show that given an approximation m

nof x with preci-

sion p we can approximate∑N

i=0(−1)i

(2i+1)!x2i+1 by

∑Ni=0

(−1)i

(2i+1)!(m

n)2i+1 with precision p −

2dlog2(2N − 1)e − 2.

The sign of the terms (−1)i

(2i+1)!x2i+1 alternates between positive and negative. Thus,

adding two arbitrary terms with different signs from the expansion can significantlyreduce the precision (see Theorem 5.5.4.ii). To avoid this, we first consider specific

137


pairs of terms for which loss of precision due to addition is bounded. Then, we calcu-late the summation of these pairs. The following identity shows the way we calculate∑N

i=0(−1)i

(2i+1)!x2i+1:

N∑

i=0

(−1)i

(2i+ 1)!x2i+1 =

k∑

i=0

x4i+1

(4i+ 1)!(1−

x2

(4i+ 2)(4i+ 3))

Choosing N = 2k+ 1 allows us to make pairs of terms.The number x is given with precision p. Thus, we can approximate x2 with precision

p− 2 (see Theorem 5.5.2):

|x2 − (m

n)2|<

1

2p−2 |(m

n)2|

and hence

|x2

(4i+ 2)(4i+ 3)−

(mn)2

(4i+ 2)(4i+ 3)|<

1

2p−2 |(m

n)2

(4i+ 2)(4i+ 3)|

We approximate 1− x2

(4i+2)(4i+3)by 1−

( mn)2

(4i+2)(4i+3). Loss of precision in the approximation

can be estimated by calculating the quantity log2(1+

( mn )

2

(4i+2)(4i+3)

1−( m

n )2

(4i+2)(4i+3)

) (see Theorem 5.5.4.ii):

log2(1+

( mn)2

(4i+2)(4i+3)

1−( m

n)2

(4i+2)(4i+3)

)≤ log2(1+ 1

6

1− 16

) = log2(7

5)< 1

Thus, we lose at most 1 unit of precision:

|(1−x2

(4i+ 2)(4i+ 3))− (1−

(mn)2

(4i+ 2)(4i+ 3))|<

1

2p−3 |1−(m

n)2

(4i+ 2)(4i+ 3)|

The powers x4i+1 are approximated by (mn)4i+1 for 0 ≤ i ≤ k and 2dlog2(4i + 1)e units

of precision is lost in this operation. Thus, in the worst case, the precision is reduced by2dlog2(4k+ 1)e units:

|x4i+1 − (m

n)4i+1|<

1

2p−2dlog2(4k+1)e |(m

n)4i+1|=

1

2p−2dlog2(2N−1)e |(m

n)4i+1|

Multiplying approximations of x4i+1 by a constant does not influence the precision:

|x4i+1

(4i+ 1)!−(m

n)4i+1

(4i+ 1)!|<

1


n)4i+1

(4i+ 1)!|

138


The multiplication x4i+1

(4i+1)!(1 − x2

(4i+2)(4i+3)) can be approximated by multiplying the ap-

proximations( m

n)4i+1

(4i+1)!and 1−

( mn)2

(4i+2)(4i+3)(see Theorem 5.5.2):

|x4i+1

(4i+ 1)!(1−

x2

(4i+ 2)(4i+ 3))−(m

n)4i+1

(4i+ 1)!(1−

(mn)2

(4i+ 2)(4i+ 3))|

<1

2p−max{2dlog2(2N−1)e,3}−2|(m

n)4i+1

(4i+ 1)!(1−

(mn)2

(4i+ 2)(4i + 3))|

=1

2p−2dlog2(2N−1)e−2|(m

n)4i+1

(4i+ 1)!(1−

(mn)2

(4i+ 2)(4i+ 3))|

For the last equality, we use the assumptions ( 56)( (2N+2)!(N−1)2

22N−2dlog2(2N−1)e )> 2p and N = 2k+ 1; wecan conclude that N ≥ 3.

For 0 ≤ i ≤ k the terms( m

n)4i+1

(4i+1)!(1 −

( mn)2

(4i+2)(4i+3)) have the same sign which is deter-

mined by the sign of mn

(see Proposition B.5 in Appendix B). Thus, we can approximate∑k

i=0x4i+1

(4i+1)!(1− x2

(4i+2)(4i+3)) by

∑ki=0

( mn)4i+1

(4i+1)!(1−

( mn)2

(4i+2)(4i+3)) without losing precision (see

Theorem 5.5.4.i):

|k∑

i=0

x4i+1

(4i+ 1)!(1−

x2

(4i+ 2)(4i+ 3))−

k∑

i=0

(mn)4i+1

(4i+ 1)!(1−

(mn)2

(4i+ 2)(4i+ 3))|<

1

2p−2dlog2(2N−1)e−2|

k∑

i=0

(mn)4i+1

(4i+ 1)!(1−

(mn)2

(4i+ 2)(4i+ 3))|

ut

Theorem 5.7.1 provides a top-down approximation for sin(x) in the base interval.Loss of precision in this approximation is estimated independently of the argument x . Toshow that iterative calculations can be avoided in the base interval, we calculate | x f ′(x)

f (x)|

for f (x) = sin(x):

|x f ′(x)f (x)

|= |x · cos(x)

sin(x)|= |x · cot(x)| (5.71)

Proposition B.7 (see Appendix B) shows that |x · cot(x)| < 1 for x ∈ (−1,1). Thus, wecan approximate sin(x) in the base interval in one pass.

Cosine

In this section we introduce an approximation for cos(x) where x is represented by(m, n, p) and |m

n| < 1. Our approximation is based on the Taylor expansion from equal-

ity (5.62).

139


Theorem 5.7.2. Let x be a real number represented by (m, n, p) such that −1 < mn<

1. Then cos(x) can be represented by (m′, n′, p − 2dlog2(2N − 2)e − 3) where m′

n′=

∑Ni=0

(−1)i

(2i)!(m

n)2i and N ∈ N is an odd number such that (2N+1)!(2N−2)2

22N > 2p.

Proof. The real number x is represented by (m, n, p) and hence we can write:

m

n− |

m

n|<

m

n−

1

2p |m

n|< x <

m

n+

1

2p |m

n| ≤

m

n+ |

m

n| (5.72)

To prove the theorem, we need to show:

| cos(x)−N∑

i=0

(−1)i

(2i)!(m

n)

2i|<

1

2p−2dlog2(2N−2)e−3|

N∑

i=0

(−1)i

(2i)!(m

n)

2i| (5.73)


| cos(x)−N∑

i=0

(−1)i

(2i)!(m

n)

2i|=

| cos(x)−N∑

i=0

(−1)i

(2i)!x2i +

N∑

i=0

(−1)i

(2i)!x2i −

N∑

i=0

(−1)i

(2i)!(m

n)

2i| ≤

| cos(x)−N∑

i=0

(−1)i

(2i)!x2i |+ |

N∑

i=0

(−1)i

(2i)!x2i −

N∑

i=0

(−1)i

(2i)!(m

n)

2i|

We prove inequality (5.73) by showing that the following inequalities are valid:

| cos(x)−N∑

i=0

(−1)i

(2i)!x2i |<

1

2p−2dlog2(2N−2)e−2|

N∑

i=0

(−1)i

(2i)!(m

n)

2i| (5.74)

|N∑

i=0

(−1)i

(2i)!x2i −

N∑

i=0

(−1)i

(2i)!(m

n)

2i|<

1

2p−2dlog2(2N−2)e−2|

N∑

i=0

(−1)i

(2i)!(m

n)

2i| (5.75)

Proof for inequality (5.74): We use Taylor’s theorem (see equality (5.60)) and thebounds calculated for x in inequality (5.72) to rewrite the left hand side of inequal-ity (5.74):

| cos(x)−N∑

i=0

(−1)i

(2i)!x2i |= |

cos(2N+1)(cx)x2N+1

(2N + 1)!| ≤|m

n|2N+122N+1

(2N + 1)!(5.76)

We choose N = 2k + 1 ≥ 1 and apply Proposition B.6 (see Appendix B) to rewrite theright hand side of inequality (5.74):

1

2p−2dlog2(2N−2)e−2|

N∑

i=0

(−1)i

(2i)!(m

n)

2i|=

1

2p−2dlog2(2N−2)e−2

N∑

i=0

(−1)i

(2i)!(m

n)

2i(5.77)

140


To show that inequality (5.74) holds, it suffices to prove the following (see inequal-ity (5.76),(5.77)):

|mn|2N+122N+1

(2N + 1)!<

1

2p−2dlog2(2N−2)e−2

N∑

i=0

(−1)i

(2i)!(m

n)

2i(5.78)


1

2p−2dlog2(2N−2)e−2

N∑

i=0

(−1)i

(2i)!(m

n)

2i−|m

n|2N+122N+1

(2N + 1)!=

1

2p−2dlog2(2N−2)e−2(1−

1

2(m

n)2 +

N∑

i=2

(−1)i

(2i)!(m

n)

2i)−|m

n|2N+122N+1

(2N + 1)!> 0

From Proposition B.6 (see Appendix B) we conclude that the quantity∑N

i=2(−1)i

(2i)!(m

n)2i is

positive. Since |mn|< 1, it suffices to show:

1

2p−2dlog2(2N−2)e−2(1−

1

2(m

n)2)−

|mn|2N+122N+1

(2N + 1)!>

(2N − 2)2

2p−2 (1−1

2(m

n)2)−

22N+1

(2N + 1)!(m

n)2 > 0 (5.79)


1−1

2(m

n)2 −

2p+2N−1

(2N + 1)!(2N − 2)2(m

n)2 > 0

Since (mn)2 < 1, it is sufficient to choose an N that satisfies the following inequality:

1

2+

2p+2N−1

(2N + 1)!(2N − 2)2< 1

Thus, we should choose an N = 2k+ 1 that satisfies (2N+1)!(2N−2)2

22N > 2p.Proof for inequality (5.75): To prove the inequality, we estimate the amount of precisionthat is lost when we approximate

∑Ni=0

(−1)i

(2i)!x2i by

∑Ni=0

(−1)i

(2i)!(m

n)2i . The sign of the terms

(−1)i

(2i)!x2i alternates between positive and negative. Thus, adding two arbitrary terms with

different signs from the expansion can potentially cause significant loss of precision (seeTheorem 5.5.4.ii). To avoid this, we first consider pairs of terms for which addition canbe calculated with a bounded loss of precision. Afterwards, we calculate the summationof these pairs. The following identity shows our computation scheme:

N∑

i=0

(−1)i

(2i)!x2i =

k∑

i=0

x4i

(4i)!(1−

x2

(4i+ 1)(4i+ 2))

141


Choosing N = 2k+ 1 allows us to pair the terms of the summation.Since x is given with precision p, we can approximate x2 with precision p − 2 (see

Theorem 5.5.2):

|x2 − (m

n)2|<

1

2p−2 |m

n|2

Multiplying the approximation of x2 by a constant does not influence the precision:

|x2

(4i+ 1)(4i+ 2)−

(mn)2

(4i+ 1)(4i+ 2)|<

1

2p−2 |(m

n)2

(4i+ 1)(4i+ 2)|

We approximate 1− x2

(4i+1)(4i+2)by 1−

( mn)2

(4i+1)(4i+2). To estimate lose of precision in our

approximation, we calculate the quantity log2(1+

( mn )

2

(4i+1)(4i+2)

1−( m

n )2

(4i+1)(4i+2)

) (see Theorem 5.5.4.ii):

log2(1+

( mn)2

(4i+1)(4i+2)

1−( m

n)2

(4i+1)(4i+2)

)≤ log2(1+ 1

2

1− 12

) = log2 3< 2

Thus, we lose at most 2 units of precision:

|(1−x2

(4i+ 1)(4i+ 2))− (1−

(mn)2

(4i+ 1)(4i+ 2))|<

1

2p−4 |1−(m

n)2

(4i+ 1)(4i+ 2)|

Approximating x4i by (mn)4i reduces the precision by 2dlog2(4i)e units (see Lemma B.9

in Appendix B); in the worst case we lose 2dlog2(4k)e units of precision:

|x4i − (m

n)4i |<

1

2p−2dlog2(4k)e |(m

n)4i |=

1


n)4i |

Multiplying (mn)4i by a constant factor does not influence the precision of the calculation:

|x4i

(4i)!−(m

n)4i

(4i)!|<

1


n)4i

(4i)!|

We approximate x4i

(4i)!(1− x2

(4i+1)(4i+2)) by multiplying the approximations

( mn)4i

(4i)!and (1−

( mn)2

(4i+1)(4i+2)) (see Theorem 5.5.2):

|x4i

(4i)!(1−

x2

(4i+ 1)(4i+ 2))−(m

n)4i

(4i)!(1−

(mn)2

(4i+ 1)(4i+ 2))|

<1

2p−max{4,2dlog2(2N−2)e}−2|(m

n)4i

(4i)!(1−

(mn)2

(4i+ 1)(4i+ 2))|

=1

2p−2dlog2(2N−2)e−2|(m

n)4i

(4i)!(1−

(mn)2

(4i+ 1)(4i+ 2))|

142


To obtain the last equality, we use the assumptions (2N+1)!(2N−2)2

22N > 2p and N = 2k+ 1;we conclude that N ≥ 3.

The terms( m

n)4i

(4i)!(1 −

( mn)2

(4i+1)(4i+2)) are positive for 0 ≤ i ≤ k (see Proposition B.6 in

Appendix B) and hence we can approximate the summation∑k

i=0x4i

(4i)!(1 − x2

(4i+1)(4i+2))

without losing precision (see Theorem 5.5.4.i):

|k∑

i=0

x4i

(4i)!(1−

x2

(4i+ 1)(4i+ 2))−

k∑

i=0

(mn)4i

(4i)!(1−

(mn)2

(4i+ 1)(4i+ 2))|<

1

2p−2dlog2(2N−2)e−2|

k∑

i=0

(mn)4i

(4i)!(1−

(mn)2

(4i + 1)(4i+ 2))|

ut

Theorem 5.7.2 estimates loss of precision in cos(x) in the base interval independentlyof the argument x . To show that iterative computations can be avoided in the baseinterval, we calculate | x f ′(x)

f (x)| for f (x) = cos(x):

|x f ′(x)f (x)

|= |−x · sin(x)

cos(x)|= |x · tan(x)| (5.80)

From Proposition B.8 (see Appendix B) we conclude that |x · tan(x)| < tan(1) for x ∈(−1,1). Thus, we can approximate cos(x) in the base interval in one pass.

5.7.2 Extending Base Interval Approximations

In Section 5.7.1 and 5.7.1, we discussed approximations for sin(x) and cos(x) in thebase interval. In what follows, we show that range reduction identities can be used toextend these approximations to calculate sine and cosine for an argument x representedby (m, n, p) where |m

n| ≥ 1.

In our calculations, we use a representation (m′, n′, p) of π. This representation canbe obtained based on our approximation for arctan(x) (see Section 5.6.3) and the fol-lowing identity:

π= 4 arctan(1)

Sine

Theorem 5.7.3. Let x be a real number represented by (m, n, p) such that |mn| ≥ 1 and

(m′, n′, p) be a representation for π. Suppose mn= m

n+ k m′

n′where k ∈ Z and 0< m

n< m′

n′.

The value of sin(x) can be approximated as follows:

143


i. If 0< mn< 1, then sin(x) can be represented by (m1, n1, p− i1) where:

i1 =s1 + t1

m1

n1=

N1∑

i=0

(−1)i

(2i+ 1)!(m

n)

2i+1

ii. If 1≤ mn< 2, then sin(x) can be represented by (m2, n2, p− i2) where:

i2 =s1 + t2 + 2

m2

n2=2� N1∑

i=0

(−1)i

(2i+ 1)!(

m

2n)

2i+1�

·� N2∑

i=0

(−1)i

(2i)!(

m

2n)

2i�

iii. If 2≤ mn< m′

n′, then sin(x) can be represented by (m3, n3, p− i3) where:

i3 =s1 + s2 + t3 + 6

m3

n3=8� N1∑

i=0

(−1)i

(2i+ 1)!(

m

4n)

2i+1�

·� N2∑

i=0

(−1)i

(2i)!(

m

4n)

2i�

·� N3∑

i=0

(−1)i

(2i+ 1)!(

m′

4n′−

m

4n)

2i+1�

·� N4∑

i=0

(−1)i

(2i)!(

m′

4n′−

m

4n)

2i�

In the approximations above, s1, s2, N1, N2, N3, N4 ∈ N are the smallest natural numberssatisfying:

s1 ≥ log2(1+

min(| mn|,k m′

n′ )

max(| mn|,k m′

n′ )

1−min(| m

n|,k m′

n′ )

max(| mn|,k m′

n′ )

) , s2 ≥ log2(1+

min( m′

4n′ ,m4n)

max( m′4n′ ,

m4n)

1−min( m′

4n′ ,m4n)

max( m′4n′ ,

m4n)

)

(5

6)((2N1 + 2)!(2N1 − 1)2

22N1)> 2p−s1 ,

(2N2 + 1)!(2N2 − 2)2

22N2> 2p−s1

(5

6)((2N3 + 2)!(2N3 − 1)2

22N3)> 2p−s1−s2 ,

(2N4 + 1)!(2N4 − 2)2

22N4> 2p−s1−s2

and t1, t2 ∈ N are defined as follows:

t1 =2dlog2(2N1 − 1)e+ 3

t2 =max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3)t3 =max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3,

2dlog2(2N3 − 1)e+ 3,2dlog2(2N4 − 2)e+ 3)

144


Proof. Since |mn| ≥ 1, we can choose k ∈ Z such that m

n= m

n+ k m′

n′and 0 < m

n< m′

n′.

Suppose y = x + kπ. We use the following identity to calculate sin(x):

sin(x) = sin(x + kπ) = sin(y) (5.81)

We approximate y by mn= m

n+ k m′

n′(see Theorem 5.5.4.ii). By performing this approxi-

mation, we lose s1 ∈ N units of precision where s1 is the smallest number satisfying:

s1 ≥ log2(1+

min(| mn|,k m′

n′ )

max(| mn|,k m′

n′ )

1−min(| m

n|,k m′

n′ )

max(| mn|,k m′

n′ )

)

We consider three cases for calculating sin(y):

1. Suppose 0 < mn< 1. We apply Theorem 5.7.1. Thus, t1 = 2dlog2(2N1 − 1)e+ 3

units of precision is lost in the approximation of sin(y). A total of s1 + t1 units ofprecision is lost in the approximation of sin(x).

2. Suppose 1 ≤ mn< 2. We use the following identity to bring the argument within

the base interval:

sin(y) = 2sin(y

2) cos(

y

2) (5.82)

We approximate y2

by m2n

. Since 12≤ m

2n< 1, we apply Theorem 5.7.1 and 5.7.2 to

approximate sin( y2) and cos( y

2), respectively. Loss of precision in these calculations

is as follows:

t2 =max(2dlog2(2N1 − 1)e+ 3, 2dlog2(2N2 − 2)e+ 3)

The multiplication in equality (5.82) reduces the precision by 2 units (see Theo-rem 5.5.2). A total of s1 + t2 + 2 units of precision is lost in the approximation ofsin(x).

3. Suppose 2 ≤ mn< m′

n′. We use the following identity to bring the argument within

the base interval.

sin(y) = 2sin(y

2) cos(

y

2)

= 4sin(y

4) cos(

y

4) cos(

y

2)

= 4sin(y

4) cos(

y

4) sin(

π

2−

y

2)

= 8sin(y

4) cos(

y

4) sin(

π

4−

y

4) cos(

π

4−

y

4) (5.83)

We approximate y4

and π

4− y

4by m

4nand m′

4n′− m

4n, respectively. We lose s2 ∈ N units

of precision in this approximation (see Theorem 5.5.4.ii) where s2 is the smallest

145


number satisfying:

s2 ≥ log2(1+

min( m′

4n′ ,m4n)

max( m′4n′ ,

m4n)

1−min( m′

4n′ ,m4n)

max( m′4n′ ,

m4n)

)

We apply Theorem 5.7.1 and 5.7.2 to approximate sin( y4), cos( y

4), sin(π

4− y

4), and

cos(π4− y

4). Lose of precision in these approximations can be calculated as follows:

t3 =max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3,

2dlog2(2N3 − 1)e+ 3,2dlog2(2N4 − 2)e+ 3)

The three multiplications in sin( y4) cos( y

4) sin(π

4− y

4) cos(π

4− y

4) reduce the precision

by 6 units (see Theorem 5.5.2). A total of s1 + s2 + t3 + 6 units of precision is lostin the approximation of sin(x).

ut

Algorithm 9 applies Theorem 5.7.1 and 5.7.3 to approximate sin(x) with arbitraryprecision. In this algorithm, initially, we calculate x with a precision that is adequatefor calculations in the base interval. However, if the obtained approximation is outsidethe base interval, we use the half-angle formula or add rational multiples of π to theargument (see equality (5.81) and (5.83)).

Observe that an arbitrary amount of precision can be lost in the approximation ofx + kπ and π

4− y

4when x ≈ −kπ. Hence, iterative computations might be necessary in

the approximation (see Line 4,22,29,38 in Algorithm 9). To show that this is essential forsine, we reconsider the perturbation analysis in equality (5.71) for f (x) = sin(x). Thequantity |x · cot(x)| can be arbitrary large for x ≈−kπ. Thus, iterative computations areessential for approximating sin(x).

Cosine

Theorem 5.7.4. Let x be a real number represented by (m, n, p) such that |mn| ≥ 1 and

(m′, n′, p) be a representation for π. Suppose mn= m

n+ (2k + 1) m′

2n′where k ∈ Z and

0< mn< m′

n′. The value of cos(x) can be approximated as follows:

i. If 0< mn< 1, then cos(x) can be represented by (m1, n1, p− i1) where:

i1 =s1 + t1

m1

n1=(−1)k

N1∑

i=0

(−1)i

(2i+ 1)!(m

n)

2i+1

146


Algorithm 9 Sine

Require: expr has the shape sin x1: procedure COMPUTE(expr, p)2: Choose an odd N such that ( 5

6)( (2N+2)!(N−1)2

22N )> 2p+2dlog2(2N−1)e+3

3: px ← p+ 2dlog2(2N − 1)e+ 34: repeat5: m


6: if −1< mn< 1 then . Theorem 5.7.1

7:m0

n0←∑N

i=0(−1)i

(2i+1)!(m

n)2i+1

8: return m0

n0

9: else10: m′

n′← COMPUTE(4arctan(1), px)

11: Choose k ∈ Z such that 0< mn+ k m′

n′< m′

n′

12: mn← m

n+ k m′

n′

13: Choose s1 ∈ N such that s1 ≥ log2(1+

min(| mn |,km′n′)

max(| mn |,km′n′)

1−min(| mn |,k

m′n′)

max(| mn |,km′n′)

)

14: Choose an odd N1 such that ( 56)( (2N1+2)!(2N1−1)2

22N1)> 2px−s1

15: Choose an odd N2 such that (2N2+1)!(2N2−2)2

22N2> 2px−s1


17: t1← 2dlog2(2N1 − 1)e+ 318: if px − s1 − t1 ≥ p then

19:m1

n1=∑N1

i=0(−1)i

(2i+1)!(m

n)

2i+1

20: return m1

n1

21: else22: px ← px + 123: else if 1≤ m

n< 2 then . Theorem 5.7.3.ii

24: t2←max(2dlog2(2N1 − 1)e+ 3, 2dlog2(2N2 − 2)e+ 3)25: if px − s1 − t2 − 2≥ p then

26:m2

n2= 2�∑N1

i=0(−1)i

(2i+1)!( m

2n)

2i+1��∑N2

i=0(−1)i

(2i)!( m

2n)

2i�

27: return m2

n2

28: else29: px ← px + 130: else . Theorem 5.7.3.iii31: Choose an odd N3 such that ( 5

6)( (2N3+2)!(2N3−1)2

22N3)> 2px−s1−s2


22N4> 2px−s1−s2

33: t3←max(2dlog2(2N1 − 1)e+ 3, 2dlog2(2N2 − 2)e+ 3,2dlog2(2N3 − 1)e+ 3,2dlog2(2N4 − 2)e+ 3)

147


Algorithm 9 Sine (Continued)

34: if px − s1 − s2 − t3 − 6≥ p then

35:m3

n3= 8�∑N1

i=0(−1)i

(2i+1)!( m

4n)

2i+1��∑N2

i=0(−1)i

(2i)!( m

4n)

2i�

�∑N3

i=0(−1)i

(2i+1)!( m′

4n′− m

4n)

2i+1��∑N4

i=0(−1)i

(2i)!( m′

4n′− m

4n)

2i�

36: return m3

n3


ii. If 1≤ mn< 2, then cos(x) can be represented by (m2, n2, p− i2) where:

i2 =s1 + t2 + 2

m2

n2=2 · (−1)k

� N1∑

i=0

(−1)i

(2i+ 1)!(

m

2n)

2i+1�

·� N2∑

i=0

(−1)i

(2i)!(

m

2n)

2i�

iii. If 2≤ mn< m′

n′, then cos(x) can be represented by (m3, n3, p− i3) where:

i3 =s1 + s2 + t3 + 6

m3

n3=8 · (−1)k

� N1∑

i=0

(−1)i

(2i+ 1)!(

m

4n)

2i+1�

·� N2∑

i=0

(−1)i

(2i)!(

m

4n)

2i�

·� N3∑

i=0

(−1)i

(2i+ 1)!(

m′

4n′−

m

4n)

2i+1�

·� N4∑

i=0

(−1)i

(2i)!(

m′

4n′−

m

4n)

2i�

In the approximations above, s1, s2, N1, N2, N3, N4 ∈ N are the smallest natural numberssatisfying:

s1 ≥ log2(1+

min(| mn|,(2k+1) m′

2n′ )

max(| mn|,(2k+1) m′

2n′ )

1−min(| m

n|,(2k+1) m′

2n′ )

max(| mn|,(2k+1) m′

2n′ )

) , s2 ≥ log2(1+

min( m′

4n′ ,m4n)

max( m′4n′ ,

m4n)

1−min( m′

4n′ ,m4n)

max( m′4n′ ,

m4n)

)

(5

6)((2N1 + 2)!(2N1 − 1)2

22N1)> 2p−s1 ,

(2N2 + 1)!(2N2 − 2)2

22N2> 2p−s1

(5

6)((2N3 + 2)!(2N3 − 1)2

22N3)> 2p−s1−s2 ,

(2N4 + 1)!(2N4 − 2)2

22N4> 2p−s1−s2

and t1, t2 ∈ N are defined as follows:

t1 =2dlog2(2N1 − 1)e+ 3

t2 =max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3)t3 =max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3,

2dlog2(2N3 − 1)e+ 3, 2dlog2(2N4 − 2)e+ 3)

148

5.8. Experiments

Proof. Since |mn| ≥ 1, we can choose k ∈ Z such that m

n= m

n+(2k+1) m′

2n′and 0< m

n< m′

n′.

Suppose y = x + (2k+ 1)π2

. We use the following identity to calculate cos(x):

cos(x) = (−1)k sin(x + (2k+ 1)π

2) = (−1)k sin(y)

We approximate y by mn= m

n+(2k+1) m′

2n′. From Theorem 5.5.4.ii, we can conclude that

s1 ∈ N units of precision will be lost in this approximation where s1 is the smallest naturalnumber satisfying:

s1 ≥ log2(1+

min(| mn|,(2k+1) m′

2n′ )

max(| mn|,(2k+1) m′

2n′ )

1−min(| m

n|,(2k+1) m′

2n′ )

max(| mn|,(2k+1) m′

2n′ )

)

We apply Theorem 5.7.3 to approximate sin(y) and determine the loss of precision inthe approximation. From Theorem 5.5.1 we can conclude that the factor (−1)k does notinfluence the precision of the approximation. ut

Algorithm 10 applies Theorem 5.7.2 and 5.7.4 to approximate cos(x) with a desiredprecision. The algorithm first calculates x with a precision that is sufficient for approx-imating cos(x) in the base interval. Similar to sin(x), we use range reduction identitiesto calculate cos(x) for an arbitrary x .

Observe that a significant amount of precision might be lost in the approximationwhen x ≈ −(2k+1)

2π. Thus, iterative computations might be necessary in our approxima-

tion (see Line 4,22,29,38 in Algorithm 10). To show that these recomputations are essen-tial, we reconsider the perturbation analysis of equality (5.80). The quantity |x · tan(x)|can be arbitrary large for x ≈ −(2k+1)

2π and hence iterative computations are unavoidable

for cos(x).

5.8 Experiments

In this section we report on some experiments that we have done with the algorithmsproposed throughout this chapter. These experiments are based on a set of rewrite rulesin the mCRL2 language that allows us to compute with a subset of the operations de-scribed by grammar (5.1). In our prototype implementation, rational numbers are themost basic type of expressions and unary negation, multiplication, inverse, addition, andsquare root are the supported operations.

Fig. 5.5 represents a set of expressions and the runtime results for computing themin mCRL2 with different precisions. These experiments are performed on a machinerunning Fedora with an Intel 2.2 GHz CPU and 900 GB RAM.

One of the main goals of the experiments is to see that the proposed algorithms yieldcorrect results in practice. To this end, we have computed the expressions from Fig. 5.5 inMathematica [Wol] and validated the results computed by our mCRL2 implementation.

149


Algorithm 10 Cosine

Require: expr has the shape cos x1: procedure COMPUTE(expr, p)2: Choose an odd N such that (2N+1)!(2N−2)2

22N > 2p+2dlog2(2N−2)e+2

3: px ← p+ 2dlog2(2N − 2)e+ 24: repeat5: m


6: if −1< mn< 1 then . Theorem 5.7.2

7:m0

n0=∑N

i=0(−1)i

(2i)!(m

n)2i

8: return m0

n0

9: else10: m′

n′← COMPUTE(4 arctan(1), px)

11: Choose k ∈ Z such that 0< mn+ (2k+ 1) m′

2n′< m′

n′

12: mn← m

n+ (2k+ 1) m′

2n′

13: Choose s1 ∈ N such that s1 ≥ log2(1+

min(| mn |,(2k+1) m′2n′)

max(| mn |,(2k+1) m′2n′)

1−min(| mn |,(2k+1) m′

2n′)

max(| mn |,(2k+1) m′2n′)

)

14: Choose an odd N1 such that ( 56)( (2N1+2)!(2N1−1)2

22N1)> 2px−s1


22N2> 2px−s1


17: t1← 2dlog2(2N1 − 1)e+ 318: if px − s1 − t1 ≥ p then

19:m1

n1= (−1)k

∑N1

i=0(−1)i

(2i+1)!(m

n)

2i+1

20: return m1

n1

21: else22: px ← px + 123: else if 1≤ m

n< 2 then . Theorem 5.7.4.ii

24: t2←max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3)25: if px − s1 − t2 − 2≥ p then

26:m2

n2= 2 · (−1)k

�∑N1

i=0(−1)i

(2i+1)!( m

2n)

2i+1��∑N2

i=0(−1)i

(2i)!( m

2n)

2i�

27: return m2

n2

28: else29: px ← px + 130: else . Theorem 5.7.4.iii31: Choose an odd N3 such that ( 5

6)( (2N3+2)!(2N3−1)2

22N3)> 2p−s1−s2


22N4> 2p−s1−s2

33: t3←max(2dlog2(2N1 − 1)e+ 3,2dlog2(2N2 − 2)e+ 3,2dlog2(2N3 − 1)e+ 3, 2dlog2(2N4 − 2)e+ 3)

150

5.8. Experiments

Algorithm 10 Cosine (Continued)

34: if px − s1 − s2 − t3 ≥ p then

35:m3

n3= 8 · (−1)k

�∑N1

i=0(−1)i

(2i+1)!( m

4n)

2i+1��∑N2

i=0(−1)i

(2i)!( m

4n)

2i�

�∑N3

i=0(−1)i

(2i+1)!( m′

4n′− m

4n)

2i+1��∑N4

i=0(−1)i

(2i)!( m′

4n′− m

4n)

2i�

36: return m3

n3


Fig. 5.5 also confirms certain observations discussed throughout this chapter. For in-stance, based on Theorem 5.5.4 we expect to encounter the “loss of significance” problemwhile computing

p6−p

5; computing this expression requires iterative computations ofthe arguments

p6 and

p5 until the required precision is guaranteed for

p6−p

5. More-over, the columns for

p6 −p

5 and 1p6+p

5from Fig. 5.5 motivate an extension of our

approach with a set of rewrite rules to avoid iterative computations for certain types ofexpressions; see the discussion in Section 5.5.4 on computing

px + 1−

px .

Finally, the obtained runtime results set a baseline and indicate certain improvementpoints in our proposed algorithms. For instance, by revisiting the proof of Theorem 5.5.5one can reduce the number of iterations (N) required for approximating square rootwith a desired precision p. In this way, we can avoid unnecessary iterations that yieldmore accurate approximations than the desired precision. The approximations computedin our experiments also indicate that due to the chosen N expressions containing squareroot are sometimes computed with a precision higher than the desired precision specifiedin the input. This justifies the runtime results for certain expressions from Fig. 5.5 whereincreasing the precision does not significantly change the computation time.

Precision (p)Expression p

2p

513p

17+1p211

p6−p

5 1p6+p

5

5 0.43 0.45 0.51 27.05 0.4610 0.44 0.48 0.51 28.08 0.4650 0.46 0.53 0.66 327.68 0.54100 0.48 0.79 1.29 4213.19 0.89200 0.48 0.8 1.21 4108.97 0.86400 0.58 1.72 3.19 81759.86 1.95650 0.97 5.59 13.28 100000+ 6.53

Figure 5.5: Runtime results (in seconds) for a prototype implementation in mCRL2

151


5.9 Related Work

An implementation for a bottom-up approach to exact real arithmetic is proposed in[Mül01]. For a given expression, the inputs are computed with predefined precisions anda bottom-up scheme is used to determine the guaranteed precision of the output. Iterativecomputations are required if the obtained precision is not adequate. A formalizationof a top-down approach in a theorem prover is proposed in [O’C08]. The author firstprovides a definition for a metric space based on a ball relation. Afterwards, real numbersare defined as the completion of the metric space Q. Rational operations are lifted toapproximate operations on real numbers. This approach is optimized in [KS13].

Two closely-related top-down approaches based on absolute errors have been studiedin [GL00; MM05]. These approaches mainly differ in their approximations of the tran-scendental functions. In [GL00] the authors introduce a general way for calculating withTaylor expansions and apply this method to approximate the transcendental functions. In[MM05], the approximations of the transcendental functions are treated separately andin a more ad-hoc way. In contrast, our approach is based on relative errors. We providedetailed proofs of correctness for each operation and use perturbation analysis to identifyessential recomputations.

In [CNR11] the authors propose a layered framework for computations with realnumbers. The lowest layer is an implementation of floating point arithmetic. In the sec-ond layer, arithmetic operations are approximated using polynomial models. The highestlayer supports more advanced features such as differential operations. Proof of correct-ness in a theorem prover and an implementation based on [CNR11] are also available. Inthis chapter, we have focused on approximating specific operations, whereas in [CNR11]polynomial models are discussed in an abstract way without concrete examples fromwell-known arithmetic operations.

The approach introduced in [Pot98] is based on linear fractional transformations(LFTs). Computations are encoded as trees of LFTs; various operations are defined toextract the result of a computation from the corresponding tree. However, this approachdoes not specify a top-down scheme to relate the desired precision in the output andthe required operations on the expression tree. Expression trees are evaluated using lazyevaluation; computations terminate when adequate information is available in the rootof a tree.

A symbolic approach to exact real arithmetic has been proposed in [Kel00]. The au-thor uses infinite binary sequences in the golden ratio base to represent real numbers.To calculate an expression, first the symbolic techniques available in Maple are appliedto obtain a simplified expression. Additional Maple procedures are implemented by theauthor to extract binary sequences from simplified expressions. Performing operationson binary sequences is also possible. However, choosing a suitable balance between sym-bolic computations and direct manipulation of binary sequences depends on the givenexpression. As indicated in [Kel00], using this approach to its full potentials requiresexpertise in Maple. Moreover, the procedure might need adaptations for each problem.

152

5.10. Conclusions

5.10 Conclusions

In this chapter, we proposed a simple representation for real numbers and discussed atop-down approach for approximating various arithmetic operations with arbitrary pre-cision. The focus was on:

• providing complete algorithms and proofs of correctness for the approximations,and

• perturbation analysis to identify essential iterative computations.

Existing exact real arithmetic approaches have explored different representations forreal numbers; approximations for algebraic operations and transcendental functions havealso been proposed based on these representations. As far as we can see, proofs of cor-rectness for existing approaches are restricted to basic operations. Moreover, no formalreasoning is provided to prove the necessity of iterative computations.

We envisage various extensions of the presented approach. From a practical pointof view, some optimizations are essential. For example, the coefficients m and n in therepresentation (m, n, p) can grow rapidly during computations. Thus, space efficiency isa relevant concern. One can consider an alternative representation in which large coef-ficients are represented in a more efficient way. Moreover, the computational efficiencyof the transcendental functions can be improved by reducing the amount of requiredcomputations (i.e, number of rectangles in Riemann sums, number of terms in Taylorexpansions) to guarantee the desired precision.

As discussed in Section 5.5.4, in certain computational problems, computing the ex-pressions as they are would lead to loss of precision, whereas rewriting the expressionswould allow us to compute them in one pass. Our top-down approach can be extendedwith a set of rewrite rules that transform problematic expressions into expressions thatcan be calculated in one pass.

From a practical point of view, the theory developed in this chapter can be a basisto address various problems. As an example, we can consider the problem discussed inSection 3.9.3 about test data generation and output validation; while testing an industrialimplementation based on a mathematical model, we have encountered failed test casesdue to differences in computation accuracies between the implementation code and themodel. Due to the limited effect of propagation errors in our models, an ad-hoc solutionin Section 3.9.3 was sufficient. Instead, a systematic solution would be based on:

• implementations that rely on a library of our exact real arithmetic algorithms forcomputations;

• models that compute expressions containing real numbers using a high-level spec-ification of the proposed algorithms.

As a vision for the latter case, one can consider integrating such a description of realoperations into existing specification and analysis technologies. For instance, it would beinteresting to have a set of rewrite rules that allow us to compute with real numbers inthe mCRL2 language. This requires addressing the efficiency issues discussed earlier inthis section.

153

Chapter 6

Conclusions

In the previous chapters we discussed various practical and theoretical aspects of model-driven software engineering. This chapter concludes the thesis by summarizing the con-tributions of our work (Section 6.1) and suggesting directions for future research (Sec-tion 6.2).

6.1 Contributions

DSLs are getting a lot of attention from industry. Experiences reported by various authors[Voe+13; ADR95] illustrate that practitioners have shown an interest in defining DSLsand using them in industrial practice. Code generators enable automatic generation ofsource code from domain-specific models and hence investments on specifying behaviorof software in terms of models pay off quickly. This return on investment is typicallymore significant when a DSL is used to develop a family of software systems.

In this thesis we have investigated various aspects of software development usingDSLs. In particular, we have developed techniques to improve the quality of softwaredeveloped by DSL approaches. Fig. 6.1 gives an overview of the techniques we have usedin this thesis.

To structure the section, we restate the research questions formulated in Chapter 1and summarize our contributions regarding each question.

RQ1: How can we validate the semantic correctness of the transformationsfrom a DSL in a practical way?

In Chapter 2 we discussed about transformations from a DSL and showed that thepresence of multiple transformations from a language immediately raises questions abouttheir correctness with respect to the semantics of the DSL. To tackle this problem, weadvocated the use of a formal semantics to assign precise meanings to the language con-structs. This was a first step towards resolving potential inconsistencies between transfor-mations. We also proposed to use equivalence checking and model-based testing to vali-date the correctness of the generated implementations and analysis models with respect

155

Conclusions

DSL Model Generate

Generate

Generate

Verification Model

Simulation Model

Test Model

Implementation

Performance

Analysis Model

GenerateGenerate

Verifier & Debugger

Formalized Properties

Report Fault Location

Model-based

Testing Against

Model-based

Testing Against

Checking Equivalence

Of Behaviors

Checking

Consistency w.r.t.

Semantics &


Chapter 4

Chapter 2

Chapter 3

Implementation

Performance

Analysis Model

Checking

Consistency w.r.t.

Semantics &


Figure 6.1: A Vision on Improving the Quality of Software Developed by DSL Approaches

to the formalized semantics (see Fig. 6.1 where we used the transformation to verifica-tion models to formalize the semantics of the DSL). The main benefit of our approach isthat equivalence checking and model-based testing are well-known techniques supportedby a number of tools (mCRL2 [Mcr] and CADP [Gar+11] support equivalence checking;JTorX [Bel10] and Axini [Axi] implement the ioco theory for model-based testing andsupport automated test generation from labeled transition systems). Hence, after writinga formal semantics, the use of these techniques can be automated. Our approach wasfeasible for an industrial DSL and effectively identified subtle inconsistencies betweendifferent transformations.

For a well-established DSL, one can use a more rigorous approach and prove the cor-rectness of transformations instead of assessing the correctness of the implementationsand analysis models generated from DSL models. In contrast with our approach, writingproofs for transformations is more time-consuming, demands user ingenuity in mathe-matical proofs, and requires additional mechanisms to cope with potential changes inthe transformations. Thus, it is more difficult to integrate such a rigorous approach in

156

6.1. Contributions

industrial software engineering practice.

RQ2: How can we validate the consistency between multiple transformationswhen certain platform-specific implementation details introduced by a code gen-erator are relevant for other transformations?

In Chapter 3 we discussed further about the consistency between transformationsfrom a DSL and indicated that this problem becomes more challenging when the im-plementation details introduced by a specific code generator (e.g. for a specific targetplatform) also influence the notion of consistency between transformations. To tacklethis problem for a given DSL, we proposed to formalize the semantics of the DSL and theimplementation details introduced by a code generator independently. We distinguishedbetween the semantics and implementation details to avoid cluttering the semantics withdecisions that are specific to a code generator. This distinction is particularly relevantwhen there are multiple code generators for different platforms. Similar to Chapter 2,the formalizations are essential for resolving conflicting interpretations. Furthermore,we used these formalizations and defined a notion of consistency between the gener-ated analysis models and implementation code. We used this notion to derive test casesand validate the generated analysis models and implementation code; Fig. 6.1 illustratesour approach for two target platforms and transformations to implementation code andanalysis models that are specific for these platforms.

We showed that our testing approach can be automated. Hence, in our approach,validating the consistency between the models and implementation generated from aDSL model does not require additional efforts from the user.

RQ3: How can we integrate state-of-the-art formal analysis techniques withDSLs?

In Chapter 4 we discussed about the correctness of domain-specific models as an es-sential factor in obtaining reliable software from DSLs. In addition to basic validationtechniques (e.g., syntax checking, type checking), we developed more advanced typesof validation and verified properties against DSL models using state-of-the-art formaltechniques (e.g., SMT solving). Although the use of these techniques was automated, ex-perimenting with multiple DSL models and properties revealed that analyzing counterex-amples for violated properties can be difficult. As another contribution, we developed anautomated debugging procedure to assist the user in identifying the cause of a violatedproperty. The results of the debugging procedure are traced back to the DSL model andare displayed in the DSL editor; see Fig. 6.1.

It should be noted that we applied the techniques mentioned above on specific DSLs.Solving some of the problems studied in this thesis in a different context requires moreelaborate theories (see [Cra15] for a theory on generating counterexamples from µ-calculus model checking problems). Empirical studies are also essential to evaluate theefficiency and usability of the used tools (e.g., SMT solvers) in industrial applications.However, due to the positive results that we obtained in our experiments, Fig. 6.1 can beconsidered as a vision for extending state-of-the-art DSL techniques such as defining theabstract and concrete syntax of a DSL, type checking, code generation, writing unit tests

157

Conclusions

at the level of DSL models or at the level of generated implementations (see [Voe13] fora detailed discussion about state-of-the-art DSL techniques).

RQ4: How to develop rigorous numerical methods to support formal analysistechniques?

In Chapter 5 we discussed about developing numerical methods to support formalanalysis on models that rely on real numbers. This was inspired by various problemsencountered during this research for which computations with arbitrary precision wereessential (see Section 3.9.3 for an example). Rigorous numerical methods also play acentral role in various techniques used for analysis and synthesis of safety-critical sys-tems [Bre+15; Hen+00]. In Chapter 5 we developed an exact real arithmetic approachand approximated various algebraic and transcendental functions. We used a top-downapproach, i.e., determining the required precision of each sub-expression based on theprecision required for its immediate parent expression. Errors of approximations are rep-resented by relative errors in our approach. One of the contributions of Chapter 5 is thedetailed algorithms and proofs of correctness that we have provided for the consideredoperations.

The devised algorithms show that operations such as x− y and ex may require multi-ple rounds of calculations to guarantee the required precision, whereas x ·y and arctan(x)are among the functions that can be calculated in one pass. We developed a perturbationanalysis method to distinguish cases for which recomputations are inherent to the oper-ation. We applied perturbation analysis to show that our approximation procedures onlyrecompute expressions when this is unavoidable.

6.2 Future Work

In the rest of this chapter we discuss possible extensions of the work presented in thisthesis.

In the previous chapters, we have demonstrated various formal techniques that canbe used to detect faults in a model-driven approach based on domain-specific models.We have used:

• formalized semantics to resolve conflicting interpretations of a DSL;

• verification and simulation to validate DSL models;

• equivalence checking and model-based testing to validate the correctness of trans-formations.

It would be interesting to conduct empirical studies and investigate the initial investmentin these techniques, the amount of effort required for applying them in practice, and theireffectiveness in detecting mistakes. The results of such studies can be used to balance theeffort invested in various development activities in DSL approaches. In [Osa12] the au-thor follows a similar approach to evaluate the impact of a model-based approach called

158

6.2. Future Work

Analytical Software Design (ASD) on the quality of the software and the productivity ofthe developers.

Since adding fault detection mechanisms is shown to be effective in finding discrepan-cies between DSL transformations, it is natural to investigate the possibility of includingother forms of validation in the development process. For instance, the approach dis-cussed in Chapter 2 can be extended with model-learning techniques to extract high-levelbehavioral models from implementations. A learned model describes the implementedbehavior in an abstract way and can be compared with analysis models using equivalencechecking and model-based testing.

As indicated in Chapter 3 and 4 modular development of languages is a promisingdirection for future research on DSLs. Developing theories and tools that support thisidea can reduce the effort for defining new languages and boost the applicability of DSLsin practice.

In Chapter 3 we used a rather ad-hoc approach for describing the implementationdetails introduced by a code generator, whereas writing such descriptions in general re-quires a more systematic approach. Developing a generic approach for this purpose mayalso lead to a more structured way for validating the consistency between transforma-tions.

The approach of Chapter 5 for approximating arithmetic operations can be improvedand extended in a number of ways. We predict that the components of the representationproposed in Chapter 5 will grow rapidly in some computations. This can potentiallyimpede computational efficiency. One can consider alternative representations to avoidlarge coefficients in the approximations of real numbers.

Another practical drawback of the approach of Chapter 5 is related to the calcula-tions required for approximating transcendental functions. The amount of calculationsin the proposed approximations (with both Riemann sums and Taylor expansions) areexponential in the required precision. Further improvements of these approximationsare necessary.

The algorithms devised in Chapter 5 for ex , ln(x), and arctan(x) based on Rie-mann sums are intuitively comprehensible and reasoning about their correctness is morestraightforward compared with the approximations based on Taylor expansions for sin(x)and cos(x). One can also approximate ex , ln(x), and arctan(x) functions using Taylorexpansions and compare the efficiency of the two approaches.

In Chapter 5 we discussed a simple example and motivated an approach to reduce thenumber of recomputations in our top-down approximation scheme. The idea is to avoidcomputations that jeopardize the precision due to recomputations and replace them withequivalent expressions that are computable in one pass. Developing a set of rewrite rulesthat realize this idea in a systematic way requires further research.

159

Appendix A

Validation Properties for PedalHandling

In this appendix we provide some example properties that can be verified against spec-ifications in the Pedal Handling DSL. All the properties presented in this appendix areexpressed in a variant of the modal µ-calculus. This logic is the language used bythe mCRL2 toolset [Mcr] for property specification. The interested reader can refer to[GM14] for more details about the syntax and semantics of this logic.

We provide example properties for the DSL model of Fig. 2.4. As discussed in Chap-ter 2, a specification in the Pedal Handling DSL declares a set of input actions and de-scribes the way the state of the system evolves as it perform the actions. For examplethe DSL model of Fig. 2.4 declares the input actions FRFluoOn, FRFluoOff, StartCond, andResetStartCond. To express properties for this DSL model, we first explain the behaviorsrepresented by the declared actions:

• FRFluoOn: request to start capturing real-time images;

• FRFluoOff : request to stop capturing real-time images;

• StartCond: notification to prevent X-ray from starting;

• ResetStartCond: notification to allow X-ray generation for new requests.

Pedal Handling performs actions output(xr, p) to send X-ray requests for xr ∈ XRay top ∈ Plane.

In what follows, we formalize some example properties for the DSL model of Fig. 2.4.The formalized properties assume that there is a data specification defining the data typesXRay and Plane (see Section 2.4.1) and refer to the actions discussed above.

• In every reachable state there is at least one outgoing transition (deadlock-freedom):

[true∗]⟨true⟩true

161

Validation Properties for Pedal Handling

• no X-ray is generated from the planes when there is no request from the user:

νX ( f : B= false).([FRFluoOn]X (true) ∧[FRFluoOff]X (false) ∧�

∀xr : XRay, p : Plane.[output(xr, p)]�

X ( f ) ∧

(¬ f ⇒ (xr= Standby∧ p = None))�

�

∧

[FRFluoOn ∧ FRFluoOFF ∧ (∀xr : XRay, p : Plane.output(xr, p))]X ( f ))

• if there is a start condition (i.e., a StartCond notification that is not canceled bya ResetStartCond), X-ray generation cannot be started. It should be noted that aStartCond notification does not interrupt the X-ray generation:

νX (fr : B= false, sc : B= false).([FRFluoOn]X (true, sc) ∧[FRFluoOff]X (false, sc) ∧[StartCond]X (false, true) ∧[ResetStartCond]X (false, false) ∧�

∀xr : XRay, p : Plane.[output(xr, p)]�

X (false, sc) ∧

�

(fr∧ sc)⇒ (xr= Standby ∧ c = None))�

�

162

Appendix B

Propositions and Lemmas forChapter 5

Proposition B.1. For any p ∈ N the following inequalities hold:

(1+1

2p )2 ≤ 1+

1

2p−2 (B.1)

1−1

2p−2 ≤ (1−1

2p )2 (B.2)

Proof. For inequality (B.1) we can write:

(1+1

2p )2 = 1+

1

22p +1

2p−1 ≤ 1+1

2p−1 +1

2p−1 = 1+1

2p−2

Similarly for inequality (B.2) we have:

(1−1

2p )2 = 1+

1

22p −1

2p−1 ≥ 1−1

2p−1 > 1−1

2p−2

ut

Proposition B.2. For any p ∈ N+ the following inequalities hold:

2p

2p − 1≤ 1+

1

2p−1 (B.3)

1−1

2p−1 ≤2p

2p + 1(B.4)

Proof. Since p ∈ N+ we have 2p ≥ 2. For inequality (B.3) we have:

2p

2p − 1=

2p − 1+ 1

2p − 1= 1+

1

2p − 1≤ 1+

1

2p−1

163

Propositions and Lemmas for Chapter 5

Similarly for inequality (B.4) we can write:

2p

2p + 1=

2p + 1− 1

2p + 1= 1−

1

2p + 1≥ 1−

1

2p−1

ut

Proposition B.3. For any 0< y < 1 the following inequality holds:

log2(1+ y)≤y

ln(2)(B.5)

Proof. Based on Taylor’s theorem, we can write the following expansion for log2(1+ y):

log2(1+ y) =N∑

i=1

(−1)i−1 y i

i ln(2)+

(−1)N yN+1

(N + 1)(1+ cy)N+1 ln(2)

where 0< cy < y . For N = 1 we obtain:

log2(1+ y) =y

ln(2)−

y2

2(1+ c1)2 ln(2)

The quantity y2

2(1+c1)2 ln(2)is positive and hence log2(1+ y)≤ y

ln(2).

ut

Proposition B.4. For x ∈ R \ {0} we have | x(1+x2)arctan(x)

|< 1.

Proof. We analyze the derivative of f (x) = | x(1+x2)arctan(x)

| = x(1+x2)arctan(x)

and find theintervals in which f (x) is increasing/decreasing.

f ′(x) =arctan(x)(1− x2)− x

(1+ x2)2(arctan(x))2

We analyze the derivative in the following cases:

1. Suppose 0< x < 1. We use the Taylor expansion of arctan(x) to rewrite arctan(x)(1−x2)− x:

arctan(x)(1− x2)− x =∞∑

i=0

(−1)i

2i+ 1x2i+1 − x − x2 arctan(x)

=∞∑

i=1

(−1)i

2i+ 1x2i+1 − x2 arctan(x)

=∞∑

i=1

−x4i−1(1

4i− 1−

x2

4i+ 1)− x2 arctan(x)

The term −x2 arctan(x) is negative and −x4i−1( 14i−1− x2

4i+1) is negative for i ≥ 1

and 0 < x < 1. Thus, the summation∑∞

i=1−x4i−1( 14i−1− x2

4i+1)− x2 arctan(x) is

negative and f ′(x)< 0. The function f (x) is decreasing for 0< x < 1.

164

2. Suppose x ≥ 1. In this case, arctan(x)(1− x2)− x < 0. Thus, f ′(x) < 0 and f (x)is decreasing for x ≥ 1.

3. Suppose x < 0. Since f ′(−x) = − f ′(x), we can conclude from the first two casesthat f (x) is increasing when x < 0.

The case analysis shows that f (x) is bounded from above by limx→0 f (x) = 1.ut

Proposition B.5. For any y ∈ (−1, 0)∪ (0, 1) and i ∈ N the following inequalities hold:

(−1)2i

(4i+ 1)!y4i+1 +

(−1)2i+1

(4i+ 3)!y4i+3 > 0 if y > 0

(−1)2i

(4i+ 1)!y4i+1 +

(−1)2i+1

(4i+ 3)!y4i+3 < 0 if y < 0

Proof. We can rewrite the summation as follows:

(−1)2i

(4i+ 1)!y4i+1 +

(−1)2i+1

(4i+ 3)!y4i+3 =

(−1)2i

(4i+ 1)!y4i+1(1−

y2

(4i+ 2)(4i + 3))

Since 1− y2

(4i+2)(4i+3)≥ 1− 1

6> 0 the sign of the summation is determined by the sign of

y4i+1.ut

Proposition B.6. For any y ∈ (−1,0)∪ (0, 1) and i ∈ N the following inequality holds:

(−1)2i

(4i)!y4i +

(−1)2i+1

(4i+ 2)!y4i+2 > 0

Proof. We can rewrite the left hand side of the inequality as follows:

(−1)2i

(4i)!y4i +

(−1)2i+1

(4i+ 2)!y4i+2 =

(−1)2i

(4i)!y4i(1−

1

(4i+ 1)(4i+ 2)y2)

Since 1− 1(4i+1)(4i+2)

y2 ≥ 1− 12> 0, the inequality holds.

ut

Proposition B.7. For x ∈ (−1, 1) \ {0} we have |x · cot(x)|< 1.

Proof. For the interval x ∈ (−1,1) \ {0}, we have |x · cot(x)|= x · cot(x). We analyze thederivative of f (x) = x · cot(x) in (−1, 1) \ {0}.

f ′(x) = cot(x)− x(1+ cot2(x)) =sin(x) cos(x)− x

sin2(x)=

sin(2x)− 2x

2 sin2(x)

The point x = 0 is a critical point for f (x). Since | sin(2x)| ≤ |2x |, f (x) is increasing in(−1,0) and decreasing in (0,1). Thus, f (x) is bounded from above by limx→0 f (x) = 1.

ut

165

Propositions and Lemmas for Chapter 5

Proposition B.8. For x ∈ (−1,1) we have |x · tan(x)|< tan(1).

Proof. For the interval x ∈ (−1, 1), we have |x · tan(x)| = x · tan(x). To determine anupper-bound for x · tan(x), we analyze the derivative of f (x) = x · tan(x):

f ′(x) = tan(x) + x(1+ tan2(x)) =sin(x) cos(x) + x

cos2(x)=

sin(2x) + 2x

2cos2(x)

The quantity sin(2x) + 2x is negative in (−1,0) and positive in (0,1). Thus, f (x) isdecreasing in (−1,0) and increasing in (0, 1). We conclude that f (x)< tan(1).

ut

Lemma B.9. Let x be a real number represented by (m, n, p). Then x i can be representedby (mi , ni , p− 2dlogi

2e).

Proof. We can apply Theorem 5.5.2 to calculate x i = x di2e× x b

i2c. Let k = dlogi

2e and P(i)denote the precision that we lose by calculating x i . From Theorem 5.5.2 we can write:

P(i)≤ P(di

2e) + 2≤ P(d

i

2ke) + 2k = 2k

Thus, we lose 2k = 2dlogi2e units of precision by calculating x i .

ut

166

Bibliography

[AAH05] J.-R. Abrial, J.-R. Abrial, and A. Hoare. The B-book: assigning programs tomeanings. Cambridge University Press, 2005.

[All] Allegio Project. http://www.commit-nl.nl/projects/composable-embedded-systems-for-healthcare. Visited: August 2015.

[AO08] P. Ammann and J. Offutt. Introduction to software testing. Cambridge Uni-versity Press, 2008.

[ABE11] S. Andova, M.G.J. van den Brand, and L. Engelen. “Prototyping the Seman-tics of a DSL using ASF+SDF: Link to Formal Verification of DSL Models.”In: Proceedings of AMMSE’11. Vol. 56. EPTCS. 2011, pp. 65–79.

[ABE12] S. Andova, M.G.J. van den Brand, and L. Engelen. “Reusable and correctendogenous model transformations.” In: Proceedings of ICMT’12. Vol. 7307.LNCS. Springer, 2012, pp. 72–88.

[And+12] S. Andova, M.G.J. van den Brand, L.J.P. Engelen, and T. Verhoeff. “MDEBasics with a DSL Focus.” In: SFM’12. Springer, 2012, pp. 21–57.

[Ang87] D. Angluin. “Learning regular sets from queries and counterexamples.” In:Information and computation 75.2 (1987), pp. 87–106.

[ADBO10] K.R. Apt, F.S. De Boer, and E. Olderog. Verification of sequential and concur-rent programs. Springer Science & Business Media, 2010.

[ADR95] B.R.T. Arnold, A. van Deursen, and M. Res. “An algebraic specification of alanguage for describing financial products.” In: Formal Methods Applicationin Software Engineering. 1995, pp. 6–13.

[Asa+11] H.R. Asaadi, R. Khosravi, M.R. Mousavi, and N. Noroozi. “Towards Model-Based Testing of Electronic Funds Transfer Systems.” In: Proceedings ofFSEN’11. Vol. 7141. LNCS. Springer, 2011, pp. 253–267.

[Axi] Axini B.V. http://www.axini.nl. Visited: August 2015.

[BK08] C. Baier and J.-P. Katoen. Principles of Model Checking. MIT Press, 2008.

[Bar+09] C. Barrett, R. Sebastiani, S.A. Seshia, and C. Tinelli. “Satisfiability modulotheories.” In: Handbook of Satisfiability 185 (2009), pp. 825–885.

[BS82] F. Bazzichi and I. Spadafora. “An automatic generator for compiler testing.”In: Software Engineering, IEEE Transactions on 4 (1982), pp. 343–353.

167

http://www.commit-nl.nl/projects/composable-embedded-systems-for-healthcare

http://www.commit-nl.nl/projects/composable-embedded-systems-for-healthcare

http://www.axini.nl

BIBLIOGRAPHY

[Bee+08] D.A. van Beek, A.T. Hofkamp, M.A. Reniers, J.E. Rooda, and R.R.H. Schif-felers. “Syntax and formal semantics of Chi 2.0.” In: Eindhoven University ofTechnology, Technical Report (2008).

[Bel10] Axel Belinfante. “JTorX: A tool for on-line model-driven test derivation andexecution.” In: Proceedings of TACAS’10. Springer, 2010, pp. 266–270.

[BRH15] F. van den Berg, A. Remke, and B.R. Haverkort. “iDSL: Automated perfor-mance prediction and analysis of medical imaging systems.” In: Proceedingsof EPEW’15. Springer, 2015, pp. 227–242.

[Ber+13] F. van den Berg, A. Remke, A.J. Mooij, and B. Haverkort. “Performance Eval-uation for Collision Prevention based on a Domain Specific Language.” In:Proceedings of EPEW’13. Vol. 8168. Springer, 2013, pp. 276–287.

[Ber+15] F. van den Berg, J. Hooman, A. Hartmanns, B.R. Haverkort, and A. Remke.“Computing Response Time Distributions Using Iterative ProbabilisticModel Checking.” In: Proceedings of EPEW’15. Springer, 2015, pp. 208–224.

[Ber97] Gino van den Bergen. “Efficient collision detection of complex deformablemodels using AABB trees.” In: Journal of Graphics Tools 2.4 (1997), pp. 1–13.

[BK84] J.A. Bergstra and J.W. Klop. “Process algebra for synchronous communica-tion.” In: Information and control 60.1 (1984), pp. 109–137.

[Béz06] J. Bézivin. “Model driven engineering: An emerging technical space.”In: Generative and transformational techniques in software engineering.Springer, 2006, pp. 36–64.

[Bie+09] A. Biere, M.J.H. Heule, H. van Maaren, and T. Walsh, eds. Handbook ofSatisfiability. Vol. 185. Frontiers in Artificial Intelligence and Applications.IOS Press, 2009.

[Bod+05] J.P. Bodeveix, M. Filali, J. Lawall, and G. Muller. “Formal methods meetdomain specific languages.” In: Proceedings of IFM’05. Springer. 2005,pp. 187–206.

[BB01] B. Boehm and V.R. Basili. “Software Defect Reduction Top 10 List.” In: Com-puter 34.1 (2001), pp. 135–137.

[Boe84] B.W. Boehm. “Verifying and validating software requirements and designspecifications.” In: IEEE software 1.1 (1984), p. 75.

[Bok02] L.J. van Bokhoven. “Constructive Tool Design for Formal Languages.” PhDthesis. Eindhoven University of Techonology, 2002.

[BG13] M.G.J. van den Brand and J.F. Groote. “Software Engineering: Redundancyis Key.” In: Science of Computer Programming 97 (2013), pp. 75–81.

[Bre+15] D. Bresolin, L. Geretti, T. Villa, and P. Collins. “An Introduction to the Veri-fication of Hybrid Systems Using Ariadne.” In: Coordination Control of Dis-tributed Systems. Springer, 2015, pp. 339–346.

168

BIBLIOGRAPHY

[Bro05] G.H. Broadfoot. “ASD case notes: Costs and benefits of applying formalmethods to industrial control software.” In: Proceedings of FM’05. Springer,2005, pp. 548–551.

[BB03] G.H. Broadfoot and P.J. Broadfoot. “Academia and industry meet: Someexperiences of formal methods in practice.” In: Proceedings of APSEC’03.IEEE. 2003, pp. 49–58.

[BF01] R.L. Burden and J.D. Faires. Numerical analysis. Brooks/Cole, USA, 2001.

[CGP99] E.M. Clarke, O. Grumberg, and D. Peled. Model checking. MIT press, 1999.

[CZ05] H. Cleve and A. Zeller. “Locating causes of program failures.” In: Proceedingsof ICSE’05. ACM, 2005, pp. 342–351.

[CNR11] P. Collins, M. Niqui, and N. Revol. “A validated real function calculus.” In:Mathematics in Computer Science 5.4 (2011), pp. 437–467.

[Com] COMMIT. http://www.commit-nl.nl. Visited: August 2015.

[Cra12] S. Cranen. “Model checking the FlexRay startup phase.” In: Formal Methodsfor Industrial Critical Systems. Springer, 2012, pp. 131–145.

[Cra15] S. Cranen. “Getting the point: obtaining and understanding fixpoints inmodel checking.” PhD thesis. Eindhoven University of Technology, 2015.

[DMB08] L. De Moura and N. Bjørner. “Z3: An efficient SMT solver.” In: Proceedingsof TACAS’08. Vol. 4963. LNCS. Springer, 2008, pp. 337–340.

[DMB11] L. De Moura and N. Bjørner. “Satisfiability modulo theories: introductionand applications.” In: Communications of the ACM 54.9 (2011), pp. 69–77.

[DKV00] A. van Deursen, P. Klint, and J. Visser. “Domain-Specific Languages: an an-notated bibliography.” In: SIGPLAN Notices 35.6 (2000), pp. 26–36.

[Din15] N. Dintzner. “Safe evolution patterns for software product lines.” In: Pro-ceedings of ICSE’15. IEEE Press. 2015, pp. 875–878.

[Din+14] N. Dintzner, U. Kulesza, A. van Deursen, and M. Pinzger. “Evaluating Fea-ture Change Impact on Multi-product Line Configurations Using Partial In-formation.” In: Proceedings of ICSR’14. Springer, 2014, pp. 1–16.

[Dut+15] A.M. Dutle, C.A. Munoz, A.J. Narkawicz, and R.W. Butler. “Software Vali-dation via Model Animation.” In: Proceedings of TAP’15. Vol. 9154. LNCS.Springer, 2015, pp. 92–108.

[EJ09] Ch. Ebert and C. Jones. “Embedded software: Facts, figures, and future.” In:Computer 4 (2009), pp. 42–52.

[EH02] A. Edalat and R. Heckmann. “Computing with real numbers.” In: AppliedSemantics. Springer, 2002, pp. 193–267.

[EE08] H. Ehrig and C. Ermel. “Semantical Correctness and Completeness of ModelTransformations Using Graph and Rule Transformation.” In: Proceedings ofICGT’08. Vol. 5214. LNCS. Springer-Verlag, 2008, pp. 194–210.

169

http://www.commit-nl.nl

BIBLIOGRAPHY

[FT86] A. Feldstein and P. Turner. “Overflow, underflow, and severe loss of signifi-cance in floating-point addition and subtraction.” In: IMA journal of numer-ical analysis 6.2 (1986), pp. 241–251.

[Fio+10] C. Fiorentini, A. Momigliano, M. Ornaghi, and I. Poernomo. “A constructiveapproach to testing model transformations.” In: Proceedings of ICMT’10. Vol.6142. LNCS. Springer, 2010, pp. 77–92.

[FL07] J. Fitzgerald and P.G. Larsen. Balancing insight and effort: The industrialuptake of formal methods. Springer, 2007.

[Fre+11] G. Frehse, C. Le Guernic, A. Donzé, S. Cotton, R. Ray, O. Lebeltel, R. Ripado,A. Girard, T. Dang, and O. Maler. “SpaceEx: Scalable Verification of Hy-brid Systems.” In: Proceedings of CAV’11. Vol. 6806. LNCS. Springer, 2011,pp. 379–395.

[Gar+11] H. Garavel, F. Lang, R. Mateescu, and W. Serwe. “CADP 2010: A toolbox forthe construction and analysis of distributed processes.” In: Proceedings ofTACAS’11. Springer, 2011, pp. 372–387.

[Gau95] M.C. Gaudel. “Testing can be formal, too.” In: Proceedings of TAPSOFT’95.Vol. 915. LNCS. Springer, 1995, pp. 82–96.

[Gla93] R.J. van Glabbeek. A complete axiomatization for branching bisimulation con-gruence of finite-state behaviours. Springer, 1993.

[GL00] P. Gowland and D. Lester. “The correctness of an implementation of exactarithmetic.” In: Proceedings of RNC 2000. Vol. 140. 2000.

[GM14] J.F. Groote and M.R. Mousavi. Modeling and Analysis of Communicating Sys-tems. MIT press, 2014.

[Hav15] S.P. Haveman. “COMBOS: Communicating Behavior Of Systems- Incorpo-rating Simulations in Conceptual Systems Design.” PhD thesis. Universityof Twente, 2015.

[Hen+00] Th.A. Henzinger, B. Horowitz, R. Majumdar, and H. Wong-Toi. “BeyondHYTECH: Hybrid systems analysis using interval numerical methods.” In:Hybrid systems: Computation and control. Springer, 2000, pp. 130–144.

[Her96] P. Hertling. “Computable Real Functions: Type 1 Computability Versus Type2 Computability.” In: Proceedings of CCA 1996. Mathematik/Informatik,Universität Trier. 1996.

[Hig02] N.J. Higham. Accuracy and stability of numerical algorithms. SIAM, 2002.

[Hig08] N.J. Higham. Functions of matrices: theory and computation. SIAM, 2008.

[HD12] A. Hohmann and P. Deuflhard. Numerical Analysis in Modern Scientific Com-puting: An Introduction. Vol. 43. Springer Science & Business Media, 2012.

[Hol96] G.J. Holzmann. “Formal methods for early fault detection.” In: Proceedingsof FTRTFT’96. Springer. 1996, pp. 40–54.

[HMW12] J. Hooman, A.J. Mooij, and H. van Wezep. “Early fault detection in indus-try using models at various abstraction levels.” In: Proceedings of iFM’12.Springer. 2012, pp. 268–282.

170

BIBLIOGRAPHY

[Hoo+08] J. Hooman, H. Kugler, I. Ober, A. Votintseva, and Y. Yushtein. “SupportingUML-based development of embedded systems by formal techniques.” In:Software & Systems Modeling 7.2 (2008), pp. 131–155.

[Hwa+09] J.H. Hwang, T. Xie, F. Chen, and A. X. Liu. “Fault Localization for FirewallPolicies.” In: Proceedings of SRDS’09. IEEE Computer Society, 2009, pp. 100–106.

[JM11] M. Jose and R. Majumdar. “Cause clue clauses: error localization using max-imum satisfiability.” In: ACM SIGPLAN Notices 46.6 (2011), pp. 437–446.

[KV10] L.C.L. Kats and E. Visser. “The Spoofax language workbench: rules fordeclarative specification of languages and IDEs.” In: ACM SIGPLAN Notices.Vol. 45. 10. ACM. 2010, pp. 444–463.

[Kel00] T. Kelsey. “Exact Numerical Computation Via Symbolic Computation.” In:Proceedings of CCA 2000. Springer, 2000, pp. 187–197.

[KG15] S. Keshishzadeh and J.F. Groote. “Exact Real Arithmetic with PerturbationAnalysis and Proof of Correctness.” In: Eindhoven University of Technology,Technical Report 15-05 (2015).

[KM14] S. Keshishzadeh and A.J. Mooij. “Formalizing DSL semantics for reason-ing and conformance testing.” In: Proceedings of SEFM’14. Springer, 2014,pp. 81–95.

[KM16] S. Keshishzadeh and A.J. Mooij. “Formalizing and Testing the Consistencyof DSL Transformations.” In: Formal Aspects of Computing (in press) (2016).

[KMH15] S. Keshishzadeh, A.J. Mooij, and J. Hooman. “Industrial Experiences witha Formal DSL Semantics to Check Correctness of DSL Transformations.” In:arXiv preprint:1511.08049 (2015).

[KMM13] S. Keshishzadeh, A.J. Mooij, and M. Mousavi. “Early Fault Detection in DSLsusing SMT Solving and Automated Debugging.” In: Proceedings of SEFM’13.Vol. 8137. LNCS. 2013, pp. 182–196.

[KSGK13] A. Khabbaz Saberi, J.F. Groote, and S. Keshishzadeh. “Analysis of Path Plan-ning Algorithms: a Formal Verification-based Approach.” In: Proceedings ofECAL’13. Vol. 12. 2013, pp. 232–239.

[KC02] D.R. Kincaid and E.W. Cheney. Numerical analysis: mathematics of scientificcomputing. Vol. 2. American Mathematical Soc., 2002.

[Koz83] D. Kozen. “Results on the propositional µ-calculus.” In: Theoretical computerscience 27.3 (1983), pp. 333–354.

[KS13] R. Krebbers and B. Spitters. “Type classes for efficient exact real arithmeticin Coq.” In: Logical Methods in Computer Science 9.1:1 (2013), pp. 1–27.

[KLS00] G. Kreisel, D. Lacombe, and J. Shoenfield. “Partial recursive functionals andeffective operations.” In: Constructivity in Mathematics, Studies in Logic andthe Foundations of Mathematics (2000), pp. 290–297.

[KL84] B.A. Kushner and L.I. Lefman. Lectures on constructive mathematical analy-sis. Vol. 60. American Mathematical Soc., 1984.

171

BIBLIOGRAPHY

[LA04] C. Lattner and V. Adve. “LLVM: A compilation framework for lifelong pro-gram analysis & transformation.” In: Proceedings of CGO’04. IEEE. 2004,pp. 75–86.

[Ler09] X. Leroy. “Formal verification of a realistic compiler.” In: Communicationsof the ACM 52.7 (2009), pp. 107–115.

[Ltd10] Formal Systems (Europe) Ltd. “Refinement, Failures-Divergence - FDR2User Manual.” In: (2010).

[Mar54] A.A. Markov. “On the continuity of constructive functions (in Russian).” In:Uspekhi Mat. Nauk (NS) 9 (1954), pp. 226–230.

[Mat] Mathlab and Simulink for Technical Computing. http://www.mathworks.com. Visited: August 2015.

[Mcr] mCRL2. http://mcrl2.org. Visited: August 2015.

[MM05] V. Ménissier-Morain. “Arbitrary precision real arithmetic: design and algo-rithms.” In: The Journal of Logic and Algebraic Programming 64.1 (2005),pp. 13–39.

[MG06] T. Mens and P. van Gorp. “A taxonomy of model transformation.” In: Elec-tronic Notes in Theoretical Computer Science 152 (2006), pp. 125–142.

[MHA13] A.J. Mooij, J. Hooman, and R. Albers. “Gaining Industrial Confidence for theIntroduction of Domain-Specific Languages.” In: Proceedings of IEESD’13.IEEE, 2013, pp. 662–667.

[MHA14] A.J. Mooij, J. Hooman, and R. Albers. “Early Fault Detection Using DesignModels for Collision Prevention in Medical Equipment.” In: Proceedings ofFHIES’13. Vol. 8315. LNCS. Springer, 2014, pp. 170–187.

[Moo+15] A.J. Mooij, G. Eggen, J. Hooman, and H. van Wezep. “Cost-Effective Indus-trial Software Rejuvenation Using Domain-Specific Models.” In: Theory andPractice of Model Transformations. Springer, 2015, pp. 66–81.

[MW88] Matthew Moore and Jane Wilhelms. “Collision detection and response forcomputer animation.” In: ACM Siggraph Computer Graphics 22.4 (1988),pp. 289–298.

[MMJ15] Hentz C Déharbe D. de Matos E.C.B. Neto J.B.S. Moreira A.M. and V. deMedeiros Jr. “Verifying Code Generation Tools for the B-Method UsingTests: A Case Study.” In: Proceedings of TAP’15. LNCS. Springer, 2015,pp. 76–91.

[Mos91] P.D. Mosses. “Denotational semantics.” In: Handbook of theoretical computerscience, Vol. B. MIT Press. 1991, pp. 575–631.

[Moz+08] M.M.R. Mozumdar, F. Gregoretti, L. Lavagno, L. Vanzago, and S. Olivieri. “Aframework for modeling, simulation and automatic code generation of sen-sor network application.” In: Proceedings of SECON’08. IEEE. 2008, pp. 515–522.

[Mül01] N. Müller. “The iRRAM: Exact arithmetic in C++.” In: Proceedings of CCA2001. Springer, 2001, pp. 222–252.

172

http://www.mathworks.com

http://www.mathworks.com

http://mcrl2.org

BIBLIOGRAPHY

[MSB11] G.J. Myers, C. Sandler, and T. Badgett. The art of software testing. JohnWiley & Sons, 2011.

[NM12] Cleophas L.G. van den Brand M. Engelen L. Raulea L. Nagy I. and E.X.L.Mithun. “VPDSL: A DSL for software in the loop simulations covering ma-terial flow.” In: Proceedings of ICECCS’12. IEEE. 2012, pp. 318–327.

[O’C08] R. O’Connor. “Certified exact transcendental real number computation inCoq.” In: Theorem Proving in Higher Order Logics. Springer, 2008, pp. 246–261.

[Osa12] A.A.H. Osaiweran. “Formal Development of Control Software in the MedicalSystems Domain.” PhD thesis. Eindhoven University of Technology, 2012.

[ORS92] S. Owre, J.M. Rushby, and N. Shankar. “PVS: A prototype verification sys-tem.” In: Proceedings of CADE’92. Springer, 1992, pp. 748–752.

[Plo04] G.D. Plotkin. “A structural approach to operational semantics.” In: Journalof Logic and Algebraic Programming 60.61 (2004), pp. 17–139.

[POO] POOSL. http://poosl.esi.nl. Visited: August 2015.

[Pot98] P.J. Potts. “Exact real arithmetic using Mobius transformations.” PhD thesis.PhD-thesis, Imperial College London, 1998.

[Pre05] R.S. Pressman. Software engineering: a practitioner’s approach. PalgraveMacmillan, 2005.

[Rat+12] D. Ratiu, M. Voelter, Z. Molotnikov, and B. Schaetz. “Implementing ModularDomain Specific Languages and Analyses.” In: Proceedings of Workshop onMoDeVVa’12. ACM. 2012, pp. 35–40.

[Red14] J. Redegeld. “Formal verification of control software in X-Ray systems.” In:(2014).

[RW99] M.K. Richter and K. Wong. “Computable preference and utility.” In: Journalof Mathematical Economics 32.3 (1999), pp. 339–354.

[RDV09] J.E. Rivera, F. Durán, and A. Vallecillo. “Formal Specification and Analysisof Domain Specific Models Using Maude.” In: Simulation (2009).

[Ros10] A.W. Roscoe. Understanding concurrent systems. Springer-Verlag New YorkInc., 2010.

[SW08] D.A. Sadilek and G. Wachsmuth. “Prototyping visual interpreters anddebuggers for domain-specific modelling languages.” In: Proceedings ofECMDA-FA’08. Vol. 5095. LNCS. Springer. 2008, pp. 63–78.

[Sch06] D.C. Schmidt. “Guest editor’s introduction: Model-driven engineering.” In:Computer 39.2 (2006), pp. 25–31.

[Sij+14] M. Sijtema, A. Belinfante, M.I.A. Stoelinga, and L. Marinelli. “Experienceswith formal engineering: Model-based specification, implementation andtesting of a software bus at Neopost.” In: Science of computer programming80 (2014), pp. 188–209.

173

BIBLIOGRAPHY

[Smi+05] A. Smith, A. Veneris, M.F. Ali, and A. Viglas. “Fault diagnosis and logic de-bugging using Boolean satisfiability.” In: IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 24.10 (2005), pp. 1606–1621.

[Spi67] M. Spivak. Calculus. Benjamin, 1967.

[Sta12] F.P.M. Stappers. “Bridging Formal Models: An Engineering Perspective.” PhDthesis. Eindhoven University of Techonology, 2012.

[Sta+12] F.P.M. Stappers, S. Weber, M.A. Reniers, S. Andova, and I. Nagy. “Formaliz-ing a Domain Specific Language using SOS: an industrial case study.” In:Proceedings of SLE’11. Vol. 6940. LNCS. Springer, 2012, pp. 223–242.

[Ste+08] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks. Eclipse ModelingFramework. Pearson Education, 2008.

[Mpf] The MPFR library. http://www.mpfr.org. Visited: August 2015.

[The+07] B.D. Theelen, O. Florescu, M.C.W. Geilen, J. Huang, P.H.A. van der Put-ten, and J.P.M. Voeten. “Software/Hardware Engineering with the ParallelObject-Oriented Specification Language.” In: Proceedings of MEMOCODE’07.IEEE, 2007, pp. 139–148.

[Tre08] J. Tretmans. “Model based testing with Labelled Transition Systems.” In:Formal methods and testing. Vol. 4949. LNCS. Springer, 2008, pp. 1–38.

[Ver+13] J. Verriet, H.L. Liang, R. Hamberg, and B. van Wijngaarden. “Model-drivendevelopment of logistic systems using domain-specific tooling.” In: Proceed-ings of CSD&M. Springer, 2013, pp. 165–176.

[Vis+12] V. Vishal, M. Kovacioglu, R. Kherazi, and M.R. Mousavi. “Integrating model-based and constraint-based testing using SpecExplorer.” In: Proceedings ofISSREW’12. IEEE. 2012, pp. 219–224.

[Vis08] E. Visser. “WebDSL: A case study in domain-specific language engineer-ing.” In: Generative and Transformational Techniques in Software Engineer-ing. Springer, 2008, pp. 291–373.

[Voe13] M. Voelter. DSL Engineering. http://dslbook.org, Version 1.0. 2013.

[Voe+13] M. Voelter, D. Ratiu, B. Kolb, and B. Schaetz. “mbeddr: Instantiating a lan-guage workbench in the embedded software domain.” In: Automated Soft-ware Engineering 20.3 (2013), pp. 339–390.

[Wei12] K. Weihrauch. Computable analysis: an introduction. Springer Science &Business Media, 2012.

[WBM12] M. Woehrle, R. Bakhshi, and M.R. Mousavi. “Mechanized Extraction ofTopology Anti-patterns in Wireless Networks.” In: Proceedings of iFM’12. Vol.7321. LNCS. Springer, 2012, pp. 158–173.

[Wol] Wolfram Research Inc. Mathematica 10.0.1.0. http://www.wolfram.com. Visited: August 2015.

[Xtea] Xtend. http://www.eclipse.org/xtend/. Visited: August 2015.

174

http://www.mpfr.org

http://www.wolfram.com

http://www.wolfram.com

http://www.eclipse.org/xtend/

BIBLIOGRAPHY

[Xteb] Xtext. http://www.eclipse.org/Xtext/. Visited: August 2015.

[YD95] Ch.K. Yap and Th. Dubé. “The exact computation paradigm.” In: Computingin Euclidean Geometry 4 (1995), pp. 452–492.

[Zel09] A. Zeller. Why Programs Fail? A Guide to Systematic Debugging. MorganKaufmann, 2009.

[ZH02] A. Zeller and R. Hildebrandt. “Simplifying and Isolating Failure-InducingInput.” In: IEEE Transactions on Software Engineering 28.2 (2002), pp. 183–200.

175

http://www.eclipse.org/Xtext/

Summary

Formal Analysis and Verification of Embedded Systems forHealthcare

High-tech systems are becoming increasingly reliant on correct functioning software com-ponents. The increasing complexity of these components and the desire to deliver innova-tive products in a short period of time have motivated the need for systematic approachesto software development.

Model-Driven Software Engineering (MDSE) addresses the mentioned challenges bypromoting the use of abstract models as the key elements in the development process;transformations are used to generate software from models.

In the context of MDSE, it is a common trend to use modeling languages that aretailored to specific domains. Such a language is called a Domain-Specific Language (DSL)and aims to address only a limited set of problems. The language abstracts from thecharacteristics shared between this specific set of problems and focuses on describing thevariations between them.

State-of-the-art DSL techniques (e.g., defining the concrete or abstract syntax for aDSL, code generation, writing unit tests at the level of DSL models) have boosted theapplicability of DSLs in industrial practice. However, for safety-critical systems, moreadvanced techniques are required to give a level of certainty in the correctness of thedeveloped software.

In this thesis we propose a vision for extending state-of-the-art DSL techniques inorder to increase the reliability of software developed in DSL approaches. The maincontributions can be summarized as follows:

• DSL approaches typically rely on an implicit semantics in terms of a transformationto implementation code. Such an implicit semantics becomes increasingly prob-lematic when multiple transformations are constructed from the DSL to various ar-tifacts. We propose to have an explicit formalization of the semantics that assignsprecise meanings to the language constructs. Moreover, we apply the semanticsand use automated formal techniques based on equivalence checking and model-based testing to validate the correctness of the generated artifacts with respect tothe formalized semantics. The use of such automated techniques is particularlyuseful in an industrial context when there is no time for constructing proofs of

177

Summary

correctness for the transformations.

• Further investigation of transformations from DSLs to implementation code andanalysis models revealed that validating transformations becomes more challeng-ing when implementation details introduced by a specific transformation are alsorelevant for the notion of consistency between the transformations. We explicitlydistinguish between the semantics of a language and the implementation details in-troduced by a transformation and propose to have separate formalizations for thesetwo components. These formalizations are the basis of our approach for validatingthe consistency between the implementation code and analysis models generatedfrom a DSL model. We define conformance relations between the generated arti-facts and DSL models. Test cases are generated based on these formal relations tovalidate the consistency of the generated code and analysis models with respect tothe semantics and implementation details.

• In addition to validating the correctness and consistency of transformations, wealso studied ways to validate the correctness of DSL models with respect to certaindesired properties. Such validation can discover modeling mistakes in DSL speci-fications that would otherwise be cascaded to the generated artifacts through thetransformations. We also propose to extend this validation with an automated de-bugging procedure to assist the user in identifying the cause for a violated property.The debugging procedure identifies a potential cause for each violated property andtraces it back to the syntactic constructs of the DSL.

• Finally, we turn our attention to the problem of analyzing models that rely on realnumbers. The fact that real numbers are infinite objects imposes a major challengein this context. Hence, there is a need to develop rigorous numerical methodsthat support formal analysis on models that contain real numbers. Correctnessof computations should be guaranteed by such methods. To this end, we havedeveloped a top-down exact real arithmetic approach and investigate the way therequired precision of a given expression influences the required precision of itssub-expressions. We apply this approach to approximate various algebraic (e.g.,addition, multiplication) and transcendental (e.g., exponential function, naturallogarithm) operations. Detailed algorithms and proofs of correctness are providedfor the considered operations.

178

Curriculum Vitae

Sarmen Keshishzadeh was born on 2 September 1985 in Tehran, Iran. After finishinghis high school studies in 2003, he went on to study Applied Mathematics at AmirkabirUniversity of Technology in Tehran, Iran. In 2011 he graduated from the ComputerEngineering master’s program of Sharif University. His graduation project was entitledAutomata-based Model Checking for Reo Connectors. From 2011 to 2012 he worked as asoftware engineer mainly developing different types of information systems for both thepublic and private sectors.

In March 2012, Sarmen started his PhD research at Eindhoven University of Tech-nology. His research has been conducted within the Allegio project and with close col-laboration with TNO-ESI, Philips Healthcare, and Axini. This research has led to severalpublications and the present thesis.

179

Titles in the IPA Dissertation Series since 2013

H. Beohar. Refinement of Communicationand States in Models of Embedded Systems.Faculty of Mathematics and Computer Sci-ence, TU/e. 2013-01

G. Igna. Performance Analysis of Real-TimeTask Systems using Timed Automata. Fac-ulty of Science, Mathematics and Com-puter Science, RU. 2013-02

E. Zambon. Abstract Graph Transforma-tion – Theory and Practice. Faculty of Elec-trical Engineering, Mathematics & Com-puter Science, UT. 2013-03

B. Lijnse. TOP to the Rescue – Task-Oriented Programming for Incident Re-sponse Applications. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2013-04

G.T. de Koning Gans. Outsmarting SmartCards. Faculty of Science, Mathematicsand Computer Science, RU. 2013-05

M.S. Greiler. Test Suite Comprehension forModular and Dynamic Systems. Faculty ofElectrical Engineering, Mathematics, andComputer Science, TUD. 2013-06

L.E. Mamane. Interactive mathematicaldocuments: creation and presentation. Fac-ulty of Science, Mathematics and Com-puter Science, RU. 2013-07

M.M.H.P. van den Heuvel. Composi-tion and synchronization of real-time com-ponents upon one processor. Facultyof Mathematics and Computer Science,TU/e. 2013-08

J. Businge. Co-evolution of the EclipseFramework and its Third-party Plug-ins.Faculty of Mathematics and Computer Sci-ence, TU/e. 2013-09

S. van der Burg. A Reference Architecturefor Distributed Software Deployment. Fac-

ulty of Electrical Engineering, Mathemat-ics, and Computer Science, TUD. 2013-10

J.J.A. Keiren. Advanced Reduction Tech-niques for Model Checking. Facultyof Mathematics and Computer Science,TU/e. 2013-11

D.H.P. Gerrits. Pushing and Pulling: Com-puting push plans for disk-shaped robots,and dynamic labelings for moving points.Faculty of Mathematics and Computer Sci-ence, TU/e. 2013-12

M. Timmer. Efficient Modelling, Gener-ation and Analysis of Markov Automata.Faculty of Electrical Engineering, Mathe-matics & Computer Science, UT. 2013-13

M.J.M. Roeloffzen. Kinetic Data Struc-tures in the Black-Box Model. Facultyof Mathematics and Computer Science,TU/e. 2013-14

L. Lensink. Applying Formal Methodsin Software Development. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2013-15

C. Tankink. Documentation and For-mal Mathematics — Web Technologymeets Proof Assistants. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2013-16

C. de Gouw. Combining Monitoringwith Run-time Assertion Checking. Fac-ulty of Mathematics and Natural Sciences,UL. 2013-17

J. van den Bos. Gathering Evidence:Model-Driven Software Engineering in Au-tomated Digital Forensics. Faculty of Sci-ence, UvA. 2014-01

D. Hadziosmanovic. The Process Mat-ters: Cyber Security in Industrial Control

Systems. Faculty of Electrical Engineer-ing, Mathematics & Computer Science,UT. 2014-02

A.J.P. Jeckmans. Cryptographically-Enhanced Privacy for Recommender Sys-tems. Faculty of Electrical Engineer-ing, Mathematics & Computer Science,UT. 2014-03

C.-P. Bezemer. Performance Optimizationof Multi-Tenant Software Systems. Fac-ulty of Electrical Engineering, Mathemat-ics, and Computer Science, TUD. 2014-04

T.M. Ngo. Qualitative and Quantitative In-formation Flow Analysis for Multi-threadedPrograms. Faculty of Electrical Engineer-ing, Mathematics & Computer Science,UT. 2014-05

A.W. Laarman. Scalable Multi-Core ModelChecking. Faculty of Electrical Engineer-ing, Mathematics & Computer Science,UT. 2014-06

J. Winter. Coalgebraic Characterizationsof Automata-Theoretic Classes. Faculty ofScience, Mathematics and Computer Sci-ence, RU. 2014-07

W. Meulemans. Similarity Measures andAlgorithms for Cartographic Schematiza-tion. Faculty of Mathematics and Com-puter Science, TU/e. 2014-08

A.F.E. Belinfante. JTorX: Exploring Model-Based Testing. Faculty of Electrical En-gineering, Mathematics & Computer Sci-ence, UT. 2014-09

A.P. van der Meer. Domain Specific Lan-guages and their Type Systems. Facultyof Mathematics and Computer Science,TU/e. 2014-10

B.N. Vasilescu. Social Aspects of Collab-oration in Online Software Communities.Faculty of Mathematics and Computer Sci-ence, TU/e. 2014-11

F.D. Aarts. Tomte: Bridging the Gap be-tween Active Learning and Real-World Sys-tems. Faculty of Science, Mathematics andComputer Science, RU. 2014-12

N. Noroozi. Improving Input-OutputConformance Testing Theories. Facultyof Mathematics and Computer Science,TU/e. 2014-13

M. Helvensteijn. Abstract Delta Modeling:Software Product Lines and Beyond. Fac-ulty of Mathematics and Natural Sciences,UL. 2014-14

P. Vullers. Efficient Implementationsof Attribute-based Credentials on SmartCards. Faculty of Science, Mathematicsand Computer Science, RU. 2014-15

F.W. Takes. Algorithms for Analyzingand Mining Real-World Graphs. Facultyof Mathematics and Natural Sciences,UL. 2014-16

M.P. Schraagen. Aspects of Record Link-age. Faculty of Mathematics and NaturalSciences, UL. 2014-17

G. Alpár. Attribute-Based Identity Manage-ment: Bridging the Cryptographic Design ofABCs with the Real World. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2015-01

A.J. van der Ploeg. Efficient Abstractionsfor Visualization and Interaction. Facultyof Science, UvA. 2015-02

R.J.M. Theunissen. Supervisory Controlin Health Care Systems. Faculty of Me-chanical Engineering, TU/e. 2015-03

T.V. Bui. A Software Architecture forBody Area Sensor Networks: Flexibility andTrustworthiness. Faculty of Mathematicsand Computer Science, TU/e. 2015-04

A. Guzzi. Supporting Developers’ Team-work from within the IDE. Faculty of

Electrical Engineering, Mathematics, andComputer Science, TUD. 2015-05

T. Espinha. Web Service GrowingPains: Understanding Services and TheirClients. Faculty of Electrical Engineer-ing, Mathematics, and Computer Science,TUD. 2015-06

S. Dietzel. Resilient In-network Aggre-gation for Vehicular Networks. Facultyof Electrical Engineering, Mathematics &Computer Science, UT. 2015-07

E. Costante. Privacy throughout the DataCycle. Faculty of Mathematics and Com-puter Science, TU/e. 2015-08

S. Cranen. Getting the point — Obtain-ing and understanding fixpoints in modelchecking. Faculty of Mathematics andComputer Science, TU/e. 2015-09

R. Verdult. The (in)security of pro-prietary cryptography. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2015-10

J.E.J. de Ruiter. Lessons learned in theanalysis of the EMV and TLS security proto-cols. Faculty of Science, Mathematics andComputer Science, RU. 2015-11

Y. Dajsuren. On the Design of an Archi-tecture Framework and Quality Evaluationfor Automotive Software Systems. Facultyof Mathematics and Computer Science,TU/e. 2015-12

J. Bransen. On the Incremental Evaluationof Higher-Order Attribute Grammars. Fac-ulty of Science, UU. 2015-13

S. Picek. Applications of EvolutionaryComputation to Cryptology. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2015-14

C. Chen. Automated Fault Localizationfor Service-Oriented Software Systems. Fac-

ulty of Electrical Engineering, Mathemat-ics, and Computer Science, TUD. 2015-15

S. te Brinke. Developing Energy-AwareSoftware. Faculty of Electrical Engineer-ing, Mathematics & Computer Science,UT. 2015-16

R.W.J. Kersten. Software Analysis Methodsfor Resource-Sensitive Systems. Faculty ofScience, Mathematics and Computer Sci-ence, RU. 2015-17

J.C. Rot. Enhanced coinduction. Fac-ulty of Mathematics and Natural Sciences,UL. 2015-18

M. Stolikj. Building Blocks for the Inter-net of Things. Faculty of Mathematics andComputer Science, TU/e. 2015-19

D. Gebler. Robust SOS Specifications ofProbabilistic Processes. Faculty of Sci-ences, Department of Computer Science,VUA. 2015-20

M. Zaharieva-Stojanovski. Closer to Re-liable Software: Verifying functional be-haviour of concurrent programs. Facultyof Electrical Engineering, Mathematics &Computer Science, UT. 2015-21

R.J. Krebbers. The C standard formalizedin Coq. Faculty of Science, Mathematicsand Computer Science, RU. 2015-22

R. van Vliet. DNA Expressions – A FormalNotation for DNA. Faculty of Mathematicsand Natural Sciences, UL. 2015-23

S.-S.T.Q. Jongmans. Automata-TheoreticProtocol Programming. Faculty of Mathe-matics and Natural Sciences, UL. 2016-01

S.J.C. Joosten. Verification of Intercon-nects. Faculty of Mathematics and Com-puter Science, TU/e. 2016-02

M.W. Gazda. Fixpoint Logic, Games,and Relations of Consequence. Facultyof Mathematics and Computer Science,TU/e. 2016-03

S. Keshishzadeh. Formal Analysisand Verification of Embedded Systems for

Healthcare. Faculty of Mathematics andComputer Science, TU/e. 2016-04

formal analysis and verification of embedded systems for … · experience as an instructor. i am...

Documents