Reliable Software Technologies - Ada-Europe 2009: 14th Ada-Europe International Conference, Brest, France, June 8-12, 2009, Proceedings (Lecture Notes ... Programming and Software Engineering)

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris ...

Author: Fabrice Kordon | Yvon Kermarrec

23 downloads 892 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

5570

Fabrice Kordon Yvon Kermarrec (Eds.)

Reliable Software Technologies – Ada-Europe 2009 14th Ada-Europe International Conference on Reliable Software Technologies Brest, France, June 8-12, 2009 Proceedings

13

Volume Editors Fabrice Kordon Université P. & M. Curie LIP6 - CNRS UMR 7606 4 Place Jussieu, 75252, Paris cedex 05, France E-mail: [email protected] Yvon Kermarrec Telecom Bretagne Technopôle Brest-Iroise CS 83818, 29238 Brest cedex 3, France E-mail: [email protected]

Library of Congress Control Number: Applied for CR Subject Classification (1998): D.2, D.1, D.3, F.3, F.4, I.1.3 LNCS Sublibrary: SL 2 – Programming and Software Engineering ISSN ISBN-10 ISBN-13

0302-9743 3-642-01923-4 Springer Berlin Heidelberg New York 978-3-642-01923-4 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12685325 06/3180 543210

Preface

The 14th International Conference on Reliable Software Technologies – AdaEurope 2009 – was part of a series of annual international conferences devoted to the promotion and advancement of all aspects of reliable software technologies. The objective of this series of conferences, which is run and sponsored by AdaEurope, the European federation of national Ada societies, is to provide a forum to promote the development of reliable software both as an industrial technique and an academic discipline. This edition marked a return to France by selecting the splendid venue of Brittany, a region marked by its history with a strong Celtic tradition and a remote situation at the western tip of the continent that was the initiator of many explorers of new worlds... and information and communication technologies. Previous editions of the Reliable Software Technologies conferences were held in: Venice (Italy) in 2008, Geneva (Switzerland) in 2007, Porto (Portugal) in 2006, York (UK) in 2005, Palma de Mallorca (Spain) in 2004, Toulouse (France) in 2003, Vienna (Austria) in 2002, Leuven (Belgium) in 2001, Potsdam (Germany) in 2000, Santander (Spain) in 1999, Uppsala (Sweden) in 1998, London (United Kingdom) in 1997 and Montreux (Switzerland) in 1996. The conference series chooses its yearly venue following two driving criteria: to celebrate the activity of one of its national member societies in a particular country and/or to facilitate the formation, or the growth, of a national community around all aspects of reliable software technologies. This edition of the conference relied on the initiatives and the support of AdaFrance, a national member of Ada-Europe: since the very beginning, the French academic and industrial communities have been active in the development and the use of Ada, and constitute highly active communities in reliable software technologies (the Turing award oﬀered to Joseph Sifakis in 2007 certiﬁes it). We can of course mention Jean Ichbiah’s dedication and leadership in launching the Ada language, and his views are still acute. We dedicate this edition of the conference to his memory. Following its usual style, the conference included a three-day technical program, where the papers contained in these proceedings were presented. Papers were received from all over the world (with several contributions from SouthEast Asia). The technical program was bracketed by two tutorial days where attendants had the opportunity to catch up on a variety of topics related to the ﬁelds covered by the conference, at both introductory and advanced levels. The technical program also included an industrial track, with contributions illustrating challenges faced and solutions devised by industry from both sides of the Atlantic. Furthermore, the conference was accompanied by an exhibition where vendors presented their products for supporting reliable software development.

VI

Preface

Associated workshops were also organized: one was on AADL and another on software vulnerabilities. The conference featured three distinguished keynote speakers, who delivered state-of-the-art information on topics of great importance, both for the present and the future of reliable software technologies: – ISO JTC 1/SC 22/WG 23 Work on Programming Language Vulnerabilities by John Benito (Blue Pilot Consulting, USA) – Fault Tolerance in Large Scale Distributed Systems by Pierre Sens (Universit´e P. & M. Curie, France) – Validation of Safety-Critical Systems with AADL by Peter Feiler (SEI, USA). We would like to express our sincere gratitude to these distinguished speakers for sharing their insights with the conference participants. Regular papers were submitted from as many as 19 diﬀerent countries. The Program Committee worked hard to review them, and the selection process proved to be diﬃcult, since many papers had received excellent reviews. The Program Committee eventually selected 18 papers for the conference and these proceedings. The ﬁnal result was a truly international program with contributions from Argentina, Australia, China, France, Italy, Spain, Switzerland, the UK and the USA, covering a broad range of topics: High-Integrity, Testing, Education, Real-Time, MDE, MDE and AADL, Ensuring Software Integrity. The industrial track of the conference also received valuable contributions from industry, and the Industrial Committee selected six of them for presentation in Brest: – Flight Management System Validation Through Performance Analysis and Simulation, V´eronique Fabre, Catherine Tesseidre (Thales Avionics Toulouse, France), Madeleine Faug`ere (Thales Research and Technology, France) – Pattern-Based Refactoring Shrinks Maintenance Costs, John S. Harbaugh (The Boeing Company, USA) – Couverture - Project Coverage - An Innovative Open Framework for Coverage Analysis of Safety Critical Applications, Matteo Bordin (AdaCore, France) – ITEA SPICES: AADL Experimentation at Airbus, Pierre Gauﬁllet (Airbus, Toulouse, France), S´ebastien Heim (CS, France), Hugues Bonnin (CS, France), Pierre Dissaux (Ellidiss, France) – Region-Based Memory Management for Safety-Critical Systems, Tucker Taft, (SofCheck, USA) – Generating Component-Based AADL Applications with MyCCM-HI and Ocarina, Thomas Vergnaud (Thales, France), Gr´egory Ha¨ık (Thales, France), J´erˆome Hugues (TELECOM ParisTech, France) The conference also included an interesting selection of tutorials, featuring international experts who presented introductory and advanced material in the domain of the conference:

Preface

VII

– Building Cross-Language Applications Using Ada, Quentin Ochem (France) – An Introduction to Parallel and Real-Time Programming With Ada, John McCormick (USA) – Software Fault Tolerance, Pat Rogers (USA) – Software Measures for Building Dependable Software Systems, William Bail (USA) – Modeling for Schedulability Analysis With the UML Proﬁle for MARTE, Julio Medina (Spain) and Huascar Espinoza (France) – SPARK - The Libre Language and Toolset for High-Assurance Software, Roderick Chapman (UK) – Hard Real-Time and Embedded Systems Programming, Pat Rogers (USA) – Designing Real-Time, Concurrent, and Embedded Software Systems Using UML and Ada, Rob Pettit (USA) – Object-Oriented Programming in Ada 2005, Matthew Heaney (USA) – Execution Time: Analysis, Veriﬁcation, and Optimization in Reliable Systems, Ian Broster (UK) We wish to extend our gratitude to these experts, for the work they put in preparing and presenting this material during the conference. Reports on the tutorial program and the industrial track will all be published in issues of the Ada User Journal produced by Ada-Europe. The 14th International Conference on Reliable Software Technologies – AdaEurope 2009 was made possible through the generous support and diligent work of many individuals and organizations. A number of institutional and industrial sponsors also made important contributions and participated in the industrial exhibition. Their names and logos appear on the Ada-Europe 2009 website1 . We gratefully acknowledge their support. A subcommittee composed of Dirk Craeynest, J´erˆome Hugues, Yvon Kermarrec, Fabrice Kordon, Ahlan Marriott, Laure Petrucci, Erhard Pl¨ odereder, Jorge Real, and Frank Singhoﬀ met in Paris to elaborate the ﬁnal program selection. Various Program Committee members were assigned to shepherd some of the papers. We are grateful to all those who contributed to the technical program of the conference. We would like to thank the members of the Organizing Committee for their valuable eﬀort in taking care of all the details that needed attention for a smooth run of the conference. J´erˆome Hugues did a superb job in organizing an attractive tutorial program. Frank Singhoﬀ took on the diﬃcult task of preparing the industrial track. We would also like to thank Dirk Craeynest, who worked very hard to make the conference prominently visible, and to all the members of the Ada-Europe Board for helping with the intricate details of the organization. Special thanks go to Yvon Kermarrec, Mickael Kerboeuf, Alain Plantec and Frank Singhoﬀ, who took care of all details of the local organization. Finally, we also thank the authors of the contributions submitted to the conference, and all the participants who helped in achieving the goal of the

1

http://www.ada-europe.org/conference2009.html

VIII

Preface

conference: to provide a forum for researchers and practitioners for the exchange of information and ideas about reliable software technologies. We hope they all enjoyed the program as well as the social events of the 14th International Conference on Reliable Software Technologies – Ada-Europe 2009. June 2009

Fabrice Kordon Yvon Kermarrec

Organization

Conference Chair Frank Singhoﬀ

Universit´e de Bretagne Occidentale/LISyC, France

Program Co-chairs Fabrice Kordon Yvon Kermarrec

Universit´e Pierre & Marie Curie, Paris, France Telecom Brest, Brest, France

Tutorial Chair J´erˆome Hugues

TELECOM ParisTech, Paris, France

Exhibition Chair Pierre Dissaux

Ellidiss Technologies, France

Publicity Chair Dirk Craeynest

Aubay Belgium and K.U. Leuven, Belgium

Local Co-chairs Alain Plantec Mickael Kerboeuf

Universit´e de Bretagne Occidentale/LISyC, France Universit´e de Bretagne Occidentale/LISyC, France

Program Committee Alejandro Alonso Johann Blieberger Maarten Boasson Bernd Burgstaller Dirk Craeynest Alfons Crespo Juan A. De la Puente Raymond Devillers Philippe Dhaussy Michael Gonz´alez-Harbour

Universidad Polit´ecnica de Madrid, Spain Technische Universit¨at Wien, Austria University of Amsterdam, The Netherlands Yonsei University, Korea Aubay Belgium and K.U. Leuven, Belgium Universidad Polit´ecnica de Valencia, Spain Universidad Polit´ecnica de Madrid, Spain Universit´e Libre de Bruxelles, Belgium ENSIETA/LISyC, France Universidad de Cantabria, Spain

X

Organization

Jos´e-Javier Guti´errez Andrew Hately G¨ unter Hommel J´erˆome Hugues Hubert Keller Yvon Kermarrec Fabrice Kordon Albert Llemos´ı Franco Mazzanti John McCormick Stephen Michell Javier Miranda

Universidad de Cantabria, Spain Eurocontrol CRDS, Hungary Technische Univesit¨ at Berlin, Germany TELECOM ParisTech, France Institut f¨ ur Angewandte Informatik, Germany T´el´ecom Bretagne, France Universit´e Pierre & Marie Curie, France Universitat de les Illes Balears, Spain ISTI-CNR Pisa, Italy University of Northern Iowa, USA Maurya Software, Canada Universidad Las Palmas de Gran Canaria, Spain Daniel Moldt University of Hamburg, Germany Scott Moody Boeing, USA Laurent Pautet TELECOM ParisTech, France Laure Petrucci LIPN, Universit´e Paris 13, France Lu´ıs Miguel Pinho Polytechnic Institute of Porto, Portugal Erhard Pl¨ odereder Universit¨at Stuttgart, Germany Jorge Real Universidad Polit´ecnica de Valencia, Spain Alexander Romanovsky University of Newcastle upon Tyne, UK Jean-Pierre Rosen Adalog, France Lionel Seinturier Universit´e de Lille, France Frank Singhoﬀ UBO/LISyC, France Oleg Sokolsky University of Pennsylvania, USA Ricky Sward MITRE, USA Tullio Vardanega Universit` a di Padova, Italy Francois Vernadat LAAS-CNRS, Universit´e de Toulouse, Insa Andy Wellings University of York, UK J¨ urgen Winkler Friedrich-Schiller Universit¨ at, Germany Luigi Zaﬀalon University of Applied Sciences, Switzerland

Additional Reviewers Stephen Creﬀ Michael Duvigneau Pierre-Emmanuel Hladik Alexei Iliasov Didier Le Botlan

Olivier Marin Javier Miranda Xavier Renault Silvano Dal Zilio

Industrial Committee Guillem Bernat Agusti Canals Roderick Chapman Colin Coates

Rapita Systems, UK CS, France Praxis HIS, UK Telelogic, UK

Organization

Dirk Craeynest Tony Elliston Franco Gasperoni Hubert Keller Bruce Lewis Ahlan Marriott Rei Str˚ ahle

Aubay Belgium and K.U. Leuven, Belgium Ellidiss Software, UK AdaCore, France Forschungszentrum Karlsruhe GmbH, Germany US Army, USA White-Elephant GmbH, Switzerland Saab Systems, Sweden

Sponsoring Institutions and Companies AdaCore Aonix Cap’tronic Ellidiss Technologies

IBM Institut T´el´ecom Rapita Systems

XI

Table of Contents

Requirements on the Target Programming Language for High-Integrity MDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alessandro Zovi and Tullio Vardanega

1

A Restricted Middleware Proﬁle for High-Integrity Distributed Real-Time Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Santiago Urue˜ na, Juan Zamorano, and Juan A. de la Puente

16

Validating Safety and Security Requirements for Partitioned Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Julien Delange, Laurent Pautet, and Peter Feiler

30

On Comparing Testing Criteria for Logical Decisions . . . . . . . . . . . . . . . . . Man Fai Lau and Yuen Tak Yu Model Checking Techniques for Test Generation from Business Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Didier Buchs, Levi Lucio, and Ang Chen

44

59

An Experience on Ada Programming Using On-Line Judging . . . . . . . . . . Francisco J. Montoya-Dato, Jos´e Luis Fern´ andez-Alem´ an, and Gin´es Garc´ıa-Mateos

75

Weak Fairness Semantic Drawbacks in Java Multithreading . . . . . . . . . . . Claude Kaiser and Jean-Fran¸cois Pradat-Peyre

90

Implementation of the Ada 2005 Task Dispatching Model in MaRTE OS and GNAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mario Aldea Rivas, Michael Gonz´ alez Harbour, and Jos´e F. Ruiz

105

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alan Burns, Andy J. Wellings, and Fengxiang Zhang

119

Predicated Worst-Case Execution-Time Analysis . . . . . . . . . . . . . . . . . . . . Amine Marref and Guillem Bernat Implementing Reactive Systems with UML State Machines and Ada 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sergio S´ aez, Silvia Terrasa, Vicente Lorente, and Alfons Crespo Modelling and Evaluating Real-Time Software Architectures . . . . . . . . . . . Jos´e L. Fern´ andez S´ anchez and Gloria M´ armol Acitores

134

149 164

XIV

Table of Contents

A Formal Foundation for Metamodeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liliana Favre

177

Modeling AADL Data Communication with BIP . . . . . . . . . . . . . . . . . . . . . Lei Pi, Jean-Paul Bodeveix, and Mamoun Filali

192

Formal Veriﬁcation of AADL Speciﬁcations in the Topcased Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bernard Berthomieu, Jean-Paul Bodeveix, Christelle Chaudet, Silvano Dal Zilio, Mamoun Filali, and Fran¸cois Vernadat Process-Algebraic Interpretation of AADL Models . . . . . . . . . . . . . . . . . . . Oleg Sokolsky, Insup Lee, and Duncan Clarke Ocarina : An Environment for AADL Models Analysis and Automatic Code Generation for High Integrity Applications . . . . . . . . . . . . . . . . . . . . . Gilles Lasnier, Bechir Zalila, Laurent Pautet, and J´erome Hugues

207

222

237

Conceptual Modeling for System Requirements Enhancement . . . . . . . . . . Eric Le Pors and Olivier Grisvard

251

Coloured Petri Nets for Chronicle Recognition . . . . . . . . . . . . . . . . . . . . . . . Christine Choppy, Olivier Bertrand, and Patrice Carle

266

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

283

Requirements on the Target Programming Language for High-Integrity MDE Alessandro Zovi and Tullio Vardanega University of Padua Department of Pure and Applied Mathematics via Trieste 63, 35121 Padova, Italy [email protected]

Abstract. This paper discusses the requirements on the selection of a programming language as the target of automated code generation in a high-integrity model driven engineering environment. We show that the dominant point of view for this selection becomes that of the designer of the model-to-code transformation engine. We then illustrate the application of the proposed requirements on a simple example.

1

Introduction

Whereas most model-driven engineering (MDE) approaches tend to consider source code as a mere by-product of the production process [5], there still exist application domains, such as the high-integrity (HI) one, which, while seriously interested in adopting some suited form of MDE, still regard source code as inescapably subject to intensive veriﬁcation and validation activities for quality and performance. Therefore, while MDE evolves MDA [16] into an encompassing engineering discipline and gains successful adoption in industrial applications [21], the designers of programming languages ought to pay attention to the novel requirements that arise from the need to integrate the target language in the fabric of the model transformations. That integration is especially delicate in the HI application domain, in that it may decisively contribute to or else fail the fulﬁllment of the MDE promises of increased quality for lesser cost. In this sense it is natural to ask ourselves how a programming language should be designed to successfully develop an integration with an MDE environment, especially so in a HI application domain. These considerations bring a novel actor and stakeholder into the landscape of programming language stakeholders, in addition to the typical programmer: the developer of the transformation engine. In this paper we shall refer to that ﬁgure as “ the supplier”, in opposition to the classic ﬁgure of “the user”. This paper has two goals: (i) ﬁrst, we want to determine which characteristics of a programming language make it equally ﬁt as the target of automated model to code generation in an MDE environment as well as suited for permitting manual coding to ﬁll in the parts of the software product that cannot be conveniently factored into model transformation rules; (ii) second, we want to F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 1–15, 2009. c Springer-Verlag Berlin Heidelberg 2009

2

A. Zovi and T. Vardanega

refer the resulting requirements — in so far as they diﬀer from those captured for example by Brosgol in [7,14] — to the consideration of programming language designers. The remainder of this section brieﬂy describes key aspects and a recent research project which were paramount sources for the generation of the following requirements. The rationale we follow in section 2 to capture and analyze such requirements is the following. We start with MDE HI requirements deﬁned from the experience in the construction of a MDE HI environment — see subsection 1.3 — then we expand each of them to address language selection requirements and relate them with those typically set for safety-critical applications as for example captured by Brosgol [14]. Previous work which describes useful requirements of a code generation engine [5] is also accounted for in the elaboration of our set of MDE HI requirements. An brief comparison of two programming languages against such requirements is also presented. 1.1

High-Integrity Application Domain

A high-integrity application domain is characterized by product-related concerns subsumed by the notions of dependability and predictability, and process-related concerns captured by the notion of “high-integrity”. Dependability [19] is that property of a computer system such that reliance can justiﬁably be placed on the service it delivers. “High-integrity” instead is primarily a quality of the software development process, which must often conform to domain-speciﬁc accreditation standards. A domain-speciﬁc accreditation standard, which may also include certiﬁcation, promulgates all the requirements needed to guarantee that a software product developed under these requirements is able to deliver its services. This ability is ascertained by a combination of static and dynamic veriﬁcation. In general, the higher the level of integrity, the more extensive the coverage by static analysis is. 1.2

The MDE Paradigm

Classical software development focuses mostly on functional needs. Aspectoriented programming [18] was the ﬁrst methodology introduced to address this problem by acknowledging separation of concerns. Concerns, or aspects, are described independently from the functional part of the system, and are weaved with it after the development process. Concerns, in fact, are a way to address the non-functional dimensions of software modularity. The Object Management Group (OMG) has launched the Model Driven Architecture (MDA) [23] initiative, which promotes a separation of concerns between platform independent and platform speciﬁc. MDA methodologies use models characterized by diﬀerent semantic specializations and diﬀerent levels of abstraction to specify software systems. In particular, the Platform Independent Model (PIM) describes the business and application logic of the system, using a

Requirements on the Target Programming Language for High-Integrity MDE

3

specialized language. A series of automated model transformations yield one or more Platform Speciﬁc Models (PSM) which include the realization details that are needed to implement the system on the target platform. Model-Driven Engineering (MDE) [16] clariﬁes and extends the MDA ideas and ambitions. First of all, MDE clariﬁes that the adopted modeling language must be deﬁned in terms of a given metamodel. It is the existence of the latter in fact that permits an economic and portable speciﬁcation of automated model transformations by attaching deﬁned semantics to the notations used in the model. Secondly, MDE extends MDA, which only expresses the dichotomy PIM-PSM, by adding the more general concept of perspectives or viewpoints, to promote better separation of concerns. These perspectives view diﬀerent models which may be linked to each other by means of (desirably automatic) model transformations. These model transformations aim to generate models and to preserve model properties in both directions. The key aspects of MDE thus certainly include separation of concerns and automated transformations. To fulﬁll its promise the MDE paradigm obviously needs an integrated development environment, equipped with view-speciﬁc modeling capabilities, model transformations and code generation engines. 1.3

A Component Model for Separation of Concerns

In a recent research project (the ASSERT project IST-FP6-2004 004033) an integrated development toolset prototype was developed to design HI systems using a metamodel conceptually traceable to a UML2 proﬁle [3,24] that comes in the form of an Eclipse plug-in [25] and supports fully automated code generation for the architectural part of the system [2,1,3], while functional modeling and functional code generation is partially covered by using state machines and a high-level action language [10]. This project achieved successful integration between MDE (for automated code generation) [5] and a support for reuse via the component model outlined in [27]. As in this project PIM serves for the business logic and PSM takes care of all the non-functional aspects of the system it was natural to use components to embed functional logic and containers to embed components providing the semantics speciﬁed in the system design phase. The adopted component model approach draws from the CORBA Component Model (CCM) [12]. In CCM, in fact, a container provides an execution environment oﬀering services for its internal components. Components with embedded functional behavior are decoupled from service conﬁguration in a way that maximizes ﬂexibility and reuse. This separation could possibly be achieved also with AOP, but the disadvantages of the complexity of the creation of the weaver outweigh the advantages of its ﬂexibility, even considering the crosscutting concerns that arise with component models [11]. In other words, the component model provides a standard way to implement non-functional aspects by use of software modules written in the same language of business logic as opposed to AOP approach which needs a description language and a weaving mechanism along, for example, the source code generation of the MDE approach.

4

1.4

A. Zovi and T. Vardanega

Object-Oriented High Integrity Components

In the aforementioned project, components are implemented via a constrained object oriented paradigm (OOP) which is deprived from features that make the static analysis diﬃcult or impossible like dynamic class loading or unbounded memory allocation and is amenable to static analysis by a feasible and aﬀordable approach [4]: domain-speciﬁc metamodeling which constrains the design semantics allows model-based static analysis of high integrity systems using dynamic-binding. The two most notable beneﬁts arise from educated use of OOP in HI domain are: (i) overcoming one of the limitation of model-driven technologies, that is maintaining a tolerable distance between the model and the implementation which may cause the losing of control over the run-time behavior of the speciﬁcations; and (ii) reducing the costs of analysis by focusing mostly on classes and considering instances only for instance-speciﬁc attributes that may not be inferred from the corresponding class. In the remainder of this paper we will refer to this restricted form of OOP when speaking about object orientation.

2

Requirements

Before discussing speciﬁc requirements, we should ﬁrst make some basic considerations. The integration of a MDE design environment with an implementation language may lead to confusion on what is ’the’ language that the user must be concerned with. The modeling language is the language used to design the system with the environment tools. The programming language, instead, implements the system as designed. Furthermore, speaking of “programming language”, we mean a set of integrated constituents, which include the programming language itself, its libraries, the compilation system, and an associated execution environment. The latter is a stacked collection of run-time libraries along with a run-time kernel, a distribution middleware and communication services which provide useful services such as concurrency, distribution, active properties preservation, etc. The capabilities of the programming language, intended as all of its constituents, can and actually should be abstracted out into a computational model that informs the metamodel space and is consequently reﬂected in the relevant semantics of the adopted modeling language. The following analysis of requirements is based on the assumption that an MDE environment provides the majority of instruments to completely model a system with minimum user intervention on the generated source code suppliers are concerned with the implementation of software artefacts to ease the implementation of the model-to-code generator, users need only to codify algorithmic or logic parts without using language-speciﬁc features or thinking about non-functional concerns of the system if necessary. The reader should be informed that in this paper we do not address security concerns and that distribution issues are discussed at an initial level only.

Requirements on the Target Programming Language for High-Integrity MDE

5

We ﬁrst enumerate the requirements of the design environment — which includes the modeling language — then we proceed with those of the programming language. We call the former supplier-level requirements to distinguish them from user-level requirements, that is, those captured by previous works which consider only programming-based development processes. 2.1

MDE HI Requirements

The requirements of a MDE HI environment come from MDE requirements, HI requirements concerning MDE approach and requirements of the infrastructure of the design environment. MDE requirements are divided in modeling language requirements and model transformations requirements. Modeling language must provide separation of concerns (requirement M1) which addresses the need for the separation between functional and non-functional concerns. The latter may in fact be seen as the application of recurrent solutions, which may consequently be automatically instantiated instead of being designed and implemented ad hoc by the user. All it takes to this end, in fact, is a transformation engine that associates non-functional declarations of system needs (to be regarded as components’ “contracts”) to proved solutions (archetypes [3]). Model transformations must obviously preserve properties (requirement M2), especially so in a HI application domain. HI requirements related with MDE are non-functional concerns such as timing predictability (requirement M3) and temporal, spatial and communication isolation (requirement M4 and relevant subrequirements). More speciﬁcally, predictability allows static analysis on timing properties of the system; timing, spatial and communication isolation prevents local faults to harm the entire system. Faults come from violations of contracts associated to timing, memory and communication bandwidth stipulation made in the system speciﬁcation. Violations are checked against execution time budgets, access outside assigned memory regions, and bandwidth allocations in the use of communication media. Environment requirements are the result of the implementation of above requirements. They are traceability (requirement M5) and economy of expression (M6). The tool which allows the construction of artefacts across diﬀerent levels of abstraction need traceability to map each of them at every level. This is also mandatory in a HI context. M6 instead means that constructed models must Table 1. Requirements of MDE HI environment M1 - Separation of concerns M2 - Property preservation M3 - Timing predictability M4 - Isolation M4.1 - temporal isolation M4.2 - spatial isolation M4.3 - communication isolation M5 - Traceability M6 - Economy of expression

6

A. Zovi and T. Vardanega

express their computational semantics with minimum notation and thus minimal user’s eﬀort. MDE HI requirements are conveniently resumed in table 1. 2.2

Supplier-Level Language Requirements

Considering only the HI application domain, previous works have deﬁned what are safety-critical requirements for programming languages. Brosgol has made a useful list of DO–178B-related [14] requirements in [7]. Clearly, this list considers only traditional code-based processes (user-level requirements). We therefore need to expand the requirements in table 1 to consider MDE processes (supplierlevel requirements) and see whether there is any correspondence with user-level requirements. Accordingly, we do not enumerate all user-level requirements but only consider the main categories of them: (1) reliability, (2) predictability, (3) analyzability, and (4) expressiveness. (1) refers to the ability of the programming language to implement the system as intended providing reliable semantics and without introducing diﬃculties in the implementation (errors or error-prone solutions). (2) refers to the proper deﬁnition and coherence of the implemented system’s behavior. (3) refers to the ease of analyzability of the implemented system and to the extent of predictability of properties of interest (such as timing ones). (4) refers to language’s support for writing or providing various functionalities. To better deﬁne what are the requirements of a target programming language we clarify its role in a MDE context. From an MDE point of view [16], a programming language could be considered the language representing the implementation perspective and thus it must be related to other high-level perspectives through a certain mapping (language translation). The mapping aims both to be a generative method from a close-to-implementation model (PSM) to an implementation ’model’ and to maintain consistency between these models. This leads suppliers to the implementation of a model-to-code transformation engine which should reﬂect both MDE HI (table 1) and user-level requirements on supplier-level requirements of the target programming language. This happens because suppliers must convey requirements from above (modelingspace) and from below (implementation-space) to achieve the objectives of the MDE (HI) paradigm while they fulﬁll all the requirements of a HI application’s implementation. Elaboration of MDE HI requirements. From requirement M1 we derive that the target programming language should facilitate separation of concerns. In particular it should have semantics which permit and actually promote separation between functional and non-functional, that is, between product-speciﬁc (thus typically hand-written) code and recurrent, domain-speciﬁc code (thus more prone to automated generation). This separation increases the reusability of functional code, spares the veriﬁcation of generated code (which should be guaranteed to be correct by construction [3]) and permits to place recognizable boundaries that prevent reciprocal overwriting between hand-coding and automatic generation [5].

Requirements on the Target Programming Language for High-Integrity MDE

7

Table 2. Supplier-level language requirements derived from requirement “Separation of concerns” Requirement Reliability Support for MDE practice Object-oriented capabilities Specialized conﬁguration features Support for deployment Analyzability Certiﬁable execution environment

Already user-level

Allowing the implementation of a model means dealing with modeling standards typical of the MDE approach. The target programming language should have a semantics for qualiﬁers consistent with the modeling language. As we have used a UML2 inspired proﬁle (see subsection 1.3) and UML is a de facto standard, the language should support object oriented semantics to be consistent with UML and which allows the creation of containers and components which in turn facilitates separation of concerns. A language which does not directly support modeling standards makes it diﬃcult to code and to trust a system modeled with them as the distance between the model and the code may be considerably more diﬃcult to bridge and there would be much work for code generation scripts and possibly external tools (e.g., for weaving) which, in a HI context, must be submitted to certiﬁcation. A suitably certiﬁed compiler instead reduces the gap and caters for a much smoother implementation and validation of the code generation scripts. Furthermore the programming language should have the semantic capabilities to enable the implementation of every user model allowable in the domain, including those that require distribution (in which case the language must ease deployment on partitions) and hardware-dependent conﬁgurations. A language which comes with a certiﬁed execution environment (and thus is simple, small and predictable) is the preferable solution in that it eases the portability of the software implementation, particularly in distributed embedded systems, while it requires limited changes to to ﬁt the speciﬁc characteristics of the target hardware. A language which has no such run-time environment must rely on external libraries (e.g. concurrency, communication, distribution, conﬁguration) which need to be certiﬁed also to work together. For this reason, the latter solution is hardly an option. The key issue is that these capabilities must be clearly speciﬁed and simply to analyse, especially the object oriented semantics as suggested in subsection 1.4. From requirement M2 we derive that target language should itself capture and preserve PSM properties. Thus the language should provide speciﬁc syntax to capture (reliability), semantics to realize and mechanisms to preserve these contracts. An example of contract is the description of a provided service — implemented by a schedulable entity — which could be composed of priority, period and worst case execution time.

8

A. Zovi and T. Vardanega

Table 3. Supplier-level language requirements derived from requirement “Property preservation” Requirement Reliability Support for development of readable, correct code Syntax to capture contracts Run-time checking Contract monitoring and enforcement Analyzability Semantics amenable to static analysis

Already user-level

Table 4. Supplier-level language requirements derived from requirement “Timing predictability” Requirement Analyzability Semantics amenable to static analysis Time predictability Execution environment certiﬁable Kernel overheads well documented

Already user-level

Preservation can only be guaranteed if the run-time behavior of the implementation is analyzable and constantly monitorable during execution (for dynamic properties such as execution time) by means of run-time checks that capture property violations. The language semantics should also be amenable to static analysis to ensure static properties are fulﬁlled previous execution such as number of a required service invocations. Having a syntax for capturing contracts — besides a more general readable and unambiguous syntax which is also an user-level requirement — along with support of object oriented semantics to construct components further simpliﬁes the construction of a generator which maps directly models to code. In fact, being able to reduce and visually simplifying the transformation scripts greatly improves their analyzability and maintainability. From requirement M3 we derive that target language should produce timing predictable software which is also a user-level requirement. This follows from a language semantics amenable to static analysis (analyzability). Furthermore a timing predictable programming language should have a run-time kernel with well documented overheads. When they come to implementation, requirements M2 and M3 overlap to some extent. From requirement M4 we derive that target language’s execution environment should have run-time checks for fault detection (reliability). We consider timing (M4.1), memory (M4.2) and communication (M4.3) faults. As before, requirements M2 and M4 overlap to some extent. Memory faults are prevented with static analysis as typical constraints in HI application domain deny dynamic memory allocations. Timing and communication faults instead are detected by run-time checks.

Requirements on the Target Programming Language for High-Integrity MDE

9

Table 5. Supplier-level language requirements derived from requirement “Isolation” Requirement Reliability Support for MDE practice Specialized conﬁguration features Support for logical partitions Run-time checking Contract monitoring and enforcement Temporal/communication isolation Analyzability Semantics amenable to static analysis Space predictability

Already user-level

Table 6. Supplier-level language requirements derived from requirement “Traceability” Requirement Already user-level Reliability Support for good software engineering practice Reliable semantics (concurrency features) Support for MDE practice Semantics expressive enough to fully encompass the computational model of choice Support for proﬁling (deﬁnition of subsets) Predictability Unambiguous language semantics Analyzability bi-directional traceability

From requirement M5 we derive that traceability should be preserved between model and source code. Traceability is warranted if the target language maps its semantics to the computational model of choice, that is it should have a non-subset of the features of MDE metamodel proﬁle in use. In this way correct source code generation scripts assure automatic coverage of the model requirements. To this end a target language should natively support profiling to tailor itself to the proﬁle in use without relying an external independent parser to ensure that no excluded language constructs are in use (reliability) and the execution environment disables unnecessary features . The semantics implementing the computational model should be well deﬁned, in other words the language should not have unpredictable behavior (predictability) and it should be reliable (e.g., regarding concurrency, concurrency semantics should be reliable). Furthermore, requirement M5 applies to both source and object code (analyzability) generating bi-directional traceability requirements also captured by user-level requirements. M6 has no direct inﬂuence on target language requirements. However it eases the construction of the model-to-code generator, at least for the querying of model properties, as M6 inﬂuences the extent of simplicity of the modeling language while keeping the same expressive power. Therefore, a programming language with analogous simplicity for syntax — as it must have the same expressive power of the modeling language, see table 6 — allows an even simpler implementation of such engine. As stated for requirements in table 3.

10

A. Zovi and T. Vardanega

Table 7. Supplier-level language expressiveness requirements Requirement Already user-level Expressiveness General purpose features consistent with all requirements of relia bility, predictability and analyzability

Table 8. Supplier-level language requirements derived from user-level ones Reliability Support for development of readable, correct code Early error detection Strong typing Compile checking whenever possible Run-time checking for array indexing etc Analyzability Requirements coverage Expressiveness Support for specialized processing for embedded systems Interrupt handling Low-level programming

For expressiveness requirements it is enough to say that target language features which do not include speciﬁc interaction with hardware should be consistent with all the requirements of reliability, predictability and analyzability. This is also an user-level requirement. User-level requirements of interest. In keeping with the assumption made earlier in this section, we consider that the suppliers of the design environments are the main actors who have to use the language features to write source code for implementing basic components (or archetypes) [27,3] subject to HI requirements. Those suppliers are therefore interested in languages which fulﬁll HI requirements. This perspective leads to consider user-level requirements as a part of supplier-level requirements. User-level requirements are all captured by Brosgol’s list [7]. However, as we have shown that there is a match for most of them in tables [2–7], we may now discuss those that are left in table 8, leaving securityrelated requirements aside since they are not of our interest in this paper. When it comes to the implementation, the suppliers need to rely on a programming language syntax which avoids programming errors (“no traps and pitfalls”) (reliability). The language should provide also compile-time checking whenever possible and strong typing (reliability) along with run-time checking for number operations or array indexing to ease the implementation of archetypes. Furthermore requirement coverage should be made possible for archetypes. Moreover the language should support specialized processing for embedded systems such as interrupt handling, low-level programming (access to memory), etc (expressiveness). There is only a requirement of Brosgol’s list which is not present in the supplier-level requirements: encapsulation. As we consider support for object oriented features a mandatory requirement, encapsulation is not enough. This is not a surprise as DO–178B requirements are derived from a standard which was

Requirements on the Target Programming Language for High-Integrity MDE

11

written without contemplating the beneﬁts that some educated form of object orientation could bring to modularity, encapsulation and reuse.

3

Target Language Comparison

Aforementioned requirements can be used to select a programming language suitable to code generation in MDE HI environment. The following glimpse of a comparison focuses for the most part of MDE HI requirements which are not covered by previous works (for example [8]) which address user-level requirements and is based mostly on experience described in subsection 1.3. The two programming languages taken into account are Ada 2005 with Ravenscar Proﬁle (to be referred as Ada [13]) and Real Time Speciﬁcations for Java 1.0.2 (to be referred as RTSJ [15]) since other languages lack evident needed features such as an execution environment and/or object oriented features like, respectively, C++ and C safety-critical subsets [9]. In that research project Ada was chosen as primary target language for source code generation while Java code generation is still in progress. Table 9 lists the requirements taken in consideration with a corresponding grade of accommodation for each language. Requirements without a grade serve only for separating categories. Grade spans from “fair” (which means the requirement could be fulﬁlled with a great amount of work by designers of the language) to “excellent” (which means the requirement is completely fulﬁlled without intervention). Semantics expressive enough to fully encompass the computational model of choice. Given a general computational model which includes concurrency suitable for an HI application domain, both Ada and RTSJ are capable languages. For example, their general purpose concurrency features easily cater for the restricted form of concurrency of the Ravenscar proﬁle [13] which bridges over the low-level Java concurrency features and those high-level of Ada (e.g., no multiple entries in monitor, no use of select statement). Support for profiling. Ada is designed to supply language restrictions allowing to specify those features that the program is not using in so far appropriate analysis techniques can be performed. Java instead tries to support subsets with J2ME [22] although a solution amenable to certiﬁcation should come from subsetting RTSJ through safety-critical Java speciﬁcation [20]. Object Oriented capabilities. Java is a dynamic object-oriented programming language, therefore it should be diﬃcult to discard problematic features like those listed in subsection 1.4. Instead Ada, as it has an orthogonal object oriented model to the rest of the language, combine the power of Java object oriented features with the possibility to exclude the entirety or a part of them [6]. Support for deployment. Ada has its own integrated conﬁguration language for distributed application, gnatdist [17] which could be used in a HI implementation of the distributed system annex [26] which simpliﬁes the deployment of

12

A. Zovi and T. Vardanega

Table 9. Target language comparison Requirement Ravenscar Ada 2005 RTSJ 1.0 Reliability Support for MDE practice Semantics expressive enough to fully encompass the Very good Good computational model of choice Support for proﬁling (deﬁnition of subsets) Very good Average Object Oriented capabilities Very good Average Specialized conﬁguration features Support for deployment Good Average Support for development of readable, correct code Syntax to capture contracts Good Very good Run-time checking Contract monitoring and enforcement Good Very good Analyzability Certiﬁable execution environment Good Average Kernel overheads well documented Very good Average

the application and possibly describes QoS parameters. Java does not have an equivalent language, instead it relies on external framerworks. Syntax to capture contracts, contract monitoring and enforcement. With the advent of a proposed standardized high-level library that solves common real-time problems [29], Ada gains upon the RTSJ real-time API providing the same support for description of schedulable entities, deadline miss and budget overrun detection answering the critics which are raised for its limited real-time support [30]. Certifiable execution environment, kernel overheads well documented. While there are certiﬁable (Ravenscar compliant) execution environment for Ada Java still lacks one, at least until a mature implementation of safety-critical Java arises [20]. Speciﬁcations of the execution behavior and their implementation must be predictable to detect overheads for a speciﬁc platform (e.g., context switch overhead) [28]. In conclusion, based on our experience, Java is still an immature technology but with room of improvement, particularly with the arriving of the safetycritical subset. Ada, instead, could be adopted in a MDE HI environment and in fact it is. However it lacks a standardized library like RTSJ’s API and some monitoring features (e.g., logical partition budget monitoring).

4

Conclusion

The contribution of this paper is the identiﬁcation of a set of requirements for a programming language to be used in a model driven engineering environment aimed to high-integrity system development (a MDE HI environment). We have shown that supplier of a MDE HI environment are the main stakeholders who need to write source code and contemporarily write transformation language rules to generate an application-tailored implementation of pre-written

Requirements on the Target Programming Language for High-Integrity MDE

13

and proven archetypes [3] built with a target language. Thus a new set of requirements is generated from both previous captured requirements for HI application domain and new ones due to the integration with MDE HI environment which come from the experience of constructing a MDE HI environment (see 1.3). We call this set the supplier-level requirements of the language to distinguish them from user-level requirements which consider only the classical code-based approach of system development. We hope that this new set is taken into account by programming language designers as the increasing success of MDE (MDA [21]) adoption in business critical applications is an important factor of change in the way of developing software systems. This set and its possible consideration by programming language designers is all the more important in mission critical (HI) application domains where the product quality must abide by strict standards and thus the integration of the language and the design environment leaves less room in the choice of programming languages [5]. The main change from previous user-level requirements is the requirement of object oriented features. This is in fact mandatory for the construction of a reliable and simpler integration with semantically-proven bindings at a reduced cost of run-time performances [5]. Performances are, in fact, the only noteworthy weak spot of a model-driven approach which are well addressed by programmers. Nevertheless implementing static analyzable object oriented features in the target languages — supported by model analysis [4] — surely will be considerated in upcoming certiﬁcation standards such as DO–178C [31]. New requirements imply a target language with an associated execution environment, possible companion tools and libraries which, with their compliance with HI certiﬁcations, ease the implementation, conﬁguration, reuse and deployment of the software. Aside obviously HI-compliant execution environment and libraries, it is important that companion tools have the same characteristics to warrant a product with same level of compliance. Furthermore new requirements come from thinking of the language as an instrument with strict relation with the design environment. So, new notions of semantics abstracted out into a computational model expressible in the modeling language, the ability to capture and preserve component contracts at both codelevel and run time, the support for language proﬁling and separation of concerns need to be addressed directly, or at least their implementation eased, by MDEfriendly programming languages.

References 1. Bordin, M., Vardanega, T.: Automated model-based generation of ravenscarcompliant source code. In: ECRTS, pp. 59–67. IEEE Computer Society Press, Los Alamitos (2005) 2. Bordin, M., Vardanega, T.: A new strategy for the HRT-HOOD to ada mapping. In: Vardanega, T., Wellings, A.J. (eds.) Ada-Europe 2005. LNCS, vol. 3555, pp. 51–66. Springer, Heidelberg (2005) 3. Bordin, M., Vardanega, T.: Correctness by construction for high-integrity real-time systems: A metamodel-driven approach. In: Abdennahder, N., Kordon, F. (eds.) Ada-Europe 2007. LNCS, vol. 4498, pp. 114–127. Springer, Heidelberg (2007)

14

A. Zovi and T. Vardanega

4. Bordin, M., Vardanega, T.: A domain-specific metamodel for reusable, objectoriented, high-integrity components. In: OOPSLA DSM 2007 (2007) 5. Bordin, M., Vardanega, T.: Real-time java from an automated code generation perspective. In: Bollella, G. (ed.) JTRES. ACM International Conference Proceeding Series, pp. 63–72. ACM, New York (2007) 6. Brosgol, B.M.: A comparison of the object-oriented features of ada 2005 and javatm. In: Kordon, F., Vardanega, T. (eds.) Ada-Europe 2008. LNCS, vol. 5026, pp. 115–129. Springer, Heidelberg (2008) 7. Brosgol, B.M.: Languages for safety-critical software: Issues and assessment. In: Ada Core. IEEE Computer Society, Los Alamitos (2008) 8. Brosgol, B.M., Wellings, A.J.: A comparison of ada and real-time javaTM for safetycritical applications. In: Pinho, L.M., Gonz´ alez Harbour, M. (eds.) Ada-Europe 2006. LNCS, vol. 4006, pp. 13–26. Springer, Heidelberg (2006) 9. MISRA C, http://www.misra-c2.com/ 10. Cechticky, V., Egli, M., Pasetti, A., Rohlik, O., Vardanega, T.: A UML2 profile for reusable and verifiable software components for real-time applications. In: Morisio, M. (ed.) ICSR 2006. LNCS, vol. 4039, pp. 312–325. Springer, Heidelberg (2006) 11. Clemente, P.J., N´ un ˜ez, J.H., Murillo, J.M., P´erez, M.A., S´ anchez, F.: AspectCCM: An aspect-oriented extension of the corba component model. In: EUROMICRO, pp. 10–16. IEEE Computer Society Press, Los Alamitos (2002) 12. Deng, G., Xiong, M., Gokhale, A.S., Edwards, G.: Evaluating real-time publish/subscribe service integration approaches in qoS-enabled component middleware. In: ISORC, pp. 222–227. IEEE Computer Society Press, Los Alamitos (2007) 13. Dobbing, B., Burns, A.: The ravenscar tasking profile for high integrity real-time programs. In: SIGAda, pp. 1–6 (1998) 14. Radio Technical Commission for Aeronautics, http://www.rtca.org 15. The Real-Time Specification for Java, http://www.rtsj.org 16. Kent, S.: Model driven engineering. In: Butler, M., Petre, L., Sere, K. (eds.) IFM 2002. LNCS, vol. 2335, pp. 286–298. Springer, Heidelberg (2002) 17. Kermarrec, Y., Nana, L., Pautet, L.: Gnatdist: a configuration language for distributed ada 95 applications. In: TRI-Ada 1996: Proceedings of the conference on TRI-Ada 1996, pp. 63–72. ACM Press, New York (1996) 18. Kiczales, G., Lamping, J., Menhdhekar, A., Maeda, C., Lopes, C., Loingtier, J.M., Irwin, J.: Aspect-oriented programming. In: Aksit, M., Matsuoka, S. (eds.) ECOOP 1997. LNCS, vol. 1241, pp. 220–242. Springer, Heidelberg (1997) 19. Laprie, J.C.C., Avizienis, A., Kopetz, H. (eds.): Dependability: Basic Concepts and Terminology. Springer, New York, Inc (1992) 20. Douglass Locke, C.: Safety critical javaTM technology. In: JTRES 2006: Proceedings of the 4th international workshop on Java technologies for real-time and embedded systems, Paris, France, pp. 95–96. ACM, New York (2006) 21. OMG’s MDA, http://www.omg.org/mda/products_success.htm 22. Sun Microsystems. JavaTM 2 Platform, Micro Edition (November 2002), http://java.sun.com/j2me 23. Miller, J., Mukerji, J.: Model driven architecture (MDA). Draft ormsc/2001-07-01, Architecture Board ORMSC (July 2001) 24. Panunzio, M., Vardanega, T.: A metamodel-driven process featuring advanced model-based timing analysis. In: Abdennahder, N., Kordon, F. (eds.) Ada-Europe 2007. LNCS, vol. 4498, pp. 128–141. Springer, Heidelberg (2007) 25. The Eclipse Platform, http://www.eclipse.org

Requirements on the Target Programming Language for High-Integrity MDE

15

26. Urue´ na, S., Zamorano, J.: Building high-integrity distributed systems with ravenscar restrictions. In: IRTAW 2007: Proceedings of the 13th international workshop on Real-time Ada, pp. 29–36. ACM, New York (2007) 27. Vardanega, T.: Property-preserving reuse-geared approach to model-driven development. In: RTCSA, pp. 223–232. IEEE Computer Society Press, Los Alamitos (2006) 28. Vardanega, T., Zamorano, J., De La Puente, J.A.: On the dynamic semantics and the timing behavior of ravenscar kernels. Real-Time Syst. 29(1), 59–89 (2005) 29. Wellings, A.J., Burns, A.: A framework for real-time utilities for ada 2005. In: IRTAW 2007: Proceedings of the 13th international workshop on Real-time Ada, pp. 41–47. ACM Press, New York (2007) 30. Wellings, A.: Is java augmented with the rtsj a better real-time systems implementation technology than ada 95? In: IRTAW 2003: Proceedings of the 12th international workshop on Real-time Ada, pp. 16–21. ACM Press, New York (2003) 31. SC-205 WG-71, http://ultra.pr.erau.edu/SCAS/

A Restricted Middleware Profile for High-Integrity Distributed Real-Time Systems Santiago Urue˜ na, Juan Zamorano, and Juan A. de la Puente Universidad Polit´ecnica de Madrid (UPM), E28040 Madrid, Spain {suruena,jzamorano,jpuente}@dit.upm.es

Abstract. High-integrity computer systems are usually required to go through a strict veriﬁcation and validation process, often leading to certiﬁcation according to some safety or security standard. Veriﬁcation activities may include some kind of static analysis because some types of errors cannot be removed just with testing. Temporal analysis techniques are available for systems with hard real-time requirements, but they are limited to systems complying with a well-deﬁned computational model and with a restricted semantics that ensures a predictable temporal behaviour. The Ravenscar proﬁle implements such a model for Ada programs running on single processor platforms, but it cannot be used in distributed high-integrity real-time systems, which are becoming more and more common. This papers discusses the feasibility of designing a real-time middleware for distributed high-integrity Ada programs with an statically analysable behaviour, and the necessary language restrictions that should be used in order to enable the required predictability and timeliness properties. Keywords: Ada 2005, real-time systems, high-integrity systems, distributed systems, Ravenscar proﬁle.

1

Introduction

Static analysis tools are increasingly being employed in high-integrity systems to prove the absence of some kinds of software errors. For example, stack memory overﬂows or inﬁnite loops cannot be detected merely with dynamic testing. In addition, high-integrity systems often have hard real-time requirements which must be guaranteed in order to ensure a proper temporal behaviour under all circumstances. Temporal static analysis methods, such as response-time analysis (RTA) [1,2], are often used to assess predictability and timeliness properties of critical real-time systems. Static analysis methods may require the expressive power of programming languages to be restricted in order to enhance determinism. In the case of Ada, the Guide for the use of the Ada programming language in high integrity systems [3]

This work has been funded in part by the Spanish Ministry of Science, project no. TIC2005-08665-C03-01 (THREAD), and by the IST Programme of the European Commission under project IST-004033 (ASSERT).

F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 16–29, 2009. c Springer-Verlag Berlin Heidelberg 2009

A Restricted Middleware Proﬁle

17

provides a set of guidelines for restricting the sequential part of the language in order to use diﬀerent kinds of static analysis methods. The Ravenscar proﬁle (RP) [4], in turn, deﬁnes a subset of Ada tasking that enables response-time analysis of concurrent Ada programs. The proﬁle can be enforced at run time by means of a pragma that sets a number of restrictions in the code [5]. The restrictions ensure that the program complies with a computational model—the Ravenscar Computational Model (RCM)—on which RTA can be applied. Response-time analysis methods and the Ravenscar proﬁle are well established for single processor systems, which have been the dominant kind of platform for high-integrity systems for a long time. However, there is a rising interest in building critical systems on distributed platforms, in a widespread of application areas including spacecraft systems, automobiles, and industrial systems, among others. Distributed systems not only enable applications to run on physically separated computers, but also provide enhanced fault tolerance, separation between parts of the system with diﬀerent safety or security levels, and more processing power than a single CPU. Therefore, there is a need for deﬁning analysis methods and computational models that are suitable for high-integrity real-time distributed systems. Since the Ravenscar proﬁle is generally admitted to be a solid foundation for building high-integrity real-time systems, it seems natural to consider its possible use in distributed systems, by extending the rationale behind it to the requirements of this kind of systems. The Ada Distributed Systems Annex (DSA) [5, Annex E] provides support for distribution in the framework of the language itself. The DSA and the Ravenscar proﬁle ignore each other, as they address diﬀerent aspects of Ada programs, and thus one might be naively tempted to think that they can be safely used together as they are. However, there are some problems that make the current form of the DSA unsuitable for hard real-time distributed systems [6]. This is not surprising since it was designed with general purpose distributed systems in mind, although implementations are allowed to extend and adapt the annex with new functionality and rules. A possible approach is to restrict the set of features deﬁned in the DSA in order to develop a predictable computational model for distributed systems, following the same line of thought that led to Ravenscar proﬁle. The main goals of this paper are to make progress in the deﬁnition of such a restricted DSA, and to explore the possibility of developing a middleware that implements the computational model so that it can be used for developing predictable, timely real-time distributed systems. The rest of the paper is organized as follows. Section 2 describes previous related work, including some relevant results in scheduling theory. Section 3 discusses the adequacy of the Ada DSA for real-time distributed systems. Section 4 analyses the requirements of a high-integrity DSA implementation. A set of restrictions to be applied for developing predictable distributed systems is deﬁned in section 5. Middleware implementation requirements are discussed in section 6. Finally, section 7 summarizes the main conclusions of this work.

18

2 2.1

S. Urue˜ na, J. Zamorano, and J.A. de la Puente

Previous Work Response Time Analysis

Response time analysis [1,2] is a well-established method for analysing the temporal behaviour of mono-processor real-time systems. It allows developers to analyse systems with a static set of periodic and sporadic tasks with arbitrary deadlines, communicating by means of a static set of shared data objects protected by mutual exclusion constraints. Tasks can be scheduled using a variety of scheduling methods, but usually ﬁxed-priority pre-emptive scheduling (FPPS) is assumed. A priority inheritance protocol [7] such as the immediate ceiling priority protocol (ICPP) must be used in order to limit the eﬀects of priority inversion. Temporal analysis can be extended to distributed systems by using holistic analysis methods [8,9]. These methods assume that a system executes a set of transactions, each of them consisting of a sequence of tasks with precedence constraints. Tasks may be ordinary real-time tasks running on a computer node, or messages transmitted over a communication link. The scheduling model is an extension of that used for monoprocessor systems, i.e. FPPS and ICPP with arbitrary deadlines plus oﬀsets modelling precedence relationships. This model can be used to calculate upper bounds of worst case response times with some degree of pessimism. The most important implication of holistic RTA for distributed systems is the requirement that messages have bounded and known worst-case transmission times. The method also assumes that, in case of conﬂict, messages are scheduled using a predictable method that enables response times to be computed for every single message transmission. Analysis tools such as Cheddar [10] and MAST [11] provide support for response-time analysis techniques. 2.2

Real-Time Distributed Systems in Ada

The suitability of the Ada DSA for real-time systems has been analysed on diﬀerent occasions [6,12]. One important problem that has been identiﬁed is that the DSA does not take into account any kind of real-time attributes, including priorities [13]. An extension of the DSA that can be used to build distributed real-time systems has been implemented in RT-GLADE [14], a derivative of the GNAT-based GLADE middleware [15] enabling detailed priority speciﬁcation for all components of a transaction. However, it is not compatible with the Ravenscar proﬁle as it uses dynamic priorities and other features which are not allowed by the proﬁle. An alternative approach, which will be explored further in this paper, is to restrict the DSA features in a similar way as the Ravenscar proﬁle, in order to enable implementations to support static response time analysis for distributed systems. A preliminary proposal of such a distributed Ravenscar proﬁle was presented by the authors at IRTAW 2007 [16]. New results presented here include the deﬁnition of a comprehensive set of restrictions for a distributed high-integrity

A Restricted Middleware Proﬁle

19

proﬁle based on DSA, as well as a discussion of possible implementations based on some common RTOS interfaces. Other distribution models are also possible. For example, PolyORB-HI [17] is a high-integrity middleware based on AADL [18]. It is compatible with the Ravenscar proﬁle, and has been integrated with other subsystems in the ASSERT Virtual Machine [19], a predictable platform for aerospace embedded systems. Another distribution model that has raised some interest is RT-CORBA [20]. However, implementations of this model are generally considered not suitable for high integrity systems due to various concerns related to size, complexity, and lack of predictability of the middleware [21].

3

The Ada Distributed Systems Annex

Diﬀerent approaches can be used for building distributed applications in Ada. One possibility is to use the RTOS communication services directly, e.g. ARINC 653 ports [22] or Posix sockets [23]. This approach is error-prone and fragile, as the programmer has to add code for address resolution and connection handling, parameter marshalling and unmarshalling, as well as message sending. This is a low-level approach that cannot be considered acceptable under the current state of software technology. Another possibility is to use a distribution middleware, such as CORBA [24], DDS [25], or Java RMI [26]. This is a more structured and less error-prone approach. It commonly includes type checking and auto-generation of low-level communication code. Each middleware supports one or more communication paradigms, such as Remote Procedure Call (RPC), Remote Method Invocation (RMI), or Publish/Subscribe (P/S). However, although a middleware framework provides some transparency for connecting with other nodes, the user still has to manually call a set of complex communication services, such as naming services or object registry for remote operation binding. A better alternative is to use a distributed programming language, where the distribution mechanism is not merely a library API, but is incorporated into the language semantics. In the case of Ada, the DSA deﬁnes the features needed for distributing an Ada program over diﬀerent nodes. Such a program is divided into a number of partitions, which can be allocated to computer nodes. Each partition can deﬁne interfaces which can be called remotely, and the compiler generates the code for connection setting, data marshalling and unmarshalling, and request processing. The DSA supports several communication paradigms, namely Distributed Shared Memory, Asynchronous Message Passing, Remote Call Interface, and Remote Method Invocation. This is the most advanced and less error-prone approach, and has been part of the language standard since Ada 95. The Ada DSA has additional advantages over other kinds of distribution middleware. For example, every distributed Ada application built with the DSA is also a valid centralized Ada program, which can be used for testing and debugging the software. However, from a real-time systems perspective, the most

20

S. Urue˜ na, J. Zamorano, and J.A. de la Puente

important DSA feature is the ability to perform static analysis on the whole application. Many existing ASIS tools can be used to analyse a distributed Ada application. For example, a whole DSA program coded in SPARK can be analysed using the SPARK Examiner tool “as is”. Other tools that need to be aware of the presence of distribution can be conﬁgured so that they can interpret the distribution pragmas, and even read a conﬁguration ﬁle in order to take into account the exact location of each Ada partition. The capability of checking properties of the whole application is much more diﬃcult to achieve in other approaches, where the distribution mechanism is provided by an API —even when using a restricted distribution model. The DSA also has some shortcomings [16]. For example, it does not support the P/S paradigm; it forces the programmer to always use dynamic dispatching for remote object oriented programming; or the non-standard integration with the real-time features, as discussed above. All in all, we believe that the advantages of the DSA outweigh its shortcomings, specially regarding static analysis, and make it an appropriate approach for programming high-integrity systems.

4 4.1

Requirements for a High-Integrity DSA Certification

The ﬁrst requirement for a high-integrity distribution middleware is that it can be validated for its use in critical applications, which often implies undergoing a certiﬁcation process. This requirement has two implications: – The middleware must be implemented in such a way that it can be veriﬁed and validated as required by the certiﬁcation process. This in turn usually implies that the programming language used for its implementation is restricted so that the appropriate veriﬁcation techniques can be applied. The ISO Technical Report about the use of Ada in high-integrity systems [3] and, if tasking is used within the middleware, the Ravenscar proﬁle [27], provide guidance in this respect. – The distributed model must be restricted in such a way that features that may lead to increasing the complexity of the middleware and are not strictly required for building high-integrity embedded distributed applications are removed. It should be noticed that, from this point of view only, other DSA features that may not be so well suited for a high-integrity environment need not be restricted, as long as their use has no impact on the implementation of the middleware. Optional restrictions can be added to the language so that designers of critical system are able to disable these features, while developers of embedded, but non-critical software can still use them.

A Restricted Middleware Proﬁle

4.2

21

Hard Real-Time Communication

Another key requirement for the middleware is that it must provide for hard realtime communication. This implies that the temporal behaviour of all components of a distributed system must be predictable. This usually requires the ability to assign diﬀerent priorities to client and server tasks, as well as exchanged messages. This requirement also implies that the distribution model must be restricted in some way. In particular, some distribution features that may jeopardize the temporal predictability of applications should not be allowed. Some other features, even being compatible with holistic response time analysis, lead to extremely pessimistic estimations that may make the analysis useless. An example of such a feature in centralized systems is entry queues with arbitrarily bounded lengths, which are forbidden by the Ravenscar proﬁle following a similar line of thought. It should be noticed that ideally the model restrictions should still be compatible with the unrestricted DSA, in a similar way as the Ravenscar restrictions do not aﬀect the code that is generated by the compiler, but only the run-time system functionality and structure. Therefore, the code generated by the compiler for a distributed application should be the same when using the full DSA or a restricted proﬁle, the only diﬀerence being in the middleware implementation itself. 4.3

Static Analysis of Distributed Applications

The safety-critical industry recognizes that testing is not enough for removing all the errors of a system. For example, a recent report foresees that in the near feature the use of static analysis tools will be the only cost-eﬀective way of building dependable systems [28]. In a distributed application multiple Ada partitions executing in parallel collaborate to achieve a common objective. Therefore, it is of paramount importance that a restricted distribution proﬁle enables both partition-wide and program-wide analysis of whole distributed applications.

5

Ada Restrictions for Predictable Distribution

According to the requirements that have been discussed in the previous section, the middleware supporting the Ada DSA distribution model, as well as the distributed applications running on top of it, must use a restricted subset of the language in order to ensure a predictable real-time behaviour. An appropriate language (and annex E) subset can be deﬁned without modifying the core language by using some new pragmas and restrictions, in addition to those already deﬁned in the Ada 2005 standard. The rest of this section contains a proposal of a number of new Ada pragmas and restrictions that together make up an Ada proﬁle for predictable distributed systems. Some of the restrictions are always needed to enable a simpliﬁed middleware implementation. In addition, programmers can optionally adhere to other proposed restrictions in order to ease user-code certiﬁcation. The compiler can

22

S. Urue˜ na, J. Zamorano, and J.A. de la Puente

check nearly all the restrictions at compilation time, although some violations can only be detected at run-time (or using static analysis with external tools). 5.1

Compulsory Restrictions

The following restrictions are aimed at enabling a predictable behaviour both for the middleware itself and for the distributed applications. Ravenscar restrictions. The ﬁrst step is to comply with the Ravenscar proﬁle restrictions, both at the middleware and the application level. This implies that tasks and protected objects must be statically declared, and the only way of intertask communication within a computer node is by means of protected objects with at most an entry with a simple boolean barrier and no waiting queues. Some other Ravenscar restrictions have a direct impact on the distribution model. For example, since tasks may not terminate partitions may not terminate either. Asynchronous transfer of control is forbidden, which results in no cancellation being possible for remote procedure calls. It is also worth mentioning that, although the programmer can explicitly use dynamic memory, the run-time system is not allowed to use implicit heap allocation. Therefore, the middleware should not be allowed to use dynamic memory either. Coordinated elaboration. In a hard real-time system all deadlines must be met, and consequently every real-time message must be processed in a bounded time by the destination node. A new pragma is required in order to ensure that no real-time remote call is enqueued until the target partition is elaborated. The proposed syntax for the pragma is pragma Interpartition Elaboration Policy (Coordinated); The default elaboration policy as deﬁned in the current DSA can be denoted as Decoupled. The Coordinated policy implies that pragma Partition Elaboration Policy(Sequential) is in use within each partition. Coordinated elaboration requires the set of partitions to be known before elaboration starts, which is consistent with the static conﬁguration usually required for high-integrity systems. A further requirement is that the application does not make any remote calls during the elaboration phase, which could lead to deadlocks. This requirement can be speciﬁed with a new restriction identiﬁer, No Remote Calls In Elaboration Code. Violations of this rule would result in the Program Error exception being raised at elaboration time. Explicit communication and resource creation. All the resources must be reserved at system initialization, including all channels for inter-partition communication. Therefore a new restriction identiﬁer, No Dynamic Channels, is proposed that prevents the application from invoking any operation that might require a communication channel to be dynamically created. Notice that the concept of communication channel is internal to the middleware and can be

A Restricted Middleware Proﬁle

23

implemented in diﬀerent ways. Violations of this rule also result in raising Program Error. Another important restriction is that all communication with remote partitions must be explicit, as letting the middleware exchange messages without control by the programmer might compromise the predictability of applications. For example built-in protocols for clock synchronization or routing messages would introduce extra traﬃc that will disrupt the schedulability analysis of the network. Such protocols can be provided by the system, but must be invoked explicitly by the programmer when desired. The proposed restriction identiﬁer is No Implicit Communication. Notice that implicit communication should be allowed during the elaboration phase in order to let the nodes set up the necessary communication channels. Restrictions in remote operations. Protected objects must not be deﬁned in shared distributed memory areas, as it would introduce a dangerous dependence in partition scheduling. For example, a low-criticality partition could delay a high-criticality partition if both share a protected object in a shared passive package. Therefore, a restriction identiﬁer for this purpose is proposed, No Shared Passive Protected Objects. Another necessary restriction is that pointers to objects located in shared passive objects must not be allowed, as they could lead to overwhelmingly complex implementations. A restriction identiﬁer No Aliased Shared Passive Objects is proposed for this purpose. Both restrictions can be statically checked by the compiler. Another proposed restriction is No Remote Access Class Wide Types. Currently, references to remote tagged types cannot be static, in contrast with subprograms of remote call interfaces. Therefore, remote access to tagged types requires dynamic storage allocation, and is thus incompatible with the static nature of high-integrity systems. It should be noticed that this restriction forbids the use of the RMI paradigm. A restricted form of distributed tagged types not requiring dynamic remote references could be further investigated in order to try to overcome this drawback. The restriction Max Concurrent Remote Calls => 1 limits the number of concurrent calls to the same remote subprogram. The idea behind it is similar to the Ravenscar restriction Max Entry Queue Length => 1. It must be noticed that server tasks are created per remote operation and per calling partition. Moreover, the set of tasks and their priorities must be static in order to be compliant with the Ravenscar computational model. As a result, two tasks in the same partition must not concurrently invoke the same remote operation, as there is only one server task servicing both calls. Noticed that concurrent calls to the same remote operation from tasks belonging to diﬀerent partitions can be allowed, as this problem only applies to concurrent calls from a single partition. 5.2

Optional Restrictions

The following restrictions can optionally be used by those programmers that need to statically analyse the distributed application, although in some cases

24

S. Urue˜ na, J. Zamorano, and J.A. de la Puente

they can also be used to enable the distribution tool to use a more compact middleware. Limiting remote access types. As discussed above, in some situations a distributed application can try to set up a new channel after code elaboration, resulting in a run-time error. Allowing remote accesses to subprograms to be transferred between partitions could result in such an undesirable situation. The restriction No Remote Access Subprogram Transfer avoids that problem, because it requires every access to a remote subprogram to point only to RCI operations directly “withed” by the partition. The restriction can also help the distribution tool to generate better code, as there is no need to create remote stubs for every RCI operation, but only for those directly “withed” by the partition. Avoiding nested remote calls. In principle the body of a remote subprogram operation can perform an unlimited number of nested remote calls. Although this behaviour is allowed by the holistic response time analysis methods, it can introduce a high degree of pessimism and make the resulting analysis useless. The proposed restriction No Nested Remote Calls is aimed at avoiding this situation. This can be easily detected at run-time by the middleware —if a task serving a remote operation tries to make a call to a subprogram in another partition, the exception Program Error will be raised at run-time— or with static analysis using an external tool. Restricting the communication paradigm. The rich functionality provided by the DSA oﬀers many possibilities to the programmer, but in some cases it can make the application certiﬁcation process harder. In other cases, it can result in a larger code footprint than feasible on some platforms, like microcontrollers. Some additional restrictions are proposed in order to limit the use of some communication paradigms in the application code: – – – – –

6

No No No No No

Asynchronous Calls Synchronous Calls Shared Passive Units Weak Shared Passive Units Remote Call Interface Units

Implementation Issues

There are multiple alternative approaches for implementing a restricted distribution proﬁle for the Ada DSA. For example, a package with pragma Shared Passive can be implemented as an RT-Posix shared memory area (shm open) or an ARINC 653 sampling port, i.e. either as a common memory zone when the partitions sharing the data are in the same node, or by using periodic network traﬃc when they are in remote nodes. If periodic traﬃc is used for distributed shared memory it should be noticed that memory coherence is relaxed, as the updates may be viewed in diﬀerent

A Restricted Middleware Proﬁle

25

Fig. 1. Server tasks created by the middleware for each remote call interface

order from each partition. This is not a problem as long as the programmer takes this into account when developing the application —e.g. if there is just one task updating the data, which is broadcasted to the other partitions in read-only mode. Therefore, we suggest to add a new categorization pragma for distributed shared packages in order to make explicit the possibility of a relaxed memory coherence. The proposed syntax of the pragma is pragma Weak Shared Passive; In the Ravenscar Computational Model there is a static set of tasks with a ﬁxed priority. In order to keep up with this model, and allow the programmer to assign the priority which is used to serve a remote operation, a restricted distribution proﬁle must require that there is a speciﬁc static server task for each remote subprogram and client partition. For example, in the system depicted in ﬁgure 1 there are two client partitions invoking remote subprograms in partition 3. The distribution tool generates one server task per remote operation for each client partition, so all calls to Rem Op1 from partition 1 are processed by server task 1, while all calls from partition 2 are handled by server task 2. Each server task will have the priority speciﬁed in the conﬁguration ﬁle by the programmer, and thus concurrent calls from diﬀerent partitions are allowed. Moreover, high-priority calls will preempt low-priority ones, avoiding priority inversion. The priorities of the messages must also be ﬁxed. Instead of adding an implementation-dependent API for specifying message priorities, it seems more appropriate for the restricted distribution middleware to set the priorities and other real-time attributes in a conﬁguration ﬁle. Thus, the message priorities are

26

S. Urue˜ na, J. Zamorano, and J.A. de la Puente

not client-propagated, but are statically speciﬁed by the programmer at compilation time. A possible implementation uses a conﬁguration ﬁle to specify the location of each Ada partition, as well as the ﬁxed priorities for the request message, the server task, and the reply message for every single channel. Another requirement of the implementation is that unbounded priority inversion must be avoided. Therefore, data marshalling, message creation, fragmentation, and insertion in the priority ordered network queue should be executed directly by the sender task (i.e. with its priority). It should be noticed that each partition can still have an independent runtime system. No clock synchronization is needed because the communication is message-oriented [9], but of course a mechanism to obtain a certain degree of common time is desirable in a real-time system. The implementation must document the number of intermediate tasks, protected objects, and potentially blocking operations involved in a remote operation. The maximum blocking time metrics for the longest critical section should also be documented, otherwise a complete response time analysis of the whole system would be not possible. A prototype of a high-integrity middleware, PolyORB-HI [17], was developed in the ASSERT project. The middleware is Ravenscar compliant, and runs on top of the Ada 2005 version of the Open Ravenscar real-time Kernel, ORK+ [30]. It uses a Ravenscar compliant MTS protocol stack and SpaceWire network driver [19]. Although this prototype does not support DSA nor the restrictions described in this paper, it has proved to be a valuable research prototype which uncovered important topics speciﬁc to a Ravenscar compliant communications architecture.

7

Conclusions and Future Work

A set of restrictions aimed at adapting the Ada Distributed System Annex (DSA) to the needs of high-integrity distributed systems with hard real-time requirements has been proposed in this paper. The set of restrictions has been designed so as to comply with the Ada 2005 Ravenscar Proﬁle, and shares the main principles behind it. Together, it deﬁnes a restricted proﬁle for the Ada DSA. The proposed proﬁle includes some new compulsory restrictions which are needed to enable the certiﬁcation of the middleware. There are also other optional restrictions that the programmer can adhere to for easing the certiﬁcation of the distributed application. Finally, some additional pragmas are proposed which are intended to better leverage the DSA functionality commonly used in this kind of systems, like weak coherence memory sharing using periodic traﬃc. The proposed restricted distribution proﬁle enables the development of a small, high-performance middleware, which can be implemented over a variety of buses and network technologies, such as CAN bus or SpaceWire. As Ada is a distributed programming language, one the biggest advantages of using the DSA instead of an API or a distributed environment is the ability to use program-wide static analysis on whole application (e.g. no change in the Spark

A Restricted Middleware Proﬁle

27

programming language is needed). This property of the proﬁle, together with some other features which can be derived from the set of restrictions, e.g. temporal predictability and absence of centralized or distributed deadlocks, make the proﬁle an appropiate methodology for the development of dependable and high-integrity software. Planned future work includes developing a full implementation of the proﬁle by adding the proposed pragmas to the GNAT front-end, building a prototype middleware supporting the proﬁle, and developing some illustrative examples in order to gain experience on its use.

References 1. Joseph, M., Pandya, P.K.: Finding response times in real-time systems. BCS Computer Journal 29(5), 390–395 (1986) 2. Klein, M.H., Ralya, T., Pollack, B., Obenza, R., Gonz´ alez Harbour, M.: A Practitioner’s Handbook for Real-Time Analysis. In: Guide to Rate Monotonic Analysis for Real-Time Systems. Kluwer Academic Publishers, Boston (1993) 3. ISO/IEC: TR 15942:2000 — Guide for the use of the Ada programming language in high integrity systems (2000) 4. Burns, A., Dobbing, B., Romanski, G.: The Ravenscar tasking proﬁle for high integrity real-time programs. In: Asplund, L. (ed.) Ada-Europe 1998. LNCS, vol. 1411, pp. 263–275. Springer, Heidelberg (1998) 5. ISO/IEC: Std. 8652:1995/Amd 1:2007 — Ada 2005 Reference Manual. Language and Standard Libraries. Springer, Heidelberg (2007) ISBN 978-3-540-69335-2 6. Gonz´ alez Harbour, M., Moody, S.A.: Session summary: Distributed Ada and realtime. ACM SIGAda Ada Letters 19(2), 15–18 (1999); IRTAW 1999: Proceedings of the Ninth International Workshop on Real-time Ada 7. Sha, L., Rajkumar, R., Lehoczky, J.P.: Priority inheritance protocols: An approach to real-time synchronization. IEEE Tr. on Computers 39(9) (1990) 8. Tindell, K., Clark, J.: Holistic schedulability analysis for distributed hard realtime systems. Microprocessing and Microprogramming 40(2–3), 117–134 (1994); Euromicro Journal (Special Issue on Parallel Embedded Real-Time Systems) 9. Palencia Guti´errez, J.C., Gonz´ alez Harbour, M.: Exploiting precedence relations in the schedulability analysis of distributed real-time systems. In: RTSS 1999: Proceedings of the 20th IEEE Real-Time Systems Symposium, pp. 328–339 (December 1999) 10. Singhoﬀ, F., Plantec, A., Dissaux, P.: Can we increase the usability of real time scheduling theory? the Cheddar project. In: Kordon, F., Vardanega, T. (eds.) AdaEurope 2008. LNCS, vol. 5026, pp. 240–253. Springer, Heidelberg (2008) 11. Gonz´ alez Harbour, M., Guti´errez, J.J., Palencia, J.C., Drake, J.M.: MAST modeling and analysis suite for real time applications. In: Proceedings of 13th Euromicro Conference on Real-Time Systems, Delft, The Netherlands, pp. 125–134. IEEE Computer Society Press, Los Alamitos (2001) 12. P´erez, H., Guti´errez, J.J., Sangorr´ın, D., Harbour, M.G.: Real-time distribution middleware from the Ada perspective. In: Kordon, F., Vardanega, T. (eds.) AdaEurope 2008. LNCS, vol. 5026, pp. 268–281. Springer, Heidelberg (2008) 13. Audsley, N., Wellings, A.: Issues with using Ravenscar and the Ada distributed systems annex for high-integrity systems. In: IRTAW 2000: Proceedings of the 10th International Real-Time Ada Workshop, pp. 33–39. ACM Press, New York (2001)

28

S. Urue˜ na, J. Zamorano, and J.A. de la Puente

14. L´ opez Campos, J., Guti´errez, J.J., Gonz´ alez Harbour, M.: The chance for Ada to support distribution and real-time in embedded systems. In: Llamos´ı, A., Strohmeier, A. (eds.) Ada-Europe 2004. LNCS, vol. 3063, pp. 91–105. Springer, Heidelberg (2004) 15. Pautet, L., Tardieu, S.: GLADE: a framework for building large object-oriented real-time distributed systems. In: Proc. of the 3rd IEEE Intl. Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 2000) (March 2000) 16. Urue˜ na, S., Zamorano, J.: Building high-integrity distributed systems with Ravenscar restrictions. Ada Letters XXVII(2), 29–36 (2007); Proceedings of the 13th International Real-Time Ada Workshop (IRTAW 2007) 17. Hugues, J., Pautet, L., Zalila, B.: From MDD to full industrial process: Building distributed real-time embedded systems for the high-integrity domain. In: Kordon, F., Sokolsky, O. (eds.) Monterey Workshop 2006. LNCS, vol. 4888, pp. 35–52. Springer, Heidelberg (2007) 18. SAE: Architecture Analysis and Design Language (AADL) — AS5506A. (January 2009), http://www.sae.org 19. de la Puente, J.A., Zamorano, J., Pulido, J.A., Urue˜ na, S.: The ASSERT Virtual Machine: A predictable platform for real-time systems. In: Chung, M.J., Misra, P. (eds.) Proceedings of the 17th IFAC World Congress, IFAC-PapersOnLine (2008) 20. OMG: Real-Time CORBA Speciﬁcation, version 1.2. OMG TC Document formal/05-01-04 (2005) 21. Hugues, J., Pautet, L., Kordon, F.: Revisiting COTS middleware for DRE systems. In: Proceedings of the 8th IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 2005), pp. 72–79 (2005) 22. ARINC: Avionics Application Software Standard Interface — ARINC Speciﬁcation 653-1 (October 2003) 23. IEEE: Portable Operating System Interface (POSIX) — Part 1: System Application Program Interface (API) [C Language]. (1990) ISO/IEC 9945-1:1990; IEEE 1003.1-1990 24. OMG: CORBA Speciﬁcation, version 3.1. OMG TC Document formal/2008-01-04 (2008) 25. OMG: Data Distribution Service for Real-time Systems. Version 1.2 edn. (January 2007) 26. Gosling, J., Joy, B., Steele, G.: The Java Language Speciﬁcation. Addison-Wesley, Reading (1996) 27. ISO/IEC: TR 24718:2005 — Guide for the use of the Ada Ravenscar Proﬁle in high integrity systems (2005) Based on the University of York Technical Report YCS-2003-348 (2003) 28. Jackson, D., Thomas, M., Millett, L.I.: Software for dependable systems: Suﬃcient evidence? Technical report, Committee on Certiﬁably Dependable Software Systems — National Academy of Science (2007) 29. Urue˜ na, S., Pulido, J.A., Zamorano, J., de la Puente, J.A.: Adding new features to the Open Ravenscar Kernel. In: Proc. 1st International Workshop on Operating Systems Platforms for Embedded Real-Time Applications (OSPERT 2005), Palma de Mallorca, Spain (July 2005) 30. Urue˜ na, S., Pulido, J.A., Redondo, J., Zamorano, J.: Implementing the new Ada 2005 real-time features on a bare board kernel. Ada Letters XXVII(2), 61–66 (2007)

A Restricted Middleware Proﬁle

29

Appendix: Summary of Proposed Pragmas and Restrictions 7.1

Compulsory Restrictions

A new pragma is deﬁned: pragma P r o f i l e ( D i s t r i b u t e d R a v e n s c a r )

which is equivalent to: pragma P r o f i l e ( R a v e n s c a r ) ; −− ( Not new ) pragma P a r t i t i o n E l a b o r a t i o n P o l i c y ( S e q u e n t i a l ) ; −− ( Not new ) pragma I n t e r p a r t i t i o n E l a b o r a t i o n P o l i c y ( C o o r d i n a t e d ) ; −− D e f a u l t : D e c o u p l e d pragma R e s t r i c t i o n s ( No Dynamic Channels , −− P r o g r a m E r r o r No Implicit Communication , N o R e m o t e C a l l s I n E l a b o r a t i o n C o d e , −− P r o g r a m E r r o r No Shared Passive Aliased Objects , −− s t a t i c N o S h a r e d P a s s i v e P r o t e c t e d O b j e c t s , −− s t a t i c No Remote Access Class Wide Types , −− s t a t i c M a x C o n c u r r e n t R e m o t e C a l l s => 1 ) ; −− P r o g r a m E r r o r

7.2

Optional Restrictions

The following restrictions can be used whenever convenient: pragma R e s t r i c t i o n s ( No Remote Access Subprograms , No Remote Access Subprogram Transference , No Shared Passive Units , No Weak Shared Passive Units , No Remote Call Interface Units , No Asynchronous Calls , No Synchronous Calls , No Chained Remote Calls ) ;

7.3

New Functionality

The following new pragma is proposed: pragma W e a k S h a r e d P a s s i v e ;

−− −− −− −− −− −− −− −−

static static static static static static static Program Error

Validating Safety and Security Requirements for Partitioned Architectures Julien Delange1, Laurent Pautet1 , and Peter Feiler2 1

TELECOM ParisTech LTCI UMR 5141 46, rue Barrault, F-75634 Paris CEDEX 13, France [email protected], [email protected] 2 Software Engineering Institute Carnegie Mellon University [email protected]

Abstract. Design and validation of safety-critical systems are crucial because faults or security issues could have significant impacts (loss of life, mission failure, etc.). Each year, millions of dollars are lost due to these kinds of issues. Consequently, safety and security requirements must be enforced. Systems must be validated against these requirements to improve safety and security and to make them more reliable and robust. We present our approach to avoid such issues by modeling safe and secure systems with both safety and security requirements. We rely on a modeling language (AADL) to model and design partitioned systems with their requirements and constraints. We then validate these models to ensure security and safety enforcement. We also discuss how this approach can be used to automatically generate and build safe and secure partitioned systems.

1 Introduction Every system has safety and security requirements. Unlike many domains, they are especially important in the safety-critical domain since a fault can have major impact (mission failure, loss of life, etc.). Thus, we have to ensure that security and safety requirements are enforced across the system to avoid faults and failures and to provide better reliability. Many standards and approaches were designed to solve security and safety problems. Some of them provide a methodology to check requirements at a high level while others define low-level functionnalities to enforce safety or security requirements. Despite their importance, it is still difficult to validate security and safety requirements together, since existing validation techniques work with different abstractions instead of a common conceptual framework. Several years ago, the concept of partitioned architecture [1] has been proposed to address security and safety issues. The idea behind this concept consists in isolating pieces of software in partitions and make them appear independent, as if they run on different processors. By doing that, we separate system resources and isolate each partition so they cannot interfer each others. F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 30–43. c Springer-Verlag Berlin Heidelberg 2009

Validating Safety and Security Requirements for Partitioned Architectures

31

The most known standard of partitioned architecture, ARINC653 [2], provides support for safety-critical software by defining a partitioned architecture that isolates software components in partitions. It also defines a complete set of functionnality to create and manage resources inside partitions. The MILS [3] approach classifies and separates components according to their security levels. In consequence, each security level is considered as independent. To do that, MILS proposes the concept of separation kernel that is close to the partitioned kernel defined in ARINC653 [2]. Other approaches address the problem of security and safety policies enforcement. Security policies describe allowed operation between software and hardware components regarding their security levels. Once again, all these methods do not act at the same level and do not use the same representation format which makes the verification of all requirements tedious and error prone. As mentioned earlier the different approaches operate at different levels of abstraction and with different concepts. This makes it difficult to validate both security and safety requirements without developing separate analyzable models and then having to demonstrate consistency between the model in order to assure validity of the results. Therefore, we have chosen an approach that utilizes an extensible architecture language with a set of concepts that provides a semantically strong framework for reasoning about security and safety. By doing that, we help system designers: our approach detects errors in the system before any implementation. It is very important, because 70% of errors are introduced in systems design[4], prior to implementation efforts. To solve these issues and to make the development of safe and secure system easier, we propose an approach to model and validate partitioned architectures with their requirements. The modeling language describes partitioned architectures with both security and safety contraints. We check the correctness of the system by validating its security and safety policies enforcement. In our approach, we use the Architecture Analysis and Design Language (AADL) [5] to model partitioned architectures with their requirements and properties. AADL is an extensible language for modeling realtime and safety-critical systems, which led us to check models through different kind of analysis like reliability analysis [6] or schedulability analysis [7]. This work is also a part of the POK (PolyORB Kernel) project, whose purpose is to create safe and secure systems from their specification. In this project, we rely on the AADL language because its semantics fits with the needs of safety-critical systems. It defines components and properties that ease the specification of software and hardware parts of the system with their requirements (scheduling, memory, etc.). This paper details the modeling approach we use to describe real-time embedded architectures with their security and safety requirements. It also explains their validation, detailing our model validator, POK Checker. In the remainder of this paper, we first describe different approaches and standards dedicated to security and safety in the context of safety-critical and embedded systems. Then we present the AADL [5] and detail the modeling of safe and secure system using this modeling language. Finally we describe AADL models validation against security and safety policies and present our implementation.

32

J. Delange, L. Pautet, and P. Feiler

2 Security and Safety Approaches This section summarizes the state of the art on security and safety in the safety-critical domain. We present ARINC653 standard, MILS and other security policies. 2.1 Security and Safety Guidelines In the context of safety-critical systems, safety means that we want to avoid all possible occuring faults and keep the system in an error-free state. To do so, we must handle all faults and define their associated recovery procedures. Beyond that, some faults can be not handled. In that case, we want to limit their impact and avoid their propagation so they cannot affect other partitions of the system. Moreover, we separate resources across different entities of the system. We also want to prevent any unallowed usage of them. We present the ARINC653 [2] standard that defines the concept of partitioned architectures and handled faults and exceptions inside each partition. On the security side, we want to check that only allowed entities have an access to some data according to their security clearances. Consequently, all data are transported through explicit channels and we avoid covert channels that may break the security policy. This section presents the MILS [8] approach to create independent levels of security. It also describes some well-known security policies such as Bell-Lapadula [9,10] or Biba [11]. Other security policies could be found in [12]. 2.2 ARINC653 ARINC653 [2] is an industrial avionics standard published by Aeronautical Radio. It defines a set of services and functionalities to create reliable systems for the avionics domain. It defines the concept of partitioned systems. Partitioned architectures isolate software components in an entity called partition. Resources (such as processor, network interface, etc.) are isolated and separated across partitions. A dedicated kernel provides isolation in terms of: • Space: each partition owns a unique adress space to store is code and data. Also, it cannot cannot access to other address spaces. • Time: timeslices are allocated for each partitions to execute their threads. Space partitioning means that partitions have separated address space and cannot read, write or execute data from other address spaces. This mechanism isolates partition memory and prevent any modification from other partitions. Time isolation means that each partition has at least one timeslice to execute their threads and a partition cannot overrun its time budget. In ARINC653 systems, partitions are scheduled according to a static timeline protocol. It means that partitions are scheduled according to a static scheduled algorithm which is repeated at a given rate (also called the major time frame). Partitions can communicate through legal channels supervised by the kernel. No other channel can be used for inter-partition communication. Thus, no covert channel can be created. This functionnality ensures data isolation and prevents data propagation across partitions.

Validating Safety and Security Requirements for Partitioned Architectures

33

Partitions are isolated and are considered as independent. Moreover, a failure inside one partition cannot affect the others. When a fault is raised, a dedicated program recovers it to keep the system in an error-free state. The fault can be caught at different levels (thread level, partition level or kernel level). ARINC653 defines all possible faults, errors or exceptions that could happen in the system. They range from software fault (e.g: division by zero) to hardware fault (e.g: loss of power). For each possible fault, the system designer indicates at which level the fault is raised and what is its the recovering procedure. ARINC653 defines three levels of faults: kernel (called module), partition and thread (called process). For each possible fault, the system designer associates a recovering procedure. Following these guidelines, an ARINC653-compliant system ensures that: 1. Resources are separated across partitions so a partition cannot use all resources 2. Occuring faults are recovered 3. Faults cannot be propagated outside a partition. 2.3 MILS MILS (which stands for Multiple Independent Levels of Security) is an approach defined by John Rushby [8]. It isolates software components according to their security levels. It means that a software component at a certain security level may not be collocated nor exchange data with another software component at another security level. The main idea behind this concept is to prevent the mix of different security levels. As in ARINC653, we need to isolate software components. But unlike ARINC653, the isolation is achieved to isolate different security levels. MILS also defines a separation kernel that isolates and separates resources across partitions. In an ideal MILS system, each partition may have one security level (all software components inside a partitition operate at the same security level). The separation kernel isolates partitions in terms of space and time. MILS introduces a security classification for each component of the system. A component can be characterized as SLS, MSLS or MLS. An SLS (Single Level of Security) component handles only one security level. An MLS (Multiple Level of Security) uses different security levels and does not enforce isolation between these security levels. An MSLS (Multiple Separated Level of Security) component handles several security levels but enforce isolation between the different security levels. Unlike ARINC653 that deals with safety, the MILS approach is focused on security and isolate security levels. Communications between partitions are also supervised by the kernel, which enforces communication isolation, prevents covert channels and ensures that different security levels are not mixed. There is no standard that defines which functionnalities reside in a MILS-compliant system and how a MILS kernel should be designed. However, we can validate the enforcement of the MILS guidelines at different level (kernel, partition, thread, . . . ), checking security levels isolation, components classification at an architecture level. 2.4 Other Security Policies Several security policies exist and address several kind of enforcement. Each of them states allowed operations regarding subjects and objects security levels. Objects

34

J. Delange, L. Pautet, and P. Feiler

represent accessed data (for example, shared memory between partitions) whereas subjects are the entities that manipulate (read, write or execute) objects (the partitions that manipulates the shared memory). Subjects and objects are evaluated at a certain security level (confidential, etc.). A security policy describes allowed operations between subjects and objects regarding their security levels. Famous security policies are Bell-Lapadula[9], Biba [11] or Chineese Wall (other security policies could be found in [12]). Each of them defines subjects, objects and allowed or denied operations (read/write/execute) according to their security levels.

3 Modeling Safety and Security Using AADL In this section, we first present the AADL. Then, we present the modeling approach we use to describe real-time embedded systems with their safety and security requirements. We also map ARINC653 and MILS concepts to AADL models. However, readers must keep in mind that other approaches dedicated to safety or security [6] exist. 3.1 Overview of AADL AADL is a component-centric language which allows the modeling of both software and hardware components. It focuses on the definition of clear block interfaces, and separates the implementations from these interfaces. A graphical as well as a textual representation of the syntax exist. Only non-functional aspects of components can be described with AADL, e.g.: security, safety or timing properties, memory footprints, interface specification and how components are interconnected. An AADL description is made of components. The AADL standard defines software components (data, thread, thread group, subprogram, process), execution platform components (memory, bus, processor, device, virtual processor, virtual bus) and hybrid components (system). Components describe well identified elements of the actual architecture. Subprograms model procedures as in C or Ada. Threads model the active part of an application (such as POSIX threads). Processes model address spaces that contain the threads. Processors model micro-processors and a minimal operating system (mainly a scheduler). Virtual processors model a part of the processor and could be understood in different ways : part of the physical processor, virtual machine, . . . . In our case, we use it to model the runtime accessible from a partition. Memories model hard disks, RAMs, buses model all kinds of networks, wires, devices model sensors, etc.. virtual buses are not formally a hardware component, they are bounded to connections in order to describe their requirements and can also be used for several purposes. They can model protocol stacks, security layers of a bus or other requirements of a connection. Systems represent composite components that are made up of hardware components or software components or a combination of the two. For example, a system may represent a board with multiple processors and memory chips. Components may be hierarchical, i.e.: components can contain other components (called subcomponents in this case). In fact, an AADL description is always hierarchic,

Validating Safety and Security Requirements for Partitioned Architectures

35

Fig. 1. Partitioned producer/consumer system AADL

with the topmost component being an AADL system that contains—for example— processes and processors, with the processes containing threads and data. The interface specification of a component is called its type. It provides features (e.g. communication ports). Components communicate one with another by connecting their features (the connections section). Each component describes their internals: subcomponents, connections between these subcomponents, etc. An implementation of a thread or a subprogram can specify call sequences to other subprograms, thus describing the execution flows in the architecture. Since there can be different implementations of a given component type, it is possible to select the actual components to be put into the architecture, without having to change the other components, thus providing a convenient approach to application configuration. AADL allows properties to be associated with AADL model elements. Properties are typed and represent name/value pairs that represent characteristics and constraints. Examples are the period and execution time of threads and the bandwidth of a bus. The standard includes a predeclared set of properties and users can introduce additional properties through property definition declarations. For interested readers, an introduction to the AADL can be found in [13]. Other languages can be integrated in AADL models using annex libraries. These languages can be added on each component to describe other aspects. Some annex languages have been designed, such as the behavior annex [14] or the error model annex [6]. The error model annex define states of a component, its potential faults and errors and their propagation in the system. An example of AADL model is shown in figure 1. The model defines a simple system which has two processes that exchange data (one partition send a ping to another). We give a more detailed description later in the paper. AADL provides two major benefits for building safety-critical systems. First, compared to other modeling languages, AADL defines low-level abstractions including hardware descriptions. Second, the hybrid system components help refine the architecture as they can be detailed later on during the design process. These, among other reasons, are why AADL is a good design vehicle for such systems. 3.2 Modeling Security and Safety Requirements To model systems with their security and safety requirements, we must add properties and design appropriate modeling patterns. In particular, we want to:

36

J. Delange, L. Pautet, and P. Feiler

• Model partitioned architectures • Specify the security levels of each software component • Specify the security classification of each partition • Define faults, their handling and their propagation We dedicate a section to each modeling requirements. We also present another way to describe possible faults, their containment and propagation. 3.3 Modeling Partitioned Architectures In the last version of the AADL standard [5], virtual processor and virtual bus components were introduced. Their semantics are suitable to model partitioned architectures. The virtual processor is an abstraction for a processor. It models a runtime with its own requirements. We rely on this component to model partition runtime. In addition, the process component models an address space. Combination of virtual processor and process components models a partition. In this way, the process component models space isolation and the virtual processor models partition runtime. We associate each virtual processor component with a process component to combine both space and time isolation. To do that, we bound a process to a virtual processor using a specific property (Actual_Processor_Binding). The virtual processor components are contained in a processor component, which model the partitioned kernel responsible to enforce partionning functionnalities. In this component, we model the time isolation requirement using two properties: Slots and Slots_Allocation. The Slots property models allocated timeslices while the Slots_Allocation property models timeslices allocation. We also specify the memory requirements of each partition. Each partition has an address space to store its code and data. Consequently, we have to model this address space. We can also model the memory requirements of threads inside the partition using the standard property set of the AADL. The figure 1 depicts a partitioned system with two partitions and the listing 1.1 is the textual representation of this model. We add two virtual processors inside the main processor (lines 20-21) to model the partitioned kernel partitions runtime. Process components are bound to virtual processor (lines 55-56) to assiociate address spaces with partition runtimes. The connection between the ports of the process components (line 53) models inter-partitions communication. Scheduling requirements are defined in the main processor component (lines 2330) which contains and controls the partitions. The property POK::Slots defines all scheduling slots in the kernel and the POK::Slots_Allocation property defines the slots usage policy (which slot is used by which partition). In this example, the first partition is executed during 10 ms, then, the second partition is executed for 20 ms and the first partition is finally executed again during 30ms. Scheduling requirements of each partition is specified in the virtual processor component (line 3 and 10): here, each partition schedules its threads using a Rate Monotonic algorithm.

Validating Safety and Security Requirements for Partitioned Architectures

v i r t u a l processor implementation p a r t i t i o n . one properti es S c h e d u l i n g _ P r o t o c o l => (RATE_MONOTONIC_PROTOCOL) ; POK : : R ecovery_Errors => ( I l l e g a l _ R e q u e s t ) ; POK : : R ecovery_Act i ons => ( P a r t i t i o n _ R e s t a r t ) ; end p a r t i t i o n . one ; v i r t u a l processor implementation p a r t i t i o n . two properti es S c h e d u l i n g _ P r o t o c o l => (RATE_MONOTONIC_PROTOCOL) ; POK : : R ecovery_Errors => ( M em ory_Vi ol at i on ) ; POK : : R ecovery_Act i ons => ( P a r t i t i o n _ R e s t a r t ) ; end p a r t i t i o n . two ; processor ppc end ppc ; processor implementation ppc . i m p l subcomponents part _one : v i r t u a l processor p a r t i t i o n . one ; p a r t _ t w o : v i r t u a l processor p a r t i t i o n . two ; properti es S c h e d u l i n g _ P r o t o c o l => ( STATIC_TIMELINE ) ; POK : : Major_Frame => 60ms ; POK : : Schedul er => s t a t i c ; POK : : S l o t s => (10ms, 20ms, 30ms ) ; POK : : S l o t s _ A l l o c a t i o n => ( reference ( part _one ) , reference ( p a r t _ t w o ) , reference ( part _one ) ) ; POK : : R ecovery_Errors => ( Hardware_Fault , Pow er_Fai l ) ; POK : : R ecovery_Act i ons => ( I gnore , K e r n e l _ R e s t a r t ) ; end ppc . i m p l ; process send_ping_process features d a t a o u t : out event data port i n t e g e r ; properti es POK : : Needed_Memory_Size => 58000 KByte ; end send_ping_process ; process r e c e i v e r _ p i n g _ p r o c e s s features d a t a i n : i n event data port i n t e g e r ; properti es POK : : Needed_Memory_Size => 24000 KByte ; end r e c e i v e r _ p i n g _ p r o c e s s ; system implementation node . one subcomponents cpu : processor ppc . i m p l ; pr1 : process send_ping_process ; pr2 : process r e c e i v e r _ p i n g _ p r o c e s s ; connections port pr1 . d a t a o u t −> pr2 . d a t a i n ; properti es a c t u a l _ p r o c e s s o r _ b i n d i n g => ( reference ( cpu . part _one ) ) appl i es to pr1 ; a c t u a l _ p r o c e s s o r _ b i n d i n g => ( reference ( cpu . p a r t _ t w o ) ) appl i es to pr2 ; end node . one ;

Listing 1.1. Modeling of a partitioned system using AADL

37

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

38

J. Delange, L. Pautet, and P. Feiler

3.4 Modeling Security Levels Modeling security requirements in AADL models offers a way to check security policies at a high-level. We annotate the model with requirements and properties dedicated to a security policy. For example, in the case of the Bell-Lapadula and Biba models, we dintinghish subjects (which manipulate data) and objects (that correspond to data). In the following, we present our approach to add information on the model to be compliant with the Bell-Lapadula security policy. The mapping of the Bell-Lapadula security policy to AADL is clear and easily understandable. For every subject (thread, process, etc.), we add a property that models their evaluated security level. On the other hand, objects are not formally identified in the model. Instead, we define security level for each port involved in a connection. Ports and connections link two subjects and manipulate objects so we must specify the security level of manipulated objets. For each connection, we add properties that describe the security level of transfered objects. We take this security level as the one used to manipulate object. We model the security levels using the virtual bus component. The virtual bus models a security layer, describing its own security level. Thus, we define the property POK::Security_Level to specify the security level of a virtual bus. Then, we assign the security level of a partition by binding the virtual bus that represent it (with the Provided_Virtual_Bus_Class property). We also specify the security level of ports using the Allowed_Connection_Binding_Class property. The listing 1.2 illustrates the modeling of security requirements. In this example, we define two virtual bus components, each of them models a single security level. The first virtual bus (vb_secret) models the secret security level while the other (vb_unclassified) models the unclassified security level. Then, these security levels are added to partitions (to specify which security levels the partition handles) and to ports. In our example, the sender partition is classified as secret (this partition is bound to the vb_secret virtual bus) while the receiver partition is considered as unclassified (the partition is bound to the vb_unclassified virtual bus). v i r t u a l bus v b _ s e c r e t properti es POK : : S e c u r i t y _ L e v e l => 4 ; end v b _ s e c r e t ; v i r t u a l bus v b _ u n c l a s s i f i e d properti es POK : : S e c u r i t y _ L e v e l => 1 ; end v b _ u n c l a s s i f i e d ; v i r t u a l processor p a r t i t i o n _ s e c r e t properti es P r o v i d e d _ V i r t u a l _ Bu s _ C l as s => ( c l a s s i f i e r ( v b _ s e c r e t ) ) ; end p a r t i t i o n _ s e c r e t ; v i r t u a l processor p a r t i t i o n _ u n c l a s s i f i e d properti es P r o v i d e d _ V i r t u a l _ Bu s _ C l as s => ( c l a s s i f i e r ( v b _ u n c l a s s i f i e d ) ) ; end p a r t i t i o n _ u n c l a s s i f i e d ;

Listing 1.2. Modeling security levels with AADL

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Validating Safety and Security Requirements for Partitioned Architectures

39

3.5 Modeling MILS Classification We previously define the mapping of a partitioned kernel, we must also map remaining MILS concepts in AADL models. The concept of security levels has been addressed in the previous section, we now define how to map components classifications in AADL. To do that, we define a property MILS::Classification that defines the components classification. The property can have the value SLS, MLS or MSLS. By doing that, the system designer can easily define the classification of its components, detailing their security levels and isolation enforcement across them. The MILS classification are also defined in the listing 1.3. In this example, each partition is an SLS component: it handles only one security level. On the other hand, the main system that contains these partitions would be an MSLS component since it handles several security levels at the same time but enforce isolation between partitions using space isolation mecanisms. We can validate this example against the MILS rules.

v i r t u a l processor p a r t i t i o n _ s e c r e t properti es P r o v i d e d _ V i r t u a l _ Bu s _ C l as s => ( c l a s s i f i e r ( v b _ s e c r e t ) ) ; MILS : : C l a s s i f i c a t i o n => SLS ; end p a r t i t i o n _ s e c r e t ; v i r t u a l processor p a r t i t i o n _ u n c l a s s i f i e d properti es P r o v i d e d _ V i r t u a l _ Bu s _ C l as s => ( c l a s s i f i e r ( v b _ u n c l a s s i f i e d ) ) ; MILS : : C l a s s i f i c a t i o n => SLS ; end p a r t i t i o n _ u n c l a s s i f i e d ;

1 2 3 4 5 6 7 8 9 10 11

Listing 1.3. Modeling partition runtime with MILS requirements

3.6 Modeling ARINC653 Faults As we said in the previous section, faults in ARINC653-compliant systems can be declared and handled at three different levels: kernel, partition and thread. For each component that models one of these levels, we must specify what faults are handled and their associated recovery actions. For that, we introduce two dedicated properties: • The Recovery_Errors property describes all possible faults that may be raised. • The Recovery_Actions property describes available recovery procedures. These properties are added to the processor (kernel level), virtual processor (partition level) and thread (thread level) components and describe which faults and handled in each level and how we recover them. The listing 1.1 includes the definition of ARINC653-related properties. We attach to the processor all caught errors at kernel-level. In our example, the kernel ignores hardware faults and restarts when a power failure is detected. We use the same mecanisms for the partition level (the properties are then declared inside the virtual processor component) and thread level (with the thread component). The list of potential errors described in our property set could be extended by the system designer.

40

J. Delange, L. Pautet, and P. Feiler

4 Validation of Safety and Security Requirements In this section, we present our validation techniques to check security and safety requirement in AADL models. In this validation process, we check that systems satisfy the ARINC653 and MILS requirements. We also verify that security policies are enforced at the architecture level. First, we explain models validation according to partitioned architectures. Then, we check that safety requirements are enforced and all faults are handled in the system. We also present our validation techniques regarding the MILS requirements and explain how we can check other security policies using AADL models. All these analysis techniques are made on the same architecture model. This eliminates the need to create separate models for each requirement, and led us to verify all requirements together in the same model. 4.1 Validate Partitioned Architectures This first validation consists in verifying AADL models against partitioned architecture requirements. The AADL provides many components and it does not define a single component to model partitioned architectures. Consequently, we have to check the components aggregation: – Each virtual processor is contained in a processor component. – Each process component is bounded to a single virtual processor. A virtual processor component must be bound to exactly one process (1-1 relation). – All required properties of the partitioned architecture are set and their values are correct (scheduling, memory requirements and so on). The first verification checks that partitions (virtual processor) are contained to a partitioned kernel (processor) component. The second verification ensures that each separated address space is associated with a part of the partitioned runtime. It ensures space isolation (because the process models a separate address space). Then, the other verification checks others requirements. We validate scheduling requirements inspecting the timeslices allocated for partitions: we check that each partition has at least one timeslice for its execution. We also validate memory requirements of kernel and partitions according to the requirements of their subcomponents (for example, the size of a partition is correct if its threads do not need more memory than the partition memory space). Such verifications help system designers to ensure that requirements are met and models are correct. Once it has been validated, we can make further analysis and check security and safety requirements. 4.2 MILS Requirements Validation Then, we can also check MILS requirements. MILS defines the concept of a separation kernel, which is quite similar to the concept of partitioned kernel. However, we must check component connections and flows according to their classification level. As we explain in section 2, a component can be classified SLS, MSLS and MLS.

Validating Safety and Security Requirements for Partitioned Architectures

41

In the case of an SLS component, we verify that components handle only one security level. To do that, we inspect all incoming and outgoing ports and check they are at the same security level. In the case of MLS components, we verify that incoming and outgoing ports have different security levels. If all ports are at the same security level, the MILS classification is obviously wrong and should be SLS. The MSLS component is more complex since it handles different security levels but enforces isolation between security levels. To validate this kind of component, we inspect all flows inside the component and verify that incoming and outgoing ports are at the same security level. By doing that, we ensure security levels isolation. 4.3 ARINC653 Fault-Containment Validation The validation of partioned architectures was detailed previously, we now focus on fault handling. We must verify that various faults are handled at any time during system execution by thread, partition or kernel level mechanisms. For each thread, we analyze the faults handled by itself, its contained partitions and the partitioned kernel. We consider these three levels and check that all kind of faults are handled and managed. By doing that, we can determine the coverage of faults and check if every kind of faults could be recovered for each potential runnable entity. This techniques ensures that at any time, any potential fault would be recovered. So this sytem will be more reliable and errors would not have an impact on the system. 4.4 Validate Security Policy Enforcement As we said in section 2, many security policies exist, each of them uses different properties to analyze and validate a system. In the remainder of this article, we consider the Bell-Lapadula and the Biba security policies to illustrate the verification of security policies in AADL models. Bell-Lapadula and Biba security policies deal with objects and subjects. Subjects manipulate objets and each of them is evaluated at a certain security level. Then, the policy allow operations (read/write) depending on the security level of each component. Security levels are added in each component with properties. If components do not have a security level, we use the one declared in their parent component (if a thread does not have a security level, we consider the one of its containing process). Security analysis is focused on two main verifications. At first, the compliance of connections according to the security policy. It ensures that a connection does not break the security policy. Then, the compliance of the hierarchy of components against the security policy. It detects errors prevent modeling approach that are wrong regarding the partitioned architecture requirements. In our model, the security levels of each connection is identified by a virtual bus component which models security requirements of the connection. For each connection between two components, two security levels are involved: the one from the source and the one from the destination. Therefore, we can use these information to check connection legality according to a security policy requirements. Using this information,

42

J. Delange, L. Pautet, and P. Feiler

we can state if the security policy is enforced on each connection. For example, if we check the model against the Bell-Lapadula security policy, we check that the security level of the port source does not write any data at a lower-security level and security level of destination port does not read data at a higher-security level. However, we must consider the underlying executive in our verifications. Indeed, in partitioned architectures, each partition is executed in its own address space so all threads inside a partition share the same address space. Even if threads do not own a data at the model-level, they can read, write and update data contained in their partition at the implementation-level. Consequently, we have to address this issue and adapt the verification of security according to runtime internals. Thread components inside the same partition are evaluated at the same security level than their containing partition (process or virtual processor component) because they can manipulate the same data. 4.5 Other Validation Techniques AADL supports a range of model consistency checks and analysis that help system designers develop a predictable system and validate it against requirements. There is also a validation method for scheduling requirements that can be interesting in our context. In partitioned systems, scheduling is achieved at two levels : kernel and partition level. The kernel schedules partitions using a fixed timeline algorithm while partitions use their own scheduling algorithm to schedule their threads. We can check the scheduling feasability using analysis tools like Cheddar [7] which validate AADL models regarding their scheduling requirements. 4.6 Model Validator Implementation and Experiments We implement these validation patterns in our model validator, POK checker. It validates models against our modeling approach and check that: • Models describe a partitioned architecture • Each kind of faults is handled at each level (kernel, partition and thread) so we ensure that occuring faults would be recovered at run time. • Security policy is enforced at the architecture level. At this time, our software validates AADL models against Bell-Lapadula, Biba and MILS security policies. Use-cases and examples that demonstrate the correctness of our implementation are available in the releases of the POK project1. They are also detailed on our AADL portal (http://aadl.enst.fr). The current implementation is a command-line based tool that relies on Ocarina [15] functionnalities. We are currently working on another implementation as an Eclipse plug-in to validate models in this modeling platform. It will also give the possibility to combine our validation technique with other requirements validation approaches available on this platform. 1

Interested readers can learn more about the project on http://pok.gunnm.org

Validating Safety and Security Requirements for Partitioned Architectures

43

5 Conclusion and Future Work In this paper, we have proposed an approach to model security and safety concerns in AADL. In doing so we utilize a common conceptual framework for safety and security analysis. It allows us to model how partitions can be used as a common runtime mechanism to support fault isolation and separation of security levels. It improves software reliability, dependability and reduces costs of development. The result of the work discussed in this paper will be reflected in the ARINC653 annex document to the AADL standard [5]. This paper is currently in a work in progres state and will be published with the other annexes. This work is also part of the POK project, whose purpose is to create safe and secure systems from AADL specification. Once requirements are met at a model level, code generation patterns are used by a code generator to produce code for a partitioned runtime system implementation. We have implemented a working prototype of such a code generator [16] in Ocarina [15] that produces Ada and C code from AADL models. We are also working on an ARINC653 and MILS compliant AADL runtime.

References 1. Rushby, J.: Partitioning for avionics architectures: Requirements, mechanisms, and assurance. NASA Contractor Report CR-1999-209347, NASA Langley Research Center (1999) 2. Airlines Electronic Engineering: ARINC Specification 653 (2003) 3. Alves-Foss, J., Harrison, W.S., Oman, P., Taylor, C.: The MILS Architecture for HighAssurance Embedded Systems. International journal of embedded systems (2005) 4. National Institute of Standards and Technology (NIST): The economic impacts of inadequate infrastructure for software testing. Technical report (2002) 5. SAE: Architecture Analysis & Design Language v2.0 (AS5506) (September 2008) 6. Rugina, A.E., Feiler, P.H., Kanoun, K., Kaaniche, M.: Software dependability modeling using an industry-standard architecture description language. In: Proceedings of 4th European Congress ERTS, Toulouse (January 2008) 7. Frank Singhoff, A.P.: AADL Modeling and Analysis of Hierarchical Schedulers. In: ACM SIGAda Ada Letters (2007) 8. Rushby, J.: The design and verification of secure systems. In: Eighth ACM Symposium on Operating System Principles (SOSP), Asilomar, CA (December 1981) 9. Bell, D.E., LaPadula, L.J.: Secure computer system: Unified exposition and multics interpretation. Technical report, The MITRE Corporation (1976) 10. Rushby, J.: The Bell and La Padula Security Model. Computer Science Laboratory, SRI International, Menlo Park, CA (1986); Draft Technical Note 11. Biba, K.J.: Integrity considerations for secure computer systems. Technical report, MITRE 12. Kalkowski, S.: Security policies in Nizza on top of L4.sec. PhD thesis, University of Technology Dresden (2006) 13. Feiler, P.H., Gluch, D.P., Hudak, J.J.: The Architecture Analysis and Design Language (AADL): An introduction. Technical report (2006) 14. Frana, R., Bodeveix, J.P., Filali, M., Rolland, J.F.: The AADL behaviour annex – experiments and roadmap. Engineering Complex Computer Systems, 377–382 (2007) 15. Zalila, B., Hugues, J., Pautet, L.: Ocarina user guide. TELECOM ParisTech 16. Delange, J., Pautet, L., Kordon, F.: Code Generation Strategies for Partitioned Systems. In: 29th IEEE Real-Time Systems Symposium (RTSS 2008). IEEE Computer Society Press, Los Alamitos (2008)

On Comparing Testing Criteria for Logical Decisions Man Fai Lau1 and Yuen Tak Yu2, 1

Faculty of Information and Communication Technologies, Swinburne University of Technology Hawthorn, Victoria, AUSTRALIA, 3122 [email protected] 2 Department of Computer Science, City University of Hong Kong Kowloon Tong, HONG KONG [email protected]

Abstract. Various test case selection criteria have been proposed for quality testing of software. It is a common phenomenon that test sets satisfying diﬀerent criteria have diﬀerent sizes and fault-detecting ability. Moreover, test sets that satisfy a stronger criterion and detect more faults usually consist of more test cases. A question that often puzzles software testing professionals and researchers is: when a testing criterion C1 helps to detect more faults than another criterion C2, is it because C1 speciﬁcally requires test cases that are more fault-sensitive than those for C2, or is it essentially because C1 requires more test cases than C2? In this paper, we discuss several methods and approaches for investigating this question, and empirically compare several common coverage criteria for testing logical decisions, taking into consideration the diﬀerent sizes of the test sets required by these criteria. Our results demonstrate evidently that the stronger criteria under study are more fault-sensitive than the weaker ones, not solely because the former require more test cases. More importantly, we have illustrated a general approach, which takes into account the size factor of the generated test sets, for demonstrating the superiority of a testing criterion over another. Keywords: Boolean expression, condition coverage, condition/decision coverage, control ﬂow criteria, decision coverage, modiﬁed condition/ decision coverage (MC/DC), software testing.

1

Introduction

Various test case selection criteria have been proposed in the literature, and some criteria are known to be more stringent than others. For example, basis path

The work described in this paper was supported in part by a grant from the Australian Research Council, Australia (project id. DP0558597), and in part by a grant from the Research Grants Council of Hong Kong Special Administrative Region, China (project no. 123206). Corresponding author.

F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 44–58, 2009. c Springer-Verlag Berlin Heidelberg 2009

On Comparing Testing Criteria for Logical Decisions

45

coverage [1, 2] (that is, coverage of all basis paths) is known to be more stringent than branch coverage. In choosing a testing criterion, two competing factors are often considered. A primary consideration is the fault-detecting ability of the test sets selected by the criterion. Another important consideration is the number of test cases required. For example, the basis path coverage criterion exercises a wider variety of control ﬂows of the program under test as compared to the branch coverage criterion, and hence the former is often thought to be more fault-sensitive than the latter. However, the basis path coverage criterion often requires many more test cases. Thus, comparing the fault-detecting ability of two testing criteria without considering the number of test cases required would not be adequate. A common way of comparing the eﬀectiveness of test case selection criteria is to compare the percentage of (non-equivalent) mutants that can be detected by the test sets that satisfy each criterion. A mutant of a program is another program which diﬀers from the original one by some syntactic changes. Given two test case selection criteria C1 and C2, C1 is considered to be more fault-sensitive than criterion C2 if C1 requires test sets that detect a higher percentage of mutants than C2. However, such a comparison does not take into consideration the factor of size of the test sets required by the two criteria. Of course, if the size of the test sets required by C1 is smaller than that of C2, we can be sure that the higher fault detecting ability of C1 is due to the characteristics of the test cases required to satisfy C1. Otherwise, if the size of the test sets required by C1 is larger than that of C2, then the question is, “Does C1 help to detect more faults because it specifically requires test cases that are more fault-sensitive than those for C2, or is it essentially because C1 requires more test cases than C2 does?” In this paper, we shall discuss several methods for investigating the above question (Section 2), compare several common coverage criteria for testing logical decisions (Section 3) by means of an empirical study (Section 4), and ﬁnally conclude with a brief summary of our ﬁndings (Section 5).

2

Methods for Comparing Testing Criteria

To compare two testing criteria C1 and C2, where C1 requires larger test sets than those for C2, there are several general approaches to bring the two test sets to a common ground for fair comparison: (1) Compare the “eﬃciency” of the two criteria C1 and C2, deﬁned as the “eﬀectiveness per test case” [3]. Despite its apparent intuitive appeal, such a comparison misses the important goal in testing, which is to discover as many faults/failures as possible [4]. For example, suppose that a software contains 5 faults. Suppose further that C1 requires only 2 test cases and can only detect one fault (hence its “eﬃciency” is 0.5 fault per test case), whereas C2 requires 20 test cases but can detect all 5 faults in the software (hence its “eﬃciency” is 0.25 fault per test case). Then even though the latter is apparently “less eﬃcient”, it is actually much more useful than the former. In other words, from the quality assurance point of view, fault

46

M.F. Lau and Y.T. Yu

detection eﬀectiveness is the primary goal, while “eﬃciency” is secondary. It would be better to ﬁnd a less costly criterion that achieves the same faultdetecting eﬀectiveness than to ﬁnd an “eﬃcient” criterion at the expense of eﬀectiveness. (2) Compare the eﬀectiveness of the two criteria C1 and C2, where C1 is ﬁrst to generate a test set T1 to satisfy C1, and then to randomly discard test cases from T1 until its size is reduced to the same as a test set T2 that satisﬁes C2. The resultant test set is denoted by T1 . There are two obvious problems of this approach. First, it wastes resources and time in generating those test cases that satisfy criterion C1 but turn out to be discarded later. Second, it is likely that the test set T1 satisﬁes neither C1 nor C2. In such cases, it would be hard to justify such comparison of C1 and C2 by simply comparing T1 with T2 . (3) Compare the eﬀectiveness of the two criteria C1 and C2 , where C2 is ﬁrst to generate a test set T2 to satisfy C2, and then to add randomly generated test cases to T2 up to the size of a test set T1 that satisﬁes C1. The resulting test set is denoted by T2 . A clear advantage of this approach is that the test set T2 also satisﬁes C2. However, there is no guarantee that the set T2 will satisfy C1. When comparing T1 and T2 , we are indeed comparing test sets of the same size and they satisfy the criteria C1 and C2, respectively. In view of the problems of the ﬁrst two approaches, we shall adopt the third one here. In reality, there are scenarios where the third approach is clearly justiﬁed and relevant. From software testing practitioners’ perspective, they need to perform high quality testing within certain resource constraints. Suppose the tester is considering two testing criteria, C1 and C2, such that C1 is known to have a higher fault-detecting ability than C2, and C1 generally requires more test cases than C2 does. For the sake of discussion, let us assume that no other testing criteria are under consideration, and that the tester has the necessary resources to satisfy C1, the more stringent criterion. Then the software testers have three obvious choices, namely (a) simply generate test cases randomly up to the number required by C1, or (b) generate a set of test cases to satisfy C2, and then generate more test cases randomly until the total number is the same as that required by C1, or (c) generate a set of test cases to satisfy C1. Now, it is important for the tester to know which choice would result in a test set that has the highest fault-detecting ability. Our study seeks to address this question. For ease of expression, we employ the following terminologies in this paper. – Given any testing criterion C, a test set that satisﬁes C will be called a C test set. Note that the size of C test sets may not be unique. – Given any testing criterion C, a test set consisting of random test cases alone and is of the same size as a C test set is called a C size-equivalent random test set.

On Comparing Testing Criteria for Logical Decisions

47

The notion of size-equivalent test set is mainly for individual comparison purposes in our experiments. For example, in our experiments, if one C test set has 30 test cases, we then generate a random test set with 30 test cases and compare the fault-detecting ability of these two sets. However, on another occasion, a C test set may have 40 test cases, we then randomly generate 40 test cases for comparison. – Suppose we have two testing criteria C1 and C2, where C1 is more faultsensitive than C2. To compare the eﬀectiveness of C1 and C2 with consideration of the test set size factor, we can generate a C2 test set T2 and then augment it by adding random test cases to T2 until the augmented test set T2 has the same size as that of a corresponding C1 test set. In this case, we shall say that T2 is a C1 size-equivalent test set augmented from C2 (to C1), abbreviated as “C2 to C1”. Note that such a test set T 2 (1) is not minimal1 with respect to C2, (2) does not necessarily satisfy C1, but (3) has the same size as a C1 test set. Previously, many empirical studies have been performed to evaluate and compare the fault-detecting ability of various test case selection criteria [5–11]. Basically, the methods used in these studies fall into the following four categories.2 Category 1. A test case selection criterion C is compared with random testing [7, 8]. More precisely, these experiments compare the fault-detecting ability of C test sets with the corresponding size-equivalent sets of test cases that are selected at random. Category 2. The fault-detecting ability of testing criteria are compared without taking into consideration the sizes of test sets required to satisfy each criterion [6, 7, 9–11]. Typically, test sets that satisfy each criterion are generated and their fault-detecting ability evaluated and compared. This is probably the most commonly used method in the literature. However, as explained in Section 1, it leads to the question of whether the sizes of the test sets are the primary factor in aﬀecting the eﬀectiveness of the two criteria. Category 3. Given two testing criteria C1 and C2 such that C1 requires more test cases than C2 does, the criteria C2 + C1 and C1 are compared [5]. Here, the criterion C2 + C1 is to ﬁrst generate a C2 test set T2 and then add test cases to T2 until the expanded test set T2 satisﬁes C1 as well. Thus, T2 satisﬁes both C1 and C2. Comparison is then made between T1 and T2 . There are three problems with methods in this category. First, the test sets T1 and T2 may not have the same size. Hence, our original question related to the factor of test set size remains. Second, 1 2

A test set is said to be minimal with respect to a testing criterion if it satisﬁes the criterion but none of its proper subsets does. Our classiﬁcation of these categories is diﬀerent from that of the three approaches as suggested in [5] because we feel that our Categories 3 and 4 should be treated as two separate categories rather than as one (combined) category.

48

M.F. Lau and Y.T. Yu

T2 is likely to be even more fault-sensitive as it satisﬁes two criteria (C2 and C1), whereas T1 satisﬁes only one (that is, C1). Third, the size of C2 + C1 test set can be larger than a typical C1 test set due to the need to satisfy C2 ﬁrst. Category 4. Given two testing criteria C1 and C2 such that C1 requires more test cases than C2 does, the criteria C2 and C1 are compared, where C2 requires the generation of a C1 size-equivalent test set augmented from C2 [5]. Our empirical study uses this method. Furthermore, there are some variations to the method in Category 4, when generating the augmented test set T2 from C2. (a) Use a random number within the theoretical range of the sizes of C1 test sets for controlling the number of random test cases to be added to C2 test sets to form the augmented test sets from C2 [7]. One problem with this variation is that the actual range of the size of C1 test sets may not exactly coincide with the theoretical range. That is, the sizes of the actual C1 test sets may not be exactly the same as the sizes of the corresponding test sets augmented from C2. (b) Use the average size of C1 test sets for controlling the number of random test cases to be added to C2 test sets. This ensures that the C1 test sets and the augmented test sets from C2 will always have the same average size. However, their size distributions may not be exactly the same. Moreover, it requires the prior knowledge of the average size of C1 test sets. (c) Use a number randomly generated from the statistical distribution of the sizes of C1 test sets for controlling the number of random test cases to be added to C2 test sets. This ensures that the sizes of C1 test sets and the augmented test sets from C2 will always come from the same statistical distribution. However, their actual size distributions in any particular instance may not be exactly the same. Moreover, it requires the prior knowledge of the statistical distribution of the sizes of C1 test sets, which is even harder to obtain. (d) Generate a C1 test set T1 and then a C2 test set T2 each time, and then add enough random test cases to T2 until the augmented test set T2 has the same size as that of T1 . This ensures that the C1 test sets and the corresponding augmented test sets from C2 will always have exactly the same size. The size distributions will also be identical, without the need of any prior knowledge. In our empirical study, we will employ this variation of the method when comparing two testing criteria.

3

Comparing Common Testing Criteria for Logical Decisions

Our empirical study considers four common coverage criteria for testing logical decisions, namely, condition coverage (CC), decision coverage (DC), condition/decision coverage (C/DC) and modiﬁed condition/decision coverage

On Comparing Testing Criteria for Logical Decisions

49

(MC/DC). In this section, we ﬁrst outline the necessary deﬁnitions related to logical decisions and the four coverage criteria, then discuss some previous work on these criteria, and ﬁnally postulate two hypotheses to be investigated in our empirical study. 3.1

Logical Decisions

We assume that the reader is familiar with Boolean expressions. If necessary, the reader may consult [12] for more details. A Boolean expression is one which evaluates to either FALSE (0) or TRUE (1). A logical decision, or simply a decision, is a Boolean expression composed of conditions and zero or more Boolean operators. We denote the Boolean operators AND, OR and NOT by “·”, “+” and “ ¯ ”, respectively. The “·” symbol will usually be omitted if it is clear from the context. Thus, the Boolean expression a OR (b AND NOT c) can be represented as a + b¯ c. A Boolean expression can always be expressed in disjunctive normal form (DNF) as a sum of products. A condition, or a variable, is a Boolean expression with no Boolean operators. It is denoted by a letter such as a, b, c, . . ., which may represent either a simple Boolean variable such as “Running” (indicating whether or not the engine of an automobile is running) in a Cruise Control System [13], or a relational expression such as “rom->paddles-deployed == 1” [14]. A literal is an occurrence of a variable (or its negation) in a logical decision. 3.2

Coverage Criteria for Logical Decisions

The main parts of the deﬁnitions of condition coverage (CC), decision coverage (DC), condition/decision coverage (C/DC) and modiﬁed condition/decision coverage (MC/DC)3 are as follows [6, 15]. – CC (Condition Coverage): every condition has taken on all possible outcomes at least once; – DC (Decision Coverage): every decision has taken on all possible outcomes at least once; – C/DC (Condition/Decision Coverage3 ): every condition in a decision has taken on all possible outcomes at least once, and every decision in the program has taken on all possible outcomes at least once; – MC/DC (Modiﬁed Condition/Decision Coverage): every condition in a decision has taken on all possible outcomes at least once, and every decision has taken on all possible outcomes at least once, and each condition has been shown to independently aﬀect the decision’s outcome. A condition is shown to independently aﬀect a decision’s outcome by varying just that condition while holding ﬁxed all other possible conditions. 3

The term “C/DC (condition/decision coverage)” has been used by Chilenski and Miller in [6] when they proposed the concepts of MC/DC. We follow this terminology to be consistent with the well-known term MC/DC. Myers [15] used the term “decision/condition coverage”.

50

3.3

M.F. Lau and Y.T. Yu

Previous Work

The four coverage criteria, CC, DC, C/DC and MC/DC, were primarily derived by intuition and analysis. Despite being well known for more than two decades, for a long time their actual fault-detecting eﬀectiveness has been largely unclear due to the inadequate empirical evidence reported in the literature. Recently, however, they have gained the attention of many researchers. Many analytical and empirical studies [6, 7, 9, 10, 14, 16] on these criteria have subsequently been published, contributing to a much clearer picture of their various characteristics, including the size of test sets they require, and the distributions of their faultdetecting eﬀectiveness. While it is commonly believed [14] that some coverage criteria, such as MC/DC, are more fault-sensitive than others, and both practical experiences [14] and experimental data [9, 10] have clearly supported this intuition, it is also well known that the more fault-sensitive criteria typically demand many more test cases [6, 10]. Organizations, however, are often reluctant to invest greater testing eﬀort than is considered necessary unless there are strong justiﬁcations. For instance, serious doubts by the industry have been reported on whether the additional test cases required by MC/DC are really eﬀective in ﬁnding errors [14]. Chilenski and Miller [6] noted that the fault-detecting probability of a test set of size M grows rapidly as M increases, and further commented that this fact “suggests that much of the beneﬁt of the modiﬁed condition/decision criterion lies not so much in the speciﬁc tests selected as in the requirement that at least N + 1 tests are executed” (where N is the number of variables in the logical decision under test). Thus, despite being advocates of the MC/DC criterion, the authors themselves were not that sure of its intrinsic beneﬁt other than the higher number of tests required, and recommended that the “sensitivity of modiﬁed condition/decision coverage to speciﬁc faults should be investigated further” [6]. Several recent studies on logical decision based testing have clariﬁed the sensitivity of many coverage criteria to various classes of fault, but most of these studies have not considered in detail the eﬀect of the diﬀerences in test set sizes (e.g., [9, 10]). One of the few exceptions is the work done in [8]. When evaluating “non-speciﬁcation-based approaches” to testing logical decisions in software, Kobayashi et al. [8] compared the percentages of faults detected by k-factor covering designs (k = 2, 3, 4) with those by test sets of exactly the same size generated by random testing and anti-random testing. On the other hand, when trying to compare DC and MC/DC, Kapoor and Bowen [7] augmented DC test sets by adding random test cases up to a size determined by a random number between n + 1 and 2n. The values n + 1 and 2n are the theoretical lower and upper bounds, respectively, of the size of MC/DC test sets for logical decisions of n variables. However, they did not compare MC/DC with CC or C/DC in [7]. 3.4

Hypotheses

Our empirical study seeks to address the concern of whether the beneﬁts of the coverage criteria for testing logical decisions can be primarily attributed to the

On Comparing Testing Criteria for Logical Decisions

51

number of test cases required. More speciﬁcally, we shall consider the following two hypotheses regarding the coverage criteria CC, DC, C/DC and MC/DC. H1: A test set satisfying each of these criteria is more eﬀective in detecting faults than a corresponding random test set of the same size. H2: A test set satisfying a stronger criterion is more eﬀective in detecting faults than a corresponding test set satisfying a weaker criterion, even when the latter has been augmented to the same size as the former by adding random test cases. Hypothesis H1 helps to establish the fault-sensitivity as an inherent property of each coverage criterion rather than just a property of the size of test set. Hypothesis H2 helps to establish the superiority of the fault-sensitivity property of a stronger coverage criterion over that of a weaker one by compensating the diﬀerence in the number of test cases required. It helps to conﬁrm that the higher fault-sensitivity of a stronger criterion is attributed to the speciﬁc test selection requirement rather than essentially due to the larger number of test cases required.

4 4.1

Experiments and Results Experiment Setup

Subjects and Test Sets. The subjects of our experiments are logical decisions sampled from the software of Line Replaceable Units (LRUs, also known as black boxes), which belong to ﬁve diﬀerent airborne systems across two different airplane models [16]. From this collection, we extracted a sample of 20 logical decisions that are in DNF and 20 logical decisions in other (that is, nonDNF) forms. The sample was extracted in such a way that the logical decisions collectively have as many diﬀerent number of variables as possible, and that their forms diﬀer as much as possible. For ease of reference, these 20 DNF and 20 non-DNF logical decisions were identiﬁed as D01-D20 and N01-N20, respectively. The number of variables in each of these logical decisions ranges between 3 and 16. For each coverage criterion C among CC, DC, C/DC and MC/DC, we would ﬁrst attempt to generate as many test sets satisfying C as possible for each logical decision S. When the number of test sets satisfying C for S exceeds 1000, however, we simply generated a random sample of 1000 such test sets to avoid an inordinate amount of time spent in running the experiment. To investigate hypothesis H1, for each coverage criterion C, we generated the same number of C size-equivalent random test sets as that of the corresponding test sets generated to satisfy C. For example, all C/DC test sets have sizes of either 2 or 3. To investigate hypothesis H1 for C/DC, we generated exactly the same number of random test sets of sizes 2 or 3, respectively, as that of the corresponding C/DC test sets. To investigate hypothesis H2, for each pair of coverage criteria C1 and C2 in which C1 is the stronger one, we generated the same number of C1 sizeequivalent test sets augmented from C2 as that of the corresponding test sets

52

M.F. Lau and Y.T. Yu

generated to satisfy C1. For example, to investigate hypothesis H2 for the pair of coverage criteria C/DC and MC/DC, we would compare the fault-detecting ability of MC/DC test sets with that of the MC/DC size equivalent test sets that were augmented from C/DC. Faults in Logical Decisions. We note that the observations of real faults in [14, 17] are consistent with the common intuition that typical programmer errors include missing or extra conditions and paths, and the use of incorrect operators or operands [15, 18]. Insofar as logical decisions are concerned, these errors translate to the omission, insertion or incorrect reference of conditions and Boolean operators. As such, we shall consider the following classes of simple faults for logical decisions. Detailed explanation and descriptions of these fault classes can be found in [10]. For the purpose of illustration, let the correct expression be S = ab + c¯d + e. – Expression Negation Fault (ENF):- The entire Boolean expression, or its sub-expression thereof, is replaced by its negation. For example, S becomes ab + c¯d + e. – Term Negation Fault (TNF):- A term is replaced by its negation. For example, S becomes ab + c¯d + e. – Term Omission Fault (TOF):- A term is omitted. For example, S becomes c¯d + e. – Operator Reference Fault (ORF):- It refers to either a disjunctive ORF (ORF[+]) which replaces an OR operator (+) by AND (·), or a conjunctive ORF (ORF[·]) which replaces an AND operator (·) by OR (+). For example, S becomes ab · c¯d + e or a + b + c¯d + e, respectively. – Literal Negation Fault (LNF):- A literal is replaced by its negation. For example, S becomes a ¯b + c¯d + e when the ﬁrst literal a is negated. – Literal Omission Fault (LOF):- A literal is omitted. For example, S becomes b + c¯d + e when the ﬁrst literal a is omitted. – Literal Insertion Fault (LIF):- A literal is inserted into a term of the expression. For example, S becomes abc + c¯d + e when the literal c is inserted into the ﬁrst term. – Literal Reference Fault (LRF):- A literal is replaced by another literal. For example, S becomes cb + c¯d + e when the ﬁrst literal a is replaced by c. – Stuck-At Fault (STF):- It refers to either a stuck-at-0 fault (STF[0]) or a stuck-at-1 fault (STF[1]), which causes the value of a literal to be stuck at 0 or 1, respectively. For example, when the literal a is stuck at the value 0, S will become 0 · b + c¯d + e, which simpliﬁes to c¯d + e; and when a is stuck at 1, S will become 1 · b + c¯d + e, which simpliﬁes to b + c¯d + e. Except for TNF and TOF, all of the above fault classes apply equally well to logical decisions that are not written in DNF. Moreover, for non-DNF expressions, faults may also occur in the brackets or in the precedence of evaluation of the conditions, and so the following class of fault will also be considered. – Associative Shift Fault (ASF):- The associativity of terms is changed once. For example, the non-DNF expression a(b + c) is replaced by (ab) + c.

On Comparing Testing Criteria for Logical Decisions

53

Table 1. Average size of test sets Decision ID CC DC C/DC MC/DC D01 – D20 2.0 2.0 2.8 10.5 N01 – N20 2.0 2.0 2.8 10.2

In our experiments, for each logical decision S, we generated all expressions that can be formed by introducing a single instance of a fault of each of the classes deﬁned above, and used only those resulting expressions that are not equivalent to the original expression S. Finally, we recorded which test set can distinguish an original logical decision from its faulty versions due to each class of fault, and computed the statistics. 4.2

Observations

Size of Test Sets. In general, CC can be satisﬁed by two test cases such that one is the complement of the other, and DC can be satisﬁed by using a test case which leads to an outcome of TRUE and another leading to FALSE. Hence CC and DC always require only two test cases. If a CC test set T (which is necessarily of size 2) happens to satisfy DC as well, then T already satisﬁes C/DC. Otherwise, either both test cases in T produce the same outcome of TRUE, or both produce the same outcome of FALSE. In either case, adding to T one more test case which produces the alternate outcome will render the resulting set to satisfy C/DC. Hence C/DC requires only either 2 or 3 test cases. The size of a MC/DC test set depends on the number of variables in the logical decision. Table 1 summarises the size of test sets generated to satisfy each of CC, DC, C/DC and MC/DC, respectively, averaged over the subject DNF and non-DNF logical decisions. CC and DC Size-Equivalent Test Sets. Since both CC and DC always require 2 test cases, a random test set of size 2 is both CC size-equivalent and

100.0

80.0 Random CC DC

60.0

40.0

20.0

0.0

Percentage of Faults Detected

Percentage of Faults Detected

100.0

80.0 Random CC DC

60.0

40.0

20.0

0.0 ENF

TNF

TOF ORF LNF

LOF

LIF

LRF

STF

Fault Class

(a) Results for DNF logical decisions

ENF

ORF

LNF

LOF

LIF

LRF

STF

ASF

Fault Class

(b) Results for non-DNF logical decisions

Fig. 1. Fault detection of CC and DC size-equivalent test sets

M.F. Lau and Y.T. Yu 100.0

Percentage of Faults Detected

100.0 80.0 60.0 Random CC to C/DC* DC to C/DC* C/DC

40.0 20.0

Percentage of Faults Detected

54

80.0 60.0

20.0

0.0 ENF TNF TOF ORF LNF LOF

LIF

Random CC to C/DC* DC to C/DC* C/DC

40.0

0.0

LRF STF

ENF

Fault Class

ORF

LNF

LOF

LIF

LRF

STF

ASF

Fault Class

*See the paper for the explanations of "XX to C/DC"

*See the paper for the explanations of "XX to C/DC"

(a) Results for DNF logical decisions

(b) Results for non-DNF logical decisions

Fig. 2. Fault detection of C/DC size-equivalent test sets 100.0

80.0 60.0 Random CC to MC/DC* DC to MC/DC* C/DC to MC/DC* MC/DC

40.0 20.0 0.0

Percentage of Faults Detected

Percentage of Faults Detected

100.0

80.0 60.0 Random CC to MC/DC* DC to MC/DC* C/DC to MC/DC* MC/DC

40.0 20.0 0.0

ENF TNF TOF ORF LNF LOF LIF LRF STF

ENF ORF LNF LOF

LIF

LRF

STF

Fault Class

Fault Class

*See the paper for the explanations of "XX to MC/DC"

*See the paper for the explanations of "XX to MC/DC"

(a) Results for DNF logical decisions

ASF

(b) Results for non-DNF logical decisions

Fig. 3. Fault detection of MC/DC size-equivalent test sets

DC size-equivalent. Figure 1 shows graphically the average percentage of faults detected by random test sets of size 2, CC test sets, and DC test sets, respectively, for each of the classes of fault. From the ﬁgure, we observe that, with only a few exceptions, DC is more eﬀective than CC, which in turn is marginally more eﬀective than random testing. In the few exception cases (such as LIF in Figure 1(a)), the diﬀerences among the three criteria are very small. C/DC Size-Equivalent Test Sets. Figure 2 shows graphically the average percentage of faults detected by C/DC test sets, C/DC size equivalent random test sets, and C/DC size equivalent test sets augmented from CC and DC, respectively, for each of the classes of fault. From the ﬁgure, we observe the following. (i) C/DC test sets are more eﬀective than all other test sets. (ii) Test sets augmented from DC are more eﬀective than both the (sizeequivalent) random test sets and those augmented from CC, except only for LIF and TOF in Figure 2(a). MC/DC Size-Equivalent Test Sets. Figure 3 shows graphically the average percentage of faults detected by MC/DC test sets, MC/DC size equivalent

On Comparing Testing Criteria for Logical Decisions

55

random test sets, and MC/DC size equivalent test sets augmented from CC, DC and C/DC, respectively, for each of the classes of fault. From the ﬁgure, we observe the following. (i) MC/DC test sets are highly eﬀective in all cases. With the only exception of LIF, MC/DC test sets detects more than 85% of the faults of each class. (ii) MC/DC test sets are much more eﬀective than all other test sets except for the fault classes ENF, TNF and ASF. These three classes of fault are generally easier to detect, since a high proportion of these faults is detected by random tests. (iii) Generally, MC/DC size-equivalent test sets augmented from CC, DC and C/DC, together with the MC/DC size-equivalent random testing sets, all behave very similarly in that their eﬀectiveness does not diﬀer greatly. 4.3

Results and Discussions

Confirmation of Hypothesis H1. Overall, the CC, DC, C/DC and MC/DC test sets are more eﬀective than the corresponding size-equivalent random test sets. Thus, our ﬁrst hypothesis H1 is conﬁrmed. That is, we can safely conclude that each of the four coverage criteria does contribute, though in varying degrees, to the fault-sensitivity of the tests. Among these criteria, CC is closest to and only marginally more fault-sensitive than random testing in all of the 40 logical decisions under study. While DC is generally signiﬁcantly better than CC and random testing for DNF logical decisions, its relative advantage is much less pronounced for detecting faults in the non-DNF logical decisions under study. The advantage of C/DC over random testing is in many ways similar to that of DC over random testing. In contrast, MC/DC test sets are unquestionably much better than random tests of the same size in all cases. Confirmation of Hypothesis H2. From Figure 2, it is clear that C/DC test sets are more eﬀective than test sets augmented from each of the weaker coverage criteria. It is equally clear from Figure 3 that the same is true for MC/DC test sets. Thus, our second hypothesis H2 is also conﬁrmed. In other words, both C/DC and MC/DC are more fault-sensitive than the weaker criteria not just because they require more test cases. In particular, at least for the logical decisions and fault classes considered in our present experiment, there is strong evidence to reject the suggestions of Chilenski and Miller that the beneﬁts of MC/DC are largely due to the higher number of test cases required [6]. Augmenting Test Sets with Random Test Cases. We further note some interesting observations on test sets augmented from the weaker criteria CC, DC and C/DC. First, the relative ordering of fault-sensitivity among these criteria remains basically unchanged as their test sets are augmented by the same number of random test cases. For instance, CC test sets are generally slightly less eﬀective than DC test sets in Figure 1, and this remains true in Figures 2 and 3, when both CC and DC test sets are augmented to C/DC and MC/DC size-equivalent test sets, respectively. This is not surprising, as there is no reason why adding

56

M.F. Lau and Y.T. Yu

the same number of random test cases to both CC and DC test sets should reverse the ordering of their relative eﬀectiveness. Secondly, as the test sets from the weaker criteria are augmented with more and more random test cases, while the ordering of their eﬀectiveness is not changed, their diﬀerences tend to become levelled out. This can be seen by comparing the diﬀerences between test sets augmented from CC and DC in Figure 2 with those in Figure 3. In particular, in Figure 3(b), the augmented test sets from CC, DC and C/DC are almost indistinguishable in terms of faultsensitivity. This can be explained by the fact that, as more and more random test cases are added to a test set, it becomes increasingly more likely that the augmented test set eventually satisﬁes all of the weaker criteria, regardless of which criterion the original test set is augmented from. In other words, the additional random test cases gradually “dilute” out the contributing eﬀect of the weak criteria, rendering them indistinguishable. This may not be true, however, for a strong criterion, which will not be easily satisﬁed by the addition of even a large number of random test cases. In this study, the coverage criteria CC, DC and C/DC are not greatly diﬀerent, and MC/DC seems to be the only “strong” coverage criterion. To verify how selective MC/DC test cases are, we have further augmented the CC, DC and C/DC test sets up to a size which is 2 to 3 times that of MC/DC test sets. Even so, the augmented test sets are still much less eﬀective than the original (“unaugmented”) MC/DC test sets. This provides further evidence that MC/DC is not only a stronger criterion than the other three coverage criteria, but also that it is actually much stronger. Comparison Among Fault Classes. It is interesting to note that the percentages of faults detected vary among diﬀerent fault classes. Higher percentage of faults of certain fault classes are detected than those of other classes. More speciﬁcally, ENF and TNF are easiest to detect, followed by ORF and LNF, then by LRF, LOF and LIF. This observation is in line with the results of recent formal studies of the relationships among the fault detection conditions of diﬀerent classes of fault. The reader is referred to [11] for more details and references.

5

Summary and Conclusion

We have started this paper by considering the question, “How should the faultdetecting ability of testing criteria be empirically compared, given that a more fault-sensitive criterion may (and actually usually) require a larger number of test cases than other criteria do?” We have next discussed several methods and approaches employed in previous empirical studies. One reasonable approach is to augment the test sets that satisfy the weaker criteria by adding random test cases to them until their sizes are the same as those of the test sets that satisfy the stronger criteria. We have then employed this approach to empirically compare the fault-detecting ability of several coverage criteria, namely, CC, DC, C/DC and MC/DC, that are commonly advocated for testing logical decisions.

On Comparing Testing Criteria for Logical Decisions

57

Our experiments conﬁrmed two hypotheses, namely, that (1) each of these criteria is better than random testing, and (2) among them, the stronger criteria are indeed better than the weaker ones even after compensating for the larger number of test cases required by the former. Furthermore, we observed that the fault-sensitivity contribution of the weaker criteria tend to become less signiﬁcant as the test sets are augmented by adding more and more random test cases. Notwithstanding this, a really strong testing criterion, such as MC/DC in the present study, does possess an intrinsic contribution to fault-sensitivity that is unparallelled by random test sets that are even much larger in size. Although the interpretation of the results we report here are in principle limited by the set up of our experiments (such as the subject logical decisions chosen), we tend to believe that they are more generally valid than they seem to be. Our results are also in line with several recent studies on the same or related testing criteria, such as those reported in [7–11]. More importantly, this work has shown how random test cases can be used as part of a benchmark to verify and compare the eﬀectiveness of other testing criteria to take into account of the eﬀect of diﬀerent sizes of test sets required. To follow up this idea further, we plan to carry out more experiments in a similar way to verify or compare other testing criteria, so as to contribute more to the body of empirical knowledge on the fault-sensitivity of various testing criteria in use. Acknowledgments. The authors would like to thank Isaac Yeung for his assistance in the empirical study described in this paper.

References 1. McCabe, T.J.: A complexity measure. IEEE Transactions on Software Engineering 2, 308–320 (1976) 2. Pressman, R.S.: Software engineering: a practitioner’s approach, 6th edn. McGrawHill, New York (2005) 3. Gupta, A., Jalote, P.: An approach for experimentally evaluating eﬀectiveness and eﬃciency of coverage criteria for software testing. International Journal on Software Tools and Technology Transfer 10, 145–160 (2008) 4. Chen, T.Y., Yu, Y.T.: On the relationship between partition and random testing. IEEE Transactions on Software Engineering 20, 977–980 (1994) 5. Chen, W., Untch, R.H., Rothermel, G., Elbaum, S., von Ronne, J.: Can faultexposure-potential estimates improve the fault detection abilities of test suites? Software Testing, Veriﬁcation and Reliability 12, 197–218 (2002) 6. Chilenski, J.J., Miller, S.P.: Applicability of modiﬁed condition/decision coverage to software testing. Software Engineering Journal 9, 193–229 (1994) 7. Kapoor, K., Bowen, J.: Experimental evaluation of the variation in eﬀectiveness for DC, FPC and MC/DC test criteria. In: Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE 2003), Roman Castles, Italy, pp. 185–194. IEEE Computer Society Press, Los Alamitos (2003) 8. Kobayashi, N., Tsuchiya, T., Kikuno, T.: Non-speciﬁcation-based approaches to logic testing for software. Information and Software Technology 44, 113–121 (2002)

58

M.F. Lau and Y.T. Yu

9. Vilkomir, S.A., Kapoor, K., Bowen, J.: Tolerance of control-ﬂow testing criteria. In: Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC 2003), Dallas, Texas, USA, pp. 182–187. IEEE Computer Society Press, Los Alamitos (2003) 10. Yu, Y.T., Lau, M.F.: A comparison of MC/DC, MUMCUT and several other coverage criteria for logical decisions. Journal of Systems and Software 79, 577–590 (2006) 11. Lau, M.F., Yu, Y.T.: An extended fault class hierarchy for speciﬁcation-based testing. ACM Transactions on Software Engineering and Methodology 14 (2005) 12. Mano, M.M.: Digital Design, 2nd edn. Prentice-Hall, Englewood Cliﬀs (1991) 13. Atlee, J.M., Buckley, M.A.: A logic-model semantics for SCR software requirements. In: Proceedings of 1996 International Symposium on Software Testing and Analysis, San Diego CA, USA, pp. 280–292 (1996) 14. Dupuy, A., Leveson, N.: An empirical evaluation of the MC/DC coverage criterion on the HETE-2 satellite software. In: Proceedings of Digital Aviation Systems Conference (DASC 2000), Philadelphia, USA (2000) 15. Myers, G.J.: The Art of Software Testing, 2nd edn. John Wiley & Sons, Chichester (1979) 16. Chilenski, J.J.: An investigation of three forms of the modiﬁed condition decision coverage (MCDC) criterion. Technical Report DOT/FAA/AR-01/18, Oﬃce of Aviation Research, Federal Aviation Administration, U.S. Department of Transportation, Washington, D.C. 20591 (2001) 17. Daran, M., Th´evenod-Fosse, P.: Software error analysis: A real case study involving real faults and mutations. In: Proceedings of the 1996 International Symposium on Software Testing and Analysis, pp. 158–171 (1996) 18. Tai, K.C., Su, H.K.: Test generation for Boolean expressions. In: Proceedings of the Eleventh Annual International Computer Software and Applications Conference (COMPSAC), pp. 278–284 (1987)

Model Checking Techniques for Test Generation from Business Process Models Didier Buchs, Levi Lucio, and Ang Chen Software Modeling and Veriﬁcation laboratory University of Geneva, route de Drize 7, CH-1227 Carouge Switzerland {didier.buchs,levi.lucio,ang.chen}@unige.ch http://smv.unige.ch

Abstract. We will present a methodology and a tool to generate test cases from a model expressed in Business Process models and a set of test intentions for choosing a particular kind of tests. In order to do this we transform the Business Process models in an intermediate format called Algebraic Petri Nets. We then use model checking techniques (e.g. Decision Diagrams) to encode the state space — the semantics — of the model and producing test cases including their oracles according to that transition system. Keywords: System design and veriﬁcation, Higher-level Nets, Algebraic Petri Nets, State Space Generation, Decisions Diagrams.

1

Introduction

Model-Driven Engineering (MDE) is currently a very promising technique which aims at increasing the reliability of software while lowering the development time and associated costs. The approach consists of building models (abstractions) of the system under construction and automatically or semi-automatically reﬁning those models until a program executable by machine is reached. Some of the main advantages of such approaches are: models are in general platform-independent and simple to maintain than programs; their properties can be proved on those models insuring — to a certain extent — the ﬁnal implementation will also have those properties; test sets can be generated at the level of the model thus reducing the complexity of producing oracles for the test cases; the language in which the model is written can be aimed at describing certain kinds of realities — in other words the models can be written in Domain Speciﬁc Languages (DSL). In this paper we will describe an approach to generating test cases from models for business processes. The business process models are subsequently implemented or deployed into real systems (e.g. information systems) to which we can apply our test cases. In order to build the oracles for the test cases we will use techniques pertaining to model-checking. In model-checking an exhaustive state space of the model is built and certain properties can be proved by examining the states in that state space. Currently very eﬃcient model checkers exist — e.g. F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 59–74, 2009. c Springer-Verlag Berlin Heidelberg 2009

60

D. Buchs, L. Lucio, and A. Chen

NuSMV [1] — allowing encoding state spaces of models up to tens of millions of states and eﬃciently verifying properties expressed in temporal logics. Compact representation techniques for large state spaces based on BDD (Binary Decision Diagrams) are used to achieve such performances. We use similar techniques in order to eﬃciently build oracles for our test cases. The paper is organized in the following fashion: section 2 provides the methodological framework for our approach and introduces the concepts of ModelDriven Engineering we will be using throughout the paper. In section 3 we introduce the language used to build business process models and the running example (a credit approval process) we will use throughout the paper. We also describe Model Based Testing (MBT) from the point of view of generating test cases for business processes. Section 4 introduces and describes the technique we have developed to transform business process models into Algebraic Petri Nets (APN) — an extension of Petri Nets with Algebraic Abstract Data Types. In fact we use Algebraic Petri Nets as the intermediate format to produce the necessary state space. We then go on to introduce the semantics of Algebraic Petri Nets in section 5. In section 6 we introduce some test intentions for the running example. Test intentions are speciﬁcations of the test cases we wish to produce for the credit approval process. Finally section 7 introduces the model checking techniques we have used to build the state space and generating test cases with their respective oracles. In order to do that we have used both the test intentions and state space obtained from the model.

2

Model-Driven Engineering

Scientists have tried to ﬁnd repeatable, predictable processes or methodologies that improve productivity and quality of software for decades. Some try to systematize or formalize the tasks of developing software, others apply project management techniques to the development process. A software engineering process is composed of many activities, notably the following: requirement analysis, speciﬁcation, veriﬁcation, system design (architecture), and testing. In particular, safety-critical software systems are often carefully speciﬁed (veriﬁcation) prior to application development and thoroughly tested after implementation. MDE is a software development methodology which focuses on creating models, or abstractions, more close to some particular domain concepts rather than computing or algorithmic concepts. One objective of MDE is to apply model transformation and composition automatically via supporting tools. In this context, ”Models” are rigorously deﬁned speciﬁcations. Some activities or steps of development process can be automatized or semi-automatized. For example, instead of manually writing code, tools can generate executable code from speciﬁcations; on the other hand, tests can be automatically generated from speciﬁcation and validate the code written by programmers; veriﬁcation of properties (model-checking) can be also applied automatically on the models. Figure 1 shows the activities and artifacts involved in MDE, activities such as test generation, testing, properties validation, and implementation are supposed to be fully automatized or automatized with human assistance.

Model Checking Techniques for Test Generation

61

Fig. 1. Activities and Artifacts in Model-Driven Engineering

Depending on the level of automation of the implementation task in ﬁgure 1 the testing activity may be necessary for diﬀerent purposes. In the cases where an implementation is obtained with strong human assistance a large set of test cases is justiﬁed in the sense that the speciﬁcation may have been misinterpreted and a test set derived from the speciﬁcation will provide a fashion of detecting those discrepancies. A more automated code generation will in principle reduce the need for strong functional testing, although the correction of the implementation regarding the speciﬁcation assumes the test generator itself is well implemented. When code generation is fully automatic it may be necessary to use automatically generated test sets for regression testing as additional functionalities or hardware are introduced.

3

MBT from BP Models

The notation we use for business process modeling is Business Process Modeling Notation (BPMN) — a graphical representation for specifying business processes. Developed by Business Process Management Initiative (BPMI), it is currently an OMG standard for business process modeling. An improvement of BPMN since its initial version and comparing with similar approaches, is the semantics of control structure, i.e. activity, ﬂow and gateways, are given by Petri Nets. Details on BPMN can be found in OMG’s BPMN speciﬁcation [2]. Figure 2 shows a simple BPMN process for credit approval. It has 4 pools, each pool represents a process participant: client, credit approval, approver, and

62

D. Buchs, L. Lucio, and A. Chen

assessor. The pool client is the user interface which represents a client in this process; the pool credit approval contains the main processing we are modeling; approver and assessor are entities which provide services. Moreover, 3 types of messages are used by this process: request, risk, and approval. Each message has simple attributes related to the identiﬁcation of the process, i.e. name of the credit demander, and they can be represented using tuples with the following signatures: – request: (name: String, amount: Integer), e.g. (’John’, 1000) – risk:(name: String, risk: String), e.g. (’Peter’, ’high’) – approval:(name: String, result: String), e.g. (’John’, ’approved’), (’Peter’, ’refused’)

Client

A process instance starts when a client submits request via the request form and ends when the client receives an approval message. Basically, this process tries to automatically approve credit requests with low amount (less than 10000) and low risks. The evaluation of risk is delegated to assessor, which returns the risk of the credit demander. If the request’s amount is high (equal or more than 10000) or its risk is high, the approval is delegated to approver, and implies a human approval task. In the context of MDE, BPMN is the central artifact which the automation tools can work upon. By providing deployment information, the BPMN process in ﬁgure 2 can be transformed into executable BPEL speciﬁcations. Our current work focuses on automating the activities of test generation and property

Request Form

Response

request

approval

Credit Approval

check amount

amount>=10000

amount<10000 receive request

Invoke assessor

Assesor

Approver

request

risk

risk=high

approval

Invoke approver

reply

AssignYes

risk=low check assessment request

approval

Approve Task

Assess Risk

Fig. 2. BPMN Example for Credit Approval

approval

Model Checking Techniques for Test Generation

63

Fig. 3. Model Based Testing of the Credit Approval Implementation

validation with BPMN models. In particular in this paper we focus on automated test generation. The two current main trends in testing are white-box and black-box. In whitebox testing the actual code for the system under test (SUT) is analyzed and tests are produced from an observation of that code. On the other hand, the assumption behind black-box testing is that the state of the SUT is hidden and that its behavior is only observable by providing its inputs and observing its outputs. In this case an auxiliary — intellectual or formalized — specification of the SUT is necessary to produce the tests and decide their verdict (pass, meaning no error was found, or fail, meaning at least one error found). When the model of the SUT is formalized we have a specialized kind of black-box testing called Model-Based Testing (MBT). In reality MBT corresponds to a comparison of two artifacts (the speciﬁcation and the SUT) via a third artifact called a test set. In order to apply MBT techniques to models expressed in BPMN we have chosen to isolate each pool as an individual speciﬁcation from which we wish to extract test cases. This choice naturally ﬁts the paradigm of MBT as a pool is a process which exchanges messages (inputs/outputs) with other pools. The test cases extracted from a particular pool can then be applied to an implementation of that pool which is seen as a black box. This principle can be observed in ﬁgure 3. A possible test case extracted from the credit approval swimlane speciﬁcation in ﬁgure 2 is:

64

D. Buchs, L. Lucio, and A. Chen

The formalism we use to describe test cases consists of sequences of events which can be either inputs or outputs). The test case described above consists of a sequence of six events: ﬁrstly client ’jo’ sends a message asking for the approval of a loan of 1000 (the parameter (jo,1000) corresponds to the request message). Because the quantity of money asked is inferior to 10000 (see ﬁgure 2) the automatic assessor is sent a message to decide whether there is a risk associated to giving the loan. The assessor replies the risk associated to lending 1000 to ’jo’ high, which means a request message has to be sent to the human approver asking for a decision. Finally the human approver sends a message stating the loan can be granted and the client is sent a message saying the loan has been approved. Note that the test case we have presented corresponds to an expected behavior of the SUT. When automatically generating test cases it is necessary to understand whether or not a sequence of inputs/outputs corresponds to an expected behavior. In order to automatically perform this decision we need an operational version of the speciﬁcation where the generated test cases can be tried upon. In the context of MBT this operational version is called an oracle.

4

Building an Oracle

We have built an automatic procedure to extract oracles for our test cases from BPMN speciﬁcations. The procedure corresponds to the transformation of BPMN speciﬁcations into Algebraic Petri Nets. The transformation itself is similar to the approaches described in [3] and we present the set of rules we have devised for the transformation in [4]. From a technical point of view we use standard model transformation techniques, in particular the ATL transformation language [5]. ATL allows writing rules at the level of the elements of the meta-models of BPMN and APN. Those rules then act over instantiations of the meta-model of BPMN and transforms them into instantiations of the meta-model of APN. InvokeApproverOut _ : request

InvokeApproverIn _ : approval replyOut _ : approval

ReceiveRequestIn _ : request

t8 t2

t5

invokeApprover

t10

Reply

checkAmount t1 receiveRequest

invokeAssessor

t3

t6

t9 checkAssessment

t4

InvokeAssessorOut _ : request InvokeAssessorIn _ : risk synchronization

Fig. 4. Result of Transformation in APN

t7

assignYes

Model Checking Techniques for Test Generation

65

In ﬁgure 4 we partially present the result of transforming the Credit Approval swimlane of ﬁgure 2 into an APN. In this example, we use modularized APN, i.e. APN encapsulated in rectangle with black box on the edges representing incoming events and white box representing outgoing events. An event is parametrized with by type of message it sends or receives. Internal transitions are invisible from outside of the APN model, except when it is synchronized with observable events. Synchronization between event and transition is represented as dashed arrow. In the followed parts of this paper, we apply our test generation approach on the transformed encapsulated algebraic Petri nets.

5

Algebraic Petri Nets

Algebraic nets is an evolution of P/T Petri nets where tokens are belonging to domains deﬁned by algebraic speciﬁcations. Although not very diﬀerent from other extention of Petri nets, APN have several signiﬁcant advantages: – The possibility to deﬁne any data structure; – An abstract level of axiomatisation; – A formal notation allowing to reason about data types and their usage. An APN deﬁnition is split into two parts: a Petri Net with places holding typed tokens; a set of ADT (Abstract Algebraic Data Types) representing data. 5.1

Algebraic Abstract Data Type

Algebraic Abstract Data Type (AADT or ADT for simplicity) provide a mathematical way to deﬁne properties of data types. ADT modules deﬁne data types by means of algebraic speciﬁcations. Each module describes one or more sorts, along with generators and operations on these sorts. The properties of the operations are given in the section body of the modules, by means of positive conditional equational axioms. An algebraic abstract data type is then composed of a signature Σ = S, OP where S is the set of sorts and OP the set of operations with their arity. In general, there are two types of ADTs: – Primitive data ADTs: boolean, natural, and integer are simple data types. – Container ADTs: set, list, pair, bag, etc. They represent structured data and allow to construct complex data types and operations. The contained types can be data ADTs or container ADTs. Moreover, through equations (Ax) based on terms deﬁned by the signature (TΣ ) and variables (X) the term with variables (TΣ,X ) the properties are deﬁned. A speciﬁcation is given by Spec = Σ, Ax, X. It is theoretically possible to model any data type with this algebraic approach (under the hypothesis that only ﬁrst order axiomatisation is necessary, which is not the case for real numbers). There are no predeﬁned data types in ADT and all used

66

D. Buchs, L. Lucio, and A. Chen

types should be deﬁned by ADT modules. However, we provide a library of ADTs as part of COOPNBuilder[6]/ALPINA framework which includes the most commonly used data types: boolean, natural, string, pair, list, etc. These types are fully axiomated allowing to infer properties of models for veriﬁcation purposes. A calculus can be deﬁned through rewriting techniques, Rew : TΣ → TΣ , which provides a normal for that can be used for deciding equalities between terms (the eval function evaluates terms into their semantic domains) i.e ∀t, t ∈ TΣ , Rew(t) = Rew(t ) ⇒ eval(t) = eval(t ). 5.2

APN

Components are described by modular Algebraic Petri Nets with particular parameterized transitions which are deﬁned by so-called behavioral axioms, similar to the axioms in an ADT. Encapsulated Petri nets possess ports input and output allowing developer to model components of a system. Input and output represent the provided services (input events) and the required services (output events) of the module, respectively. An APN spec is noted apn − spec = Spec, P, In, Out, Beh, X where Spec is the algebraic speciﬁcation, P the set of places (with τ as the typing function), In the input ports and Out the output ports, Beh the behavioural axioms (detailled below) and X some variables. The (behavior) axioms have the following structure: Cond ⇒ event :: pre → post In which each one of the terms has the following meaning: – Cond is a set of equational conditions, similar to a guard; – event is the name of a input or output or local silent transition λ with algebraic term parameters (only this part of axiom is mandatory); EventsIn,Out,Σ = InΣ ∪ OutΣ ∪ {λ} and: • InΣ = {in(t1 , ..., tn )|in ∈ Ins1 ,...,sn ∧ ti ∈ (TΣ,X )si , i ∈ 1, ..., n} • OutΣ = {out(t1 , ..., tn )|out ∈ Outs1 ,...,sn ∧ ti ∈ (TΣ,X )si , i ∈ 1, ..., n} – pre and post are typical Petri net ﬂow relations (indexed by P ) determining what is consumed and what is produced in the net’s places. 5.3

Semantics of APN

Knowing the semantics of an ADT, we can build the semantics of an APN. The semantics of an APN is given by a transition system where labels represents what it is visible from outside i.e. the events. The states are represented by an place indexed set of multiset of tokens expressed by algebraic values of the ADT’s. M : P indexed familly of Dom(τ (p)) with operations such as marking union, marking diﬀerence and comparisons.

Model Checking Techniques for Test Generation

67

Given an axiom Cond ⇒ event :: pre → post and m, m ∈ M the markings, event ∈ EventsIn,Out,Σ , the transitions induced by that behavioral property is: eval(event)σ

∀σ 1 , if |=σ Cond,eval(pre))σ ⊆ m, m −−−−−−−−→ m−eval(pre)σ +eval(post)σ 2 The resulting construction is the transition system build from the initial marking by applying this ﬁring rule until reaching a ﬁx point T Sapn (m0 ).

6

Test Intentions

The formalism we have used to represent test cases is the HML (Hennessy-Milner Logic) HML is a simple branching time logic that includes the sequence, not and and operators.Test intentions are written as HML formulas with constrained variables. The domains of those variables correspond to the three abstract dimensions of a test case we stated previously, namely: the shape of the execution paths; the kind of input/output pairs inside a path; and the parameters of the inputs and outputs. The constraints over the variables allow shaping the test intention. Interface SixEvents Axioms (nbEvents(f) <= 6) Variables f : primitiveHML

=>

f in SixEvents;

Fig. 5. Test Intentions for the Credit Approval Process

In the very simple test intention named SixEvents in ﬁgure 5, f is a variable having as domain the execution paths of the Credit Approval process. The nbEvents function allows measuring the number of events (inputs or outputs) contained in an execution path — thus the ’nbEvents(f)<=6’ condition reduces the domain of f to execution paths including less than six events. The idea behind this test intention — admittedly not very sophisticated — is thus to generate tests that cover at most six interactions (inputs or outputs) with the SUT. Possible test cases produced by this test intention are depicted in ﬁgure 6. Notice that the last test is annotated with the False logic value. This is because that particular sequence of events is an invalid behavior according to the speciﬁcation — the domain of variable f includes any path that can be generated from the signature of the Credit Approval process, independently from the fact that it corresponds to a valid or invalid behavior of the SUT. 1 2

σ is a term substitution. eval is the evaluation morphism extended to APN structures such as multiset and parameterized events from the algebraic morphism eval.

68

D. Buchs, L. Lucio, and A. Chen

, true , true , false

Fig. 6. Simple Test Cases for Credit Approval Process

Summarizing, a test intention is formally written as a set of partially instantiated HML formulas where the variables present in those formula are by default universally quantiﬁed. All the combined instantiations of the variables will produce a (possibly inﬁnite) number of test cases. Each test intention may be given by several rules, each rule having the form: [ condition => ] inclusion. In the condition part of the rule it is possible to deﬁne constraints over the variables present in the HML formulas that make up the test. The inclusion part is comprised of the HML formulas with variables and a name for the test intention deﬁned by that rule. Although for space reasons we cannot include in this paper the deﬁnition of the constraint language for the variable types of SATEL (execution paths, input/output pairs, input/output parameters), the full description can be found in [7]. SATEL (Semi-Automatic Testing Language) allows guiding test generation in a more precise fashion than the ”brute force” approach in the SixEvents test intention. In the test intentions in ﬁgure 7 the oneLoanCycle test intention generates test cases that exercise one cycle of the credit approval process. The shape of the test intention states that tests generated from this test intention start with the event receiveRequestIn(john , amount) and ends with the replyOut(approval) Interface oneLoanCycle multipleLoanCycle LoadTestLoanCycle Axioms uniformity(amount), nbEvents(path), (sequence(path) <= 4) => receiveRequestIn(’john’,amount) . path . replyOut(approval) in oneCreditCycle; path in oneLoanCycle, bigPath in multipleCreditCycle => path . bigPath multipleLoanCycle; path in multipleLoanCycle, (nbEvents(path)/6 <= 3) => path in LoadCreditCycle; Variables: path : primitiveHML; bigPath : primitiveHML; amount : Integer; approval : Boolean; Fig. 7. Load Test Test Intentions

Model Checking Techniques for Test Generation

69

, true

Fig. 8. Guided Test Cases for Credit Approval Process

event where amount and approval are variables. The path variable represents an HML formula itself which is a sequence of events of size inferior to 4 as stated in the conditions. On the other hand the uniformity predicate ensures that only one value is chosen for variable amount and the variable approval is left unbound. Test sets generated by this test intention include only test case. A possible test set generated from this test intention is depicted in ﬁgure 8. The multipleLoanCycle is deﬁned recursively and allows building test cases which are repetitions of one cycle of the credit approval process as deﬁned in the oneCreditCycle test intention. Finally, the LoadCreditCycle generates test sets which include up until three repetitions of the credit approval process — as a load test for the SUT. Note that in order to generate the test sets there are two main problems to solve: expanding the axioms which are recursive and instantiating of the variables within those axioms according to the stated conditions. This procedure is called unfolding. More formally, let apn − spec = Spec, P, In, Out, Beh, X be an algebraic petri net. A test intention module for apn − spec is a triple I, Λ, X where: – I is a set of test intention names. In the example of ﬁgure 5 I = oneLoanCycle, multipleLoanCycle, LoadT estLoanCycle ; – Λ is a set of test intention axioms where a test intention axiom is a triple cond, pat, i, also written cond ⇒ pat ∈ i. In the topmost axiom of ﬁgure 7 we have: • cond = unif ormity(amount), nbEvents(path) <= 4 . Conditions can be of several types, notably equalities l = r, inclusion of other test intentions f ∈ i and uniformity over variables unif (v); • pat = receiveRequestIn(john , amount).path.replyOut(approval) . Patterns correspond to concatenations of HML formulas where events are inputs or outputs of the SUT. These HML formulas include variables at the level of parameters, inputs or outputs or the formulas themselves. The abstract syntax of the formulas (without variables) is T ∈ Hml, (¬f ) ∈ Hml, (f ∧ g) ∈ Hml or ef ∈ Hml, where f and g are HML formulas and e ∈ EventsIn,Out,Σ . The abstract syntax of patterns is f ∈ P at, p . p ∈ P atwhere f ∈ Hml and p, p ∈ P at; • i = oneLoanCycle ; – X is a set of variables used in test intention axioms. In the example of ﬁgure 5 I = path, bigP ath, amount, approval .

7

Operational Techniques

In this section we will deﬁne the model checking techniques that will be used for representing the transition system of the speciﬁcation, the test space expressed

70

D. Buchs, L. Lucio, and A. Chen

in the test intentions and for extracting valid test cases according to the test space. Data Decision Diagrams (DDD [8]) and Set Decision Diagrams (SDD [9]) are both evolutions of the well-known Binary Decision Diagrams (BDD)[10]. While BDD is often seen as representing a Boolean function, it can also be seen as a set of sequences of assignments of Boolean values to variables. DDD (resp. SDD) are similar for assignments of any kind of values (resp. sets) of the form (var1 := val1 ).(var2 := val2 ) . . . (varn := valn ). V al will designate the possible values and V ar the variable names. 7.1

Abstract Definition of Decision Diagrams

A decision diagram (DD) is a structure DD with properties of set and: internal op. (DD × DD → DD) suchas ∪DD , ∩DD , \DD , one constant ∅DD , encoding and decoding op. enDD : SeqA → DD, decDD : DD → SeqA, speciﬁc internal op. (DD → DD) such as inductive homomorphisms homDD . all operations are homomorphic i.e. op(d ∪ d ) = op(d) ∪ op(d ). the domain SeqA is the sequence of assigment speciﬁc to the encoded informations. Sequences of assignments are composable with concatenantion . or for an indexed sequence of concatenation. – an eﬃcient comparison is provided = : (DD × DD → B). Which works in constant time due to the canonicity of the representations. – encoding and decoding are reverse op. enDD ◦ decDD = decDD ◦ enDD = Id. – – – – –

In the encoding necessary for this paper we will use various structures based on diﬀerent kind of assignment (deﬁned in the domain SeqA = {(v1 := val1 ).(v2 := val2 )...(vn := valn )}): – DDD (Data Decision Diagrams) where SeqA is based on v := val, v ∈ V ar, val ∈ V al – SDD (Set Decision Diagrams) where SeqA is based on v := val, v ∈ V ar, val ∈ P(V al) – MSDD (Multi Set Decision Diagram) where SeqA is based on v := val, v ∈ V ar, val ∈ PMS(V al)3 – ΣDD (Signature based Decision Diagrams) where SeqA is based on v := val, v ∈ S, val ∈ TΣ,X with an homomorphism implementing rewriting RewΣDD compatible with rewriting on terms Rew. 7.2

Computing Transition System

Computing the transition system needs to have a basic schema of how to encode the transition system, and homomorphisms that compute new transition relation from existing one. Without entering into a detailed description, we will just give a sketch of what is the encoding of states, events and transition relation. Such kind of encoding is unfortunately not optimal, this is due to the limited reuse caused by presence of discriminating events. 3

The PMS notation corresponds to the power multi-set.

Model Checking Techniques for Test Generation

71

Encoding. The encoding is given for transition systems following its inductive deﬁnition: event

– en SDD (m −−−→ m ) = p∈P (p := enMSDD (mp ).p := enMSDD (mp )).ev := enΣEvent DD (event) – enMSDD (s ) = s := ∅MSDD , s ∈ S – enMSDD ([t]s ) = (s := enΣDD ({t}))4 , s ∈ S and t ∈ TΣ – enMSDD (ms + ms ) = enMSDD (ms) ∪MSDD enMSDD (ms ) – enMSDD (ms − ms ) = enMSDD (ms) \MSDD enMSDD (ms ) – enΣDD : P(TΣ,X ) → SIGDDΣ which encodes a term as a ΣDD [11].

Homomorphisms. Homomorphisms are used to encode the transition relation, we can deﬁne in [12] homomorphisms for algebraic nets that compute successor states of given states. Let Beht = event, pre, Cond, post be a transition behaviour. We deﬁne − + HBeh , CheckBeht and HBeh , based on elementary homomorphisms H + and t t − H working on each individual places, [12] by: − – HBeh = p∈P H − (p, prep , event), t

+ – HBeh = p∈P H + (p, postp , event), t

– CheckBeht = l,r∈Cond check(l, r). The homomorphism HomBeh applies the behaviour of all transitions−of T by combining the previous operators: HomBeh = P roj 5 ◦ Beht ∈Beh HBeh ◦ t + ∗ CheckBeht ◦ HBeht and ﬁnally we compute the transitive closure: HomBeh = (HomBeh ∪ Id)∗ . At the end of this process, we obtain a SDD structure building the whole transition system T Sapn (m0 ) from an initial marking 6 :

enSDD (m −−−→ m ) = Hom∗Beh (enSDD (m0 − → m0 )) event

λ

event m−−−→m ∈T Sapn (m0 )

7.3

Computing Tests by Unfolding Test Intentions

Unfolding test intentions is essentially an iterative process determined by the rules expressed in the test intention language. We need to have a collection of sets keeping these structures. If I is the set of the test intention names, we will have an I indexed structure initialized as an empty set: i := ∅SDD i∈I 4 5 6

The basic encoding element of a sequence. P roj is a projection function keeping only the destination (third argument) of the transition relation. We need to provide a pseudo silent event λ in order to start the process.

72

D. Buchs, L. Lucio, and A. Chen

and directly the set of values for each existing sorts of S. We do not worry about this very exhaustive deﬁnition of the domains because we only explore domains at once and we do not give a combinatorial deﬁnition. s := TΣ,s s∈S

Each step of the computation will successively apply the test intention rule on the structure, condition on other intention will be used to instantiate variable and ﬁnally alter the set of tests under construction. Consider I, Λ, X a test intention module. The Apply : Λ×SDD → SDD homomorphism is based on several other homomorphisms not detailed here but close to that deﬁned on ΣDD. Additional ones such as Select : P at × I × SDD → SDD, Keep : X × SDD → SDD, Add : SDD → SDD and Instantiate : Hml × SDD → SDD are necessary to manage the set structure of test intentions. In particular the Apply and the Select homomorphisms are deﬁned as follows: Apply(l, r ∪ Cond ⇒ t ∈ i) = Apply(Cond ⇒ t ∈ i) ◦ check(l, r) Apply(f ∈ i ∪ Cond ⇒ t ∈ i) = Select(f ∈ i ) ◦ Apply(Cond ⇒ t ∈ i) Apply(unif (v) ∪ Cond ⇒ t ∈ i) = Keep(v) ◦ Apply(Cond ⇒ t ∈ i) Apply(∅ ⇒ t ∈ i) = Add(t ∈ i) Select(T, f ) = Id Select(< e > f ∈ i) = Instantiate(e) . Select(f ∈ i) Select(f ∧ g ∈ i) = Select(f ∈ i) ∪ Select(g ∈ i) Select(¬f ∈ i) = Select(e ∈ f ) Select(pat . pat ∈ i) = Select(pat ∈ i) . Select(pat ∈ i) The Apply function is successively computed for each rule of Λ until reaching a ﬁx-point. ∗ ApplyΛ =( Apply(cond ⇒ t ∈ i))∗ cond⇒t∈i∈Λ

The encoded tests are then: ∗ ApplyΛ ( s := TΣ,s . i := ∅SDD ) s∈S

i∈I

This DD structure can be used to extract the generated tests. 7.4

Computing Tests by Unfolding Intentions and Validating Tests

The Apply homomorphism in section 7.3 allows calculating all the test case shapes by expanding all the test intentions in a test intention module. Within the unfolding process of the test intention the formula t ∈ i expresses the fact that we add a new test to the set of already selected test cases. However, the

Model Checking Techniques for Test Generation

73

Apply homomorphism only expands the test intentions in test cases without any semantics, which means we do not know if those test cases correspond to behaviors which are expected or not in the SUT — we are missing calculating the Oracles for those test cases. This step will be achieved by performing a walk on the transition system of the algebraic Petri net resulting from translating the BPMN speciﬁcation as explained in section 4. Although we leave the additional details of this walk abstract, the ﬁnal tests will be marked as satisﬁed or not when computing the homomorphism Add in Apply(∅ ⇒ t ∈ i) = Add(t, i).

8

Conclusions and Future Work

We have presented in an abstract manner a line of work currently in progress at our laboratory that links model checking and veriﬁcation for event based systems. We explored such methods on a case study of business process modeling, i.e. transforming BPMN into APN models, automatically generating test sets and ﬁnally applying them to verify implementations of those models. There are many approaches in the literature to provide semantics to BPMN in terms of Petri Nets, e.g. in [3], as well as of test case generation using model checkers, e.g. in [13]. Finally, several model checkers as the already mentioned NuSMV [1] uses BDD based technology to encode large state spaces. We have presented a way to select test cases from the model and a description of the test intentions — the tests that seem useful to provide to the system under test. We have developped techniques, based on the use of model checking principles using symbolic representation, to ﬁrst build a representation of the semantics of the system and then to unfold the test intentions into usable tests that have been compared head to head with the speciﬁcation semantics. This lets us to produce tests with correct oracles. Apart the fact that a real benchmark must be done, we think that this approach is extensible to many DSL, following the same pattern of activities: deﬁnition of the modeling language; deﬁnition of transformations in a target language; establishment of the interface of the SUT in a black-box fashion; development of the test selection tools.

References 1. Cimatti, A., Clarke, E., Giunchiglia, E., Giunchiglia, F., Pistore, M., Roveri, M., Sebastiani, R., Tacchella, A.: NuSMV Version 2: An OpenSource Tool for Symbolic Model Checking. In: Brinksma, E., Larsen, K.G. (eds.) CAV 2002. LNCS, vol. 2404, p. 359. Springer, Heidelberg (2002) 2. Object Management Group. Business process modeling notation, v1.1 (2008), http://www.bpmn.org 3. Dijkman, R.M., Dumas, M., Ouyang, C.: Semantics and analysis of business process models in bpmn. Inf. Softw. Technol. 50(12), 1281–1294 (2008) 4. Ang Chen, L.L.: Transform bpmn to algebraic petri nets with encapsulation. Technical Report 207, CUI, University of Geneva (January 2009), http://smv.unige.ch/tiki-download_file.php?fileId=1153

74

D. Buchs, L. Lucio, and A. Chen

5. ATLAS Group. Atlas transformation language (2008), http://www.eclipse.org/m2m/atl/ 6. Al-Shabibi, A., Buchs, D., Buﬀo, M., Chachkov, S., Chen, A., Hurzeler, D.: Prototyping object oriented speciﬁcations. In: van der Aalst, W.M.P., Best, E. (eds.) ICATPN 2003. LNCS, vol. 2679, pp. 473–482. Springer, Heidelberg (2003) 7. L´ ucio, L.: SATEL — A Test Intention Language for Object-Oriented Speciﬁcations of Reactive Systems. PhD thesis, Universit´e de Gen`eve - Switzerland (2008), http://smv.unige.ch/tiki-download_file.php?fileId=975 8. Couvreur, J.-M., Encrenaz, E., Paviot-Adet, E., Poitrenaud, D., Wacrenier, P.: Data decision diagrams for petri net analysis. In: Esparza, J., Lakos, C.A. (eds.) ICATPN 2002. LNCS, vol. 2360, p. 101. Springer, Heidelberg (2002) 9. Couvreur, J.M., Thierry-Mieg, Y.: Hierarchical decision diagrams to exploit model structure. In: Wang, F. (ed.) FORTE 2005. LNCS, vol. 3731, pp. 443–457. Springer, Heidelberg (2005) 10. Bryant, R.: Graph-based algorithms for boolean function manipulation. Transactions on Computers C-35, 677–691 (1986) 11. Buchs, D., Hostettler, S.: Sigma decisions diagrams. Technical Report 204, CUI, Universit´e de Gen`eve. TERMGRAPH 2009 (January 2009) (to appear), http://smv.unige.ch/tiki-download_file.php?fileId=1147 12. Buchs, D., Hostettler, S.: Toward eﬃcient state space generation of algebraic petri net. Technical report, CUI, Universit´e de Gen`eve (January 2009), http://smv.unige.ch/tiki-download_file.php?fileId=1151 13. Lucio, L., Samer, M.: Technology of test-case generation. Model-Based Testing of Reactive Systems, 323–354 (2004)

An Experience on Ada Programming Using On-Line Judging Francisco J. Montoya-Dato, Jos´e Luis Fern´ andez-Alem´an, and Gin´es Garc´ıa-Mateos Department of Informatics and Systems, University of Murcia, 30100 Espinardo, Murcia, Spain {fmontoya,aleman,ginesgm}@um.es

Abstract. Ada has proved to be one of the best languages to learn computer programming. Nevertheless, learning to program is diﬃcult and when it is combined with lack of motivation by the students, dropout rates can reach up to 70%. In order to face up to this problem, we have developed a ﬁrst-year course for computing majors on programming based on two key ideas: supplementing the ﬁnal exam with a series of activities in a continuous evaluation context; and making those activities more appealing to the students. In particular, some of the activities are designed as on-line Ada programming competitions; they are carried out by using a web-based automatic evaluation system, the on-line judge. Human instructors remain essential to assess the quality of the code. To ensure the authorship of the programs, a source-code plagiarism detection environment is used. Experimental results show the eﬀectiveness of the proposed approach. The dropout rate decreased from 61% in the autumn semester 2007 to 48% in the autumn semester 2008. Keywords: Programming, e-learning, assessment.

1

Introduction

Currently, educational tendencies are centered in the student’s learning rather than the instructor’s teaching. A clear example of this trend is the European Space of Higher Education. One of the aims of the European Union countries is to develop new teaching methodologies based on the student’s learning process. The purpose is to create independent, reﬂective and life-long learners. The new methods should stimulate students interest and oﬀer appealing material, fair assessment and appropriate feedback. This paper describes an innovative experience with a ﬁrst-year course on programming which is supplemented with some activities of e-learning. A web-based automatic judging system called Mooshak [1] has been adapted to receive and evaluate programs in Ada. Previous experience on programming competitions for secondary and higher education shows the viability of the proposal and a high capacity to generate motivation and enthusiasm among students. The approach described is highly complementary with other learning techniques and methods. F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 75–89, 2009. c Springer-Verlag Berlin Heidelberg 2009

76

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

The rest of the paper is organized as follows. Section 2 presents a review of related work. Section 3 brieﬂy describes the fundamentals of on-line judging. Then, we introduce in Section 4 the methodological approach of the proposal. Section 5 oﬀers the main results of the e-learning experience applied to 107 students in a ﬁrst-year course for computer programming majors. In Section 6, we discuss the results achieved by employing this new methodology. The last section presents some concluding remarks.

2

Related Work

In the literature, most authors reach the same conclusion: learning to program is diﬃcult [2]. For example, some studies point out that it takes approximately ten years to transform a novice into an expert programmer [3]. A large number of techniques and methods have been proposed to improve students’ comprehension in computer programming courses [2]. E-learning activities constitute a viable and promising supplement in programming pedagogy. Particularly, on-line judging systems have already been applied in this discipline. Guerreiro and Georgouli [4,5] propose an e-learning educational strategy in ﬁrst-year programming courses. They adopt Mooshak automatic judging system for grading lab assignments and for self-assessment purposes. Automatic evaluation accounts for about 30% of the ﬁnal mark. This approach provides important beneﬁts in a CS1 course. A well thought out set of test cases prevents wrong programs sent by students from passing test runs. As a consequence, students must be much more rigorous in developing their programs. Likewise, students obtain immediate feedback from Mooshak. Another advantage of their proposal is the objectivity of the evaluation. Moreover, the authors consider that teachers can save time and work if an automatic judging system is used. Nevertheless, important concepts such as robustness and legibility are manually graded by the instructors. In order to address this issue, Bowring [6] proposes a new paradigm for programming competitions where the quality rather than the fast completion of the programs is evaluated. Both technical and artistic merit are taken into account as judging criteria. According to the author, technical quality refers to how well submissions meet the stated requirements, whereas artistic quality is related to the organization of the code, the readability of the code and its documentation, and the readability of other artifacts such as output ﬁles. Our novel contribution resides in the use of the on-line judging system in Ada programs. Our approach complements the traditional “ﬁnal exam evaluation” with a series of activities, many of them using Mooshak. Four important beneﬁts are obtained: (i) students are very motivated to take part in the proposed activities; (ii) the work of the students is evaluated along the course, rather than just in a single ﬁnal exam; (iii) the workload of instructors is reduced since many compilation and runtime errors are detected by the on-line judge; and (iv) students receive feedback on their submissions during the process of acceptance by the on-line judge, and can ask questions to the human judges, which promotes both independent learning and reﬂective thinking.

An Experience on Ada Programming Using On-Line Judging

3

77

On-Line Judging

An on-line judging system is an automatic tool which is able to evaluate the correctness of computer programs, based on a predeﬁned set of pairs input/output. We are using Mooshak 1.4 [1], which is free and publicly available. Mooshak has a web-based interface, which is diﬀerent for the students, teachers, guest users and the system administrator (see Figure 1). For example, a user (student) can access the description of the problems, the list of submissions sent by all users, the ranking of the best students, and the questions asked and answered. In contrast, a judge (teacher) can see and analyze the submissions sent, rejudge submissions, answer questions, and view statistics of system’s usage.

Fig. 1. Sample view for a judge (teacher) of Mooshak

The on-line judge works as follows: – A set of problem descriptions is available in the students’ web interface. These descriptions present problems related to the theoretical concepts studied in class. Each description contains a statement of the problem, a precise speciﬁcation of the input of the program and the expected output, along with some sample input/output pairs. – The students tackle each problem in their own computers, by writing a program which eﬃciently produces the expected outputs. When they have tested their implementation enough, they submit the solution to the judge using their interface. – The on-line judge receives the source code, compiles the program, and executes it using the predeﬁned sets of secret input cases. Then, Mooshak analyzes the output of the program (comparing it to the expected output)

78

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

and sends a response to the student which indicates whether the program is correct or not. – Statistical information is accessible both for teachers and for students. In particular, a ranking of the students sorted by the number of problems solved is given. The system also includes tools to send comments about any problem and ask questions to the teachers.

4

A Programming Methodology

We will introduce here the methodology that we follow in our CS1 programming course. First, the educational context in which this activity takes place is described. Then, we will justify the choice of Ada as the ﬁrst programming language for our students. Finally, we will see the kind of problems that we ﬁnd suitable to be judged by Mooshak, and how it is a convenient tool to help in the evaluation of the solutions provided by students. 4.1

Our Programming Course in CS1

Our programming course in CS1 is called Methodology and Technology of Programming (MTP), and it extends along the whole academic year. It is organized as three hours of classroom lessons and two hours of laboratory practices per week. For this course we have chosen the imperative paradigm, as the concepts of encapsulation and data hiding in implementations of abstract data types provide an adequate way for the study of data abstraction whose path naturally leads to the concept of class. For a more detailed discussion on this topic, the reader may see [7] and [8]. Object Oriented Programming (OOP) is studied later with the introduction of classes in the programming courses in CS2, and more in depth in a programming course utterly dedicated to OOP in CS3. The MTP course consists of two diﬀerentiated parts, which take about half of the course each: – A ﬁrst part in which students concentrate their attention on the design of elemental iterative algorithms. In this part, a great emphasis is made in methodological aspects, like the loop invariant based design and the mathematical deﬁnition of inductive relations that allow programmers to obtain the most signiﬁcant sentences of the iterative construction, like initialization and loop body. Some other basic concepts like subprogram decomposition, algorithmic schemes, scope and visibility rules, and scalar and structured data types (arrays and records) are also studied simultaneously. Contents of this part are based on Anna Gram Group’s works, most of them gathered in [9] (in French). These works have been collected and extended by the authors and can be found in their book [10] (in Spanish). Most of the problems studied in this part are related to the data type sequence, which is a container data type that only allows sequential access to its elements. Particularities of this data type make it specially suitable to be taken as a base for most iterative algorithms design problems.

An Experience on Ada Programming Using On-Line Judging

79

– A second and last part in which some other topics are studied: recursive design, dynamic memory management, elemental data structures (linear structures, and binary trees), abstract data types (ADT), generics, and an introduction to eﬃciency. ADT’s and generics are introduced by means of algebraic speciﬁcations, in order to clearly distinguish an ADT, which is an abstract and purely mathematical concept by itself, from its implementation, which is a computational and more concrete entity. 4.2

Why Ada?

In our opinion, Ada perfectly matches the required conditions for a programming language that should simultaneously be: (1) the most appropriate to be the very ﬁrst students’ programming language; and (2) an adequate framework to clearly illustrate the course contents, as described above. Most of these advantages are related to the early error detection that this programming language provides by itself. For the ﬁrst condition, we ﬁnd the following advantages in Ada: – In contrast to some other more popular languages, there exist several international standards for the Ada programming language, supported by institutions like ANSI and ISO. – Ada is a very strongly typed language. This feature allows the programmer to trust in the compilation process to catch some of the errors derived from mixing diﬀerent magnitudes in expressions. This type checking includes also parameter control in subprogram calls and instances of generics. Ada includes also the concept of subtype, which allows domain checking but relaxing incompatibilities that otherwise would exist among diﬀerent types. – Its syntax is very clear and well structured. Any construct beginning has its own terminator. All sentences end with semicolon, that does not act as a separator but as a terminator. – A strict access to control loop variables is imposed in for iterations. Also, this control variable is implicitly declared in the iteration and it exists only during the loop execution. This prevents ambiguity problems in the semantic of the for iteration related to the ﬁnal value of this variable upon loop termination. – Ada provides mechanisms to adequately handle exceptions. – It has suitable compilers freely available for academic institutions. In particular, we highly appreciate and acknowledge the excellent and free support that the company AdaCore oﬀers for their Ada GNAT based compiler to all universities enrolled in their Academic Program. This software is currently available for a wide variety of platforms, and also includes the GPS integrated development environment. There exist also some other friendly environments based on the GNAT free Ada compiler that may adequately be used as a basis for CS1 programming practices. – Ada provides a good basis for further courses on parallel/concurrent programming, OOP, hardware description languages (HDL) and software engineering that could also be taught using Ada as base programming language.

80

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

And for the second condition, we ﬁnd the following advantages. Most of them are closely related to the above ones: – Taking in mind that this is a CS1 programming course, details related to compilation, execution and debugging should be as easy as possible, so that students may concentrate their eﬀorts in studying and learning topics related to the course itself. GPS provides a very friendly environment to adequately cover with easiness all stages in any project development. – A rich repertoire of control structures (while, repeat-until, loop-exit-end and for loops) can be illustrated in Ada. – Ada features in modular programming make easy to implement extensions to deal with concepts (like the data type sequence) that are not usually included in common programming languages. In particular, we have created packages for students to be able to use these extensions in their Ada programs in a transparent way and in almost the same way they do in the algorithmic notation we use in our classroom lessons to teach these concepts. – The structure of Ada allows an easy top-down or bottom-up program design, where a subprogram may be decomposed into some others in a hierarchical fashion. Ada also closely keeps track of how a subprogram makes use of its own parameters depending on their kind (in, out, or in out) and forces all parameters of any function to be only of in kind, respecting in this way the theoretical concept of function as an operator whose invocation should never modify the computational process state. – The previously mentioned structure not only aﬀects to an independent program or compilation unit, but also to the relation among all compilation units that a whole project consists of. – Ada packages provide an excellent mechanism for opaque data types encapsulation and information hiding. Though this is not an exclusive feature of opaque data types, the possibility of declaring some of these types as limited prevents problems of misbehavior of default comparisons among expressions and, in the case of assignments, aliasing of complex data structures which could lead to data corruption. – Ada perfectly supports generics since its ﬁrst Ada’83 standard. This support allows us to deﬁne generic packages for data types like sequence, which due to its own nature of container data type is clearly a generic type. – Mechanisms for data handling through access data types provide adequate methods for dynamic memory management. They are also designed in such a way that some hazardous situations like side eﬀects due to aliasing of static and automatic variables are prevented by default. These variables may still be handled by access data types, but the programmer should be aware of this fact and must explicitly declare these variables as aliased. 4.3

Proposed Exercises

We will present here a taxonomy of the diﬀerent kinds of exercises that can be proposed to students using Mooshak. First, we identify the pedagogical principles

An Experience on Ada Programming Using On-Line Judging

81

that have guided our eﬀorts. Second, we will see how to overcome some of the problems that arise at this point when using the Mooshak on-line judging system. The assignments proposed in our course are designed to cover the cognitive domain of Bloom’s Taxonomy [11]. Bloom’s cognitive domain involves knowledge and development of intellectual skills. There are six categories, of diﬀerent degrees of diﬃculty. The correspondence between these categories and some of our educational activities is shown in Table 1. Mooshak is a tool ﬂexible enough to be used with any programming language, provided that its corresponding compiler is available and installed on the server. The compilation and execution processes can be done by means of a simple script Table 1. Educational activities in the cognitive domain of Bloom’s Taxonomy Category

Educational activities

Knowledge: Recall data.

Memorize concepts such as type, variable, constant, function, procedure, algorithm, algorithmic scheme. Translate an algorithm written in pseudocode into a programming language. Write a program from a known formula or algorithm (e.g. greatest common divisor, factorial, Fibonacci sequence). Choose the correct program from a list to solve a given problem. Fill an incomplete algorithmic scheme according to certain sequential access model. Create a problem with the format of the judge: problem description, source code to solve it, input cases, and expected outputs. Four sequential access models are introduced using the sequence data type. Apply these control models to new data structures such as arrays, lists and trees. Parameterize a data structure such as a stack, queue or tree to build a generic data type. Generalize a numerical sorting algorithm to any data type with an order relation deﬁned. Divide and conquer, stepwise reﬁnement, recursion, inductive reasoning are techniques used to tackle the complexity of an algorithmic problem. The use of these techniques implies performing both analysis and synthesis.

Comprehension: Understand the meaning of instructions and problems. State a problem in one’s own words.

Application: Use a concept in a new situation or unprompted use of an abstraction.

Analysis: Separate materials or concepts into component parts so that its organizational structure may be understood. Distinguish between facts and inferences. Synthesis: Build a structure or pattern from diverse elements. Put parts together to form a whole, with emphasis on creating a new meaning or structure. Evaluation: Make judgments about the value of ideas.

Implement iterative schemes starting from four pieces of code: initialization, termination condition, treatment of the current element, ending treatment. Several schemes can be built by using four sequential access models. Students have to achieve a tuned solution. Choose between linear search and binary search and justify the response. Calculate the algorithmic complexity and select the most eﬃcient sorting algorithm in a certain context.

82

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

that does not necessarily require interactive human intervention, like it could be the case of languages that require the use of GUIs environments in any of these two stages. Fortunately, Ada falls into the category of usable languages. There is another aspect to take into account: when submitting a solution for any problem proposed in Mooshak, the submission process consists of uploading a single ﬁle. This fact imposes a severe constraint to the problems we should propose to fully cover all the topics involved in our course. How could we manage to propose problems whose solution is not a program from which an executable could be obtained, but just a compilation unit like a package or a generic subprogram? In the case of packages, there exists an additional problem: a package consists of two diﬀerent ﬁles, whereas Mooshak on-line judging system only allows to upload one. The solution we ﬁnally decided to adopt for these cases is as follows: 1. Students should upload one single zip archive which contains all the ﬁles required by the problem. It is part of students’ responsibility that the names of these ﬁles and also the interface of their compilation units match the speciﬁcations given in the problem description. 2. As a ﬁrst step, the content of this zip ﬁle is extracted by the script that performs the judging process. These ﬁles are compiled and object modules are obtained from them if no compilation errors are found. 3. Then, a testing program that is designed to test students’ solution (and that is not known by them, of course), is compiled and linked against the object modules obtained in the previous step. If everything went well, an executable program should be obtained in this step. 4. This last executable program is the one that will be run and judged. Testing programs are designed to make a test as much exhaustive as possible of all features that the compilation units provided by students should oﬀer. Mutation testing [12] was used to ensure the quality of the test cases. Bearing in mind the above strategy to automatically grade the diﬀerent kind of exercises, we can group problems into four main categories: Single problems: We include in this category problems whose solution is just a compilation unit from which an executable program may be obtained as a result. This is the kind of problems that are usually proposed in programming contests. Some of these problems should be solved by using some of the extensions mentioned above (like the data type sequence), so these compilation units needed should be present in the system in order to correctly compile and link the source code uploaded by the students. We can distinguish here two kinds of problems, depending on how programs should get their input data. First kind are problems whose data is taken from the standard input, as it is usually done in programming contests. We have also another kind of problems, where the input consists of a single line containing the name of the ﬁle where the input should be taken from. We use this kind of input for the case of problems related to the data

An Experience on Ada Programming Using On-Line Judging

83

type sequence, where data should be loaded from the ﬁle to the sequence before proceeding. Compilation unit development problems: These are problems whose solution is not a main program but a compilation unit (package, subprogram, generic, etcetera). As mentioned above, for this kind of problems the main program is already uploaded in the judging server and is compiled and linked against the compilation unit(s) provided by the students. This testing program should be designed in such a way that it checks that: – All elements implemented in the compilation unit(s) (types, subprograms, constants, exceptions, etcetera) match the names provided in the problem description. – Compilation unit(s) subprograms return correct results and show the right behaviour as speciﬁed by the problem description. These tests should be performed for a wide variety of diﬀerent subprogram input data. It should also be checked that the name, type and kind of any subprogram parameters are those speciﬁed by the problem description. – Exceptions deﬁned in the compilation unit(s) are raised in the cases, and only in the cases, speciﬁed by the problem description. Exceptional situations should be provoked and the corresponding exceptions properly handled in order to perform an adequate test of the expected unit(s) behaviour (for example, popping out from an empty stack, etcetera). Whole project problems: In this kind of problems, students should provide all modules that the project consists of. The only constraint imposed for these cases is the name of the main unit where the executable program should be obtained from. Solutions provided for this kind of problems are judged as usual. These problems may be thought as a continuation to the previous ones: ﬁrst, compilation units are tested and judged separately, and then the project is judged as a whole. Judge problems: The students have to create a problem with the format of the judge: problem description, source code to solve it, input cases, and expected outputs. Table 2 shows the Mooshak’s activities organized in the course. Notice that the level of diﬃculty (Bloom’s level) of the activities is gradually increasing. All of them are to be done individually. The problems are graded from 1 to 5 according to their degree of diﬃculty and are freely chosen by students. The instructor notiﬁes the results to the students in a personal interview. The activities are voluntary and are not required as part of the regular assignments. Mooshak’s activities evaluation accounts for 20% of the ﬁnal mark. Since most work is not done in the presence of the teacher, a tricky concern is to guarantee the originality and authorship of the programs submitted by the students. Some strategies are applied to reduce the risk of plagiarism and to detect it: – There are many aspects of programming that are not so easy to automatically evaluate: computational complexity, design and organization of the code, programming style, robustness, legibility, etcetera. For this reason, all

84

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

Table 2. Description of the activities proposed in Mooshak. “Type”: Single Problems (SP), Compilation Unit Development Problems (CUDP), Whole Project Problems (WPP) and Judge Problems (JP);“# p.”: number of problems existing in the judge; “Bloom”: category covered in the cognitive domain of Bloom’s Taxonomy, knowledge (K), comprehension (C), application (Ap), analysis (An), synthesis (S) and evaluation (E). Activity

Type

Sequentiation SP Selection SP Iteration SP Schemes CUDP Generics CUDP, WPP Packages CUDP, WPP ADT SP Dynamic Memory WPP Recursion SP Sorting SP, CUDP, WPP Miscellany JP

Language # p. Ada Ada Ada Ada Ada Ada Maude Ada Ada Ada Ada

6 5 8 12 2 2 7 8 10 11 6

Bloom K, C K, C C, Ap An, S Ap Ap An, S Ap, An, S An, S Ap, An, S, E E

activities include a compulsory interview with a teacher, where students have to explain their submissions and answer some questions. Nevertheless, some of these quality factors could be automatically assessed using software quality assurance tools. These tools will be considered in a future work. C N Pc 0.1×(T N Sc −N SSPc,p ) – The formula N , is used to grade the Mooshak’s c=1 p=1 T N Sc activities performed by each student. N Pc is the number of problems proposed in the contest c and NC is the number of contests organized. A student is considered as a contestant in the contest c if he has a Mooshak account in this contest. N SSPc,p is the number of contestants that solved the problem p of the contest c, and T N Sc is the total number of contestants in the contest c. Note that the score of each accepted submission is in inverse proportion to the number of accepted submissions. Therefore, we think that this formula is an eﬀective deterrent measure against plagiarism lovers. – Students will have to demonstrate their knowledge on the topics by an individual written exam. – For the activities done in Mooshak, we use a plagiarism detection system developed by Cebrian et al. [13]. Thanks to Mooshak, all the submissions are available in judge’s server, so the plagiarism detector can be easily applied. In our case, this plagiarism detector reported three possible cases of copy. Nevertheless, after manual inspection of the programs and an individual interview with students, plagiarism was ruled out.

5

Evaluation of the Method

The approach proposed here has been used eﬀectively in an introductory computer programming course at the University of Murcia (Spain). In this section,

An Experience on Ada Programming Using On-Line Judging

85

Table 3. Pass, failure and dropout rates of MTP in previous years. Ann.: Annual; Aut.: Autumn semester. Year

2003/04

Duration Language Pass rate

Ann. Modula-2 14 11% Failure rate 25 19% Dropout rate 92 70% Total of 131 students

Aut. 18 14% 28 21% 85 65% 131

2004/05 Ann. Modula-2 17 16% 21 20% 67 64% 105

Aut. 20 19% 27 26% 58 55% 105

2005/06 Ann. Modula-2 12 11% 18 16% 82 73% 112

2006/07 2007/08

Aut. Ann. Aut. ADA 14 9 13 12% 10% 14% 24 18 30 22% 19% 33% 74 65 49 66% 71% 53% 112 92 92

Ann. Aut. ADA 16 21 13% 17% 20 27 17% 22% 85 73 70% 61% 121 121

detailed information about the experiment designed and conducted during the autumn semester of 2008 is provided. The aim was to assess the application of the programming learning method proposed in this paper. 5.1

Participants and Background

As mentioned in Section 4, the experience described here was applied to a ﬁrst-year course for computer programming majors. MTP has a load of 12 ECTS (European Credits Transfer System) and has been traditionally organized in a monolithic form: weekly lectures, laboratory sessions, and a ﬁnal exam for each semester. The ﬁrst exam consisted of between 3 and 4 algorithmic problems about basic procedural programming constructs of sequence, selection and iteration, inductive reasoning and loop patterns. The second exam consisted of between 5 and 7 problems about recursive design, dynamic memory management, linear structures, binary trees, eﬃciency and algebraic speciﬁcations to represent abstract data types. Grading was manually done by the instructors according to criteria such as correctness, eﬃciency, robustness, extendibility and legibility. In autumn of 2008, the 107 students enrolled in MTP were involved in the new learning method. Though participation was voluntary in Mooshak’s activities, most students actively participated in the proposed activities. In previous years, the main problem observed in this course was a low motivation and participation of the students in class, that resulted in a high dropout rate. In the last ﬁve years, around 70% of enrolled students dropped out, as shown in Table 3. With the aim of reversing this trend, we decided to adopt a new learning paradigm based on a continuous evaluation organization, with activities that are appealing and motivating for all students. 5.2

Results of the On-Line Judge

Statistical data related to the programming learning method described in this paper was gathered during the autumn semester of 2008. Up to 92 of the 107

86

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

Table 4. Detail of the classiﬁcation of the submissions by knowledge unit. “# subm.”: Number of submissions. A: Accepted. PE: Presentation error. WA: Wrong answer. RE: Runtime Error. CE: Compile Time Error. Activity

# subm.

A

PE

WA

RE

CE

Sequentiation Selection Iteration Schemes Generics

276 280 718 1039 193

111 (40%) 122 (43%) 299 (41%) 409 (39%) 78(40%)

51 (18%) 28 (10%) 145(20%) 220 (21%) 35 (18%)

41 (14%) 74(26%) 87 (12%) 135 (12%) 22 (11%)

59 (21%) 44 (15%) 155(21%) 200 (19%) 51 (26%)

14 (5%) 12 (4%) 32 (4%) 75 (7%) 7(3%)

Total

2512

1019 (40%) 479 (19%) 359 (14%) 509 (20%) 140 (5%)

enrolled students (86%) participated in some activity related to the on-line judge; 60 of them (56%) solved and 62 (58%) tried to solve at least one problem. In total, the on-line judge received 2512 submissions, i.e., Ada programs and packages, with an average of 27.3 submissions per student. The on-line judge classiﬁed around 1019 of these as “accepted” (40.6%), and 359 as “wrong answer” (14.3%). More information on the classiﬁcation of the submissions, and the percentages per unit of knowledge is shown in Table 4. The average number of submissions per student until getting the program accepted is 2.2. Nevertheless, many students found the solution to the problems at the ﬁrst attempt (mode is 1). The highest number of programs that a student submitted to get an “accepted” was 21. Figure 2(a) shows a histogram of the number of problems solved per student. This value covers a range from 1 to 33. The mean number of solved problems per student is 11, with a standard deviation of 8.2, and with three modes of 4, 5 and 8. It is also interesting to analyze when the students work. Figure 2(b) represents the number of accepted and rejected submissions in each hour of the day. The minima are located at 2 and 6 am (0 submissions) and the maximum at 4 pm (467 submissions). On the other hand, the students achieved the highest acceptance rates at 10 pm and 10 am with 82% and 66%, while they had the lowest acceptance rate at 6 pm with 17%. Most activity takes place from 8 am to 8 pm, when computer laboratories are open to the students. However, submissions done by the students outside these hours represent a total of 24%.

(a) Number of problems solved by the students.

(b) Submissions in each hour of the day.

Fig. 2. Statistical information on Mooshak

An Experience on Ada Programming Using On-Line Judging

6

87

Discussion

The results obtained after the application of our programming learning method during the autumn semester 2008 are very promising. We have observed a signiﬁcant increase in the pass rate, from 17% (13% in whole academic year) in 2007 to 21% in 2008. However, the most striking fact is the dramatic decline in the dropout rate, from 61% (70% in whole academic year) in 2007 to 48% in 2008. The new methodology encourages students to make them get back on pace again. The advantages that we ﬁnd in our approach, considering the kind of problems that we propose to students in the on-line judge, can be summarized in the following points: – In single problems, the importance of making a methodological and systematic program development in order to minimize errors becomes evident. It frequently happens that students, most times due to an excess of selfconﬁdence, omit the necessary steps to analyze the problem and to design the solution. In most cases, this kind of hurried development results in a program that apparently works correctly, but there exist some cases in which it fails. When the validation stage is made locally in the own student’s computer, the causes of these errors are usually quite evident and the proper program modiﬁcations quite easy too. This creates in the students the false illusion that those methodological issues are not important, as the consequences of disregarding them can be easily and quickly overcome. On the contrary, in the case of Mooshak on-line judging system, input test cases are unknown by students and the only feedback that they get is a laconic “wrong answer” message, which forces them to make a more in depth and methodological review of their programs in order to discover the error. This situation is similar to the real case, in which all program input data cases are obviously a priori unknown and the only information that programmers will get is that their programs fail sometimes. As a result, the error will be rather diﬃcult to isolate just by analyzing the program behaviour from the input/output point of view. – In compilation unit development problems, the student becomes aware of the importance of strictly following the speciﬁcation of the unit interface. The slightest variation in an identiﬁer name, number/type/kind of parameters in a subprogram, etc. may result in a testing program compilation error. On the other hand, unit behaviour should be as expected: subprograms results should be correct, exceptions should be raised in the right and only in the right cases, etcetera. Otherwise, testing program execution would not generate the expected output or even would result in a run-time error. – In whole project problems, the student becomes responsible of correctly organizing all the submitted code. In particular, it is possible that some of the project compilation units were independently judged in previous problems, and more than one version were accepted by the on-line judging system. The student should decide at this point which is the version that he/she considers the best one to be included in the ﬁnal project.

88

F.J. Montoya-Dato, J.L. Fern´ andez-Alem´ an, and G. Garc´ıa-Mateos

– In judge problems, students have to make judgments about the interest, diﬃculty and complexity of a problem. The creativity of the students to produce original and relevant problems is evaluated. On the other hand, we think the proposed organization of the course successfully meets most important pedagogical principles [14]: Motivation. The public ranking plays a fundamental role in motivating students to solve more problems, faster and more eﬃciently. If students get an “accepted”, a rise in ranking means students get an incentive to continue tackling other algorithmic problems. Active learning. When students solve the proposed problems, they are involved in, and conscious of, their own learning process in order to achieve a real and long-lasting learning. Continuous learning. The new methodology has a crucial advantage: the students work along the course, and not just some weeks before the ﬁnal exam. Autonomous work. Students can work in the laboratories, where they have help from the teachers. However, students mostly work at home, and ask questions to the teachers by using Mooshak. Feedback of the learning process. The web system provided feedback to help students to correct many errors of their programs, thus avoiding assistants spend much eﬀort ﬁguring out the causes of the failure, as happens in a traditional evaluation. The judge is accessible 24-hours a day and the feedback is instantaneous. From the point of view of the teachers, information is also comprehensive and immediate; they can analyze the diﬃculty of the problems, the evolution of the students, identify the best students, etcetera. Finally, regarding our experience on these e-learning activities, we advocate the use of on-line judging systems as a support for the teacher in the task of evaluating students’ know-how. In any case, it will always be also necessary the teacher’s criterion to determine the degree of correctness of the submitted code.

7

Conclusions

We have presented in this paper an innovative experience on computer science education using Ada. In general, the results of our experiment are excellent. We have shown that on-line judging systems can be used to make the activities of a programming course more interesting. The approach improves self-assessment skills and encourages students to work independently. The public ranking and other statistical data provided by Mooshak, promote competitiveness and oﬀer appealing material to the students. The assessment is fair and objective, and students are able to gain additional feedback from the human judges. The approach contributes to build a strong foundation for the student’s life-long learning. Students get themselves more involved into their own learning process.

An Experience on Ada Programming Using On-Line Judging

89

References 1. Leal, J.P., Silva, F.M.A.: Mooshak: a web-based multi-site programming contest system. Softw., Pract. Exper. 33, 567–581 (2003) 2. Robins, A., Rountree, J., Rountree, N.: Learning and teaching programming: A review and discussion. Computer Science Education 13, 137–172 (2003) 3. Winslow, L.E.: Programming pedagogy—a psychological overview. SIGCSE Bull. 28, 17–22 (1996) 4. Guerreiro, P., Georgouli, K.: Enhancing elementary programming courses using e-learning with a competitive attitude. Int. Journal of Internet Education (2008) 5. Guerreiro, P., Georgouli, K.: Combating anonymousness in populous CS1 and CS2 courses. In: Proc. ITICSE 2006, pp. 8–12 (2006) 6. Bowring, J.F.: A new paradigm for programming competitions. In: SIGCSE 2008: Proceedings of the 39th SIGCSE technical symposium on Computer science education, pp. 87–91. ACM Press, New York (2008) 7. Bruce, K.B.: Controversy on how to teach CS 1: a discussion on the SIGCSEmembers mailing list. SIGCSE Bulletin 36, 29–34 (2004) 8. Reges, S.: Back to basics in CS1 and CS2. In: SIGCSE, pp. 293–297 (2006) 9. Peyrin, J., Scholl, P.: Schemas Algorithmiques Fondamentaux. Sequences et Iteration. Masson, Paris (1988) (in French) 10. Garc´ıa-Molina, J., Montoya-Dato, F., Fern´ andez-Alem´ an, J., Majado-Rosales, M.: Una Introducci´ on a la Programaci´ on. Un Enfoque Algor´ıtmico. Thomson (2005) (in Spanish) 11. Bloom, B., Furst, E., Hill, W., Krathwohl, D.: Taxonomy of Educational Objectives: Handbook I, The Cognitive Domain. Addison-Wesley, Reading (1956) 12. Woodward, M.R.: Mutation testing—its origins and evolution. Information and Software Technology 35, 163–169 (1993) 13. Cebrian, M., Alfonseca, M., Ortega, A.: Towards the validation of plagiarism detection tools by means of grammar evolution. IEEE Transactions on Evolutionary Computation (2008) (in press) 14. Vrasidas, C.: Issues of pedagogy and design in e-learning systems. In: SAC 2004: Proceedings of the ACM symposium on Applied computing, pp. 911–915. ACM, New York (2004)

Weak Fairness Semantic Drawbacks in Java Multithreading Claude Kaiser1 and Jean-Fran¸cois Pradat-Peyre2 1

CEDRIC - CNAM Paris 292, rue St Martin, F-75003 Paris [email protected] 2 LIP6 - Universit´e Pierre et Marie Curie 104 avenue du Pr´esident Kennedy, F-75016 Paris [email protected] http://quasar.cnam.fr/

Abstract. With the development of embedded and mobile systems, Java is being widely used for application programs and is also considered for implementing systems kernel or application platforms. It is the aim of this paper to exemplify some subtle programming errors that may result from the process queuing and awaking policy, which corresponds to a weak fairness semantic and which has been chosen for implementing the monitor concept in this language. Two examples show some subtle deadlocks resulting from this policy. The ﬁrst example deals with process synchronization: processes seeking after partners for a peer-to-peer communication call a symmetrical rendezvous server. The second example concerns resource sharing according to a solution of the dining philosophers paradigm. In this example, several implementations are presented, the last ones aiming to provide deterministic process awakening. All these examples have been validated and simulated and this allows comparing their concurrency complexity and eﬀectiveness. Our conclusion is, ﬁrst, that the use of Java for multithreading programming necessitates sometimes additional shielding code for developing correct programs and, second, that a good acquaintance with several styles of concurrent programming helps designing more robust Java solutions, once the choice of the implementation language is irrevocable.

1 1.1

Introduction Concurrency Programming

Java is widely used for application programs and, with the development of embedded and mobile systems, it is also being considered for implementing systems kernel or application platforms. Concurrent programming is a proliﬁc source of complexity. Thus it is a serious cause of errors when developing applications, system kernels or platforms. One proper engineering solution is to choose a good level of abstraction for concurrency control. For this reason the monitor concept [10] has been implemented in F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 90–104, 2009. c Springer-Verlag Berlin Heidelberg 2009

Weak Fairness Semantic Drawbacks in Java Multithreading

91

past operating systems, as early as in the personal computer system Pilot with the Mesa language [13]. Java designers are aware that concurrent programming is diﬃcult and is still a challenge for developers. “Since concurrency techniques have become indispensable for programmers who create highly available services and reactive applications, temporal dimensions of correctness introduced by concurrency, i.e., safety and liveness, are central concerns in any concurrent design and its implementation” [14]. “Providing signiﬁcant examples and paradigms is of prime importance for mastering good and correct style. Even if you never employ them directly, reading about diﬀerent special-purpose design patterns can give you ideas about how to attack real problems” [14]. When implementing multithreading, choosing reliable concurrent algorithms is necessary, however it is not suﬃcient. The behavioural context must also be considered since subtle running errors often arise from the semantics of the run time kernel or the underlying platform. It is the aim of this paper to point out some possibly negative consequences of the concurrency semantic chosen for the Java language. 1.2

Overview of the Monitor Concept as Implemented in Java

Several possible monitor concurrency semantics have been used in the past and a classiﬁcation has been presented in [4]. Every implementation has to provide mutual exclusion during the execution of a distinguished sequence. However an implementation may have a speciﬁc policy for blocking, signalling and awaking processes. The languages Java and C# both include the monitor concept and have chosen the same run time policy. The Java language provides mutual exclusion through synchronized block or synchronized method, using a lock for every object, and uses explicit selfblocking and signalling instructions. It provides “wait()”,“notify()” and “notifyAll()” clauses with a unique waiting queue per encapsulated object (termed “synchronized”). A self-blocking thread joins the waiting queue and releases the object mutual exclusion lock. A notifying thread wakes up one or all waiting threads (which join the ready threads queue), but it does not release the lock immediately. It keeps it until it reaches the end of the synchronized method (or block); this is the “signal and continue” monitor discipline. Hence the awaked threads must still wait and contend for the lock when it becomes available. However, as the lock is released, and not directly passed to an awaked thread (the lock availability is globally visible), another thread contending for the monitor may take precedence over awaked threads that have already been blocked on the waiting queue. This awaking policy involves weak fairness. If this elected thread calls also a synchronized method (or enters a synchronized block) of the object, it will acquire the lock before the awaked threads and then access the object before them. This may contravene some problem speciﬁcations and in that case may require adding some shielding code to maintain the original algorithmic correctness.

92

C. Kaiser and J.-F. Pradat-Peyre

Since Java 1.5, the basic Java monitor has been extended and allows using multiple named condition objects. This provides more programming ﬂexibility, however the signalling policy remains the same and the weak fairness semantic is still present. The C# language has also thread synchronization classes using for example Wait(), Pulse(), Monitor.Enter(), Monitor.Quit(). Its thread queuing and signalling policy relies also on a weak fairness semantic. Thus it has the same drawbacks as Java. 1.3

Outline of the Paper

Process synchronization and resource sharing are basic concerns when developing concurrent software. We present an example in each domain. Each will show some subtle consequences of Java’s basic policy that may lead to deadlock. The ﬁrst example is a symmetrical rendezvous server, called by processes seeking after partners for a peer-to-peer communication. The second example concerns resource sharing and is a new solution of the dining philosophers paradigm. Several implementations are presented, using diﬀerent semantics choices, the Java one and another one that gives precedence to the awaked processes, i.e. that implements strong fairness. It will be shown that in this case, which is the Ada choice[16], the implementations are simpler and safer. All these examples have been submitted to our veriﬁcation tool Quasar and have also been simulated for performance comparison. This allows comparing their concurrency complexity and eﬀectiveness. Our conclusion is, ﬁrst, that the use of Java for multithreading programming may necessitate additional shielding code when implementing concurrency algorithms which have been proven correct in strong fairness context and, second, that good acquaintance with several styles of concurrent programming is helpful for designing better Java solutions for concurrent applications, once the choice of the implementation language is irrevocable. General appraisals of the Java concurrency features as well as their comparison with Ada have been published [3,15]. Our paper focuses on the incidence of fairness semantic on reliability and our appraisal is supported by a concurrency veriﬁcation tool.

2

Process Synchronization Example: Symmetrical Rendezvous Paradigm

The synchronization example is the mutating chameneos paradigm [12]. It involves a symmetrical rendezvous before peer-to-peer cooperation of concurrent processes. The cooperation, depicted as a possible colour mutation between the chameneos of a pair, is not developed in this paper. Here we cope only with a solution where a chameneos eager to cooperate calls a rendezvous server in order to ﬁnd a partner. The rendezvous server has the following speciﬁcation: 1. it must wait until it has received two requests before giving notiﬁcation, 2. multiple requests shall not disturb the service,

Weak Fairness Semantic Drawbacks in Java Multithreading

93

3. notiﬁcations must be sent as soon as possible, 4. once A and B are paired, A must know that its partner is B and B that its partner is A. A possible server behaviour, respecting mutual exclusion, is: – at the ﬁrst call, the server registers the name of the ﬁrst caller; then it waits the end of second call before reading the name of the mate and returning it to the ﬁrst caller. – at the second call, it registers the name of the second caller, reads the name of the mate, notiﬁes it to the second caller, and wakes the ﬁrst request, signalling that its mate name is now available. This algorithm has been proven reliable by our tool Quasar when implemented in Ada (i.e. with a strong fairness semantic). The corresponding Java class is given in Program 1. A synchronized method is used.

public c l a s s Rendez Vous { p r i v a te ThreadId APartner , BP a r t n e r ;

}

// names of the first and // second requesting thread p r i v a te boolean F i r s t C a l l = true ; // false when Second Call p r i v a te boolean MustWait = f a l s e ; // used for defensive code public synchronized ThreadId p a r t n e r ( ThreadId x ) { ThreadId r e s u l t ; // the following loop is a necessary defense, forbidding access by a third partner while ( MustWait ) { try { w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} } // the following is the code solving the specifications of the problem if ( FirstCall ){ APartner = x ; F i r s t C a l l = f a l s e ; // now the caller must wait the end of the second request while ( ! F i r s t C a l l ) { try { w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} } r e s u l t = BP a r t n e r ; MustWait = f a l s e ; n o t i f y A l l ( ) ; } else { BP a r t n e r = x ; r e s u l t = APartner ; F i r s t C a l l = true ; MustWait = true ; n o t i f y A l l ( ) ; } return r e s u l t ; }

Program 1. Symmetrical rendezvous implementation in Java Due to the Java choice of locking and notifying semantics, if the access of a third chameneos had not been explicitly forbidden in the code (this is done using MustWait), the program would have been erroneous. Indeed, suppose that the barrier with MustWait is not implemented and consider four requests, A, B, C and D: partner(A) may be D, partner(B) may be A, partner(C) may be D and partner(D) may be C. A and B are not correctly paired and this leads to deadlock. A semantic choice giving precedence to the awaked processes, as in Ada, removes the need of this defensive barrier. Java, Ada and Posix solutions are compared in [12].

94

C. Kaiser and J.-F. Pradat-Peyre

This simple program is our ﬁrst example showing that the Java implementation of a correct algorithm must care of the underlying semantics and that this care may often lead to add compulsory shielding code.

3 3.1

Resource Allocation Example Another Solution of the Dining Philosophers Paradigm

The dining philosophers, originally posed by [6], are a well-known paradigm for concurrent resource allocation. Five philosophers spend their life alternately thinking and eating. To dine, each philosopher sits around a circular table at a ﬁxed place. In front of each philosopher is a plate of food, and between each pair of philosophers is a chopstick. In order to eat, a philosopher needs two chopsticks, and they agree that each will use only the chopsticks immediately to the left and to the right of his place. The problem is to write a program simulating the philosopher’s behaviours and to devise a protocol that avoids two unfortunate conclusions: deadlock and starvation. This paradigm has two well-known approaches: step-wise or global allocation [9,1]. Let us consider now another approach, which has been experimented in [11] and which has been proven correct by our tool Quasar when implemented with a strong fairness semantic (in Ada). The chopsticks are allocated as many as available and the allocation is completed as soon as the missing chopsticks are released. 3.2

Straightforward Java Implementation

A straightforward Java implementation of this latter solution leads to the following Chop class with get LR and release methods (Program 2).

public f i n a l c l a s s Chop { p r i v a te i n t N ; p r i v a te boolean a v a i l a b l e [ ] ; Chop ( i n t N) { t h i s .N = N ; t h i s . a v a i l a b l e = new boolean [N ] ; f o r ( i n t i =0 ; i < N ; i ++) { a v a i l a b l e [ i ] = true ; // non allocated stick } } public synchronized void get LR ( i n t me) { while ( ! a v a i l a b l e [ me ] ) { try { w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} } a v a i l a b l e [ me ] = f a l s e ; // left stick allocated // don’t release mutual exclusion lock and immediately requests // second stick while ( ! a v a i l a b l e [ ( me + 1 )% N ] ) { try { w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} } a v a i l a b l e [ ( me + 1 )% N ] = f a l s e ; // both sticks allocated now } public synchronized void r e l e a s e ( i n t me) { a v a i l a b l e [ me ] = true ; a v a i l a b l e [ ( me + 1 )% N ] = true ; notifyAll () ; } }

Program 2. Unsafe Chop implementation in Java

Weak Fairness Semantic Drawbacks in Java Multithreading

95

It is inﬂuenced by the Java choice of a monitor with a unique and implicit condition queue. This Java implementation may give misleading conﬁdence. Actually the program is not safe. It occasionally fails and deadlocks, but this is a situation which is rare, diﬃcult to reproduce and therefore to explain and debug. 3.3

Deadlock Analysis

Let us consider the following running sequence. Philosophers request the sticks in the following sequential order: 4, 3, 2, 1, and 0. Philosopher 4 takes two sticks (sticks 4 and 0) and eats while Philosophers 3, 2 and 1, one after the other, take their left stick and wait for their right stick that they ﬁnd already allocated. Philosopher 0 ﬁnds that its left stick has been taken, so it waits for it. As soon as Philosopher 4 has released its two sticks, it becomes hungry anew and calls Get LR immediately. Suppose that Philosopher 0 has been awaked ﬁrst and in the meanwhile has taken its left stick and now waits for its right one. The correctness relies on the choice of the next process that will access the monitor and take stick 4. If it is Philosopher 3, it will take its right stick and eat. If it is Philosopher 4, it will take its left stick and ﬁnd its right stick already allocated. It will be blocked, as already are the four other Philosophers, and this is a deadlock. The Java policy allows Philosopher 4 to compete for acquiring the access lock of the object chop, and if it succeeds occasionally to take precedence over Philosopher 3, this will cause a deadlock. If precedence were given to the existing waiting calls (as it is the semantic choice of Ada 95 and also of the private semaphore schema [5]), Philosopher 3 would have always precedence over Philosopher 4 and there would never be a deadlock. This shows that the correctness relies on the concurrency semantic of the run-time system. It shows also why deadlock is not systematic in the Java solution, and why this non-deterministic behaviour makes its correctness diﬃcult to detect by tests. 3.4

Defensive and Safe Java Straightforward Implementation

A safe solution is achieved in giving precedence to a philosopher already owning its left stick and requesting its right stick over a philosopher requesting its left stick. A stick must be booked for being used as a right stick and forbidding its use as a left stick (this is programmed using the boolean bookedRight[ ] as a barrier). This leads to a safe although unfair solution (no deadlock, possible starvation). It is given below as a subset of the safe and fair solution. This approach needs shielding code because of the Java monitor policy. Care had to be taken of the underlying platform behaviour, as quoted, in java.lang.Object, in the wait method detail section. “A thread can also wake up without being notiﬁed, interrupted, or timing out, a so-called spurious wakeup... In other words, waits should always occur in loops.” This solution is safe but unfair. For example suppose philosopher 4 eats (it uses sticks 4 and 0) while philosopher 0 is hungry and is waiting for stick 0. Suppose now that after releasing its sticks, philosopher 4 requests them immediately, calling get LR. Philosopher 4 may acquire the monitor lock anew before philosopher 0, involving starvation of the latter.

96

C. Kaiser and J.-F. Pradat-Peyre

A fairness constraint may be derived from this example, prescribing that a releasing philosopher cannot get again a stick as its right stick before an already waiting philosopher, which has previously booked this stick as its left stick (the boolean bookedLeft[ ] is used as a barrier for programming it). However this fairness constraint is circular and re-introduces deadlock, unless a releasing philosopher is denied a new access to the monitor when one of its neighbours is already waiting for one of its released sticks. This gives precedence to already waiting philosophers. Additional shielding code is again necessary because of the chosen monitor policy.

public f i n a l c l a s s Chop { p r i v a te i n t N ; p r i v a te boolean a v a i l a b l e [ ] ; p r i v a te boolean b o o k e d R i g h t [ ] ; p r i v a te boolean b o o k e d L e f t [ ] ; Chop ( i n t N) { t h i s .N = N ; t h i s . a v a i l a b l e = new boolean [N ] ; // chop availability when true t h i s . b o o k e d Ri g h t = new boolean [ N] ; // always compulsory for deadlock avoidance barrier t h i s . b o o k e d L e f t = new boolean [N ] ; // used only when fairness is required f o r ( i n t i =0 ; i < N ; i ++) { a v a i l a b l e [ i ] = true ; b o o k e d R i g h t [ i ] = f a l s e ; bookedLeft [ i ] = fa ls e ; } } public synchronized void get LR ( i n t me) { // compulsary defensive code giving precedence to already waiting // philosophers when seeking fairness while ( b o o k e d Ri g h t [ me ] | | b o o k e d L e f t [ me + 1 )% N) { // a stick has been booked by one neighbour try { w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} } while ( ! a v a i l a b l e [ me ] | | b o o k e d R i g h t [ me ] ) { // deadlock avoidance barrier even when unfair allocation try { b o o k e d L e f t [ me ] = true ; w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} // bookedLeft[me] reserves left stick if fairness is requested // otherwise bookedLeft is not used } a v a i l a b l e [ me ] = f a l s e ; // left stick allocated b o o k e d L e f t [ me ] = f a l s e ; // no more reason for booking left stick b o o k e d R i g h t [ ( me + 1 )% N ] = true ; // compulsary booking of right // stick for deadlock avoidance // don’t release mutual exclusion lock and immediately requests // second stick while ( ! a v a i l a b l e [ ( me + 1 )% N ] | | b o o k e d L e f t [ ( me + 1 )% N] { try { w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} } a v a i l a b l e [ ( me + 1 )% N ] = f a l s e ; // both sticks allocated now b o o k e d R i g h t [ ( me + 1 )% N ] = f a l s e ; // no more reason for booking // right stick } public synchronized void r e l e a s e ( i n t me) { a v a i l a b l e [ me ] = true ; a v a i l a b l e [ ( me + 1 )% N ] = true ; notifyAll () ; } }

Program 3. Safe and fair Chop implementation in Java Program 3 is a solution proven correct by our veriﬁcation tool Quasar.

Weak Fairness Semantic Drawbacks in Java Multithreading

3.5

97

A Single Waiting Queue with Priority Given to Signalled Threads

This solution, with a single condition queue, has been implemented in Ada where protected objects implement a monitor where signaled threads (named tasks in Ada) take precedence over new calls. Ada implements a strong fairness semantic. This allows comparing both fairness semantics, the weak one and the strong one. The results are given in Section 5.

4 4.1

Implementations with More Waiting Queues A Waiting Queue for Each Blocking Condition

In the preceding solutions, all signalled philosophers have to check the availability of their sticks, even when the released sticks don’t concern them. This unfortunate and ineﬃcient behaviour is frequent in the Java programming style and it occurs naturally since a Java monitor has just one anonymous condition variable. The optimization, consisting in notifying a thread only when its both sticks have been allotted to it, provides also a more deterministic solution since it is independent of queuing policies. Two approaches are presented in Java, the ﬁrst one reproducing the private semaphore schema, the second reproducing a monitor with named condition variables. In both approaches, Java still imposes to add some defences against weakness with ad hoc low-level like code. These approaches have been proved safe and fair by our veriﬁcation tool Quasar. A third approach is given in Ada and allows a comparison with the semantics where priority is given to signalled threads (i.e. strong fairness). The results are given in Section 5. 4.2

A First Implementation Using Notiﬁcation Objects

This solution takes inspiration from the private semaphore schema [5] and a similar one can be found in [9]. Mutual exclusion is provided by synchronized methods; condition synchronisation is provided by additional notiﬁcation objects. A waiting philosopher is notiﬁed only when it has been allocated its requested forks, giving precedence to it over a new request of the releasing philosopher and avoiding thus a deadlock situation. It results in Program 4. The synchronized methods of Chop provide only mutually exclusive access to shared data and don’t block a calling thread. The blocking test and the resulting blocking action are done in the critical section deﬁned by synchronized(Allocated[ ]), avoiding the race conditions that may occur when a thread is notiﬁed while it has been CPU pre-empted just before calling the wait() method. This copies the private semaphore schema where shared data are accessed in mutual exclusion without blocking and where semaphores realize an atomic test and block action.

98

C. Kaiser and J.-F. Pradat-Peyre

public f i n a l c l a s s Chop { p r i v a te p r i v a te p r i v a te p r i v a te p r i v a te

int N ; boolean a v a i l a b l e [ ] ; boolean r e q u e s t i n g [ ] ; O b j e c t A l l o c a t e d [ ] ; // similar role as private semaphores int sc or e [ ] ; // # of allocated sticks to each philosopher

Chop ( i n t N) { t h i s .N = N ; t h i s . a v a i l a b l e [ ] = new boolean [N ] ; t h i s . r e q u e s t i n g [ ] = new boolean [N ] ; t h i s . A l l o c a t e d [ ] = new O b j e c t [ N ] ; t h i s . s c o r e = new i n t [ N] ; f o r ( i n t i =0 ; i < N ; i ++) { a v a i l a b l e [ i ] = true ; r e q u e s t i n g [ i ] = f a l s e ; A l l o c a t e d [ i ] = new O b j e c t ( ) ; s c o r e [ i ] = 0 ; } } public void get LR ( i n t me) { synchronized ( A l l o c a t e d [ me ] ) { i f ( s u c c e s s F i r s t T i m e (me) ) return ; // checks condition only, // no blocking in critical section else while ( r e q u e s t i n g [ me ] ) { try { A l l o c a t e d [ me ] . w a i t ( ) ; } catch ( I n t e r r u p t e d E x c e p t i o n e ) {} // when Allocated[me].notiﬁed will be posted, // requesting[me] will be false } } } p r i v a te synchronized boolean s u c c e s s F i r s t T i m e ( i n t me) { // successFirstTime is true when both sticks are granted; // there is no blocking when it is false; // score and requesting provide more about philosopher state s c o r e [ me ] = 0 ; r e q u e s t i n g [ me ] = true ; i f ( a v a i l a b l e [ me ] && a v a i l a b l e [ ( me + 1 )% N] ) { s c o r e [ me ] = 2 ; r e q u e s t i n g [ me ] = f a l s e ; a v a i l a b l e [ me ] = f a l s e ; a v a i l a b l e [ ( me + 1 )% N ] = f a l s e } e l s e i f ( a v a i l a b l e [ me ] ) { s c o r e [ me ] = 1 ; a v a i l a b l e [ me ] = f a l s e ; } return ( s c o r e [ me ] == 2 ) ; }

}

;

public synchronized void r e l e a s e ( i n t me) { a v a i l a b l e [ me ] = true ; a v a i l a b l e [ ( me + 1 )% N ] = true ; s c o r e [ me ] = 0 ; // now waiting neighbours are served preferentially during // this synchronized (critical) section i f ( r e q u e s t i n g [ ( N + me − 1 )% N ] && s c o r e [ ( N + me − 1 )% N] == 1 ) { // the left neighbour has already its left stick and waits for // its right stick since its score is one a v a i l a b l e [ me ] = f a l s e ; s c o r e [ ( N + me − 1 )% N ] = 2 ; r e q u e s t i n g [ ( N + me − 1 )% N ] = f a l s e ; synchronized ( A l l o c a t e d [ ( N + me − 1 )% N ] ) { A l l o c a t e d [ ( N + me − 1 )% N ] . n o t i f y ( ) ; } } i f ( r e q u e s t i n g [ ( me +1)% N ] ) { // the right neighbour is waiting for its ﬁrst stick and its // right stick is allocated also if it is available a v a i l a b l e [ ( me + 1 )% N ] = f a l s e ; s c o r e [ ( me + 1 )% N ] = 1 ; i f ( a v a i l a b l e [ ( me + 2 )% N ] ) { a v a i l a b l e [ ( me + 2 )% N ] = f a l s e ; s c o r e [ ( me + 1 )% N] = 2 ; r e q u e s t i n g [ ( me + 1 )% N ] = f a l s e ; synchronized ( A l l o c a t e d [ ( me + 1 )% N ] ) A l l o c a t e d [ ( me + 1 )% N ] . n o t i f y ( ) ; } } }

Program 4. Chop Java implementation using notiﬁcation objects

Weak Fairness Semantic Drawbacks in Java Multithreading

99

This code is abstruse and is not easy to generalize since a very simple change may introduce deadlock. This occurs if get LR() code is modiﬁed for avoiding embedded critical sections, and hence starts calling successFirstTime() before

import j a v a . u t i l . c o n c u r r e n t . l o c k s . C o n d i t i o n ; import j a v a . u t i l . c o n c u r r e n t . l o c k s . Lock ; import j a v a . u t i l . c o n c u r r e n t . l o c k s . Re e n t r a n t L o c k ; public f i n a l c l a s s p r i v a te i n t N ; p r i v a te boolean f i n a l Lock l o c k f i n a l Condition f i n a l Condition

Chop { p r i v a te boolean a v a i l a b l e [ bookedRight [ ] ; = new Re e n t r a n t L o c k ( ) ; LeftAllocated [ ] ; RightAllocated [ ] ;

]

;

Chop ( i n t N) { t h i s .N = N ; t h i s . a v a i l a b l e [ ] = new boolean [ N] ; t h i s . b o o k e d Ri g h t [ ] = new boolean [ N ] ; L e f t A l l o c a t e d = new C o n d i t i o n [N ] ; R i g h t A l l o c a t e d = new C o n d i t i o n [ N ] ; f o r ( i n t i =0 ; i < N ; i ++) { a v a i l a b l e [ i ] = true ; b o o k e d R i g h t [ i ] = f a l s e ; L e f t A l l o c a t e d [ i ] = l o c k . n e wCo n d i t i o n ( ) ; R i g h t A l l o c a t e d [ i ] = l o c k . n e wCo n d i t i o n ( ) ; } } public void get LR ( i n t me) throws I n t e r r u p t e d E x c e p t i o n { lock . lock () ; // mutual exclusion entrance try { while ( ! a v a i l a b l e [ me ] | | b o o k e d R i g h t [ me ] ) { L e f t A l l o c a t e d [ me ] . a w a i t ( ) ; } a v a i l a b l e [ me ] = f a l s e ; // left stick allocated b o o k e d R i g h t [ ( me + 1 )% N] = true ; // right stick booked

}

}

// don’t release mutual exclusion lock and immediately requests second stick while ( ! a v a i l a b l e [ ( me + 1 )% N ] ) R i g h t A l l o c a t e d [ me + 1 )% N ] . a w a i t ( ) ; a v a i l a b l e [ ( me + 1 )% N ] = f a l s e ; // both sticks allocated now b o o k e d R i g h t [ ( me + 1 )% N] = f a l s e ; // no more reason for booking // right stick } finally { l oc k . unlock ( ) ; // mutual exclusion leave }

public synchronized void r e l e a s e ( i n t me) throws InterruptedException { lock . lock () ; // mutual exclusion entrance a v a i l a b l e [ me ] = true ; a v a i l a b l e [ ( me + 1 )% N ] = true ; // waiting neighbours are served preferentially i f ( b o o k e d Ri g h t [ me ] ) R i g h t A l l o c a t e d [ ( me + N − 1 )% N ] . s i g n a l ( ) ; // booked by the left neighbour L e f t A l l o c a t e d [ ( me + 1 )% N ] . s i g n a l ( ) ; // signal the right neighbour; if the right neighbour // is not waiting, the signal is lost l oc k . unlock ( ) ; // mutual exclusion leave }

Program 5. Java implementation using conditions and locks

100

C. Kaiser and J.-F. Pradat-Peyre

deﬁning a critical section only when it returns false. A two level implementation, deﬁning ﬁrst a Java class of semaphores and using it then for implementing a private semaphore schema would result in a program using a unique synchronisation mechanism, therefore much easier to understand and less error prone. 4.3

A Second Implementation Using Locking Utilities for JDK 1.5

J2SE/JDK 1.5 proposes Lock implementations that provide more extensive locking operations than can be obtained using synchronized methods and statements. These implementations support multiple associated Condition objects and provide an ad hoc solution to mitigate the absence of named conditions in the basic Java monitor. Where a Lock replaces the use of synchronized methods and statements, a Condition replaces the use of the Object monitor methods. (see http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/package-summary.html)

In Program 5, this style improvement, due to named conditions use, allows a code that is easier to understand. It needs nevertheless the addition of booked[] variables. Moreover, even with one queue per condition, signalled threads have to request the lock again, causing more context switching and additional execution complexity.

g en er i c Type I d i s mod < >; −− instanciated as mod N package Chop i s procedure Get LR (C : I d ) ; procedure R e l e a s e (C : I d ) ; end Chop ; package body Chop i s type S t i c S t a t e i s array ( I d ) o f Bo o l e a n ; protected S t i c k s i s entry Get LR ( I d ) ; −− entry family allowing a set of N waiting queues procedure R e l e a s e (C : i n I d ) ; p r i v a te entry Get R ( I d ) ; −− entry family allowing a set of N waiting queues A v a i l a b l e : S t i c S t a t e := ( others => True ) ; −− Stick availability end S t i c k s ; protected body S t i c k s i s entry Get LR ( f o r C i n I d ) when A v a i l a b l e (C) i s begin A v a i l a b l e (C) := F a l s e ; requeue Get R (C + 1 ) ; end Get LR ; −− Left stick is allocated entry Get R ( f o r C i n I d ) when A v a i l a b l e (C) i s begin A v a i l a b l e (C) := F a l s e ; end Get R ; −− stick C is allocated as a right stick procedure R e l e a s e (C : I d ) i s begin A v a i l a b l e (C) := True ; A v a i l a b l e (C + 1 ) := True ; end R e l e a s e ; end S t i c k s ; procedure Get LR (C : I d ) i s begin S t i c k s . Get LR (C) ; end Get LR ; procedure R e l e a s e (C : I d ) i s begin S t i c k s . R e l e a s e (C) ; end R e l e a s e ; end Chop ;

Program 6. Safe and fair Chop implementation in Ada

Weak Fairness Semantic Drawbacks in Java Multithreading

101

The use of Java 1.5 extensions in an operating system kernel would suﬀer other criticisms. First, the monitor schema with several named conditions has still to be built with low level tools: locks and queues. Second, allowing a mix of synchronization mechanisms (locks, conditions, semaphores) may lead to complicated code, diﬃcult to debug. Accumulating and mixing synchronization concepts, although it seems cute, is not a good engineering practice, since it usually leads to code that is hard to maintain. 4.4

A Monitor Semantics Giving Priority to Signalled Threads

The preceding laborious implementations should be compared to the elegant simplicity of the Ada protected object and entry families solution [11]. The entry family allows a set of condition queues while the requeue statement redirects the call to another condition check. This is displayed in Program 6.

5 5.1

Instrumentation and Appraisal Concurrency Complexity

The resource allocation programs have been analysed with Quasar, our veriﬁcation tool for Ada concurrent programs [7]. First, Quasar generates a coloured Petri Net model of the program, which is simpliﬁed by structural reductions, taking advantage of behavioural equivalences and factorizations. Thus the size of the Petri Net (PN places and transitions) is related to programming style. Second, Quasar performs model checking, generating a reachability graph which records all possible executions of the program. Thus the least number of elements in the graph, the least combinatorics due to concurrency in the program. The graph size (reachability nodes and arcs) is related to the execution indeterminacy. For being able to use Quasar, the Java programs have been simulated in Ada, reproducing the Java monitor semantics. This Ada transcription of the Java concurrency policy has been presented in [8]. It allows checking the weak fairness semantic when strong fairness is the underlying rule. Table 1 records the diﬀerent concurrent implementations whose complexity have been thus measured: a. b. c. d. e. f. g. h. i.

Unsafe Java with Java semantics simulated in Ada (Program 2.), Reliable Java with Java semantics simulated in Ada (see Section 3.4.), Reliable and fair Java with Java semantics simulated in Ada (Program 3.), Reliable and fair Ada with a single waiting queue (see Section 3.5.), Notiﬁcation objects with Java semantics simulated in Ada (Program 4.), Conditions and Lock with Java semantics simulated in Ada (Program 5.), Conditions queues and requeue with Ada semantics (Program 6.), Global allocation given as a useful benchmark (although not a fair solution), Dummy protected object providing a concurrent program skeleton.

These data allow comparing the diﬀerent implementations of an algorithm. Comparing the sizes of the Petri nets provides insight on implementation simplicity and readability. The Petri net of the Java reliable and fair solution (Program 3), which is the smallest net of Java correct implementations, is one and half larger

102

C. Kaiser and J.-F. Pradat-Peyre Table 1. Complexity measures given by Quasar

Program

Coloured PN Coloured PN Chop part of Reachability

Reachability

#places

a Unsafe Java 127 b Reliable Java 136 c Fair Java 147 d Ada single 129 e Notiﬁcation 170 f Conditions 158 g Ada families 96 h Global Java 116 i Skeleton 60

#trans

places & trans #nodes

#arcs

103 111 124 111 148 132 75 89 42

67 & 61 76 & 69 87 & 82 69 & 69 110 & 106 98 & 90 36 & 33 56 & 47 0& 0

42 193 39 558 148 968 118 676 186 708 958 931 4 244 5 073 22

39 620 37445 141 465 107 487 180 585 920 924 3 860 4 745 22

than the net generated for the Ada families implementation (Program 6). Comparing the sizes of the reachability graph allows comparing the indeterminacy of the diﬀerent implementations. The smallest graph generated for a correct Java implementation (Program 3) is 35 times larger than the graph of the Ada families implementation (Program 6). This is partly the cost of using a weak fairness semantic and partly the result of the skilful design of the Ada protected object. 5.2

Concurrency Eﬀectiveness

The diﬀerent Java implementations of the dining philosophers have been simulated in order to measure the number of times philosophers eat jointly, i.e. the eﬀective concurrency. The instrumentation analyses also why a stick allocation is denied, whether it is structural, i.e., because one of the neighbours is already eating, or it is cautious, i.e. for preventing deadlock or starvation. The implementations have been instrumented to program explicitly the guards evaluation and to record the denial events. Table 2 records the data collected after runs of 100 000 requests performed by a set of ﬁve philosophers. They think and eat during a random duration, uniformly distributed between 0 and 10 milliseconds. The data collected are: NbPairs :

ratio of times a philosopher starts eating while another is already eating, ratio of times a philosopher starts eating alone, NbStructuralRefusals : number of denials due to a neighbour already eating, NbCautiousRefusals : number of denials due to deadlock or starvation prevention, Simulation time : duration of the simulation run, Allocation time : mean allocation time for a philosopher during the simulation, Allocation ratio : ratio of time used allocating the chopsticks. NbRequestSingletons :

NbPairs, the ratio of times a philosopher starts eating while another is already eating, gives an idea of execution concurrency. The number of refusals gives an idea of the additional complexity due to condition testing dynamically.

Weak Fairness Semantic Drawbacks in Java Multithreading

103

Table 2. Concurrency eﬀectiveness given by simulations Program

NbPairs

NbRequest

NbStructural NbCautious Simulation

Allocation

Allocation

Singletons

Refusals

Refusals

time(s)

time (s)

ratio

40 %

60 %

10 630

88 385

430

217

51 %

36 % 43% e Notifications 40 % f Conditions 40 % g Ada families 42 % h Global Java 84%

64% 57% 60% 60 % 58 % 16 %

103 130 100 010 31 940 45 109 45 318 69 240

92 903 86 433 41 761 28 019 28 773 0

527 512 550 437 500 442

284 249 287 218 245 159

54 % 49% 52% 50% 45 % 36%

100 000 requests b Reliable Java c Fair Java

d Ada single

5.3

Concurrency Appraisal

These simulations show that all the diﬀerent implementations of our new solution of the dining philosophers paradigm are close in eﬀective concurrency. With the same simulation parameters, the global allocation solution doubles the number of times two philosophers eat jointly (however this solution, which is used as a benchmark for concurrency, allows starvation). The implementations with a unique condition queue and thus with dynamic re-evaluation of requests are very comparable in style, indeterminacy and number of condition denials. The solutions with several named conditions have much less refusals. The Ada family solution shows the best style measure and the least indeterminacy. The analysed programs and the data collected are available on Quasar page at: http://quasar.cnam.fr/ﬁles/concurrency papers.html

6

Java Concurrency Must be Handled with Care

Concurrent programming is diﬃcult and Java multithreading may reveal some misleading surprises, due to its weak fairness semantic. Using basic Java for concurrent programming implementation is a risky challenge since one cannot venture to ignore whether a concurrency paradigm remains correct or not when running in a weak fairness context. If an algorithm is fairness sensitive, a usually correct algorithm may fail and it must be reconsidered; some defence against weakness must be programmed. This additional coding is rarely obvious. Adopting rather a strong fairness policy could reduce this risk and it could be a good choice for a future Java revision. Note that programs running safely with the current Java monitor implementation would remain safe. This is upwards compatibility. “Who who can do more can do less”. Then the shielding code would become superﬂuous. More generally, our former experience in developing operating systems and real-time applications [2] and also our long experience in teaching concurrency [1], allows us to assert that the acquaintance with several

104

C. Kaiser and J.-F. Pradat-Peyre

styles of concurrent programming is helpful for choosing the best concurrency skill of each language or mechanism and then designing better Java (or C#) solutions. Better means for us simpler, safer and also more robust when well disposed, but not always fortunate, slight variations are programmed in wellknown paradigms.

References 1. Accov master class lecture notes, http://deptinfo.cnam.fr/Enseignement/CycleSpecialisation/ACCOV/ 2. B´etourn´e, C., Ferri´e, J., Kaiser, C., Krakowiak, S., Mossi`ere, J.: System design and implementation using parallel processes. In: IFIP Congress, vol. (1), pp. 345–352 (1971) 3. Brosgol, B.M.: A comparison of the concurrency features of ada 95 and java. In: SIGAda, pp. 175–192 (1998) 4. Buhr, P.A., Fortier, M., Coﬃn, M.H.: Monitor classiﬁcation. ACM Comput. Surv. 27(1), 63–107 (1995) 5. Dijkstra, E.W.: The structure of ”THE”-multiprogramming system. Commun. ACM 11(5), 341–346 (1968) 6. Dijkstra, E.W.: Hierarchical ordering of sequential processes. In: Acta Informatica, vol. (1), pp. 115–138 (1971) 7. Evangelista, S., Kaiser, C., Pradat-Peyre, J.-F., Rousseau, P.: Quasar: a new tool for analyzing concurrent programs. In: Rosen, J.-P., Strohmeier, A. (eds.) AdaEurope 2003. LNCS, vol. 2655, pp. 166–181. Springer, Heidelberg (2003) 8. Evangelista, S., Kaiser, C., Pradat-Peyre, J.-F., Rousseau, P.: Comparing Java, C# and Ada monitors queuing policies: a case study and its Ada reﬁnement. Ada Letters XXVI(2), 23–37 (2006) 9. Hartley, S.J.: Concurrent programming: the Java programming language. Oxford University Press, Inc., New York (1998) 10. Hoare, C.A.R.: Monitors: an operating system structuring concept. Commun. ACM 17(10), 549–557 (1974) 11. Kaiser, C., Pradat-Peyre, J.F.: Comparing the reliability provided by tasks or protected objects for implementing a resource allocation service: a case study. In: TriAda, St. Louis, Missouri. ACM SIGAda (November 1997) 12. Kaiser, C., Pradat-Peyre, J.F.: Chameneos, a concurrency game for Java, Ada and others. In: Int. Conf. ACS/IEEE AICCSA 2003 (2003) 13. Lampson, B.W., Redell, D.D.: Experience with processes and monitors in mesa. Commun. ACM 23(2), 105–117 (1980) 14. Lea, D.: Concurrent Programming in Java. Design Principles and Patterns, 2nd edn. Addison-Wesley, Reading (1999) 15. Potratz, E.: A practical comparison between java and ada in implementing a realtime embedded system. In: Leif, R.C., Sward, R.E. (eds.) SIGAda, pp. 71–83. ACM, New York (2003) 16. Tucker Taft, S., Duﬀ, R.A., Brukardt, R., Pl¨ odereder, E., Leroy, P.: Ada 2005 Reference Manual. LNCS, vol. 4348. Springer, Heidelberg (2006)

Implementation of the Ada 2005 Task Dispatching Model in MaRTE OS and GNAT Mario Aldea Rivas1, Michael González Harbour1, and José F. Ruiz2 1

Grupo de Computadores y Tiempo Real, Universidad de Cantabria, 39005-Santander, SPAIN {aldeam,mgh}@unican.es 2 AdaCore, 46 rue d’Amsterdam, 75009 Paris, FRANCE [email protected]

Abstract. The Ada 2005 task dispatching model includes new scheduling policies such as EDF and round robin, in addition to the traditional fixed priority dispatching, and allows mixing these policies into a hierarchy of schedulers. This hierarchical scheduling model is a very interesting solution that allows us to have in the same system the best properties of the three policies: the high performance of EDF, the predictability of fixed priorities, and the fair distribution of unused capacity provided by a round robin scheduler. The paper presents one of the first implementations of this hierarchical dispatching model, built with GNAT over MaRTE OS. An evaluation of the implementation is provided and examples of usage are shown. Keywords: Ada 2005, Real-Time Systems, Scheduling, Compilers, POSIX.

1 Introduction Since the introduction of the utilization tests for the fixed priority and EDF scheduling policies in the seminal paper by Liu and Layland [1], much research work has focused on extending the capabilities of these policies and their corresponding analysis techniques to address the requirements of real-time applications. An interesting immediate result from Liu and Layland's paper is the comparison of the performance of both scheduling policies. EDF has better performance since, under specific constraints, it is possible to achieve 100% of the processor utilization, while with fixed priorities, under the same constraints, just around 70% of the utilization is guaranteed to be achieved. Despite the better performance of EDF, most commercial implementations of runtime scheduling policies use the fixed-priority approach, because of its simpler implementation, simpler analysis techniques and higher predictability. It is well known that in many hardware architectures predicting worst-case execution times is a difficult task that has high costs and leads to very pessimistic results [2]. For this reason in most systems except those that are safety critical, WCET estimations are made via measurement and/or probabilistic approaches [3][4], or different techniques are used depending on the criticality level of a particular task [5]. F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 105–118, 2009. © Springer-Verlag Berlin Heidelberg 2009

106

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz

In such systems it is possible that WCETs are underestimated, for instance for tasks of lesser importance, leading to potential situations of transient overload. In EDF and other dynamic priority policies this overload introduces a large degree of unpredictability, because virtually any of the tasks in the system may miss their deadlines, not necessarily the one that suffered an overrun. Fixed priority scheduling is much more benevolent to overload situations because there is guarantee that the higher priority tasks will receive the computing resources before lower priority tasks. Critical tasks can be assured to receive the required resources by having their priorities higher than those of the tasks that are less important [8]. Summarizing these properties of scheduling policies we find that EDF makes better usage of system resources, while fixed priorities offer more predictability in case of transient overloads. A good way to get the best of both worlds is to mix these scheduling policies in the same system, using a hierarchical approach [7][8]. This is the task dispatching model specified in the Ada 2005 standard. A first level of scheduling is based on fixed priorities. Some priorities or bands within the whole priority range have a secondary scheduler which can be based on EDF. In this way the critical tasks of the application, which typically require just a small fraction of the processing resources, may be scheduled at the higher priority levels, and we can leave the rest of the tasks with a lower criticality level to be scheduled at a lower priority with their own EDF scheduler. Usually these tasks make intensive use of processing resources and therefore get a high benefit of using EDF as opposed to regular fixed priorities. When there are more criticality levels it is possible to extend this approach 3ULRULW\ &ULWLFDOLW\ 6FKHGXOHUWDVNLG providing several EDF schedulers at /HYHO /HYHO different priority bands. Figure 1 shows a possible approach with two high pri )3 9HU\KLJK ority, highly critical tasks scheduled )3 +LJK with fixed priorities (FP), three EDF tasks sharing an intermediate criticality (') (') (') 0HGLXP level, and three more tasks with another EDF scheduler at a low criticality level. (') (') (') /RZ In addition two tasks with no real-time or criticality requirements are placed at 55 55 1RQFULWLFDO the lowest priority of the system, sharing the available resources with a fair distribution by using a round robin Fig. 1. Hierarchical scheduling of tasks with (RR) scheduler. Since analysis techdifferent criticality levels niques for this kind of hierarchical scheduling exist [7] it is a highly recommended approach that lets us take advantage of the best properties of the fixedpriority and EDF policies. Ada 2005 defines a priority band task dispatching model with a primary fixed priority scheduler and secondary schedulers assigned to specific priority bands. Two of these schedulers are based on EDF and round robin policies, thus giving support to the recommended approach established in Figure 1. Mutual exclusion task synchronization is taken care by using Baker's protocol (SRP) [6]. In Ada, the preemption levels defined in Baker's protocol are mapped to task priorities and protected object

Implementation of the Ada 2005 Task Dispatching Model

107

priority ceilings, which leads to a requirement to use for each EDF scheduler a band of priorities that allows expressing all the different preemption levels through different priority values. One preemption level per task is the ideal approach that leads to optimum priority and preemption level assignments. For instance, in Figure 1 the first EDF scheduler would be placed at the priority band with levels {6,7,8}, and the second scheduler would have the band {3,4,5}. The implementation of the Ada 2005 priority-band task dispatching policies requires implementing support in the compiler, the run-time and the underlying operating system. In this paper we present the main elements of one of the first implementations of this scheduling paradigm, covering priority bands with both EDF and round robin schedulers. The implementation is a joint effort by AdaCore and the University of Cantabria, and uses MaRTE OS [9] as the underlying real-time operating system. MaRTE OS runs on a bare x86 machine, but is also capable of running as a linux process, which makes it an interesting test environment for applications using the Ada 2005 scheduling paradigm. The implementation presented in the paper is evaluated through performance metrics. An example is shown to illustrate the approach and show users how to make use of the different pragmas and how to configure the scheduling parameters. The implementation is available in the MaRTE OS web page [10] and is distributed under a modified GPL license. The paper is organized as follows. Section 2 describes the implementation of the new task dispatching pragmas defined in Ada 2005, both in the compiler and the runtime system. Sections 3 and 4 describe the new task dispatching policies, respectively round robin and EDF. In both policies the implementation in the compiler and the run-time is described, as well as the required support in the operating system. Section 5 contains performance metrics including the evaluation of task synchronization and context switches. Section 6 shows an example with several periodic tasks that is useful for users to see how the pragmas are applied. The example also shows the benefits of the EDF policy. Finally, Section 7 gives our conclusions.

2 Implementation of Task Dispatching Pragmas Ada 2005 provides two different means to statically define task scheduling policies: you can either use a single (global) task dispatching policy for all priorities, or you can split priorities into subranges that are assigned individual (local) dispatching policies. One of the tasks that the compiler needs to perform is to check the consistency of the dispatching policies in the partition by first ensuring that both mechanisms (global and local) are not used in the same partition, and second that priority ranges specified in more than one Priority_Specific_Dispatching pragma do not overlap across the partition. In the first step of this consistency check, the GNAT compiler analyses the different dispatching policies specified. This information is encoded, for each compilation unit, in the corresponding Ada Library Information (ALI) file in the form of a set of triples, each containing the identifier of the dispatching policy, and the lower and upper bounds that define the priority range. During this compilation phase, the compiler can already detect inconsistent priority ranges within the compilation units. There is

108

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz

also a check to ensure that the specified priority ranges are not outside the priority range for the target. The second step of the consistency check is done during the so-called binding phase, and consists of ensuring partition-wide coherence. The dispatching policy information for each compilation unit included in the partition is extracted from the different ALI files, and the binder makes sure that there is no overlapping. Once we have all the dispatching policy information for the whole partition, and we have verified that it is consistent, the GNAT binder generates a string that encodes the dispatching policies for the different priorities. This string is then made available to the GNAT run time, so that the different tasks can be assigned the desired dispatching policies. When the tasks are actually created by the run time, there is a parameter that specifies the dispatching policy, which is then passed to the underlying operating system or kernel. At execution time, tasks are created by task activators using the available runtime services. When executing on top of MaRTE OS, the run time asks MaRTE to create the tasks with the required scheduling parameters and policy, and before the task starts its execution, the task activator sets the priority of the task that is being created to the required value, therefore setting the dispatching policy that corresponds to the selected priority. The dispatching policy to be applied to a task is determined by its base and active priorities (Ada Reference Manual D.2.2 (3.4/2) and D.2.2 (6.3/2)). Consequently the run time has to take care of the possible policy changes due to the dynamic modification of both priority values. The base priority can be changed using the functionality provided by package Ada.Dynamic_Priorities, while the active priority can change due to the inheritance of priorities. The Ada Reference Manual (RM) identifies three sources of priority inheritance: task's activation, rendezvous and protected actions (RM D.1 21/1, 22/1 and 23). The change of base priority and the priority inheritance due to activation and rendezvous are all handled in the run time by invoking the same internal procedure. That procedure changes the base priority and the policy of the underlying operating system thread associated to the Ada task. It uses the string created by the binder to identify the policy associated with the new priority. In the case of execution of a protected action, the GNAT run time does not change the scheduling parameters of the underlying thread because it completely relies on the ceiling protocol implemented by the operating system. It will be shown in the following sections that our implementation also fulfils the Ada dispatching rules in this case.

3 Round Robin Dispatching Policy 3.1 Description The round robin policy allows tasks at the same priority level to share the CPU time among them. Each task can execute for at most a time interval called “quantum”. Whenever a task has exhausted its quantum it is moved to the tail of the ready queue for its priority level and its quantum is recharged again. This policy is typically used

Implementation of the Ada 2005 Task Dispatching Model

109

at a background priority level, in order to share any spare time that is left over by the real-time part of the application. It is a quite extensively used policy that is implemented in many real time operating systems. The POSIX.13 standard real-time profiles include SCHED_RR as one of its required scheduling policies, with a behaviour similar to Ada’s Round_Robin_Within_Priorities. In Ada this policy can be applied to the whole partition using: pragma Task_Dispatching_Policy (Round_Robin_Within_Priorities);

or to a specific range of priorities using: pragma Priority_Specific_Dispatching (Round_Robin_Within_Priorities, First_Prio, Last_Prio);

Our implementation of the round robin dispatching policy is based on the POSIX round robin policy (SCHED_RR) provided by MaRTE OS. Round robin Ada tasks are directly mapped to MaRTE OS threads with the SCHED_RR POSIX scheduling policy. 3.2 Implementation in the Run-Time and Compiler The underlying round robin operating system policy takes care of the basic behavior of the round robin tasks: the quantum expiration. However there are some other aspects specific of the Ada definition of the policy that can not be delegated to the operating system and have to be imposed by the run time system itself. Those aspects are related to the following rule in the Ada Reference Manual (RM): “When a task has exhausted its budget and is without an inherited priority (and is not executing within a protected operation), it is moved to the tail of the ready queue for its priority level” (RM D.2.5 14/2). Consequently, no requeuing by a quantum expiration should happen for a round robin task while it is inheriting a priority (via activation, rendezvous, or the execution of a protected action). In order to avoid the requeuing effect for the first two sources of priority inheritance (activation and rendezvous) we have decided to implement in MaRTE OS a pair of functions to temporarily disable the expiration of the quantum: marte_disable_rr_quantum() and marte_enable_rr_quantum(). During activation, the activator task calls marte_disable_rr_quantum() for the activated task, and later the activated task calls marte_enable_rr_quantum() for itself once its activation has finished and it has its definitive priority. In the case of a rendezvous, the caller task invokes marte_disable_rr_quantum() for the acceptor task before raising its priority (if necessary) and releasing it. When the rendezvous finishes the acceptor task resets its priority to the original value and invokes marte_enable_rr_quantum() for itself. The third source of priority inheritance, protected actions, is solved by the operating system as described in the following subsection. 3.3 Support at the Operating System Level In the GNAT run time system protected objects are implemented on top of POSIX mutexes so, while the task is executing a protected operation it is holding a mutex.

110

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz

Unfortunately POSIX does not impose any restriction on the moment a round robin thread can be moved to the tail of its ready queue as a consequence of having exhausted its budget. In particular the standard allows the operating system to requeue a thread while it is holding one or more mutexes. It is important to emphasize the fact the POSIX standard does not forbid the restriction, but it does not impose it. As a consequence, POSIX operating systems can choose to follow it or not. For example MaRTE OS implements the restriction while Linux does not. As a consequence, the Ada round robin policy can not be directly implemented on top of the SCHED_RR Linux policy. Originally MaRTE OS behaved like Linux but we have modified that behaviour in order to fulfil the RM rules. Modification has been very simple only requiring to add a new flag to the thread control block and two extra checks. Currently in MaRTE OS when a round robin thread exhausts its quantum while holding a mutex the flag is set and the thread is not requeued (although a new quantum interval is started for it). Every time a thread unlocks a mutex a check is made to find out if the flag is set and there are no remaining mutexes owned by the thread; if that is the case, the thread is requeued as if a quantum expiration had occurred and the flag is reset. With the described operating system behaviour no requeueing by a quantum expiration can occur while a task is executing a protected operation. This behaviour is also appropriate for a situation in which a round robin task uses a protected object whose ceiling is out of the round robin priority band. In that situation the policy of the task should change. As exposed in Section 2, the GNAT run time just relies on the ceiling protocol implemented by the operating system to change the active priority of the underlying thread, but in this case no change is necessary because the quantum expiration will not have any effect while the task is holding the mutex. Another issue that could be seen as problematic is the possibility of changing the quantum value. Ada defines the operation Ada.Dispatching.Round_Robin.Set_Quantum that allows setting the quantum for a priority level or a range of levels. On the other hand, in POSIX all the priority levels share the same quantum value that is chosen by the operating system and can not be changed. The possible contradiction is avoided by the RM rules: “An implementation shall document the quantum values supported” (RM D.2.5 16/2) and “Due to implementation constraints, the quantum value returned by Actual_Quantum might not be identical to that set with Set_Quantum” (RM D.2.5 18/2). These rules make both standards compatible.

4 Earliest Deadline First Dispatching Policy 4.1 Description The EDF policy is probably the most popular among the policies based on dynamic priorities. It allows better usage of the available processing resources than the FIFO_Within_Priorities policy. Under some conditions, EDF is an optimal algorithm for single processor systems [1]. Two new task scheduling parameters appear with this policy: the deadline and the preemption level. The (absolute) deadline of a task is the point in time before which

Implementation of the Ada 2005 Task Dispatching Model

111

the current activation of the task should have finished. In absence of interaction between tasks, the one with the earliest deadline is always chosen for execution. In Ada, the deadline can be set using the new pragma Relative_Deadline and using the operations provided in package Ada.Dispatching.EDF. The second new parameter, the preemption level, is related to the use of protected objects and Baker's protocol [6]. Baker's protocol for EDF is the equivalent to Ceiling_Locking for the FIFO_Within_Priorities policy. It also presents the good properties (on a single processor) of the Ceiling_Locking protocol: mutual exclusion ensured by the protocol itself, deadlock avoidance, and at most a single blocking effect from any task with a longer deadline. Both tasks and protected objects have an associated preemption level value. Preemption levels of tasks should be assigned inversely proportional to their relative deadlines in order to preserve the properties of the protocol. The preemption level of a protected object should be the maximum of the preemption levels of the tasks that call it. To minimize the changes to the language, Ada 2005 reuses pragma Priority to assign preemption levels to task and protected objects. The EDF policy can be applied to the whole partition using: pragma Task_Dispatching_Policy (EDF_Across_Priorities);

or to a specific range of priorities using: pragma Priority_Specific_Dispatching (EDF_Across_Priorities, First_Prio, Last_Prio);

The EDF policy is implemented in some real-time operating systems but is not included in the POSIX standard. Anyway, POSIX allows the implementation to define new scheduling policies in addition to those defined in the standard (SCHED_FIFO, SCHED_RR, SCHED_SPORADIC, and SCHED_OTHER). Consequently, we have decided to support the EDF scheduling policy in our operating system as a new implementation-defined POSIX policy (SCHED_EDF). This approach has the advantage of facilitating the integration in the GNAT run-time system, which is designed to use the POSIX interfaces. 4.2 Implementation in the Run-Time and the Compiler When the GNAT compiler processes a pragma Relative_Deadline, it sets an additional field in the internal task descriptor, which will be made available later to the run time. The expression in the task descriptor captures the argument that was present in the pragma, and is used to provide the Relative_Deadline parameter to the runtime call to create tasks. This makes it possible to inherit the Relative_Deadline variable when deriving task types as well. The compiler implements a consistency check that verifies that the pragma applies either to a task definition or to a subprogram, and in the case of a subprogram it makes sure that this is the main program (environment task). When a pragma Relative_Deadline applies to the main subprogram, and therefore to the environment task in charge of library-level elaboration (RM 10.2(8)), the value of the relative deadline cannot be passed as a static value to the run time because expressions in that pragma can only be evaluated after elaboration. Note that for Priority pragmas applied to the main subprogram, RM D.1(8) already incorporates this limitation, saying that the expression in the pragma must be static. However,

112

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz

expressions in Relative_Deadline pragmas can never be static because the Time_Span type is private, so the only option is to defer the effect of the deadline until the beginning of the sequence of statements of the environment task. Consequently, the environment task will initially have the Default_Deadline, and will continue to have this deadline during the library-level elaboration. Then, when the main subprogram is called, the pragma is evaluated and the deadline of the environment task is changed via a direct call to the corresponding run time procedure (Set_Deadline). 4.3 Support at Operating System Level Implementing an EDF scheduler in a pure fixed-priority operating system can be a really tough task. In MaRTE OS it has been much easier because the infrastructure required to support dynamic-priority scheduling policies was already implemented in order to support the application-defined scheduling interface [11]. The application-defined scheduling framework existing in MaRTE OS is based on Baker's protocol and an abstract notion of “urgency”. In the system's ready queue threads of equal priority are ordered by urgency and preemption level: a new ready thread is placed in its priority queue behind all the other threads with higher value of urgency or with an inherited preemption level higher or equal than the preemption level of the newcomer thread. Preemption levels are inherited in the same way priority ceilings are inherited with the priority protection protocol: while a thread is holding a mutex it inherits its preemption level ceiling. Our implementation of Ada EDF dispatching on top of the MaRTE EDF policy maps the priorities of tasks and protected objects into the preemption levels of the underlying operating system's objects (threads and mutexes), and uses as priority of these objects the lowest value in the EDF priority range. Besides, MaRTE OS assigns to each EDF thread an urgency value inversely proportional to the absolute deadline of the Ada task it maps (non-EDF threads have an urgency of zero). Recently, a problem with the definition of the EDF dispatching policy was discovered in the Ada RM [12], and later corrected via a language interpretation. Our implementation does not suffer from this problem thanks to the ordering of the ready queue based on the urgency (deadline) and the inherited preemption level described above. Another issue to be considered is the change of policy that occurs when, as a consequence of a priority inheritance, a task moves between EDF and non EDF priority ranges. To be compatible with the Ada dispatching rules MaRTE OS sets the urgency of the thread to zero after a policy change. In this way the FIFO ordering among nonEDF threads is observed. Only in the case the new policy is SCHED_EDF and the deadline has been previously assigned, a value of urgency according to that deadline is set for the thread. This behaviour is coherent with the Ada RM that defines Ada.Real_Time.Time_Last as the default deadline and allows using Ada.EDF.Set_Deadline for tasks that are not subject to EDF dispatching. As in the case of the round robin policy, priority inheritance due to a protected operation that causes a change of policy has to be checked carefully because in this case the run time does not change the policy explicitly. As happened in the round robin policy in this case the behaviour is coherent with the Ada rules, since, although an EDF thread will keep its urgency when moved to a different ready queue, the FIFO order will be observed since the new ready queue will be empty when the thread locks the mutex.

Implementation of the Ada 2005 Task Dispatching Model

113

The last issue about the support for EDF in MaRTE OS is related to the Ada.Dispatching.EDF.Delay_Until_and_Set_Deadline procedure. This pro-

cedure was included by the Ada standard to improve efficiency by avoiding the spurious activation of the task that could happen if the deadline change and the suspension were not performed atomically. For periodic EDF tasks, the common behaviour is that at the end of each job the task suspends itself until the next period. The deadline for the next wake up will be the current deadline augmented in its period. If both operations (suspension and deadline change) are not preformed atomically, as soon as the task changes its deadline into the future it could be preempted by a more urgent task, eventually the preempted task would execute again, but only to suspend itself immediately. Is easy to see that this extra activation can also happen if suspension is preformed before changing deadline. We have opted for a general solution: to implement an operating system function that allows setting the deadline that the thread will have the next time it becomes runnable. This deferred-deadline-set function can be used together with any POSIX suspension function to achieve the desired atomicity between the suspension and the deadline change. In particular it can be used with pthread_cond_timedwait(), which is the function the GNAT run time uses to perform task suspension with a delay until operation.

5 Performance Metrics The implementation of the Ada 2005 priority-specific task dispatching model described above has been tested to evaluate its performance, in comparison with the regular FIFO_Within_Priorities scheduling policy. Measurements have been made on an industrial computer using a Pentium III processor running at 800 MHz. Table 1 summarizes the different metrics obtained. Each value is the worst observed case. Table 1. Performance metrics on a Pentium III at 800 MHz

Description

Fixed priorities

EDF

1. Protected operation with ceiling above base priority

1.67 μs

1.67 μs

2. Task entry call with mixed EDF and Fixed Priority policies

6.80 μs

3.40 μs

3. Task entry call with only fixed priorities

9.00 μs

4. Context switch time with delay until, from task that suspends itself to a lower priority (or longer deadline) task

8.00 μs

9.20 μs

5. Context switch time with delay until, from running task task to higher priority (or shorter deadline) task that gets active

5.90 μs

6.80 μs

6. Context switch time caused by end of time slice

Round Robin

10 μs

114

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz

The first three experiments try to measure synchronization overhead. In the first experiment we measure the execution time of a call to a protected operation with a null body. The protected object has a ceiling that is above the base priority of the task, and therefore a double change to a higher priority and back is necessary as a consequence of locking the internal mutex associated with the protected object. We can see that there is no difference between the overheads for fixed priorities or EDF. The second and third experiments consist of calling an entry of a low priority task from a high priority task, with both tasks set at priority levels with the same policy. The entry has a null body. In experiment number 2 there are EDF and fixed priority bands, and we test two cases, with EDF or fixed priority tasks. In experiment 3 there is no EDF band. The next three experiments try to evaluate the overheads of context switches under different conditions. Experiment number 4 has the running task suspend itself by executing delay until (or calling Delay_Until_And_Set_Deadline in the case of EDF). The interval measured is from before the call to the delay until operation, to the first instruction executed by the new task after the context switch. Experiment number 5 has a high priority task that wakes up from a delay until operation preempting the running task and thus causing a context switch that includes executing the OS timer interrupt. For EDF tasks the operation used was Delay_Until_And_Set_Deadline. The time is measured from the last instruction executed by the preempted task, to the first instruction executed by the new running task. Experiment number 6 measures the context switch caused by the consumption of the round robin time slice. It is measured from the last instruction of the preempted task, to the first instruction of a new round robin task. In general we can see that the overheads for EDF tasks are comparable to those of fixed priority tasks, and are even smaller in some cases. The overhead of the round robin scheduler is a bit higher than for EDF or fixed priorities, mainly because of the need to handle a timer interrupt and set up execution time timers, but the numbers are relatively similar.

6 Usage Example This section describes an example of using the Ada 2005 priority-specific task dispatching model, with the purpose of showing how the different scheduling policies can be used, how the scheduling parameters are specified, and how it is possible to achieve better performance by using EDF, in a real experiment. The example is similar in structure to the system shown in Figure 1, except that it has fewer tasks, to make it simpler. It has one high priority periodic task (FP), two periodic EDF tasks (EDF 1 and 2) at an intermediate priority level, and two round robin (RR 1 and 2) tasks at the lowest priority level. The code presented here just has one task of each of the policies, because the others are similar. Table 2 shows the task parameters.

Implementation of the Ada 2005 Task Dispatching Model

115

Table 2. Parameters of the tasks in the example 3DUDPHWHU

)3

(')

(')

55

55

3ULRULW\

3HULRG

PV

PV

PV

'HDGOLQH

PV

PV

PV

0D[LPXPH[HFXWLRQWLPH

PV

PV

PV

The code executed by each task consists of a synthetic workload with adjustable execution time. The round robin tasks execute for a very long time. The fixed priority task has fixed utilization. The execution time of the EDF tasks is increased until one or more of the task deadlines are missed. The maximum execution time achieved in the experiment is shown in Table 2, and corresponds to the maximum theoretical utilization of 100%. If the same experiment is run with the two intermediate tasks running under fixed priorities with deadline monotonic optimum priorities, the maximum utilization achieved is only 86.7%. As we see, EDF allows us to make effective use of the available processing resources. pragma Priority_Specific_Dispatching (EDF_Across_Priorities, 10, 25); pragma Priority_Specific_Dispatching (Round_Robin_Within_Priorities, 9, 9); with Ada.Dispatching.EDF; with Ada.Dispatching.Round_Robin; with Ada.Real_Time; procedure Example_3_Policies is package EDF renames Ada.Dispatching.EDF; package RR renames Ada.Dispatching.Round_Robin; package RT renames Ada.Real_Time; use type RT.Time; ------------------------------- Global configurable data ------------------------------FIFO_Prio : constant := 26; FIFO_Period : constant := 0.01; EDF_Prio : constant := 10; EDF_Period : constant := 0.02; EDF_Relative_Deadline : constant RT.Time_Span := RT.To_Time_Span (0.02); RR_Prio : constant := 9; RR_Quantum : constant RT.Time_Span := RT.To_Time_Span (0.02);

116

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz ---------------- FIFO task ---------------task FIFO_Task is pragma Priority (FIFO_Prio); end FIFO_Task; task body FIFO_Task is Next_Activation : RT.Time := RT.Clock; Period : constant RT.Time_Span := RT.To_Time_Span (FIFO_Period); begin loop -- Do useful work ...; -- Wait for next period Next_Activation := Next_Activation + Period; delay until Next_Activation; end loop; end FIFO_Task; --------------- EDF_Task --------------task EDF_Task is pragma Priority (EDF_Prio); pragma Relative_Deadline (EDF_Relative_Deadline); end EDF_Task; task body EDF_Task is Next_Activation : RT.Time := RT.Clock; begin loop -- Do useful work ...; -- wait for next period Next_Activation := Next_Activation + EDF_Period; EDF.Delay_Until_And_Set_Deadline (Delay_Until_Time => Next_Activation, Deadline_Offset => EDF_Relative_Deadline); end loop; end EDF_Task; -------------- RR task -------------task RR_Task is pragma Priority (RR_Prio); end RR_Task;

Implementation of the Ada 2005 Task Dispatching Model

117

task body RR_Task is begin -- Set quantum for its priority level RR.Set_Quantum (RR_Prio, RR_Quantum); loop -- Do useful work ...; end loop; end RR_Task; begin null; end Example_3_Policies;

7 Conclusions The new task dispatching model described in the Ada 2005 reference manual is a major advance in the state of the art of standard and commercial support for real-time systems, because it allows getting the best benefits of different scheduling policies: the high predictability of fixed priorities for critical tasks, the effectiveness in the usage of resources provided by EDF, and the fair sharing of spare capacity for non realtime tasks. The paper presents one of the first implementations of the task dispatching model defined in Ada, with hierarchical fixed priorities, EDF, and round robin schedulers. The implementation has been done with the GNAT compiler using MaRTE OS as the underlying support for the run time. The paper discusses the details of the implementation and provides performance metrics that show that the EDF policy is as efficient as the fixed priority policy in regard to the overheads of task synchronization and context switches. The round robin policy has slightly higher overheads, but they are still similar to those of the other two policies. The implementation is provided under a modified GPL license for bare x86 machines and for an implementation of MaRTE OS as a Linux process. The availability of this implementation makes it possible to develop advanced real-time systems and to experiment with the new policies, for instance to develop new design patterns for real-time applications.

References [1] Liu, C.L., Layland, J.W.: Scheduling Algorithms for Multiprogramming in a Hard RealTime Environment. Journal of the ACM 20(1), 46–61 (1973) [2] Kirner, R., Puschner, P., Wenzel, I.: Measurement-Based Worst-Case Execution Time Analysis using Automatic Test-Data Generation. In: Proc. 4th Euromicro International Workshop on Worst Case Execution Time, Catania, Sicily, Italy, June 29 (2004) [3] Bernat, G., Colin, A., Petters, S.M.: WCET Analysis of Probabilistic Hard Real-Time systems. In: Real-Time Systems Symposium, Austin, Texas, USA (December 2002) [4] Bernat, G., Newby, M.J., Burns, A.: Probabilistic timing analysis: an approach using copulas. Journal of Embedded Computing 1-2, 179–194 (2005)

118

M. Aldea Rivas, M. González Harbour, and J.F. Ruiz

[5] Vestal, S.: Preemptive scheduling of multi-criticality systems with varying degrees of execution time assurance. In: Proceedings of the Real-Time Systems Symposium, Tucson, AZ, pp. 239–243 (December 2007) [6] Baker, T.P.: Stack-Based Scheduling of Realtime Processes. Journal of Real-Time Systems 3(1), 67–99 (1991) [7] González Harbour, M., Palencia, J.C.: Response Time Analysis for Tasks Scheduled under EDF within Fixed Priorities. In: Proceedings of the 24th IEEE Real-Time Systems Symposium, Cancun, Mexico (December 2003) [8] Baruah, S., Vestal, S.: Schedulability analysis of sporadic tasks with multiple criticality specifications. In: Proceedings of the 20th Euromicro Conference on Real-Time Systems (ECRTS 2008), Prague, July 2-4 (2008) [9] Aldea, M., González, M.: MaRTE OS: An Ada Kernel for Real-Time Embedded Applications. In: Strohmeier, A., Craeynest, D. (eds.) Ada-Europe 2001. LNCS, vol. 2043, p. 305. Springer, Heidelberg (2001) [10] MaRTE OS home page, http://marte.unican.es [11] Aldea, M., Miranda, J., Harbour, M.G.: Integrating Application-Defined Scheduling with the New Dispatching Policies for Ada Tasks. In: Vardanega, T., Wellings, A.J. (eds.) Ada-Europe 2005. LNCS, vol. 3555, pp. 220–235. Springer, Heidelberg (2005) [12] Zerzelidis, A., Burns, A., Wellings, A.J.: Correcting the EDF protocol in Ada 2005. In: ACM Ada Letters, IRTAW 2007: Proceedings of the 13th international workshop on Real-time Ada (April 2007)

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005 Alan Burns, Andy J. Wellings, Fengxiang Zhang Real-Time Systems Group Department of Computer Science University of York, UK

Abstract. Earliest Deadline First (EDF) and Fixed Priority (FP) scheduling represent the two main dispatching policies within the research domain of real-time systems engineering. Both dispatching policies are now supported by Ada. In this paper the two approaches are combined to maximize the advantages of both schemes. From EDF comes efficiency, from FP predictability. A system model is presented in which a relatively small number of high-integrity tasks are scheduled by FP, with the rest of the tasks being handled via an EDF domain of lower priority. Two aspects of integration are covered in this paper. Firstly, ResponseTime Analysis (for FP) and Processor-Demand Analysis (for EDF) are brought together to provide a single analysis framework. Secondly, the programming of systems which combine FP and EDF is addressed within the facilities provided by Ada 2005. Both partitioned and dynamic schemes are covered.

1 Introduction and Related Work It is remarkable that the two most common scheduling schemes for real-time systems, EDF (Earliest Deadline First) and FP (Fixed Priority – sometimes known as rate monotonic) were both initially defined and analyzed in the same paper [19]. Since the publication of this seminal work in 1973, there has been a vast amount of research material produced on both of these schemes, and on the many ways of comparing and contrasting them. In this paper we will not rehearse the ‘which is better’ debate but will motivate the use of the combination of both approaches. We will show how combined EDF+FP dispatching can be analyzed and how systems can be programmed in Ada 2005 that make use of separated and combined EDF and FP domains. Indeed we will show how tasks can migrate from EDF to FP dispatching during execution. In general, EDF has the advantage of optimality – its makes the best use of the available processor, whilst FP has the advantage of predicability and efficiency of implementation over current real-time operating systems. For general task parameters, FP has (up to recently) also have the advantage that schedulability is easier to evaluate (but see new results reviewed in Section 3). The motivation for combining the two schemes comes from the wish to exploit the benefits of both approaches: EDF for its effectiveness and FP for the predictability it affords to high priority tasks [12]. In keeping with a number of recent papers on hierarchical approaches to scheduling, we shall explore the properties of a system that has FP as its basic dispatching mechanism. So high integrity tasks will run under FP, F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 119–133, 2009. c Springer-Verlag Berlin Heidelberg 2009

120

A. Burns, A.J. Wellings, and F. Zhang

but the majority of tasks within the system will be managed by EDF (at a conceptually low priority). As a result of this scheme, FP tasks are isolated from the EDF ones, any overrun of the EDF tasks will not effect the FP ones, and the FP tasks will have regular execution patterns which helps to reduce input and output jitter. The desire to combine EDF and FP is not new [26,15,6]. In this paper we combine RTA (Response-Time Analysis) for FP and PDA (Processor-Demand Analysis) for EDF using an adaption of the hierarchical scheduling approach presented by Zhang and Burns in 2007[23]. We are able to present necessary and sufficient analysis of combined EDF and FP systems. Although EDF does have a number of advantages over FP, its use by industry has been limited. Priority based systems are supported by a wide range of real-time kernel APIs (such as POSIX) and programming languages such as Real-Time Specification for Java (RTSJ) and Ada. EDF support is found only on academic research platforms. Recently Ada [9] has been extended to include a number of features of relevance to the programming of real-time systems. One of these is the support for EDF dispatching and combined EDF and FP dispatching – including the sharing of protected objects between tasks scheduled by the different schemes. The structure of this paper is straightforward, a system model is presented in Section 2, existing analysis for FP and EDF systems is covered in Section 3 with Section 4 containing the new integrated analysis. The programming of integrated FP and EDF systems is addressed in Section 5. Sections 3 to 5 address statically partitions systems. Although this may be appropriate for application where all tasks must be guaranteed, many applications will contain soft tasks. These require a more dynamic approach that is able to guarantee hard tasks and effectively schedule soft tasks. One such scheme is illustrated in Section 6. Conclusions are drawn together in Section 7.

2 System Model We use a standard system model in this paper, incorporating the preemptive scheduling of periodic and sporadic task systems. A real-time system, A, is assumed to consist of N tasks (τ1 .. τN ) each of which gives rise to a series of jobs that are to be executed on a single processor. Each task τi is characterized by several parameters: – A period or minimum inter-arrival time Ti ; for periodic tasks, this defines the exact temporal separation between successive job arrivals, while for sporadic tasks this defines the minimum temporal separation between successive job arrivals. – A worst-case execution time Ci , representing the maximum amount of time for which each job generated by τi may need to execute. The worst-case utilization (Ui ) of τi is Ci /Ti . – A relative deadline parameter Di , with the interpretation that each job of τi must complete its execution within Di time units of its arrival. In this paper we assume Di ≤ Ti . The absolute deadline of a job from τi that arrives at time t is t + Di . Once released, a job does not suspend itself. We also assume in the analysis, for ease of presentation, that tasks are independent of each other and hence there is no blocking factor to be incorporated into the scheduling analysis. The use of protected objects to allow data sharing is however allowed in the program model.

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

121

System overheads are ignored in this treatment. Their inclusion would not impact on the structure of the results presented, but would complicate the presentation of these results. In practice, these overheads must of course not be ignored [11]. There are no restrictions on the relative release times of tasks (other than the minimum separation of jobs from the same task). Hence we assume all tasks start at the same instant in time – such a time-instant is called a critical instant for the task system[19]. In this analysis we assume tasks do not experience release jitter. In the initial specification of the model, the system A is statically split into two sets: AF P and AEDF . All task in AF P are scheduled using fixed distinct priorities with the priorities being assign by some appropriate scheme (for the application) such as Deadline Monotonic[18]. Tasks within AEDF are scheduled by EDF. The total utilization of the tasks in these two sets is denoted by UF P and UEDF . For any system to be feasible: UF P + UEDF ≤ 1. At any time during execution, if a task within AF P has an active job (released but not yet competed) then it, or another member of AF P will execute. The order of execution of the tasks from AF P is determined by the static priority parameter of the task. If there are no active jobs from AF P then an active job from AEDF is chosen for execution. The job with the earliest (soonest) absolute deadline is picked for execution. At all times, the arrival of a high priority job will preempt a lower priority or EDF job. Similarly the arrival of a job with an earlier absolute deadline will preempt the current EDF job. As a consequence of these rules, tasks in AF P are unaffected by the existence of EDF tasks (other than by the use of shared protected objects). The EDF tasks, however, suffer interference from the FP tasks. In order to illustrate the application of the methods described in this paper, the example provided in Table 1 will be used. It consists of ten tasks, three of which are high-integrity I/O routines that require their deadlines to be met on all occasions and additionally require minimum jitter over their input and output operation. The other seven tasks are less critical and may be subject to occasional overruns in their execution times. Nevertheless they require their deadlines to be met if there are no execution time faults. Note the total utilization of this task set is high at 0.97 and that a number of tasks have deadline less than period.

Table 1. Example Task Set Task ID τ1 τ2 τ3 τ4 τ5 τ6 τ7 τ8 τ9 τ10

T 10 50 65 10 20 30 50 100 200 1500

C 1 2 1 2 1 5 4 13 26 80

D 4 50 30 8 20 20 50 100 150 900

122

A. Burns, A.J. Wellings, and F. Zhang

3 Existing Schedulability Analysis We are concerned with analysis that is necessary, sufficient and sustainable [3]. In general, schedulability is asserted by either a direct test for this property or via the intermediate calculation of response times. Response times are then trivially compared with (relative) deadlines to complete the analysis. Direct and response-time analysis exists for both FP and EDF. However, Response-Time Analysis (RTA) is the more common approach for FP systems, and the values of the response times will be needed in the integrated scheme. Hence RTA will be used for fixed priority analysis. For EDF the reverse is true, with a direct test known as Processor-Demand Analysis (PDA) being the most appropriate to apply. 3.1 RTA for FP Systems Response-Time Analysis [16,1] examines each task in turn, and computes it latest completion time (response-time) which is denoted by Ri . An equation for Ri is obtained by noting that if task τi is released at time t and this is a critical instant, then in the interval (t,Ri ] there must be time for τi to complete and every higher priority job that is released in the interval to also complete. Hence, Ri Ri = Ci + Cj (1) Tj j∈hp(i)

For all i, hp(i) denotes the set of tasks with higher priority than τi . This equation for Ri is solved by forming a recurrence relation: wn n+1 i wi = Ci + Cj (2) Tj j∈hp(i)

As long as the start value (wi0 ) is less than Ri then this recurrence relation will find the worst case response time (win+1 = win = Ri ) or it will correctly determine that the task is not schedulable (win+1 > Di ). Finding an effective start value for wi0 is the subject of considerable conjecture (see for example some recent results [14]). We shall return to this issue in the integrated approach. The task set illustrated in Table 1 can be analysed using RTA (with the priorities assigned by the optimal deadline monotonic ordering). Unfortunately not all tasks are schedulable, as shown in Table 2. Note the value 1 denotes the highest priority in this example (and 10 the lowest); this is the normal representation in the scheduling literature but is the reverse of the order used by Ada. 3.2 PDA for EDF Systems Processor-Demand Analysis [5,4] considers the entire system in one sequence of tests. It does not compute Ri but uses the property of EDF that at any time t only jobs that have an absolute deadline before t need to execute before t. So the test takes the form (the system start-up is assumed to be time 0): ∀t > 0 : h(t) ≤ t

(3)

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

123

Table 2. RTA Analysis Task ID τ1 τ2 τ3 τ4 τ5 τ6 τ7 τ8 τ9 τ10

T 10 50 65 10 20 30 50 100 200 1500

C 1 2 1 2 1 5 4 13 26 80

D 4 50 30 8 20 20 50 100 150 900

P 1 6 5 2 3 4 7 8 9 10

R 1 15 10 3 4 9 19 48 FAIL FAIL

where h(t) is the total load/demand on the system (all jobs that have started since time 0 and which have a deadline no greater than t). A simple formulae for h(t) is therefore (for D ≤ T ): N t + T j − Dj h(t) = Cj (4) Tj j=1 The need to check all values of t is reduced by noting that only values of t that correspond to job deadlines have to be assessed. Also there is a bound on t. An unschedulable system is forced to fail inequality (3) before the bound L. A number of values for L have been proposed in the literature, here we give one that we shall use in the integrated approach. It is called the synchronous busy period [20,22] and is denoted here by LB . It is calculated by forming a similar recurrence relationship to that used for RTA: m+1

s

=

N m s i=1

Ti

Ci

(5)

The recurrence stops when sm+1 = sm , and then LB = sm . Note that the recurrence 0 cycle N is guaranteed to terminate if U ≤ 1 for an appropriate start value such as s = i=1 Ci . With all available estimates for L there may well be a very large number of deadline values that need to be checked using inequality (3) and equation (4). This level of computation has been a serious disincentive to the adoption of EDF scheduling in practice. Fortunately, a new much less intensive test has recently been formulated [24,25]. This test, known as QPA (Quick Processor-demand Analysis), starts from time L and integrates backwards towards time 0 checking a small subset of time points. These points are proved [24,25] to be adequate to provide a necessary and sufficient test. The QPA algorithm is encoded in the following pseudo code in which D min is the smallest relative deadline in the system and d min(t) is the smallest absolute deadline strictly less than t: t := d min(L) loop s := h(t)

124

A. Burns, A.J. Wellings, and F. Zhang if s <= D min then exit (schedulable) if s > t then exit (unschedulable) if s = t then t := d min(s) else t := s end if end loop

In each iteration of the loop a new value of t is computed. If this new value is greater than the old value the system is unschedulable. Otherwise the value of t is reduced during each iteration and eventually it must become smaller than the first deadline in the system and hence the system is schedulable. Theorem 1. ([24,25]) A general task set is schedulable if and only if U ≤ 1, and the iterative result of the QPA algorithm is s ≤ Dmin where Dmin is the smallest relative deadline of the task set. If the example of Table 1 is scheduled entirely with EDF then the QPA test easily determines that it is schedulable. 3.3 Hierarchical Scheduling In a recent paper on hierarchical scheduling [23], the following result was given for the situation where a collection of EDF tasks are scheduled within a fixed priority server (eg. a deferrable [17] or sporadic server [21]). Theorem 2. (adapted from [23]) In a two level hierarchical system when the local scheduler is EDF, a set of periodic or sporadic tasks in the application is schedulable if all of the following conditions are true: 1. The utilization of the task set is less than the capacity of the server. 2. All tasks in the application are released simultaneously at time 0. 3. ∀di ∈ (0, LB ), R(h(di )) ≤ di where LB is the worst-case synchronous busy period, and the term R(h(t)) is the worst-case response time for the load h(t) when executed within the server. We shall use this result in the following integrated analysis for FP and EDF.

4 Integrated Analysis of FP and EDF Integration comes from linking RTA and PDA (QPA) using the approach developed for hierarchical scheduling. Under EDF the amount of work that must be completed by time t is represented by h(t). But during the execution of an EDF job, some FP jobs may preempt and use some of the available time. It follows that a minimum requirement on the combined task set is that: Cj + Cmin ≤ Dmin j∈AF P

where Cmin is the computation time of the EDF task with the shortest deadline (Dmin ).

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

125

By modeling the entire EDF load as a single low priority task within a FP system, h(t) becomes the computation time of this lower priority task. And hence the response time of this task is the earliest completion time for the EDF load generated by time t. Define R(h(t)) to be this completion time. The fundamental schedulability test for EDF becomes: Theorem 3. In the combined EDF+FP system when all EDF tasks run at the lowest priority level, the EDF tasks are schedulable if and only if: 1. U ≤ 1 where U is the total utilization of the whole task set (including EDF and FP tasks). 2. ∀di ∈ (0, LB ), R(h(t)) ≤ di , where LB is the synchronous busy period of the whole task set. Proof. From Theorem 2’s discussion ∀t > 0, R(h(t)) ≤ t ⇒ h(t) ≤ A(t) where A(t) is the worst-case available processor execution time in a given time interval [0,t]. Also from Theorem 2, the system is schedulable if and only if ∀di > 0, R(h(di )) ≤ di . The upper bound LB can be obtained from the argument of Liu and Layland [19], if there is an overflow in any tasks’ arrival pattern, then there is also an overflow without idle time prior to it when all tasks arrive simultaneously. Since all EDF tasks run at the lowest priority level, when all tasks arrive simultaneously at time 0, then the busy period of the EDF tasks ends when there is no pending tasks in the system. Hence the schedulability check can be bounded to the synchronous busy period of the whole task set. 2 To obtain the value of R(h(t)) within the FP domain, equation(1) becomes: R(h(t)) R(h(t)) = h(t) + Cj (6) Tj FP j∈A

This is again solved using the recurrence relationship identified in equation (2). The value of LB is calculated by equation (5). The QPA algorithm outlined in Section 3.2 is essentially unchanged. Since R(h(t)) is non-decreasing with t, we can use the same argument used in the proof of Theorem 1 to show that only line in the pseudo code needs altering: the assignment to s which must now be: s := R(h(t)) To test a complete system the response time equation is evaluated for a series of ‘loads’ starting with h(LB ) and decreasing each iteration of the QPA loop. This usage of RTA facilitates an efficient start value (w0 ) for equation (6). In general, the utilization of the FP tasks will be relatively small and the size of h(t) large when compared to the typical FP task’s execution time. In these circumstances the start value derived by Bril et al [8] is the best one to use: w0 =

h(t) (1 − UF P )

(7)

So in the example the three fixed priority tasks (τ1 ...τ3 ) are easily schedulable – the values for these task are given in Table 3.

126

A. Burns, A.J. Wellings, and F. Zhang Table 3. RTA Analysis of FP Tasks Task ID τ1 τ2 τ3

T 10 50 65

C 1 2 1

D 4 50 30

P 1 3 2

R 1 4 2

Table 4. Full Analysis of EDF Subsystem t 988 967 954 948 908 889 764 677 576 505 436

h(t) 815 803 800 765 750 643 570 485 424 367 313

w0 965 951 947 906 888 761 675 574 502 435 371

w1 w2 R(h(t) t h(t) w0 w1 w2 R(h(t) 967 967 373 271 321 323 323 954 954 323 224 265 268 268 948 948 268 184 218 220 220 908 908 220 158 187 188 188 889 889 188 128 152 155 155 764 764 155 113 134 136 136 677 677 136 73 86 88 88 576 576 88 41 49 49 505 505 49 17 20 22 23 23 436 436 23 10 12 15 15 373 373 15 2 2 6 6

The synchronous busy period estimation of LB is 988. Using equation (4) to compute h(988) gives the value 815. Equation (7) for h(t) = 815 provides an initial value for the RTA analysis of 965. Equation (6) is then solved with this initial value to give R(815) = 967. As 988 > 967 this initial QPA test is positive (ie. R(h(988)) < 988). From the value of 967 the iteration continues. Table 4 shows this process for all the stages that the QPA analysis requires. Termination occurs when t becomes less then the shortest EDF deadline in the system (ie 6 < 8). The result is that on all iterations R(h(t)) ≤ t and therefore the EDF part of the system is deemed schedulable. And hence the dual scheduled complete system is schedulable. Note Table 4 includes all the calculations needed to verify this system. A useful way of estimating the effort required to complete the verification process is to count the number of ceiling/floor function calls that are required. Within this example, for all but two of the steps only two iterations are needed to compute the response time for the EDF load. For one step three iterations were needed; for another only one. The combination of an efficient start value to this part of the algorithm and the use of the QPA approach means that a total of only 69 ceiling/floor computations have been necessary to test the entire system (3 for the FP part, 22 processor demand calculations and 44 w evaluations).

5 Programming EDF and FP in Ada 2005 To implement combined EDF and FP systems requires either support from an underlying operating system (OS) or from a programming language. Unfortunately few commercial OSs support EDF let alone combined EDF/FP. Similarly, programming

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

127

languages aimed at the embedded and real-time domain are weak in their provisions for real-time abstractions and notations. The only engineering languages that does support a variety of dispatching policies is Ada; this section therefore focussed on the implementation of combined EDF/FP systems in that language. A typical time-triggered task type, dispatched by FP, has the form: task type Periodic_FP (Pri : Priority; Period_in_MS : Integer) is pragma Priority(Pri); -- fixed priority end Periodic_FP; task body Periodic_FP is Next_Release : Time; Period : Time_Span := Milliseconds(Period_in_MS); begin Next_Release := Clock; loop -- application code Next_Release := Next_Release + Period; delay until Next_Release; end loop; end Periodic_FP; Actual_FP_Periodic_Task : Periodic_FP(16,25); -- task with priority of 16 and a period of 25 ms

The time types and the clock function are all defined in the predefined language package Ada.Real Time. Note as is typical in FP systems, the actual deadline of the task is not represented in the program’s code. To inform the run-time system that FP dispatching is required, the following pragma is used: pragma Task_Dispatching_Policy(FIFO_Within_Priorities);

5.1 Supporting EDF Scheduling To support EDF requires two language features: – representation of the deadline for a task, – representation of preemption level for a protected object. The first is obviously required; the second is the EDF equivalent of priority ceilings and allows protected objects to be ‘shared’ by multiple tasks [2]. A predefined package provides support for deadlines: package Ada.Dispatching.EDF is subtype Deadline is Time; Default_Deadline : constant Deadline := Time_Last; procedure Set_Deadline(D : in Deadline; T : in Task_ID := Current_Task); procedure Delay_Until_And_Set_Deadline(Delay_Until_Time : Time; TS : in Time_Span); function Get_Deadline(T : Task_ID := Current_Task) return Deadline; end Ada.Dispatching.EDF;

128

A. Burns, A.J. Wellings, and F. Zhang

Within a complete system, the priority range is split into different ranges for different dispatching policies. For the approach adopted in this paper, a collection of high values (larger integers) are used for FP, and a range of lower values are used for EDF. If the base priority of a task is within the range of priorities defined as EDF Across Priorities then it is dispatched by EDF. Note also that the ready queues for priorities within this range are ordered by absolute deadline (not FIFO). The typical code pattern for a periodic task type, scheduling by EDF, is therefore now: task type Periodic_EDF (Pri : Priority; Period_in_MS, Deadline_in_MS : Integer) is pragma Priority(Pri); pragma Relative_Deadline(Milliseconds(Deadline_in_MS)); end Periodic_EDF; task body Periodic_EDF is Next_Release: Time; Period : Time_Span := Milliseconds(Period_in_MS); Rel_Deadline : Time_Span := Milliseconds(Deadline_in_MS); begin Next_Release := Clock; loop -- application code Next_Release := Next_Release + Period; Delay_Until_and_Set_Deadline(Next_Release, Rel_Deadline); end loop; end Periodic_EDF; Actual_EDF_Periodic_Task : Periodic_EDF(5,25,20); -- 5 is within the EDF_Across_Priorities range. -- Period of 25 ms, and relative deadline of 20 ms. -- The first absolute deadline of the task is 20ms from the time the -- task is created.

The different priority ranges are indicated by the following pragmas (in this example, the bottom ten are allocated to EDF and the next higher ten to FP). pragma Priority_Specific_Dispatching(FIFO_Within_Priorities, 20, 11); pragma Priority_Specific_Dispatching(EDF_Across_Priorities, 10, 1);

Note the code for a task object of type Periodic EDF could be dispatched by FP by merely changing the range into which its priority falls – there is no need to make any changes to the code of the task. 5.2 Protected Objects With standard fixed priority scheduling, priority is actually used for two distinct purposes: – to control dispatching, and – to facilitate an efficient and safe way of sharing protected data.

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

129

In Baker’s stack-based protocol, two distinct notions are introduced for these policies[2]: – earliest deadline first to control dispatching1, – preemption levels to control the sharing of protected data. With preemption levels, each task is assigned a static preemption level (represented by the task’s base priority), and each protected object is assigned a ceiling value that is the maximum of the preemption levels of the tasks that call it. At run-time, a newly released task, T1 say, can preempt the currently running task, T2, if and only if: – the absolute deadline of T1 is earlier (i.e. sooner) than the absolute deadline of T2, and – the preemption level of T1 is higher than the ceiling preemption level of every locked protected object. With this protocol it is possible to show that, on a single processor, mutual exclusion (over the protected object) is ensured by the protocol itself (in a similar way to that delivered by fixed priority scheduling and ceiling priorities)2 . Baker also showed, for the classic problem of scheduling a fixed set of periodic or sporadic tasks, that if preemption levels are assigned according to each task’s relative deadline then a task can suffer at most a single block from any task with a longer deadline. Again this result is identical to that obtained for fixed priority scheduling. The definition of Ada 2005 provides support for Baker’s algorithm – see Burns and Wellings[10] for details.

6 Dynamic Partitioning of EDF and FP Tasks Rather than partition the two types of tasks (with the high integrity tasks being scheduled as FP and the others as EDF), a dynamic scheme can be used. This is particularly appropriate where the system has a mixture of high-integrity (hard) and soft real-time tasks. In one such approach, all tasks are initially scheduled using EDF, but if it becomes critical for a high-integrity task to execute, it is pulled from the EDF level and is allowed to complete as a FP task where the execution behaviour is more predictable. This means of scheduling tasks is known as dual priority scheduling [13,7]. Each high-integrity task has a promotion time, Si , that indicates when (relative to its release) it must move to its higher level. The scheduling equations when they compute worst-case response time Ri immediately allow this value to be obtained: Si := Ti −Ri . The full analysis is given in [13]. Here, we focus on the programming aspects. To support dual priority scheduling in Ada 2005 requires two features: – a means of dynamically changing a task’s priority, and – a means of making such a change at a particular point in time. 1 2

His paper actually proposes a more general model of which EDF dispatching is an example. This property requires that there are no suspensions inside the protected object – as is the case with Ada.

130

A. Burns, A.J. Wellings, and F. Zhang

The former is supported by a straightforward dynamic priority package. More significantly, Ada 2005 has introduced a new abstraction of a timing event to allow code to be executed at specified times without the need to employ a task/thread. These events are like interrupts, but they are generated by the progression of the real-time system clock. Associated with a timing event is a handler that is executed at the allotted time. An implementation should actually execute this handler directly from the interrupt handler for the clock device. This leads to a very efficient implementation scheme. It would be quite possible for each task to have its own handler that alters its base priority when required. However, using the ‘tagged’ feature of the event type it is possible to have just a single handler that uses the event parameter to reference the correct task. To do this, the type Timing Event is first extended (in a library package) to include a task ID field: type Dual_Event is new Timing_Event with record TaskID : Task_ID; end record;

The single handler has a straightforward form (it is placed in the same library package as the type definition): protected Dual_Event_Handler is pragma Interrupt_Priority(Interrupt_Priority’Last); procedure Change_Band(Event : in out Timing_Event); end Dual_Event_Handler; protected body Dual_Event_Handler is procedure Change_Band(Event : in out Timing_Event) is The_Task : Task_ID; P : Priority; begin The_Task := Dual_Event(Timing_Event’Class(Event)).TaskID; P := Get_Priority(The_Task); Set_Priority(P+10, The_Task); end Change_Band; end Dual_Event_Handler;

The specific task ID is obtained by two view conversions, the parameter Event is converted first to a class-wide type and then to the specific type Dual Event. The run-time system does not know about the extended type but the underlying type is not changed or lost, and is retrieved using the view conversions. Now consider a high integrity task that has a base priority 4 in the EDF level and 14 in the upper FP level. Initially it must run with priority 14 to make sure all its initialisation is complete. It has a period of 50 ms and a relative deadline set to the end of its period (i.e. also 50 ms). Its promotion point is 30 ms after its release. task Example_Hard is pragma Priority(14); end Example_Hard;

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

131

task body Example_Hard is Dual_E : Dual_Event := (Timing_Event with TaskID => Current_Task); Start_Time : Time := Clock; Period : Time_Span := Milliseconds(50); Promotion : Time_Span := Milliseconds(30); begin Dual_E.Set_Handler(Start_Time + Promotion, Dual_Event_Handler.Change_Band’access); Set_Deadline(Start_Time + Period); Set_Priority(4); -- now dispatched according to EDF loop -- application code of the task Start_Time := Start_Time + Period; Dual_E.Set_Handler(Start_Time + Promotion,Dual_Event_Handler. Change_Band’access); Set_Priority(4); Delay_Until_And_Set_Deadline(Start_Time,Period); end loop; end Example_Hard;

If the event triggers then the task’s priority will be raised to 14 and it will be subject to fixed priority dispatching; as a result it will complete the execution of its code by its deadline (guaranteed by the scheduling analysis). It will then set its new release time (Start Time), set its event handler again and lower its priority back to the value within the EDF range. Its deadline will be quite soon and so it is likely to continue executing into its delay statement. If the system is not heavily loaded, the hard task will complete its invocation before the promotion point. The second call of Set Handler will then cancel the previous call. A final point to note with this example concerns the use of protected objects by the tasks. If such an object is used by a hard task then it must have a ceiling in the 11..20 range, otherwise an error would occur if the task with its promoted priority calls the object. Using the event handler to also change the ceiling priorities of such protected objects is unlikely to be justified.

7 Conclusions This paper has considered the means by which EDF and FP scheduling can be used together to produce a hybrid scheme that has many of the benefits of the individual approaches. From EDF comes efficiency, from FP comes predictability. With this combination it is possible to run systems that have a number of critical tasks that require the determinacy of FP together with soft tasks that utilize most of the remaining capacity of the processor. Two aspects of the integration of EDF and FP have been covered. First the integration of the forms of analysis available – specifically, RTA for FP and PDA (with QPA) for EDF. Secondly, integration of the implementations via the programming model available in Ada 2005. This enables industrially relevant systems to be produced that make use of FP and EDF, and moveover allows a late binding to the scheduling scheme to be employed. Indeed a dynamic approach is discussed that allows tasks at run-time to migrate between scheduling routines.

132

A. Burns, A.J. Wellings, and F. Zhang

References 1. Audsley, N.C., Burns, A., Richardson, M., Tindell, K., Wellings, A.J.: Applying new scheduling theory to static priority preemptive scheduling. Software Engineering Journal 8(5), 284– 292 (1993) 2. Baker, T.P.: Stack-based scheduling of realtime processes. Real-Time Systems 3(1) (March 1991) 3. Baruah, S.K., Burns, A.: Sustainable schedulability analysis. In: IEEE Real-Time Systems Symposium (RTSS), pp. 159–168 (2006) 4. Baruah, S.K., Howell, R.R., Rosier, L.E.: Feasibility problems for recurring tasks on one processor. Theorectical Computer Science 118, 3–20 (1993) 5. Baruah, S.K., Mok, A.K., Rosier, L.E.: Preemptive scheduling of hard real-time sporadic tasks on one processor. In: IEEE Real-Time Systems Symposium (RTSS), pp. 182–190 (1990) 6. Baruah, S.K., Mok, A.K., Rosier, L.E.: Hybrid-priority scheduling of resource-sharing sporadic task systems. In: IEEE Real-Time Systems and Applications Symposium, RTAS (2008) 7. Bernat, G., Burns, A.: Combining (n m)-hard deadlines with dual priority scheduling. In: Proceedings 18th IEEE Real-Time Systems Symposium, pp. 46–57 (1997) 8. Bril, R.J., Verhaegh, W.F.J., Pol, E.-J.D.: Initial values for on-line response time calculations. In: Proceedings of the 15th Euromicro Conference on Real-Time Systems (ECRTS), pp. 13– 22 (2003) 9. Brukardt, R. (ed.): Ada 2005 reference manual. Technical report, ISO (2006) 10. Burns, A., Wellings, A.J.: Concurrency and Real-Time Programming in Ada 2005. Cambridge University Press, Cambridge (2007) 11. Burns, A., Wellings, A.J.: Real-Time Systems and Programming Languages, 4th edn. Addison-Wesley Longman, Amsterdam (2009) 12. Buttazzo, G.: Rate monotonic vs. EDF: Judgement day. Real-Time Systems Journal 29(1), 5–26 (2005) 13. Davis, R.I., Wellings, A.J.: Dual priority scheduling. In: Proceedings 16th IEEE Real-Time Systems Symposium, pp. 100–109 (1995) 14. Davis, R.I., Zabos, A., Burns, A.: Efficient exact schedulability tests for fixed priority preemptive systems. IEEE Transaction on Computers 57(9), 1261–1276 (2008) 15. Harbour, M.G., Gutirrez, J.C.P.: Response time analysis for tasks scheduled under EDF within fixed priorities. In: IEEE Real-Time Systems Symposium (RTSS), pp. 200–209 (2003) 16. Joseph, M., Pandya, P.: Finding response times in a real-time system. BCS Computer Journal 29(5), 390–395 (1986) 17. Lehoczky, J.P., Sha, L., Strosnider, J.K.: Enhanced aperiodic responsiveness in a hard realtime environment. In: Proceedings 8th IEEE Real-Time Systems Symposium, pp. 261–270 (1987) 18. Leung, J.Y.T., Whitehead, J.: On the complexity of fixed-priority scheduling of periodic, real-time tasks. Performance Evaluation (Netherlands) 2(4), 237–250 (1982) 19. Liu, C.L., Layland, J.W.: Scheduling algorithms for multiprogramming in a hard real-time environment. JACM 20(1), 46–61 (1973) 20. Ripoll, I., Mok, A.K.: Improvement in feasibilty testing for real-time tasks. Journal of RealTime Systems 11(1), 19–39 (1996) 21. Sprunt, B., Sha, L., Lehoczky, J.P.: Aperiodic task scheduling for hard real-time systems. Real-Time Systems 1, 27–69 (1989)

Combining EDF and FP Scheduling: Analysis and Implementation in Ada 2005

133

22. Spuri, M.: Analysis of deadline schedule real-time systems. Technical Report 2772, INRIA, France (1996) 23. Zhang, F., Burns, A.: Analysis of hierarchical EDF preemptive scheduling. In: IEEE RealTime Systems Symposium (RTSS), pp. 423–435 (2007) 24. Zhang, F., Burns, A.: Schedulability analysis for real-time systems with EDF scheduling. Technical Report YCS 426, University of York (2008) 25. Zhang, F., Burns, A.: Schedulability analysis for real-time systems with EDF scheduling. IEEE Transaction on Computers (to appear) (2008) 26. Zuberi, K.M., Pillai, P., Shin, K.G., Emeralds, K.G.: A small memory real-time microkernel. In: ACM Symposium on Operating Systems Principles, pp. 277–291 (1999)

Predicated Worst-Case Execution-Time Analysis Amine Marref and Guillem Bernat The University of York {marref,bernat}@cs.york.ac.uk

Abstract. Tightness in WCET estimation is highly desirable for an eﬃcient utilisation of resources. In order to obtain accurate WCET values, more program execution-history must be accounted for. In this paper we propose the use of Predicated WCET Analysis with constraint logicprogramming to model context sensitive execution-times of program segments. Our method achieves considerable tightness in comparison to traditional calculation methods that exceeded 20% in some cases during evaluation. Computing the WCET of programs modeled using our approach reveals a great ease of expressing execution-time dependencies and manageable WCET-calculation time-complexity.

1

Introduction

Finding the worst-case execution-time (WCET) of real-time tasks is of primordial importance for schedulability analysis for the correct functioning of real-time programs [9]. WCET computation requires safety and tightness i.e. no underestimation is accepted or at least accepted to some degree [4], and overestimation should be minimized as much as possible [6]. WCET analysis techniques have been explored for approximately two decades and can be divided into three categories: end-to-end testing, static analysis (SA), and measurement-based analysis (MBA) [11]. SA and MBA ﬁnds the WCET of a program as follows: (a) decomposing the program into segments, (b) ﬁnding the execution times of these segments, and (c) combining these execution times using a calculation technique: tree-based [10,7], path-based [13,26], or implicit path-enumeration (IPET) [17,23]. Path-based methods suﬀer from exponential complexity and tree-based methods cannot model all types of program-ﬂow, leaving IPET as the preferred choice for calculation especially because of the ease of expressing ﬂow dependencies and the availability of eﬃcient integer-linear programming (ILP) [1] solvers. The term IPET has most commonly been used to refer to the use of ILP to model the execution of the program. In [23], the program is represented as a graph-circulation problem which can be solved using ILP. In fact the term IPET is a generalisation of any calculation method that implicitly enumerates all the paths of the program. Performing IPET using ILP, however, has got limitations. ILP models struggle to cope with the variations in the execution times of program segments caused F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 134–148, 2009. c Springer-Verlag Berlin Heidelberg 2009

Predicated Worst-Case Execution-Time Analysis

135

by modern-hardware accelerators e.g. pipelines and caches. The reason for this is the complexity resulting from trying to model all these execution times in one linear model. This motivates for the use of a more powerful calculation technique which copes with execution-time variations and yields tighter, more context-sensitive WCET estimations. We want to compute tight WCET estimations by exploiting execution-context i.e. by identifying the eﬀects of past execution on the execution time of a program segment. We proceed by identifying the necessary conditions leading to the observation of diﬀerent execution-times of program segments by static or measurement-based analysis. Subsequently, we construct eﬀect tables which list the execution times of a segment together with the combination of blocks that caused them. There can be many segments which have multiple execution-times, and each execution time of the segment is caused by one or more segments that previously executed. This makes the constraints extremely complex and their number considerably large. If we attempt to capture these execution time dependencies using ILP, we are soon faced with the limitation that the constraints in ILP are linear and disjunction cannot be expressed “naturally” in ILP. In the current work, we conduct an empirical analysis to evaluate the suitability of using ILP or constraint logicprogramming (CLP) [2] in order to express the constraints governing the execution ﬂow and times of the segments in the program and perform calculation. The rest of the paper is organized as follows. Section 2 describes related work where account is given to work done using ILP and context-sensitive calculations as a way of pointing out the beneﬁts of using our technique. Section 3 establishes the required terminology used in the paper. Section 4 explains the philosophy behind our predicated analysis and introduces the execution-time eﬀect-tables. Section 5 details the diﬀerent ways by which ILP and CLP can model the predicated analysis. Section 6 shows the tightness in WCET estimations we obtained during the evaluation together with calculation times. Finally, Section 7 summarizes the important results, draws conclusion, and sets aims for future work.

2

Related Work

WCET analysis using context-sensitive IPET is not novel, the idea has been around for a long time. The focus has always been to achieve context sensitivity in the execution counts of segments rather than the execution times due to the fact that ILP was used to compute the solution which is by deﬁnition linear (i.e. either execution counts or execution times can vary but not both). WCET Analysis using IPET started in [17,18,23] and later in [21,3,8,15,16]. The execution times considered in [17,18,23] are constant. In [21,3,8,15,16], ILP is used to represent execution history by modeling caches, pipelines, branch predictors, and speculative execution. The objective function is generally augmented by execution-time gains/penalties resulting from the use of the hardware component being analysed. These objective functions have not been integrated

136

A. Marref and G. Bernat

together because of their complexity. Each segment has two execution times at most. In recent work [14,25], timing variability of basic blocks with respect to pipelines has been analysed where there can be multiple execution times of a basic block depending on the subpath previously traversed, then ILP is used to calculate the overall WCET. In [12] WCET calculation is performed using the notion of scopes to provide context-sensitivity mainly through constraining execution counts. At the lowlevel, the execution-times of segments are expressed in a scenario-based fashion where multiple execution times are allowed in theory. The integration in the ILP model requires bounds on diﬀerent execution times of a basic block to be known a priori which as we shall see (Section 5.3) still generates pessimism, and are very hard to derive. The common feature between the WCET works in the literature is that once a program segment’s execution-time is variable and depends on previous distanthistory (e.g. because of cache), the execution time is assumed to be in its worst case. For example, if a segment can perform a cache hit or a cache miss depending on previous history, it is conservatively assumed to perform a miss. In contemporary hardware, conservative analysis of this type leads to overestimations. In this paper, we will show the way we conditionally capture previous execution-history and its corresponding execution times of the segment via our predicated analysis.

3

Deﬁnitions

The program under analysis is represented by a control-ﬂow graph (CFG) which is deﬁned as a tuple (V, E). V is the set of vertices, in this case basic blocks in the program, |V | = n. E is the set of edges, which in this case are the transitions between the blocks in the program. A basic block is a contiguous sequence of instructions where the ﬁrst instruction is jumped to (or is the ﬁrst instruction of the program) and the last instruction is jumped from (or is the last instruction of the program) [22]. Each block Bi (i ∈ [1..n]) is associated an execution count xi and an execution time ci . When Bi has θi execution times, these will represented as chi where h ∈ [1..θi ]. We use the notation ci to refer to the largest execution-time of Bi . We also use xi to refer to the maximum number of iterations of Bi . In order to express conditional execution-time observations, we use the operator ’/’. For example, the term ci = α/(xj > 0∧xk = 0) means that the execution time of block Bi is α if and only if Bj executes and Bk does not execute. In the simple case ci = α/(xj > 0), we use the abbreviated notation ci/j = α.

4

Eﬀect Tables and Time Constraints

The need for tight WCET values is always desirable because largely pessimistic WCET estimates are impractical. One important source of pessimism comes from

Predicated Worst-Case Execution-Time Analysis

137

assuming the longest execution times of program segments during calculation in order to achieve safety. In fact, program segments might exhibit their longest execution times only rarely which leads to a large gap between the computed WCET of programs and their largest observable execution times. The size of this gap can be narrowed if more execution context is taken into account. This can be achieved for instance through parameterizable WCET analysis [5] where the WCET of a subroutine of a program is expressed as a function of a set of parameters rather than a constant WCET value. Another way of obtaining tight WCET estimations is to consider execution-time variations of program segments. We call this predicated WCET analysis which we deﬁne as performing WCET analysis by considering all diﬀerent execution times of a program segment and expressing them as the outcomes of executing some other segments in the past. There is therefore the need to (a) identify the diﬀerent execution times of a program segment and (b) identify the -previously executed- program segments that cause these execution times. We use the basic blocks as our program segments. We use eﬀect tables to represent the execution-times of basic blocks together with the blocks that cause them. We deﬁne Ψi as the set of blocks Bj that aﬀect the execution-time of Bi . The eﬀect table ETi of Bi is constructed from all combinations of blocks Bj ∈ Ψi and the corresponding execution-times of Bi . The value 1 (respectively 0) in the cell ETi (row, clm) indicates that the block at position clm must (respectively must not) execute to observe the execution time at position row. Figure 1(a) shows a generic eﬀect-table ETi corresponding to block Bi aﬀected by blocks Ψi . Figure 1(b) shows the ET3 of block B3 aﬀected by blocks B1 and B2 . The execution time of B3 has four diﬀerent values depending on the execution pattern of B1 and B2 . The derivation of the eﬀect tables is possible using static or measurementbased analysis [20]. Here we assume we already have the eﬀect tables. Every row of the eﬀect table corresponds to a time constraint. For example, the fourth row of ET3 in Figure 1(b) becomes (x1 > 0 ∧ x2 > 0 ⇒ c3 = 40). The number of time constraints per block Bi increases exponentially with respect to |Ψi |. At the same time, a block Bi has a ﬁnite number θi of execution times which - in most cases - satisﬁes (θi < 2|Ψi | ).

x1 0 0 .. .

x2 0 0 .. .

· · · x|Ψi |−1 x|Ψi | ··· 0 0 ··· 0 1 .. .. .. . . .

1 1 ···

1 (a)

1

ci c1i c2i .. . |Ψi |

c2i

x1 x2 0 0 0 1 1 0 1 1 (b)

c3 10 20 30 40

Fig. 1. A generic ETi is shown in (a) together with an example ET3 in (b)

138

A. Marref and G. Bernat

Consequently, some of the rows in ETi have the same execution-time value and hence are called equivalent rows; or cannot have corresponding executiontimes ci and are termed impossible rows. An example of the latter is when two or more blocks Bj ∈ Ψi are mutually exclusive but they execute together in a row. Equivalent rows help simplify the eﬀect tables by using boolean algebra or Karnaugh maps. Generally, a block with a few execution-times has an eﬀect table which can be potentially simpliﬁed. Notice that the number of diﬀerent execution times of a basic block varies with the complexity of the architecture where it runs. Not all eﬀect tables can be simpliﬁed by boolean algebra. In this case, eﬀecttable simpliﬁcation is forced by changing the values of ci (of a block Bi with associated ETi ) in a way that maximizes row equivalences and minimizes pessimism. Since the analysis must be safe, only value-increasing changes are allowed.

5

Modeling the Time Constraints

We can model the eﬀect tables using ILP or CLP. In this section we show three diﬀerent ways of implementing our predicated analysis using ILP and then we show the way we use CLP to model the eﬀect tables. 5.1

Mutual Exclusion: ILP1

One way of implementing our predicated analysis is through the use of mutual exclusion. Consider Figure 2(a) where c6/3 = 7 and c6/4 = 10. The basic ILP formulation of the problem when c6 is constant is to maximize the sum in (1). 7

ci × xi

(1)

i=1

When c6 is not constant, the term c6 × x6 needs to be expanded further. This is done by duplicating B6 as is shown in Figure 2(b) and adding mutual-exclusive path information to the model. In Figure 2(b), B6 with execution times {7, 10} is expanded to B61 with execution time c16 = 7 and B62 with execution time c26 = 10. Since c16 = 7 is observed only when B3 is executed, we can state that B61 is mutually exclusive with B4 i.e. (x16 > 0 ∧ x4 = 0) ∨ (x16 = 0 ∧ x4 > 0). The same argument is made for B62 and B3 . The updated ILP formulation becomes (c1 x1 + c2 x2 + c3 x3 + c4 x4 + c5 x5 + c16 x16 + c26 x26 + c7 x7 )

(2)

with the additional constraints that express mutual exclusion. The CFG ﬂow is preserved by also duplicating the incoming and outgoing edges of B6 . The ILP problem needs to be solved for each set of mutually-exclusive paths, then the best solution is taken. Although this appears non-costly in this example, we can with little eﬀort imagine a more complex scenario (e.g. Figure 2(c,d)) where the number of times the ILP problem is solved is proportional to the

Predicated Worst-Case Execution-Time Analysis

B1

B1

B2

B2

B3

B4

B3

B5

B7

(a)

B2

B3

B4

B4 B5

B61

B6

B1

B62

B5

B51

B1

B2

B3

B4

B52

B53

139

B54

B7

(b)

(c)

(d)

Fig. 2. Node expansion and mutual exclusion constraints are required to implement disjunction in ILP

number of block duplications made. If in Figure 2(c) block B5 has four execution times depending on the four paths executed prior to its execution then four duplicates of B5 are created (Figure 2(d)), and eventually eight sets of mutualexclusion constraints as shown in (3) assuming eﬀect table ET5 in Figure 3: (x1 ∧ (x3 ∧ (x1 ∧ (x4 ∧ (x2 ∧ (x3 ∧ (x2 ∧ (x4

= 0 ∧ x15 = 0 ∧ x15 = 0 ∧ x25 = 0 ∧ x25 = 0 ∧ x35 = 0 ∧ x35 = 0 ∧ x45 = 0 ∧ x45

> 0) ∨ (x1 > 0) ∨ (x3 > 0) ∨ (x1 > 0) ∨ (x4 > 0) ∨ (x2 > 0) ∨ (x2 > 0) ∨ (x2 > 0) ∨ (x4

> 0 ∧ x15 > 0 ∧ x15 > 0 ∧ x25 > 0 ∧ x25 > 0 ∧ x35 > 0 ∧ x35 > 0 ∧ x45 > 0 ∧ x45

= 0) = 0) = 0) = 0) = 0) = 0) = 0) = 0)

(3)

The ILP model is solved 28 times corresponding to the number of diﬀerent combinations of the disjuncts in (3) (assuming block B5 is the only block with multiple execution times). Notice that in this example, there is mutual exclusion between the aﬀecting blocks in Ψ5 which reduces the eﬀect table ET5 to its quarter as shown in Figure 3. Should no mutual exclusion exist between the blocks in Ψ5 , there will be 32 disjunctions and eventually 232 runs of the ILP model (assuming no other block has multiple execution times). In general, the number M U Ti of mutual-exclusion constraints per block Bi that has |Ψi | aﬀecting blocks Bj - in the absence of mutual exclusion between blocks in Ψi - is equal to the number of 0s in the xj columns where j ∈ [1..|Ψi |]. Another way of implementing mutual exclusion in ILP is by use of equalities. For example, consider two blocks B1 and B2 executing in two diﬀerent loops L1 and L2 respectively in some CFG with execution bounds α1 and α2 respectively. The execution counts of B1 and B2 are x1 ∈ [0..α1 ] and x1 ∈ [0..α2 ] respectively.

140

A. Marref and G. Bernat x1 0 0 0 0 0 0 0 0

x2 0 0 0 0 1 1 1 1

x3 0 0 1 1 0 0 1 1

x4 0 1 0 1 0 1 0 1

c5 c15 c25 -

x1 1 1 1 1 1 1 1 1

x2 0 0 0 0 1 1 1 1

x3 0 0 1 1 0 0 1 1

x4 0 1 0 1 0 1 0 1

c5 c35 c45 -

Fig. 3. Eﬀect table ET5 of block B5 in Figure 2(c)

If the loop L1 (respectively L2 ) is completely unrolled, block B1 (respectively B2 ) is duplicated α1 (respectively α2 ) times. Let block B1 be substituted by blocks B11 , B12 , · · · , B1α1 and block B2 be substituted by blocks B21 , B22 , · · · , B2α2 . Mutual exclusion between B1 and B2 is represented as: ∀i ∈ [1..α1 ], ∀j ∈ [1..α2 ] • xi1 + xj2 = 1 (4) This requires α1 × α2 constraints per disjunction. Equation 4 is true both when B1 and B2 do not execute in the same loop (i.e. the unrolled blocks B11 , B12 , · · · , B1α1 all execute before the unrolled blocks B21 , B22 , · · · , B2α2 ) and when they both execute in the same loop (nest) (i.e. the execution of blocks B11 , B12 , · · · , B1α1 and blocks B21 , B22 , · · · , B2α2 can alternate). In Figure 2(d), if the loop iterates for 3 times; the required mutual-exclusion equality constraints between x1 , x15 and x3 , x15 are: x11 + (x15 )1 ∧ x11 + (x15 )2 ∧ x11 + (x15 )3 ∧ x13 + (x15 )1 ∧ x13 + (x15 )2 ∧ x13 + (x15 )3

=1 =1 =1 =1 =1 =1

∧ ∧ ∧ ∧ ∧ ∧

x21 + (x15 )1 x21 + (x15 )2 x21 + (x15 )3 x23 + (x15 )1 x23 + (x15 )2 x23 + (x15 )3

=1 =1 =1 =1 =1 =1

∧ ∧ ∧ ∧ ∧ ∧

x31 + (x15 )1 x31 + (x15 )2 x31 + (x15 )3 x33 + (x15 )1 x33 + (x15 )2 x33 + (x15 )3

=1 =1 =1 =1 =1 =1

(5)

Formula (5) shows the implementation of only two mutexes via equality and for a very small loop iteration-count. The number of mutual-exclusion equalityconstraints required to express the time-variations in a CFG of n blocks Bi of maximum execution-counts xi aﬀected by |Ψi | blocks Bj with maximum n execution-counts xj is in the worst case M U Ti × (xi × xj ) if Bj , j ∈ [1..|Ψi |] i=1

causes the execution time cri at row r of ETi and ETi (r, j) = 0. The advantage of using mutual-exclusion equality-constraints is that the ILP model is executed once only; however, the number of added mutexes is very signiﬁcant. On the other hand, the advantage of using mutual-exclusion disjunctionconstraints is that the model duplicates have very few mutexes; however, the number of runs is exponential.

Predicated Worst-Case Execution-Time Analysis

141

The usual way of solving an ILP is by solving a series of LP relaxations through branch and bound. In each LP relaxation, the simplex or cutting-plane methods are used to derive the optimal solution. Since branch and bound is used, the search for the optimal integral solution can have a worst-case exponentialbehaviour. This is to say that in the worst case, ILP1 by disjunctive mutexes and ILP1 by equality mutexes have same complexity. We unfortunately have to resort to doing an empirical evaluation of both methods and decide which one is best in practice. 5.2

Path Duplication: ILP2

Another way to capture the eﬀects on block Bi with θi execution times - as deﬁned by its eﬀect table - is to duplicate Bi θi times and duplicate all the paths leading from the blocks in Ψi to Bi . Contrary to ILP1 where the relation between the aﬀecting blocks in Ψi and the aﬀected block Bi is described in terms of mutual-exclusion constraints; this relation is encoded in the CFG itself in ILP2. Figure 4 shows an example path-expansion where block B8 has four execution times depending on B2 and B5 . Figure 4 shows an example of enforcing the time constraints of ET8 the eﬀect table of block B8 . Path p1 in Figure 4(b) is created to encode the time constraint (x2 > 0 ∧ x5 > 0 ⇒ c8 = c48 ); in Figure 4(b), both blocks B2 and B5 execute in path p1 . Similarly, the remaining three paths are constructed to encode the three remaining time constraints. In ILP2, blocks and/or paths are duplicated to encode the mutexes in the CFG. This duplication propagate with the time constraints. For example, in Figure 4, block B5 ’s execution time might depend on previous execution. This means that the CFG must be updated so that all duplicates of B5 aﬀect B8 in

B1

B1 B2

B2

B3

B41

B42

B3 B4

B5

B51

B61

B52

B62

B71

B72

B73

B74

B81

B82

B83

B84

p3

p4

B6 B7 B8

(a)

p1

p2

(b)

Fig. 4. An expanded CFG to enforce same-path relation according to ILP2

142

A. Marref and G. Bernat

the correct way. Consequently, the size of the model (variables and constraints) increases exponentially in the worst case. 5.3

Bounds on Execution Times: ILP3

Another way to express conditional execution-times is to impose bounds on the number of times each single execution time is observed. Assume a block Bi exhibiting θi diﬀerent execution times. The block is expanded as described previously to θi duplicates, in this case Bi1 , Bi2 , ..., Biθi . Then, instead of adding mutual-exclusion information, the bounds xji ≤ ω j (j ∈ [1..θi ], ωj ∈ [0..xi ]) are added to the ILP model together with the constraint x1i + x2i + · · · + xθi i = xi . This way of expressing conditional execution times allows all constraints to be solved by a single run of the model and with expanding only the blocks in question and their respective incoming and outgoing edges. However, this only works provided the bounds on the observation of diﬀerent execution times are available. When the block Bi with variable execution-time is outside any loop i.e. xi ≤ 1, the only bound that can be imposed on its individual execution-times is ∀j ∈ [1..θi ] • xji ≤ 1. This is of no use because during maximization in IPET, all execution counts xji are assigned 0 but one, namely the xji with the largest execution-time. In other words, there is no tightness achieved by ILP3 in blocks Bi which execute once at most since the only execution time that is picked is their largest execution-time ci . The more interesting case is when xi ≤ α, α > 1. Every execution time cji , j ∈ [1..θi ] of block Bi is caused by a speciﬁc combination of basic blocks. To derive bounds on the number of occurrences of the execution times cji , we need to bound the number of times their corresponding eﬀects occur during execution. For example, in Figure 4(b), in order to impose a bound on the number of times the execution time c18 is observed or equivalently the number of times B81 is executed; we need to identify the number of times the eﬀect (x2 > 0 ∧ x5 > 0) occurs during execution. This reduces to bounding the number of times the blocks B2 and B5 are both executed at run time i.e. bounding the execution-count of the subpath p which contains both B2 and B5 . The technique used for this purpose is data ﬂow analysis. Data-ﬂow algorithms are powerful and computationally expensive. 5.4

Informed Search: CLP

In this section we use CLP instead of ILP to model the eﬀect tables of our predicated analysis. CLP has better expressive power since it supports disjunctions and implications. The objective is again to maximize (1). While the solution in ILP is found by search (e.g. branch and bound) and numerical analysis; the solution in CLP is found by search, assignment, and constraint propagation. In short, in order to solve the problem at hand, the CLP solver ﬁrst assigns values to variables in the model. This operation is termed labeling. Then, a consistency check is performed where the current assignment is checked for whether

Predicated Worst-Case Execution-Time Analysis

143

or not it satisﬁes all the constraints. This uses constraint propagation. Finally, a search is performed to move from the current solution to a better solution. CLP allows non-linear constraints i.e. it allows both the execution counts and execution times to be unknowns. Therefore, there is no need to process the time constraints like in ILP1, ILP2, or ILP3. The labeling process instantiates the xi and ci variables at the same time. Labeling the variables vi in the list [v1 , v2 , v3 ] is performed in order i.e. v1 is instantiated ﬁrst, followed by v2 , and ﬁnally by v3 . If v2 for example is related to v1 by some constraint, instantiating v1 ﬁrst might reduce the domain of v2 . This means that the order in which v1 and v2 are labeled aﬀects the search. The same discussion applies to the order in which the values of a variable vi are selected. Labeling can be customised by the user. This is the area that we exploit in order to perform an eﬃcient predicated calculation. Our objective is therefore to derive an eﬃcient labeling strategy that speeds up the search. In the following we describe the rules that we use to guide the CLP search. Variable Order. Blocks Bi with large xi values are amongst the blocks that get labeled ﬁrst. These are the blocks inside loops and we know loops consume most of the execution time of programs. This simple heuristic speeds-up computation as long as there are no timing anomalies [19] associated with the choice of Bi . When Bi has a large local WCET but which leads to a smaller global WCET, then choosing Bi does not speed-up computation. Notice, that labeling the shortest alternative only aﬀects the speed of the constraint search, not the safety of the calculation. Timing anomalies do not occur frequently which means that the heuristic speeds-up computation most of the time. We are currently looking into mechanisms that enable the detection of whether labeling the variables of an alternative may or may not be beneﬁcial in the overall maximization. Blocks Bi with the least number of eﬀect dependencies are are amongst the blocks that get labeled ﬁrst. The reason for this is that in the case when the labeling choice is wrong; the incorrect decision does not propagate to many other variables. Value Order. Since the aim of the search is to maximize the execution time, it makes sense to choose the largest values ci . However, choosing the largest ci values might be a good decision locally but not globally. For example, assume in Figure 4(a) that c1 = c5 = c6 = c7 = c8 = 10, c2 = 5, c3 = 20, c4/2 = 40, and c4/3 = 30. Labeling c4 with c4/2 = c4 is not the correct choice since the longest path does not include B2 . We add one extra column to the eﬀect table ETi of block Bi . The values in the column ci are computed as shown in (6). ci = ci +

|Ψi |

cj • xj > 0

(6)

j=1

The value ci in row v is the sum of ci and the values cj of the blocks Bj ∈ Ψi that execute in row v. The value ci has a more global view about ci and the

144

A. Marref and G. Bernat x2 0 0 1 1

x3 0 1 0 1

c4 c4 30 30+20 40 40+5 -

Fig. 5. The eﬀect table ET4 is expanded by an extra column according to (6)

blocks it will constraint. For example, if the labeling choice at c4 is made based on the value c4 in Figure 5, we choose c4 = 50 which corresponds to c4 = 30. The value of ci can be expressed diﬀerently in terms of ci and past history. However, we found during evaluation that using ci as expressed in (6) leads to correct labeling-decisions in a satisfactory manner. Divide and Conquer. The other method we use to increase the eﬃciency of the search is to divide the model into sub-models. We choose a particular edge (the cut-point ) where we cut the CFG/model into two sub-CFGs/models and solve them separately. The process is recursive and stops where the number of variables and constraints in a sub-model is manageable. If no time constraints cross the cut-point then the cut is free i.e. it induces no pessimism. If there are time constraints that cross the edge then cutting occurs with some pessimism as we loose some execution history. If the cut causes a timing anomaly then the corresponding optimism is added at the end of calculation. The gain in solution time changes from model to another. We witnessed cases where the time was reduced from multiple minutes to few seconds.

6

Discussion and Results

In this section we consolidate our theoretical analysis on the tightness and complexity of the predicated WCET analysis (PWA). The purpose of the evaluation is to: – Show the tightness achieved by using PWA. – Compare the time taken to solve the model using CLP and disjunctive ILP1. 6.1

Experimental Setup

In a ﬁrst step, the source ﬁle is compiled into an ARM (Advanced RISC Machine) binary which is then disassembled and ﬁnally our tool extracts the CFG from the disassembly ﬁle. In a second step, we obtain the WCET and BCET of basic blocks through static/measurement-based analysis. The hardware used comprises a CPU with single-issue in-order pipeline, icache L1, dcache L1, and a static branch predictor. Lastly, we analyse dependencies between basic blocks and derive constraints that cause particular execution times to be observed. The generated constraints are icache constraints only to keep the evaluation focused. After that, we model and solve the constraints in the resulting eﬀect tables using

Predicated Worst-Case Execution-Time Analysis

145

ECLi P S e , a constraint logic-programming engine [2]. The programs used in the evaluation come from the WCET benchmarks available from [24]. 6.2

Tightness Comparison

Table 1 shows the execution times obtained for a subset of the benchmarks using PWA and HMU1 . The icache used has a size of 1k bytes. As can be seen, considerable tightness has been achieved in the estimated WCET for the ﬁrst four programs (select, cover, fdct, ﬁr ) which can be explained by the large number of constraints - relative to the number of blocks - which capture a rich execution history and hence less pessimism is generated. Table 1. WCETs of benchmark programs using PWA and HMU using an icache size of 1k bytes # program blocks time constraints 1 2 3 4 5 6 7 8

select cover fdct ﬁr lms cnt bsort ns

40 599 12 17 134 36 20 22

27 2593 6 4 86 2 4 5

wcet HMU PWA 558627 432803 44801 38081 77759 66975 87822 81742 747776 724752 94672 92912 58179 57539 892708 888148

gain 22.6% 15% 15% 7% 4.3% 1.9% 1.2% 0.6%

Table 2. WCETs of benchmark programs using PWA and HMU using an icache size of 64 bytes # program blocks time constraints 6 7 8

cnt bsort ns

36 20 22

10 9 12

wcet HMU PWA 101280 97792 71314 58568 1028684 966300

gain 3.5% 17.9% 7.2%

The ﬁfth program (lms) - although having a large relative number of constraints - does not score a great WCET tightness using PWA. The program lms has got a big loop which consumes more than half the number of its blocks (73), which leads to many icache conﬂicts given the used icache conﬁguration. The result of this is that there is almost always a block that displaces another block inside this loop and hence most blocks run in their worst execution times. In the last three programs (cnt, bsort, ns) very little improvement has been achieved because of the small number of dependency constraints. The number of generated constraints with respect to icache depends on the cache conﬁguration, block layout in memory, and size of loops. Therefore, dependencies are minimal when the icache can accommodate most loops. To verify the credibility of this 1

HMU is the classic hit/miss/unclassiﬁed icache analysis which unrolls the ﬁrst iteration of every loop. It conservatively assumes that any unclassiﬁed cache access is a miss.

146

A. Marref and G. Bernat

claim, we run the last three programs using a smaller icache (64 bytes) and we obtain Table 2. We witness an increased tightness due to an increased number of dependencies. The programs in Table 2 are small and generate many constraints on a small icache. The same behaviour should be expected for larger programs on larger icache if the structure of the program is similar and the memory layout of basic blocks generates similar icache speed-ups/conﬂicts. In other words, as long as a program generates many execution time dependencies, it is worth using CLP for tighter WCET estimations. The results obtained in Tables 1 and 2 are expected. The predicated analysis cannot be more pessimistic than conventional analysis. The cache accesses that are deﬁnite hits in HMU are also deﬁnite hits in PWA, the accesses that are deﬁnite misses in HMU are also deﬁnite misses in PWA, and the accesses which are unclassiﬁed in HMU are classiﬁed conditionally in PWA. If the estimated WCET by PWA is wcetP W A , and the estimated WCET by HMU is wcetHMU , then (wcetP W A ≤ wcetHMU ) holds. 6.3

Solution Time Comparison

A single instance of the disjunctive ILP1 is solved instantaneously in our case. The reason for this is that the only constraints in the model are the ﬂow preservation and time constraints (i.e. no global constraints). When solving one instance of the model, the LP relaxation ﬁnds an integral solution in around 6μs in average. However, the solution time becomes exponential when we consider all instantiations of the disjunctive ILP1 model e.g. select needs at least 227 runs to ﬁnd the solution (In Table 1, every constraint is expressed using at least one disjunction). The time it takes to run all copies of the model is more than 600 hours. The CLP solving time during evaluation (including other programs) - using uninformed search - did not exceed a few seconds except for cover. The reason for this is that cover contains more than 200 if statements2 statements divided amongst 3 loops which causes lots of execution-time variations. The solution time for cover is rendered few seconds when the search procedure uses the search heuristics described in Section 5.4.

7

Conclusions and Future Work

In this paper we have proposed the use of Prediacted WCET Analysis (PWA) based on Constraint-Logic Programming (CLP) to compute tight values of WCET by using constraints derived through execution-time dependency-analysis. We concluded that the use of CLP is justiﬁed whenever there is a reasonable number of execution-time dependencies which can also be modelled using disjunctive Integer-Linear Programming (disjunctive ILP1) at a very high cost. 2

Our CFG extractor does not handle code with case statements. All case statements are transformed into if before the analysis starts.

Predicated Worst-Case Execution-Time Analysis

147

The nature of PWA enforces path-sensitivity in the estimated WCET because execution times are expressed as conditional outcomes of execution counts, which reduces pessimism signiﬁcantly. The choice of whether or not to use PWA and CLP is dictated by the nature of the program. If execution-time dependencyanalysis reveals lots of constraints, it is worth using PWA and CLP because considerable tightness may be achieved. Also, if the user wants to express complex functional constraints (e.g. A xor B or not C), then CLP is preferred as well for ease of expressing such relations. Using appropriate heuristics in the constraint-satisfaction search reduces the solution time dramatically which makes the approach generally scalable. In a future work, we evaluate the use of ILP1 by equalities and ILP2. In our tool, all calls to subroutines in the program are inlined. We are considering to have a CLP calculation on a per subroutine basis which ought to decrease the solution time of the overall CLP model.

References 1. Schrijver, A.: Theory of Linear and Integer Programming. John Wiley & Sons, Chichester (1986) 2. Apt, K.R., Wallace, M.: Constraint Logic Programming using Eclipse. Cambridge University Press, New York (2007) 3. Bate, I., Reutemann, R.: Eﬃcient integration of bimodal branch prediction and pipeline analysis. In: Proceedings of the 11th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, pp. 39–44 (2005) 4. Bernat, G.: Speciﬁcation and Analysis of Weakly-Hard Real-Time Systems. PhD thesis, Departament de Ci`encies Matem` atiques i Inform` atica, Universitat de les Illes Balears (January 1998) 5. Bernat, G., Burns, A.: An approach to symbolic worst-case execution time analysis. In: Proceedings of the 25th Workshop on Real-Time Programming, Palma, Spain (June 2000) 6. Bernat, G., Newby, M., Burns, A.: Probabilistic timing analysis: an approach using copulas. Journal of Embedded Computing 1(2), 179–194 (2005) 7. Betts, A., Bernat, G.: Tree-based WCET analysis on instrumentation point graphs. In: 9th IEEE International Symposium on Object and component-oriented Realtime distributed Computing (ISORC 2006), Kolon Hotel, Gyeongju, Korea (April 2006) 8. Burguiere, C., Rochange, C.: A contribution to branch prediction modeling in WCET analysis. In: Proceed. of the conf. on Design, Automation and Test in Europe, Washington, USA, pp. 612–617. IEEE Computer Society Press, Los Alamitos (2005) 9. Burns, A., Wellings, A.J.: Real-Time Systems and Programming Languages: ADA 95, Real-Time Java, and Real-Time POSIX. Addison-Wesley Longman Publishing Co., Inc., Boston (2001) 10. Colin, A., Puaut, I.: Worst case execution time analysis for a processor with branch prediction. Real-Time Systems, Special issue on worst-case execution time analysis 18(2), 249–274 (2000) 11. Deverge, J.F., Puaut, I.: Safe measurement-based WCET estimation. In: Proceedings of the 5th International Workshop on Worst Case Execution Time Analysis, Palma de Mallorca, Spain, July 2005, pp. 13–16 (2005)

148

A. Marref and G. Bernat

12. Ermedahl, A.: A Modular Tool Architecture for Worst-Case Execution Time Analysis. PhD thesis, Uppsala University, Sweden (August 2003) 13. Healy, C.A., Arnold, R.D., Mueller, F., Harmon, M.G., Walley, D.B.: Bounding pipeline and instruction cache performance. IEEE Transactions on Computers 48(1), 53–70 (1999) 14. Hugues, C., Rochange, C., Sainrat, P.: On the sensitivity of WCET estimates to the variability of basic blocks execution times. In: International Conference on Real-Time and Network Systems (RTNS), Nancy, France, March 2007, pp. 85–92. INPL (2007) 15. Li, X., Mitra, T., Roychoudhury, A.: Accurate timing analysis by modeling caches, speculation and their interaction. In: DAC 2003: Proceedings of the 40th conference on Design automation, pp. 466–471. ACM Press, New York (2003) 16. Li, X., Mitra, T., Roychoudhury, A.: Modeling control speculation for timing analysis. Real-Time Systems 29(1), 27–58 (2005) 17. Steven Li, Y.T., Malik, S.: Performance analysis of embedded software using implicit path enumeration. In: LCTES 1995: Proceedings of the ACM SIGPLAN 1995 workshop on Languages, compilers, & tools for real-time systems, pp. 88–98. ACM Press, New York (1995) 18. Steven Li, Y.T., Malik, S., Wolfe, A.: Eﬃcient microarchitecture modeling and path analysis for real-time software. In: IEEE Real-Time Systems Symposium, pp. 298–307 (1995) 19. Lundqvist, T., Stenstr¨ om, P.: Timing anomalies in dynamically scheduled microprocessors. In: IEEE Real-Time Systems Symposium, pp. 12–21 (1999) 20. Marref, A., Bernat, G.: Towards Predicated WCET Analysis . In: 8th Intl. Workshop on Worst-Case Execution Time (WCET) Analysis (July 2008) 21. Mitra, T., Roychoudhury, A.: A framework to model branch prediction for worst case execution time analysis. In: Proceedings of the 2nd Workshop on WCET Analysis (October 2002) 22. Muchnick, S.S.: Advanced Compiler Design and Implementation. Morgan Kaufmann Publishers, San Francisco (1997) 23. Puschner, P., Schedl, A.V.: Computing maximum task execution times - A graphbased approach. Real-Time Systems 13(1), 67–91 (1997) 24. M¨ alardalen WCET research group. WCET project/benchmarks (January 2008), http://www.mrtc.mdh.se/projects/wcet/benchmarks.html 25. Rochange, C., Sainrat, P.: A Context-Parameterized Model for Static Analysis of Execution Times. Transactions on High-Performance Embedded Architecture and Compilation 2(3), 109–128 (2007) 26. Stappert, F., Altenbernd, P.: Complete worst-case execution time analysis of straight-line hard real-time programs. Journal of Systems Architecture 46(4), 339– 355 (2000)

Implementing Reactive Systems with UML State Machines and Ada 2005 Sergio S´ aez, Silvia Terrasa, Vicente Lorente, and Alfons Crespo Instituto de Autom´ atica e Inform´ atica Industrial, Universidad Polit´ecnica de Valencia, Camino de vera, s/n, 46022 Valencia, Spain {ssaez,sterrasa,vlorente,alfons}@disca.upv.es

Abstract. Reactive systems are complex systems which behavior can be adequately modeled using the statechart formalism. The UML standard enriches this formalism with object-oriented concepts. However, manual transformation of these expressive models to object-oriented languages is an error-prone process. Model-Driven Engineering approach advocates for an automatic process to translate models into high-level programing languages. This work deals with the conversion of UML State Machines models into Ada 2005 code and the challenges that arise in this process. Keywords: Reactive Systems, Behavioral State Machines, Embedded Systems, Code Generation, Ada 2005.

1

Introduction

A reactive system can be deﬁned as a system that continuously react to stimuli from its environment and change its behavior accordingly to that stimuli. Much of the complexity on designing reactive systems are due to the intricate nature of the reactions to these discrete events from the real world [1]. Although the computational part of a reactive system could be also complex, the event-driven control is considered the most problematic part. A widely accepted approach to deﬁne the behavior of these system is the statechart formalism [2], that adds the notion of hierarchy, concurrency and communication to the conventional state-transition diagrams or ﬁnite state machines (FSM). This extension was adopted as the basis for the behavioral state machines deﬁned in the Uniﬁed Modeling Language (UML) standard [3]. These formalisms allow the software architect to correctly specify the behavior of the system using a set of well-deﬁned concepts and artifacts. But once the reactive system has been adequately modeled using problem-domain concepts, the resulting system model has to be translated to a high-level programming language. Due to the complexity of the modeled concepts, this transformation could be an error-prone process if it is carried out directly by the system developers.

This work is partially supported by Spanish Ministry of Education, Science and Technology under grant TIC2005-08665-C03 and by the U.E. IST Programme - IST 034026.

F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 149–163, 2009. c Springer-Verlag Berlin Heidelberg 2009

150

S. S´ aez et al.

Model-Driven Engineering (MDE) [4] is an emerging approach that addresses the inability of third-generation languages to alleviate the complexity of realworld problems and express problem-domain concepts eﬀectively. This approach combines domain-specific modeling languages to formalize the application structure, behavior and requirements and transformation engines and generators that analyze the models to map expressed concepts into correct-by-construction code. Since standardization of UML, a plethora of design tools have been developed to aid the software developers to adequately model the structure and behavior of computer applications. Much of these tools also incorporate model-to-code plugins for various high-level programming languages such C, C++, Java, Python, etc. However, as these tools are not exclusively targeted for reactive systems, the languages supported and code generated for the models related with this kind of systems is not usually appropriated. A remarkable exception is Telelogic Rhapsody that is able to generate Ada code for embedded applications and allows the software engineers to custom the code generation process through the edition of the conversion rules. The UML language is integrated in a Model-Driven Architecture (MDA) [5] developed by Object Management Group that enriches the designing environment with a series of standards to achieve interoperability among the design tools involved in the software development (XML Metadata Interchange (XMI) [6]) and to manipulate deﬁned models and meta-models (Meta-Object Facility (MOF) [7]). These OMG standards have been used in previous works to support the MDE approach to develop design and transformation tools for deﬁning robotic systems based on a subset of the UML State Machine semantics [8,9]. As stated in these works their main goal is to support a component-based robotic framework called ACRoSET, being the state machine modeling one of the most important steps. The state machine semantics supported by these works have been evolved to support concurrency-related concepts required to model robotic components adequately, and successfully used to generate Ada code to implement the behavior of the components. However important concepts deﬁned in the UML State Machine semantics seems to remain unaddressed in these works. Among these missed capabilities can be found event hierarchies and extensibility, event synchronization mechanisms, deferred events, submachine encapsulation, action deﬁnition language, etc. Also the UML behavioral state machines lack of some important features that will ease the modeling of embedded and real-time reactive systems. Although the existing UML design tools lack of some remarkable features, as mentioned above, they have powerful graphical editors that address the full UML semantics and are able to generate XMI standard speciﬁcation of the described models. Additionally, there are other standard speciﬁcations formats for deﬁning state machines, such StateChart XML[10], that are more adequate to perform textual deﬁnitions of medium-sized state machines. Using as starting point these standard speciﬁcations, this work is centered on developing a ﬂexible and extensible set of open source tools that allow the developers to synthesize Ada code from UML standard models that completely

Implementing Reactive Systems with UML State Machines and Ada 2005

151

describe the behavior of a reactive system. Flexibility is important to smoothly incorporate Model-Driven Development into heterogeneous development teams without requiring the engineers to move to a unique and completely new development environment. Extensibility could allow these engineers to adapt the model speciﬁcation and code generation process to domain speciﬁc requirements. As embedded and real-time systems are two of the main domains where reactive systems are applied, the generation of clean code suitable for statical code analysis has been adopted as an important goal. The rest of this paper is organized as follows: the next section remembers the key concepts of UML State Machines and the main diﬀerences with the usual StateChart diagrams. Section 3 shows how reactive systems behavior can be speciﬁed and the global scheme of the proposed framework. Then an example of a reactive system is described in section 4 that is used to illustrate the Finite State Machine design described in section 5, where all the main challenges of the UML semantics are addressed. The paper ﬁnishes with some conclusions and future work proposals.

2

Key Elements of UML State Machines

As mentioned above, to describe the behavior of complex reactive systems requires some kind of statechart formalism. One of the ﬁrst approaches of this formalism was the Harel statecharts [2]. Statechars describe the dynamic behavior of a set of objects over time. Each object is treated as an isolated entity that interacts with the rest of the system by detecting events and responding to them. Events represents every change that an object can detect and change its behavior, so anything that can aﬀect an object has to be modeled as an event. The behavior of these objects can be modeled as ﬁnite state machine diagrams, where the key concepts are: States, that describes a period of time during the life of an object. There are three diﬀerent kinds of states: basic states, OR-states and AND-states. Basic states represents the bottom of the state hierarchy, i.e. those that have no substates. Or-States and And-States, are composite states. In Or-States only one substate could be active at any time while in And-States one o more states could be active simultaneously. Events deﬁnes that external stimuli that can aﬀect the behavior of an object. Transitions deﬁnes the object response to the occurrence of an event. The event that fires a transition is usually called trigger event. A transition could optionally have a guard condition, that have be accomplished, and/or a list of actions to be executed. Finally, Actions model the ﬁnite state machine activity. Depending on when the action is executed, it can be distinguished between: Entry Actions, that are executed each time the state is entered; Exit Actions, that are executed each time the state is exited; Do Actions, that are executed while the object remains in that state and that can be interrupted by the occurrence of an event; and Transition Actions, that are executed when the corresponding transition is ﬁred. UML State Machines are an object-based variant of Harel statecharts. This extension allows to describe object-based reactive systems by adding some new

152

S. S´ aez et al.

semantics to the previous formalism. The main diﬀerences between elements in both schemes are described next. UML standard allows parametrized events and event hierarchies in order to share a common structure. UML also makes an event classiﬁcation that distinguish four basic kinds of events: signal events, used to communicate objects in an asynchronous manner; call events, used to synchronized objects, since a rendezvous is implicit between calling and called objects; change events, generated when a given guard condition is accomplished; time events, triggered when a timeout associated with a given transition expires; and ﬁnally, completion events, generated when the activity in a given state is ﬁnished. UML standard maintains the concepts about the state hierarchy and states classiﬁcation, and only diﬀers on the used terminology (simple, composite and concurrent states). UML standard also deﬁnes the concept of pseudostate, which is a special kind of transitional state. In addition to well-known initial states, which represents the starting state when the enclosing state is invoked, final states, whose activation indicates the enclosing state has completed its activity, the UML standard adds new pseudostates, as entry and exit points, that facilitate the encapsulation of composite states and submachines.

3

FSM Generation Framework

The goal of this framework is to ensure the correctness of complex reactive system built in Ada 2005, by transforming state machine models in automatic generated code. As shown in Figure 1, the presented framework supports two types of XML-based speciﬁcation ﬁles: SCXML and XMI. From these speciﬁcation ﬁles the FSM Generator allows to obtain a full implementation in Ada 2005. The FSM Generator is the key element of the presented framework. It uses the XML ﬁles describing the state machine model and produces correct-byconstruction Ada code. This paper mainly describes this translation and the challenges that arise from the semantics of the UML state machines.

Fig. 1. FSM design framework

Implementing Reactive Systems with UML State Machines and Ada 2005

153

The functionality of the object is described by means of actions inside the ﬁnite state model. These actions, expressed in an implementation-independent action deﬁnition language, are translated into Ada code by the FSM Generator. To build a complete system, the user has to provide a set of ﬁles where the object actions representing its functionality was implemented. This last step joins the automatically generated code with the user provided packages to build the ﬁnal system. Formats used to specify the ﬁnite state model are described in the next section. 3.1

FSM Specification Formats and Designing Tools

In order to give the framework as much ﬂexibility as possible, we allow the framework to get the state machine speciﬁcation from two diﬀerent kinds of ﬁle: State Chart XML [10] and XML Metadata Interchange [6] format. State Chart XML (SCXML) is an standard that provides a generic statemachine based execution environment based on CCXML and Harel State Tables [2]. This standard has been extended in this work to support the full UML 2 semantics. Although SCXML speciﬁcation ﬁle is mainly supported for textual deﬁnitions of medium-sized FSMs and to quickly test the proposed FSM semantic extensions, an automatic conversion tool is provided to obtain SCXML ﬁles from graphical diagrams deﬁned by Toolkit for Concept Modeling tool (TCM) [11]. XML Metadata Interchange (XMI) format is an Object Management Group (OMG) standard that facilitates interchange of models via XML documents. XMI provides a mapping from MOF [7] to XML. To produce this kind of ﬁle, an UML design environment is required. Usually, these graphical environments are thought, not only to produce State Machine diagrams, but to deﬁne the whole parts of the UML design. Several of the existing UML design environments have been analyzed, focusing our attention on the support of UML 2 standard and their code generation capabilities. Only the Telelogic Rhapsody proprietary tool addresses the Ada code generation for embedded systems. This environment also allows system developers to adapt the UML to code translation process by means of a conversion rules editor. Despite of the great possibilities Rhapsody environment oﬀers, it still lacks of the possibility of extending the UML standard with domain speciﬁc characteristics1 as the ones intended in this work (see section 5.4). The rest of the UML design tools has been analyzed in order to use their capabilities to graphically describe state machines and to export them into XMI format. First tested environment was UniMod, an Eclipse pluggin that allows design Finite State Machines. Eclipse is an open source development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across its entire lifecycle. UniMod plug-in was discarded due to its inability to export the models in XMI format. Umbrello was another rejected application due to: (1) only allow very simple State Machines design, 1

As far as authors know.

154

S. S´ aez et al.

Elevator Moving

Elevator Stopped

Moving Down

OpenDoor, DoorBlocked

Door is Open

after 5s

DoorOpened

Opening Door

[inRequestList(currentFloor)]

OpenDoor, DoorBlocked

[currentFloor = targetFloor]

Stopping

[targetFloor < currentFloor]

entry / motor.SlowingDown

OpenDoor Closing Door

DoorClosed

DoorsCoupled

entry / motor.MotorOn(Down)

exit / motor.Stop

Door is Closed

[targetFloor > currentFloor] / ringDoorBell

[currentFloor = targetFloor]

Moving Up entry / motor.MotorOn(Up)

Fig. 2. Simplified view of the Elevator Finite State Machine

without properties in the transitions, states, etc. and (2) does not export to XMI ﬁles. Some of the applications that could export to XMI ﬁles are BoUML, ArgoUML, and MagicDraw. All of these tools also have a good level of detail in the State Machine design. Just one observation respect these three applications, BoUML and ArgoUML are open source applications, where the possible UML extension implementation can be aﬀorded, whereas MagicDraw is not. Any of the later environments can be used to generate the XMI ﬁle needed as entry to the proposed framework.

4

Elevator Example

Elevators are reactive systems that can be modeled using the ﬁnite state machines formalism. The basic behavior of an elevator is shown in the ﬁgure 2. As it can be seen in the diagram, the elevator can be in two main states: Elevator Stopped and Elevator Moving. Elevator stopped. There are mainly two reasons why the elevator will remain in this state: there are no requests to attend or there are requests to attend, but the elevator’s door is open. As it can be seen in the ﬁgure 2 the only way to change from stopped state to moving state is when the door is closed and there are request to attend. These requests can come from the cabinet or from any ﬂoor. If the targetFloor is equal to the currentFloor, the elevator’s door begins to open, in order to allow people come in or out the cabinet. After a programmed timeout (5 seconds), the door begins to close. Once the door is closed, the elevator could attend the pendent requests. If, while the doors are closing, something cross the doors’ detectors, the doors stop closing and begin to open. The doors will be opened until the detectors are unset.

Implementing Reactive Systems with UML State Machines and Ada 2005

155

Elevator Moving. The currentFloor and targetFloor are used to determine the elevator direction. The elevator will keep moving among ﬂoors until the target ﬂoor is reached. As it can be seen in the 1.1, each time the elevator receives a FloorDetector the currentFloor is updated, and then compared to the targetFloor in order to determined if the elevator keeps moving or changes to the stopped state. Listing 1.1 shows some details about the elevator state machine speciﬁcation in SCXML format. Figures 3 and 4 show the elevator events hierarchy and elevator class diagram used in the model-to-code translation to support action language2 to Ada conversion. Listing 1.1. Fragment of a FSM definition using StateChartXML <state id="ElevatorMoving"> <state id="MovingUp"> <exec expr="TurnOnDirectionLed(Up)"/> <exec expr="motor.MotorOn(Up)"/> <exec expr="TurnOffDirectionLed()"/> <exec expr="currentFloor := currentFloor + 1"/> <exec expr="TurnOnFloorLed(currentFloor)"/> ... <state id="Stopping"> <exec expr="motor.SlowingDown"/> <exec expr="motor.Stop"/>

5

Finite State Machine Design

As stated in [12,8], states machines can be implemented using diﬀerent software approaches or design patterns: (1) a big if..else (or case) construct that statically demultiplex into code blocks to be executed depending on the current state and the transition being ﬁred; (2) a look-up table where all possible states and transitions are related; or (3) an object oriented design pattern, called State pattern, that models an object whose behavior depends on its internal state. This section analyzes how these alternatives can ﬁt into the UML State Machine semantics and the implications for the code structure in an object-oriented language such Ada 2005. 2

The language used to describe the actions associated with a fired transition.

156

S. S´ aez et al. FSMEvent Dispatch()

DoorsCoupled

<<signal>>

<<signal>>

<<signal>>

<>

FloorSignal

DoorSignal

ElevatorSignal

OperatorRequest

FloorDetected

OpenDoor

ElevatorRequest

TechnicalStop

floor : FloorRange

DoorClosed

DoorOpened

DoorBlocked

CabinetRequest

FloorRequest sense : ElevatorSense

Fig. 3. Elevator events hierarchy

FSMControlledType

<<enum>> ElevatorSense Up Down

ElevatorType currentFloor : FloorRange targetFloor : FloorRange direction : ElevatorSense

ElevatorMotor

motor

inRequestList(floor : FloorRange) : Boolean

motorOn(dir : ElevatorSense)

addRequestList(dir : ElevatorSense, floor : ElevatorSense)

motorOff()

removeRequestList(floor : FloorRange) nextRequestList() : FloorRange doorRingBell()

Fig. 4. Elevator user-defined class

As stated above, the UML State Machines are an object-based variant of Harel statecharts [2,3]. This object-orientation nature extends the statechart formalisms in few senses including event class hierarchy, the object-oriented semantics of the action language and, in the latest revisions of the UML standard, with improved encapsulation capabilities. Although the object-oriented nature of the code to be executed does not impose any restriction on the state machine internal design, the extensibility of the events involved in the behavior of a state machine limits the possible implementation approaches that can be used. An event instance can ﬁre any transitions where it appears as the trigger, if the corresponding guard is accomplished. The existence of an event class hierarchy that can be extended implies that each event instance can also ﬁre any transition where the trigger is one of its ancestors. This dynamic behavior does not ﬁt with statically limited software structures such look-up tables. In the case of if..else, this can be achieved by means of a lot of ugly membership conditions. A more natural implementation can be obtained using the operation dispatching

Implementing Reactive Systems with UML State Machines and Ada 2005

157

capabilities of the underlying programming language, as the ones provided by the Ada language through the use of abstract or class-wide tagged types. On the other hand, when the state pattern is implemented using an objectoriented language, an usual tend is to build a dynamic structure of related objects that represents all the FSM modeled concepts such states, regions, transitions, events, actions, etc. As an example, a state machine could be implemented by a lightweight task that dispatches received events to the current state. Each state object can decide which events are accepted, rejected, deferred or passed through to a possible set of substates, and informing back to the controller object if current state has changed [12]. Also the entry, exit and do activities of a given state could be represented by means of object methods or lists of activity objects. From the design point of view, the resulting structure could seem quite ﬂexible and elegant, including the ability of modifying the state machine behavior at run-time. However, this ﬂexible approach disturbs the possible static analysis of the resulting code that some real-time embedded systems could require. This work proposes a software design that merges two of the above described structures: case sentences and dynamic dispatching of events, together with an automatically generated event class hierarchy. Next sections detail the structure of the generated code and how the UML State Machine semantics are addressed. 5.1

Code Structure

Systems based on code generated from a model description are usually composed by two diﬀerent pieces of software or components: (1) a support library shared between all the state machines; and (2) the generated code for the speciﬁed state machine model. How to divide the semantics of the systems between these two diﬀerent components has to be decided at the ﬁrst stages of the design of the generation process. In the proposed approach these FSM components are represented by two main packages. The Finite State Machine package which oﬀers common support to all the FSM in the system and the user deﬁned package where main FSM functionality are implemented. The former one is decomposed in two child packages: Controller and Events. The Controller package implements the main FSM functionality including the FSM active objects and speciﬁes the common interface, by means of abstract operations, that all FSM have to implement. The Finite State Machine support package

Elevator Finite State Machine

Finite State Machine Events

Controller

Events

Task

Fig. 5. Finite State Machine package diagram

158

S. S´ aez et al.

Events package implements the FSM event queue management and the abstract root event FSM Event. The user deﬁned package will contain two automatic generated child packages, Finite State Machine and Events, where control ﬂow of the FSM and events hierarchy are implemented respectively, and any extra child packages the user decide to use for allocating the context functionality of the FSM. All the objects and operations referenced in the FSM actions or activities have to be solved in these later packages. In contrast with related works [8,9], no code template or skeleton is generated for state activities or transition actions, since this implies that any change on the FSM model once the code template is already modiﬁed gives rise to a complicate merge process. In contrast, this work follows the UML proposal and a simple action language is deﬁned. Once this action language is translated to Ada language using the user deﬁned class diagrams (see Figures 3 and 4), the generated code only uses references to attributes and operations of these user-deﬁned objects, that can be independently implemented by the developers without any disturbance from the code generator tool. Next sections detail the FSM semantics managed on each package and how the generated code copes with the main challenges that arise from the UML FSM semantic.

5.2

Finite State Machine Algorithm

The UML State Machines provide some features that are not so commonly used such orthogonal regions, that represents concurrent states in the FSM, and the do activities, that allow to execute long-term activities while the object remains in a given state. These do activities have to be aborted if a received event gives rise to a state change. These features are not so commonly used when implementing reactive systems, but they can complicate the FSM algorithm due to multiple running activities that can require an Asynchronous Transfer Control when a concurrent state is left. Taking into account that the use of these characteristics can be detected at design/generation time, the proposed framework provides several versions of the FSM active objects. Each version gives support to diﬀerent kinds of FSM, using always the simplest implementation for the required characteristics of the state machine model. The generic algorithm that should be accomplished by any UML compliant state machine can be summarized as follows: (1) retrieve and dispatch the next even; (2) select a transition among the enabled ones, if any; (3) run the executable contents associated to the selected transition in the following order: exit activities, transition actions, entry activities; and ﬁnally, (4) start the do activities in the target state conﬁguration, if any. As mentioned above, the code design used to implement the state machine models also aﬀects the way the FSM algorithm is distributed among the diﬀerent software components. This work allocates step (1) and support for step (4) into the support package Finite State Machine, while steps (2) and (3), and initiation of do activities are allocated in the generated code.

Implementing Reactive Systems with UML State Machines and Ada 2005

159

The following code listing shows the fragment of the main loop of the FSMTask in the Finite State Machine.Controller package that implements the event retrieval and dispatching, including the time events generation. Listing 1.2. Fragment of FSMTask main loop if Transition then −− Flush deferred events from previous state to internal event queue Controller .Events.Flush Deferred Events; end if; −− Check for a new event if Controller .Exists Timeout Event then select Controller . Events.Dequeue Event(Event); or delay until Controller.State Timeout; Event := new FSM Timeout Event; end select; else Controller .Events.Dequeue Event(Event); end if; −− Dispatch event Event.Dispatch(Controller, Transition ); −− Release the invoking procedure of a Call Event if Event.Get Sync Type = Call Sync then accept Wait Completion(Event.Get Event Id); end if;

All the challenges that could arise from the semantics associated with the event processing deﬁned in the UML standard are solved at code generation time. In such a way, the selection of conﬂicting transitions and event ﬁring priorities for a given state are managed by the code generation tool and statically coded in the generated procedures. Although some conditions have to be obviously evaluated at run-time (e.g. transition guards), the generation tool copes with all the decisions that are known at the design/generation stage, such group transitions, exit and entry actions to be executed, completion and change events, etc. An example of an event dispatching sequence and the executed code is shown next.

:FSMTask

ElevatorFSM:FSMController

DequeuEvent DoorsCoupled:FSMEvent

Elevator:ElevatorType

ElevatorMoving:Stopping exit from ElevatorMoving:Stopping

Dispatch() processDoorsCoupled()

Stop()

doorRingBell()

entry in ElevatorStopped

ElevatorStopped:DoorIsClosed

Fig. 6. FSM event dispatching example

Motor:ElevatorMotor

160

S. S´ aez et al.

Event dispatching. The proposed development framework shown in ﬁgure 1 does not use the event class diagram exclusively for action language conversion to Ada language (see Figure 3). This model is also used to implement the corresponding event tagged types where only the events used in the state machine model overwrite their dispatching operation with the appropriated code. In such a way, used events know what state machine code have to execute. Any user extended event will inherit the dispatching operation of the automatically generated event and, therefore, the extended event behaves as its well-deﬁned ancestor. The automatically generated events can also use an upward conversion to use the dispatch operation of the next used ancestor, if the more speciﬁc event is not accepted in the current state. The sequence diagram depicted in Figure 6 shows how the event dispatching procedure is performed and how the user deﬁned code is ﬁnally executed as part of a transition process. The following generated code in the Elevator.Events package shows how the Dispatch operation is overwritten and how this generic operation is converted into a concrete procedure invocation on the actual Elevator FSM object. −− DoorsCoupled event dispatching procedure procedure Dispatch (Event: in out Doors Coupled Event; FSM: access FSM Controller’Class; Transition: out Boolean) is Object: Elevator FSM Ptr := Elevator FSM Ptr(FSM); begin Object.Process Doors Coupled(Event’Access, Transition); end Dispatch;

As explained above, the Elevator.Finite State Machine package contains the procedure that implements the transition from ElevatorMoving:Stopping state to ElevatorStopped:DoorIsClosed state. Figure 1.3 show how the internal transitions “exit / motor.Stop” and “/ ringDoorBell” have been converted to Ada code. Completion and Change events. Completion and change events can ﬁre transitions that only requires a given guard condition to be evaluated to true. Although change events can be potentially ﬁred at any time, the semantics of this implementation assumes that guard conditions only can change upon events arrival. The generation tool only puts code to generate the internal events that forces the evaluation of completion or change events when such an events are used in transitions from the current state. The next code example shows how the completion event is sent when the transition to ElevatorStopped:DoorIsClosed state is ﬁnished, since no entry action or do activity exists. Time events. The dispatching of time events represented by triggers of the form after N are implemented by means of a timed entry call. As it is shown in listing 1.2 the timed entry call to dequeue an external event is only used if the current state of the FSM has previously reported the existence of a time event. If no external event arrives before the speciﬁed timeout expires, the timed transition is executed through the FSM Timeout Event event that invokes the

Implementing Reactive Systems with UML State Machines and Ada 2005

161

abstract procedure Controller .Process Timeout Event inside the dispatching operation. The state timeout is set as an absolute time using the relative delay N and the current time once the State boundary is traversed. Deferred events. Any request for deferring an event produces the event to be queued in the deferred event queue of the FSM, if no other concurrent state accepts that event. The deferred event queue is ﬂushed into the internal event queue each time the FSM changes the current state as shown in listing 1.2. This process is repeated for deferred events until the event is processed in a given FSM state or no further deferred. Listing 1.3. DoorsCoupled event procedure Process Doors Coupled (Self: in out Elevator FSM; Event: access Doors Coupled Event’Class; Transition: out Boolean) is begin case Self . FSM Current State(Top) is when Stopping State => −− Transition to next state Transition := True; −− Stopping exit actions Self .Elevator.Motor.Stop; −− ElevatorStopped initial actions Self .Elevator.Ring Door Bell; −− DoorIsClosed internal completion event Self .Send Completion Event(); −− Target state Self .FSM Current State(Top) := Door Is Closed State; when others => −− No transition Transition := False; end case; end Process Doors Coupled;

Event synchronization. UML deﬁnes two kind of events depending on the synchronization characteristics: signal and call events. The sender of a signal event is resumed as soon as the event is send to the FSM and adequately queued. The sender of a call event has to wait until the event is processed and the target state of the corresponding ﬁred transition is reached, if any. As a defer action can only be speciﬁed for a whole type of events, the events of the same type always maintain the ﬁrst-in-ﬁrst-out order. Such a behavior allows the call events to be synchronized using a family of entries in the FSMTask as shown in the following code. The acceptance code is placed after the event processing code as can be observed at the end of listing 1.2. −− Send an external event to the FSM procedure Send External Event (Controller: in out FSM Controller; Event: Event Ptr) is begin Controller .Events.Insert External Event(Event); −− Event synchronization, if required if Event.Get Sync Type = Call Sync then Controller . Thread.Wait Completion(Event.Get Event Id); end if; end Send External Event;

162

5.3

S. S´ aez et al.

Model to Ada Transformation Tool

As described above, the proposed framework allows to specify the state machine and data model in several XML formats. This avoids design tool dependencies that can limit the framework usability and portability. Another key point to obtain portability is the language used to implement the model-to-code conversion. In this work, the portability and development time have been key aspects to choose an scripting language, such PHP, to implement the transformation tool. PHP is not only a very powerful language with strong support for XML document processing, but also is portable and widely used, what makes easier the framework extensibility. Additional helper tools have been developed to convert generic graphs and XMI descriptions into SCXML speciﬁcations. 5.4

Extending UML Standard to Model Real-Time Systems

Although UML State Machines allow to deﬁne the complete behavior of a reactive object or system, some features are missed if real-time reactive tasks have to be modeled. Some of these features are being tested using the presented framework, as the use of tagged values to manage diﬀerent task priorities during the execution of the FSM.

6

Conclusions

The promising Model-Driven Engineering approach is followed in this work to transform reactive system models into object-based computer programs. The UML State Machines has been successfully used as the standard formalism to the describe the behavior of this kind of systems. The proposed development framework uses standard XML-based speciﬁcations to describe the state machine behavior. These speciﬁcations ﬁles are analyzed, validated and transformed into a clear structure of Ada packages where the behavior of the reactive system is completely deﬁned. The transformation tools provide an action language that allows to describe system actions and activities in an object-oriented fashion. This action language is transformed into Ada code that references the user-deﬁned procedures, allowing a perfect interaction between the code deﬁned by the developers and the code automatically generated from the state machine model. Although the transformation process still requires a more robust parsing engine, this ﬁrst approach encourages the authors to complete the framework to offer a full set of UML-compliant development tools in the ﬁeld of reactive systems and to propose UML extensions that ﬁts the real-time domain requirements. Future research lines also include some extensions of the transformation tools to add debug and tracing capabilities to the generated code that oﬀers additional support to the static analysis of the ﬁnal system.

Implementing Reactive Systems with UML State Machines and Ada 2005

163

References 1. Harel, D., Pnueli, A.: On the development of reactive systems. Logics and models of concurrent systems, 477–498 (1985) 2. Harel, D.: Statecharts: A visual formalism for complex systems. The Science of Computer Programming 8(3), 231–274 (1987) 3. Object Management Group: Unified Modeling Language (OMG UML) V2.1 (november 2007), http://www.omg.org/spec/UML/2.1.2 4. Schmidt, D.C.: Model-driven engineering. IEEE Computer 39(2), 41–47 (2006) 5. Object Management Group: Model Driven Architecture Guide Version v1.0.1 (2003), http://www.omg.org/docs/omg/03-06-01.pdf 6. Object Management Group: MOF 2.0/XMI Mapping, Version 2.1.1 (2007), http://www.omg.org/spec/XMI/2.1/PDF 7. Object Management Group: Meta-Object Facility, MOF (2004), http://www.omg.org/spec/MOF/2.0/PDF ´ 8. Alonso, D., Vicente-Chicote, C., S´ anchez, P., Alvarez, B., Losilla, F.: Automatic ada code generation using a model-driven engineering approach. In: Abdennahder, N., Kordon, F. (eds.) Ada-Europe 2007. LNCS, vol. 4498, pp. 168–179. Springer, Heidelberg (2007) ´ 9. Alonso, D., Vicente-Chicote, C., Pastor, J.A., Alvarez, B.: Stateml+ : From graphical state machine models to thread-safe ada code. In: Kordon, F., Vardanega, T. (eds.) Ada-Europe 2008. LNCS, vol. 5026, pp. 158–170. Springer, Heidelberg (2008) 10. Barnett, J.: State Chart XML (SCXML): State Machine Notation for Control Abstraction (May 2008), http://www.w3.org/TR/scxml/ 11. Wieringa, R., Dehne, F.: Toolkit for Conceptual Modeling (TCM), http://wwwhome.cs.utwente.nl/~ tcm/ 12. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (1994)

Modelling and Evaluating Real-Time Software Architectures José L. Fernández Sánchez and Gloria Mármol Acitores Industrial Engineering School José Gutierrez Abascal 2, 28006 Madrid (Spain) [email protected]

Abstract. We describe the tool supported approach we developed for real-time systems modelling and schedulability analysis performed at the architecting phase of the software lifecycle. This approach integrates the “Pipelines of Processes in Object Oriented Architectures” (or PPOOA for short) method and tool for architecting real-time systems using UML notation, with the Cheddar tool for simulation and schedulability analysis of real-time software intensive systems. PPOOA and Cheddar were developed independently, so we have to adapt PPOOA, the method and tool we had developed, to be integrated with the Cheddar tool developed by the University of Brest. The goal of the paper is to show how this approach can be applied seamlessly to the architecting of small and medium real-time systems, identifying and solving concurrency problems at the architecture phase thus saving later testing and debugging efforts. An illustrative example of modelling and evaluation of an elevator control system is presented.

1 Introduction The gap between real-time systems research and industry is great today. A recent survey presented by Embedded Systems Design Europe shows that UML adoption remains extremely low at 16% with no expected upturn. This is disappointing after so many years of pushing by some many people and companies. Effort devoted to trial and error in embedded systems development is still at 25%. Training in well established practices is indeed lacking and everybody has his personal definitions and best practices. Traditional development of software intensive real-time systems (RTS) addresses functional correctness, introducing system efficiency issues later in the development process, for example in the testing stage of the development cycle. This approach oriented to the code level of the system does not take into account the fact that problems related to missed deadlines in a RTS may require considerable changes in the design, for example at the architecture level, or even worse at the specification level of the requirements. The research community has increased their interest in approaches that propose the use of models to characterize the behaviour of software intensive systems. These approaches are based on the existence of a performance model suitable integrated F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 164–176, 2009. © Springer-Verlag Berlin Heidelberg 2009

Modelling and Evaluating Real-Time Software Architectures

165

with the system software artefacts and the evaluation of the performance model as the means to obtain the system evaluation. The various approaches for model-based performance prediction differ in several dimensions. An extended review of model-based performance approaches is documented by Balsamo. Balsamo classifies the approaches using three indicators: the integration level of the software model with the performance model, the level of integration of performance evaluation in the software life cycle, and the automation degree of the approach for performance prediction [1]. Here we summarize some of these approaches. The main groups of approaches are: 1. 2.

3.

4.

5.

6.

Queueing based. In these approaches, they represent the key computer system resources as queues and servers. Schedulability Analysis. Rate Monotonic Analysis (RMA) is a quantitative analysis technique for ensuring that a set of fixed-priority processes can be scheduled on a processor, so that no process ever misses its execution deadline. A case study of the application of RMA to Unified Modelling Language (UML) models can be found in Saiedian [7]. Process-Algebra. Stochastic extensions of Process Algebras associate exponentially distributed random variables to actions, and provide the generation of a Markov chain out of the semantic model of a system. Petri-Nets. A Petri net consists of places, transitions and directed arcs. Petri nets have been and are being used in many areas of data processing for the modelling of hardware, communication protocols, parallel programs and distributed systems. Simulation. Currently, the performance evaluation of a RTS is mainly done using simulation or trace based simulation. In general, simulation provides estimates of the average RTS performance. Stochastic processes. These approaches consider generalized stochastic processes where general distributions are allowed and the Markovian property is only partially fulfilled.

We think that the balance between the formality level of an approach and its easy adoption is the main issue for its success. The main purpose of the paper is to show how the PPOOA model based approach combined with the Cheddar schedulability analysis and simulation, can be applied seamlessly to the architecture and evaluation of small and medium real-time systems, identifying and solving concurrency problems at the architecture phase, thus saving later testing and debugging efforts. An illustrative example of modelling and evaluation of an elevator control system is presented. Making easy its adoption by small and medium embedded systems industries is one of the main goals of the presented approach. The paper introduces the PPOOA modelling method and tool. The Cheddar schedulability and simulation tool, developed by the University of Brest (France), is also briefly described. An illustrative and complex enough example of an elevator control system is presented. We describe its architecture and the evaluation of its real-time behaviour. To conclude we summarize the benefits of this approach for the embedded systems industry.

166

J.L. Fernández Sánchez and G. Mármol Acitores

2 PPOOA and Cheddar for the Modelling and Evaluation of RTS Architectures In the next paragraphs we describe the approach we developed for real-time systems modelling and models evaluation. This approach is founded in the model based development paradigm and the real-time systems schedulability theory. Following we describe: PPOOA method and tool, Cheddar tool, and the PPOOA and Cheddar building elements mapping for tools integration. 2.1 PPOOA PPOOA is an architecture style for real-time systems. As an architectural style it supports a vocabulary of building elements and design constraints for their use in architecting a RTS. PPOOA was implemented as an extension of UML [3]. Here we described briefly the main building elements considered in PPOOA: •

•

•

•

•

•

Domain_Component . The domain component is an element of the architecture that responds directly to the modelled problem. This component does not depend on hardware or user interface. Its instances respond to the “classic object” in object oriented design. The domain component does not need an independent execution flow. Structure. A structure is a component that denotes an object or class of objects characterized as an abstract state machine or an abstract data type. Typical examples are: stack, list, ring and others. Algorithmic component. Algorithmic components or utilities are elements of the architecture that perform calculations or transform data from one type to another but separated from its structural abstraction. They are typically represented by data classification components or data processing algorithms. Process. The process is a building element of the architecture that implements an activity or group of activities that can be executed at the same time as other processes. Its execution can be scheduled. A process may be periodic or aperiodic. Controller. The controller object is the building element responsible for initiating and managing directly a group of activities that can be repetitive, alternative or parallel. These activities can be executed depending on a number of events or other circumstances. The controller is a complex component which may contain a process, a structure for maintaining state information and a dispatching table. Coordination mechanism. Coordination mechanisms support two major issues of real-time systems: synchronization of flows of activities and asynchronous communication between the components of the system. Coordination mechanisms considered in PPOOA style are buffers, semaphores, transporters, Ada rendezvous and others [3].

PPOOA describes the RTS architecture using two views that may be supported by one or more diagrams; one view is the static or structural representation, and the other view is the dynamic or behavioural view of the system. The PPOOA architecture diagram is a platform independent model that is used instead of the UML component

Modelling and Evaluating Real-Time Software Architectures

167

Fig. 1. Asynchronous and synchronous communication representation in PPOOA

diagram to describe the structural view of the RTS architecture. The architecture diagram addresses "logical components" representation and the composition and usage relationships between them. Coordination mechanisms used as connectors, are also represented. The visual notation in PPOOA extends UML with new stereotypes for coordination mechanisms. Asynchronous message communication between two processes is represented by using a FIFO queue or buffer. Synchronous message communication is represented using a combination of a FIFO queue of capacity one and a semaphore (See Figure 1). The behavioural view of the architecture is represented by modelling each system response to a stimulus that may be either external, internal or timer event. A system response is modelled using the PPOOA Causal Flow of Activities (or CFA for short) technique and represented using UML activity diagrams. A CFA is a causality flow of activities triggered by an event. The term causality flow means cause-effect chains that cut across many components of the system architecture. This chain progresses through time and executes the activities provided by the system components until it gets to an ending point. In general, there can be several active CFAs at a moment and they can also interact with each other. It is also possible that two instances of the same CFA coexist. The CFA instances can stop at certain waiting points where there is coordination with other instances. At these points, coordination mechanisms or resources with concurrent accesses are located. We implemented PPOOA on the top of Microsoft Visio tool, considering the extension mechanisms of the tool, and the PPOOA metamodel created as an extension of UML metamodel [3]. 2.2 Cheddar Cheddar is a framework implemented in Ada which provides tools to check if a realtime system meets its temporal requirements [8]. The framework is based on the realtime scheduling theory and it is an open source initiative.

168

J.L. Fernández Sánchez and G. Mármol Acitores

With Cheddar a real-time system is defined by a set of processors, tasks, buffers, shared resources and messages. Cheddar provides real-time feasibility tests in the case of monoprocessor, multiprocessor and distributed systems. The first feasibility test consists in comparing the processor utilization factor to a given bound. The second feasibility test consists in comparing the worst response time of each system task with its deadline. Cheddar also provides a simulation engine which allows the engineer to describe and run simulations of specific real-time systems. In the Cheddar framework a real-time system is defined by a set of processors, buffers, shared resources, messages and tasks. Tasks may be cyclic or aperiodic. Tasks can be periodic or can be activated with a random Poisson distribution used to model random aperiodic arrivals pattern. 2.3 Implementation of PPOOA-Cheddar Interoperability The PPOOA-Cheddar implementation is based on the data sharing integration approach and relies on the use of XML based architecture specification files. The implementation of the PPOOA-Cheddar collaboration is based on the mapping of the building elements. The real-time systems building elements represented in both tools metamodels are mapped. The mapping allows their transformation. Since one foundation of both tools is the real-time systems scheduling theory, the mapping presented in table 1 was easily implemented. Table 1. PPOOA and Cheddar building elements mapping

PPOOA

Cheddar

Process or Controller

Task

Bounded buffer Domain component, algorithm component, structure (Domain component, algorithm component or structure) + Semaphore

Buffer Resource

Shared resource

We developed an executable or Visio add-on to access the PPOOA Visio tool repository and identify the building elements used in the RTS architecture, and the usage dependencies between these building elements. The add-on generates automatically the XML file of the specification of the RTS architecture. This file is then processed by the Cheddar schedulability and simulation tool. A previous paper describes more extensively how the tools interoperability was implemented [4].

3 Example of the Application of the PPOOA-Cheddar Approach To illustrate the approach we propose, we rearchitected a realistic example of an elevator control system described previously by Gomaa [5].

Modelling and Evaluating Real-Time Software Architectures

169

The system controls a single elevator which responds to requests from elevator passengers and users at various floors. Based on these requests and the information received from floor arrival sensors, the system builds a plan to control the motion and stops of the elevator. We consider a ten floor building, so for the building elevator there are: • • • • • •

10 arrival sensors, one at each floor in the elevator shaft to detect the arrival of the elevator at the corresponding floor. 10 elevator buttons. An elevator passenger presses a button to select a destination. The elevator motor controlled by commands to move up, move down and stop. The elevator door controlled by commands to open and close it. Up and down floor buttons. A user in a floor of the house presses a floor button to request the elevator. A corresponding pair of floor lamps which indicate the directions which have been requested.

Fig. 2. Use cases diagram of the elevator control system

We represent the system use cases in Figure 2 and the domain model in Figure 3. Use cases represented in Figure 2 are the main interactions of the elevator control

170

J.L. Fernández Sánchez and G. Mármol Acitores

system and the external actors: elevator users and devices. A use case representing a safety concern related to floor detection error is also considered. Floor detection error is the most frequent safety incident in the elevators of Europe, 781 safety problems related to floor detection were registered from 2001 to 2004 in the operational elevators in Europe [6]. Common categories of concepts we considered in the domain model were tangible things, places and events; but for the sake of brevity, we can not describe them textually here. Use cases and domain model were developed in the requirements and domain analysis lifecycle phases and are used as inputs to the architecting phase developed here using PPOOA method and tool. As an example the description of the use case UC 1 Request elevator is shown in table 2. The complete description of the use cases and the classes of the domain model is presented in the technical report of the example that can be obtained by request to the authors. Table 2. Example of use case description

UC 1. Request elevator Precondition: User is at a floor and requests the elevator Description: 1. The system receives an up request 2. The system adds the request to the floors to visit 3. If the elevator is stationary then the system dispatches the elevator (UC3) 4. Repeat until Postconditions: Elevator has arrived at the floor in response to the user request Alternatives: The system receives a down request

Fig. 3. Domain model of the elevator control system

Modelling and Evaluating Real-Time Software Architectures

171

Based on observation of real systems, when the elevator is operational and moving, there is one floor arrival event per 2000 millisecond. We estimated that the minimum interarrival time of an elevator button request is 500 milliseconds and the minimum interarrival time for a floor button request is 200 milliseconds. Typically the hardware characteristics of the I/O devices are that the elevator buttons and floor buttons are asynchronous. The other input devices such as motor and door are passive. Figure 4 shows the PPOOA architecture diagram of the elevator control system we architected. In the diagram we can see the architecture we built which contains two controllers, five process components, three domain components, one structure, four semaphores and six buffers. So the complexity of the architecture to be evaluated is enough for illustrative purposes. The main components represented in the architecture diagram of Figure 4 are: • • • • •

•

•

• • • •

Monitor_Floor_Arrival_Sensors. It is a process component which monitors the floor arrival sensors. Monitor_Elevator_Buttons. It is a process component which monitors the elevator buttons. Monitor_Floor_Buttons. It is a process component which monitors the floor buttons. Elevator_Manager. It is a controller which handles elevator users and passenger’s requests. Elevator_Controller. It is a controller which handles one by one either an Elevator_Manager command or a floor arrival event, sending the corresponding commands to the elevator motor and door interfaces. Elevator_Status. It is a domain component which knows the elevator current floor and the direction of movement. Since it is a shared component, it is protected by a semaphore or mutex. Elevator_Plan. It is a structure which stores the information regarding the next elevator stop. Since it is a shared component, it is protected by a semaphore or mutex. Monitor_Floor_Lamps. It is a process component which monitors the floor lamps. Monitor_Direction_Lamps. It is a process component which monitors the direction lamps. I_Door. It is a domain component which is the interface of the elevator door. I_Motor. It is a domain component which is the interface of the elevator motor.

An activity diagram is used to represent each CFA or response of the elevator control system. Several instances of the same CFA can coexist simultaneously. For the elevator control system we identified the following system responses and represented them using UML activity diagrams with swimlanes: • • • • • •

CFA 1: Request floor from elevator. CFA 2: Request elevator from floor. CFA 3: Update current floor. CFA 4: Stop elevator at floor. CFA 5: Dispatch elevator to next destination. CFA 6: Bad floor arrival sensor event.

Fig. 4. Architecture diagram of the elevator control system

172 J.L. Fernández Sánchez and G. Mármol Acitores

Modelling and Evaluating Real-Time Software Architectures

173

As an example we show in Figure 5 the CFA 3: “Update current floor”. The CFA shows the actions implementing the system response to the floor arrival sensor detection event that is produced each time the elevator passes a floor. The protocols followed to achieve synchronous message communication are also represented as acquire and release operations on the corresponding binary semaphore. The allocation of actions to the architecture components performing them is also shown. It is important to notice that the response includes all the data processing, independently of where the code will be located. Many times, parts of the response are considered overheads. Issues such as interrupt management, device management, context switching, remote servers and system calls, are considered as part of the response.

Fig. 5. CFA modeling system response to the floor arrival sensor detection event

The smallest division of a response is an action. Due to scheduling requirements, the computation that takes place in an action cannot cause changes in the system resources allocation. The scheduling points are each of the time instants where decisions relative to system resources allocation are made. When the software engineer has completed the software architecture models in PPOOA-Visio, he or she can execute the PPOOA-XML add-on. This add-on performs the identification of the different components of the system architecture (tasks, buffers and resources) and the dependencies among them. This information is described in an XML file which is used as an input to the Cheddar tool. The software engineer has to estimate the execution period and capacity of the tasks, see table 3 below, and also the time instant each task begins using each buffer and resource. The CFAs or system responses are the inputs used for this usage estimation.

174

J.L. Fernández Sánchez and G. Mármol Acitores

For the evaluation we considered all the tasks as periodic. We transformed aperiodic tasks processing requests to periodic polling tasks with a polling period based on the particular button request deadline and the task capacity. Cheddar provides two kinds of RTS evaluations: feasibility tests and a scheduling simulation engine. Feasibility tests allow the software engineer to predict temporal behaviour without computing the scheduling of the application [8]. The Cheddar screen of results obtained for the elevator control system is shown on Figure 6. The first feasibility test result, based on processor utilization fails, but this result is inconclusive. The second feasibility test based on worst case task response time is feasible: all task deadlines are met. So we can conclude that the elevator control system task set is schedulable for the proposed architecture and execution times estimation. Table 3. Estimation of task capacity and period Task name

Elevator_Controller Elevator_Manager Monitor_Floor_Lamps Monitor_Elevator_Buttons Monitor_Direction_Lamps Monitor_Floor_Arr_Sensors Monitor_Floor_Buttons

Type

Capacity

Period

Deadline

periodic periodic periodic periodic periodic periodic periodic

20 50 5 2 5 2 4

50 100 1000 500 500 1000 200

50 100 1000 500 500 1000 200

Fig. 6. Cheddar results of the shedulability analysis of the elevator control system

Modelling and Evaluating Real-Time Software Architectures

175

Additionally Cheddar offers a simulation engine which computes the scheduling of the application. When the simulation is executed, see the top part of Figure 6, Cheddar determines for each system task and during the simulation time: number of task preemptions and context switches, blocking times and the missed deadlines. It is important to emphasize that Cheddar tool computes automatically blocking times for each system task. It is a very important tool feature to avoid missing RTS deadlines due to unbounded blocking problems related to bad design practices, for example those related to the access protocols followed to use shared resources or priority assignments that can produce priority inversion situations. This early detection of problems related to concurrency issues is one of the main strengths of the PPOOA-Cheddar approach presented here.

4 Conclusions The evaluation of real-time systems at earlier phases of their development is possible and suitable. The architecture structural and behavioural views may be used to perform the detection of unbounded blocking and the schedulability analysis to identify possible missed deadlines. Expensive testing and debugging effort may be saved. A tool based approach for architecting and schedulability analysis, and execution simulation has been presented here. The tool integration is based on the tools metamodels mapping and on the data sharing integration approach [4]. This modelling and evaluation approach is based on the RTS theory. It is rigorous enough since it is supported by scheduling theorems. It is easy to adopt because it is based on the use of diagrams that appeal to practitioners and help them tackle complex concurrent software architectures. The strengths of the PPOOA-Cheddar approach are: • • • • •

•

•

Explicit representation of the synchronization and communication mechanisms used in the RTS architecture. Support for periodic, aperiodic and sporadic processes in a platform independent model. Support for synchronous and asynchronous communication between processes. Allows the control of input and output jitter. A complete and rigorous representation based on UML activity diagrams of the system responses including the representation of the access protocols to the shared resources. This allows the estimation of the start and end time of each shared resource usage. A consistent building elements mapping between the PPOOA architecting method and tool and the Cheddar schedulability analysis and simulation tool eases the interoperability of both tools. Early detection of problems related to concurrency for example priority inversion, race conditions and deadlocks.

Other more formal approaches, for example AADL-xUML [2], produce language based modelling artefacts that formally defined syntax and semantics, but for this reason, we think are more difficult to be adopted by small and medium enterprises developing embedded systems.

176

J.L. Fernández Sánchez and G. Mármol Acitores

References 1. Balsamo, S., Di Marco, A., Inverardi, P., Simeoni, M.: Model-Based Performance Prediction in Software Development: A Survey. IEEE Transactions on Software Engineering 30(5) (May 2004) 2. Feiler, P., Niz, D., Raistrick, C., Lewis, B.A.: From PIMs to PSMs. In: 12th IEEE International Conference on Engineering Complex Computer Systems, Auckland, New Zeland (July 2007) 3. Fernandez, J., Martinez, J.C.: Implementing a Real-Time Architecting Method in a Commercial CASE Tool. In: 16th International Conference on Software & Systems Engineering, Paris, France (December 2003) 4. Fernandez, J.L., Marmol, G.: An Effective Collaboration of a Modeling Tool and a Simulation and Evaluation Framework. 18th Annual International Symposium, INCOSE 2008. Systems Engineering for the Planet, The Netherlands (June 2008) 5. Gomaa, H.: Designing Concurrent, Distributed, and Real-Time Applications with UML. Addisson-Wesley, Upper Saddle River (2000) 6. Lammalle, P.: A Successful New Standard for Europe. In: Interlift 2005, October 20 (2005) 7. Saiedian, H., Raguraman, S.: Using UML-Based Rate Monotonic Analysis to Predict Schedulability. IEEE Computer (October 2004) 8. Singhoff, F., Legrand, J., Nana, L., Marcé, L.C.: A Flexible Real Time Scheduling Framework. In: Proceedings of the ACM SIGAda International Conference, Atlanta, November 15-18 (2004)

A Formal Foundation for Metamodeling Liliana Favre Universidad Nacional del Centro de la Provincia de Buenos Aires Comisión de Investigaciones Científicas de la Provincia de Buenos Aires (CIC) Tandil, Argentina [email protected]

Abstract. The concept of formal metamodel will contribute significantly to the core principles of the OMG Model Driven Architecture (MDA). The OMG standard for metamodeling is the Meta Object Facility (MOF) meta-metamodel that defines a common way for capturing the diversity of modeling standards and interchange constructs that are used in MDA. A combination of UML (Unified Modeling Language), OCL (Object Constraint Language) and natural language is used to describe the abstract syntax and semantics of MOF. In this paper, we propose an algebraic formalization of MOF metamodels. We describe how to translate MOF metamodels into algebraic specifications. As an example, we describe a formalization of the core of the Query, View, Transformation (QVT) metamodel, the OMG standard for expressing transformations. The goal of this formalization is, on the one hand, to reason about ambiguity and consistency of metamodels and, on the other hand, to support tests and proofs in model transformations. Keywords: Model Driven Architecture (MDA); Metamodeling; Meta Object Facility (MOF); Query, View, Transformation (QVT); Formal specification.

1 Introduction Nowadays, software and system engineering had created the need of new technical frameworks for information integration and tool interoperation that allow us to manage new platform technologies, design techniques and processes. The Object Management Group (OMG) adopted the Model Driven Architecture (MDA) that is an evolving conceptual architecture for improving portability, interoperability and reusability through separation of concerns [10]. It is not itself a technology specification but it represents an evolving plan to achieve cohesive model-driven technology specifications. The original inspiration around the definition of MDA had to do with the middleware integration problem in internet. Beyond interoperability reasons, there are other good benefits to use MDA such as to improve the productivity, process quality and maintenance costs. MDA is model-driven because it uses models to direct the complete system development lifecycle. It distinguishes different kinds of models: F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 177–191, 2009. © Springer-Verlag Berlin Heidelberg 2009

178

L. Favre

•

• • •

Computation Independent Model (CIM), a model that describes a system from the computation independent viewpoint that focuses on the environment of and the requirements for the system. In general, it is called domain model and may be expressed using business models. Platform Independent Model (PIM), a model with a high level of abstraction that is independent of any implementation technology. Platform Specific Model (PSM), a tailored model to specify the system in terms of the implementation constructs available in one specific platform. Implementation Specific Model (ISM), a description (specification) of the system in source code.

In this context, a platform is a set of subsystems and technologies that provide a set of functionality, which any application supported by that platform can use without know how the functionality is implemented. The initial diffusion of MDA was focused on its relation with the Unified Modeling Language (UML) as modeling language [16] [17]. However, there are UML users who do not use MDA, and MDA users who use other modeling languages such as Domain Specific Languages (DSLs) [13]. The essence of MDA is the Meta-ObjectFacility (MOF) metamodel that allows different kinds of artifacts from multiple vendors to be used together in a same project [11]. MOF (latest revision 2.0) defines a common way for capturing all the diversity of modeling standards and interchange constructs. It provides a metadata management framework where models can be, for instance, exported from one application, imported into another, stored in a repository and then retrieved, transformed, and used to generate code. The MOF 2.0 Query, View, Transformation (QVT) metamodel addresses queries on models, views on metamodels and transformations of models [15]. MOF-metamodels are expressed as a combination of UML, the Object Constraint Language (OCL) and natural language [12]. MOF has no built-in semantics apart from the well-formedness rules in OCL and what can deduced from them. This form of specification does not make possible validating that specific metamodels, like UML metamodel, conform MOF (in the sense of each metaclass of the metamodel conforms a MOF meta-metaclass). A combination of MOF metamodeling and formal specification can help us to address MDA. A formal specification allow us to produce a precise and analyzable software specification and clarifies the intended meaning of metamodels, helps to validate model transformations, and provides reference for implementations. In light of this, we describe an algebraic formalization of MOF metamodels. We propose to use the metamodeling algebraic language NEREUS. It can be viewed as an intermediate notation that can be integrated with property-oriented approaches such as the Common Algebraic Specification Language (CASL) [2]. We show both how MOF metamodels can be integrated with NEREUS and how NEREUS can be translated into algebraic languages. We exemplify our approach with the algebraic formalization of the core of QVT. This paper is organized as follows. Section 2 explains why it is convenient to formalize metamodels and, provides background and related work. Section 3 describes MOF and Section 4 MOF formalization in terms of the NEREUS language. Section 5 describes an integration of NEREUS with algebraic specifications by using the CASL

A Formal Foundation for Metamodeling

179

language. Section 6 describes foundation for metamodel-based transformation and includes QVT formalization. Finally, Section 7 presents conclusions.

2 Motivation The concept of formal metamodel has contributed significantly to some of the core principles of MDA. MOF is the OMG standard for metamodeling. It uses an object modeling framework that is essentially a subset of the UML 2.1.2 core [17]. A central problem is how to define metamodels correct and aligned with MOF. Inconsistencies in a metamodel specification will affect to models and their implementations. Although OCL is a textual language, OCL expressions rely on UML class diagrams, i.e., the syntax context is determined graphically, OCL expressions cannot occur in isolation. It has a denotational semantics that has been implemented in tools that allow dynamic validation of snapshots. For example, the main task of USE tool [8] is to validate and verify specifications consisting of UML/OCL class diagrams. A formal specification technique must at least provide syntax, some semantics and an inference system. The syntax defines the structure of the text of a formal specification including properties that are expressed as axioms, formulas of some logic. The semantics describes the models linked to a given specification; in the formal specification context, a model is a mathematical object that defines behavior of the realizations of the specifications. The inference system allows defining deductions that can be made from a formal specification. These deductions allow new formulas to be derived and checked. So, the inference system can help to automate testing, prototyping or verification. Considering the above, several works propose metamodel formalizations. [14] proposes a formalization of MOF metamodels within the constructive type theory. [1] describes how to formalize metamodels and model transformations by using relational algebras. There are UML/OCL class diagram formalizations based on different languages but certain aspects of MOF are not addressed by present formal specification languages. For instance, different kinds of relations (dependency, binary associations, aggregation and composition) are not considered first-class entities in these languages or, OCL specification is not systematically integrated in the formal specification. In light of this, we define a special-purpose language NEREUS to provide extra support for metamodeling. NEREUS takes advantage of existing theoretical background on formal methods, for instance, the notions of refinement, implementation correctness, observable equivalences and behavioral equivalences that play an essential role in model-to-model transformations. The type system of NEREUS was defined rigorously in the algebraic framework. Considering that MOF supports only binary associations, NEREUS typifies a hierarchy of type constructor for binary associations and provides rigorous specification of them. The semantics of MOF metamodels (that is specified in OCL) can be enriched and refined by integrating it with NEREUS. This integration facilitates proofs and tests of models and model transformations via the formal specification of metamodels and metamodel transformations. Some properties can be deduced from the formal specification and could be re-injected into the MOF specification without wasting the advantages of semi-formal languages of being more intuitive and pragmatic for most implementers and practitioners.

180

L. Favre

This formalization can be viewed as an evolution of previous results. In [4] we analyze how to formalize metamodels based on the concepts on entity, relationships and systems in terms of the NEREUS language and, show how to translate NEREUS into CASL [2]. In this context we defined MDA-based forward engineering processes [6]. In this paper we update these results according to OCL 2.0 (latest reversion 2.0) [12], MOF 2.0 (latest revision 2.0) [11] and QVT (latest revision 1.0) [15]. We define a system of transformation rules to translate Essential OCL, the subset of OCL that is used to attach restrictions to MOF-based metamodels. With this restriction, all wellformed rules defined over MOF- metamodels can be translated into NEREUS. In particular, this system can be used in the formalization of QVT. Our approach has two main advantages linked to automation and interoperability. On the one hand, our approach is the only one that shows how to generate automatically formal specifications from MOF metamodels. Due to scalability problems, this is an essential requisite. On the other hand, our approach is the only one that focuses on interoperability of formal languages. Considering that there exist many formal algebraic languages, NEREUS allows any number of source languages such as different Domain Specific Languages (DSLs) and target languages (different formal language) could be connected without having to define explicit metamodel transformations for each language pair. Such as MOF is a DSL to define semi-formal metamodels, NEREUS can be viewed as a DSL for defining formal metamodels. Another advantage of our approach is linked to pragmatic aspects. NEREUS is a formal notation closed to MOF metamodels that allows meta-designers who must manipulate metamodels to understand their formal specification.

3 MOF-Based Metamodels MDA requires the ability to understand different languages such as general purpose languages, domain specific languages, modeling languages or programming languages. A underlying concept of MDA for integrating semantically in a unified and interoperable way such languages is metamodeling. The essence of MDA is MOF that allows different kinds of software artifacts to be used together in a single project. MOF provides “a metadata management framework and a set of metadata services to enable the development and interoperability of models and metadata driven systems” [11, pp. 5]. MOF facilitates interoperability among modeling and development tools, data warehouse systems and metadata repositories. A number of OMG standards, including UML, MOF, various UML profiles and XMI are aligned with MOF. MOF provides two metamodel: EMOF (Essential MOF) and CMOF (Complete MOF). The former favors simplicity of implementation over expressiveness, while the latter is more expressive, but more complex. EMOF is a subset of MOF that allows simple metamodels to be defined using simple concepts while supporting extensions for more sophisticated metamodeling using CMOF. The MOF modeling concepts are “classes, which model MOF meta-objects; associations, which model binary relations between meta-objects; Data Types, which model other data; and Packages, which modularize the models” [11, pp. 2-6]. OCL can be used to attach consistency rules to metamodel components.

A Formal Foundation for Metamodeling

181

The MOF model is self-describing, that is to say it is formally defined using its own metamodeling constructs. This provides a uniform semantic treatment between artifacts that represent models and metamodels. The MOF 2.0 Query, View, Transformation (QVT) specification describes three related transformational languages: Relations, Core and Operational Matching [15]. The acronym QVT refers to “query” for selecting and filtering of model elements; “views” of MOF metamodels involved in the transformation and “transformations” expressing relations between a source metamodel and a target metamodel. The QVT specification has a hybrid declarative/imperative nature. The declarative part of this specification is structured into a two-layer architecture: • •

A user-friendly Relations metamodel and language which supports the creation of object template, complex object pattern matching and the creation of traces between model elements involved in a transformation. A Core metamodel and language defined using minimal extensions to EMOF and OCL. All trace classes are explicitly defined as MOF models, and trace instance creation and deletion in the same way as the creation and deletion of any other object.

In addition to the declarative parts, the imperative part includes one standard language Operational Mapping and one non-standard Black-Box MOF operation implementation. Fig. 1 shows dependencies package in the QVT specification [15, pp. 12].

Fig. 1. Package dependencies in QVT specification

In particular, QVT depends on the Essential-MOF (EMOF) and Essential-OCL. Essential-OCL [12, pp. 171] is a package exposing the minimal OCL required to work with EMOF [11, pp. 31].

182

L. Favre

The Core language is equally powerful to the Relation language and can be implemented directly or used as a reference for the semantics of Relations, which are mapped to Core using the transformation language itself.

4 NEREUS: A Formal Metamodeling Language NEREUS provides modeling concepts that are supported by MOF and the UML core, including classes, associations and packages and, a repertoire of mechanisms for structuring them. 4.1 Defining Classes Classes may declare types, attributes, operations and axioms which are formulas of first-order logic. They are structured by different kinds of relations: importing, inheritance, subtyping and associations. Fig. 2 shows the class syntax in NEREUS. NEREUS distinguishes variable parts in a specification by means of explicit parameterization. The elements of <parameterList> are pairs C1:C2 where C1 is the formal generic parameter constrained by an existing class C2 (only subclasses of C2 will be actual parameters). The IMPORTS clause expresses client relations. The specification of the new class is based on the imported specifications declared in and their public operations may be used in the new specification. NEREUS distinguishes inheritance from subtyping. Subtyping is like inheritance of behavior, while inheritance relies on the module viewpoint of classes. Inheritance is expressed in the INHERITS clause; the specification of the class is built from the union of the specifications of the classes appearing in the . Subtypings are declared in the IS-SUBTYPE-OF clause. A notion closely related with subtyping is polymorphism. NEREUS allows us to define local instances of a class by the following syntax ClassName [] where the elements of can be pairs of class names C1: C2 being C2 a component of ClassName; pairs of sorts s1: s2, and/or pairs of operations o1: o2 with o2 and s2 belonging to the own part of ClassName. The GENERATED-BY clause lists the operations that are basic constructors of the interest type. NEREUS distinguishes deferred and effective parts. The DEFERRED clause declares new types, attributes or operations that are incompletely defined. The EFFECTIVE clause declares types, attributes and operations completely defined. ATTRIBUTES clause introduces, like MOF, an attribute with the following properties: name, type, multiplicity specification and “isDerived” flag. OPERATIONS clause introduces the operation signatures, the list of their arguments and result types. An attribute or parameter may be optional-value, single value, or multi-valued depending on its multiplicity specification. The multiplicity syntax is aligned with the MOF syntax. Operations can be declared as total or partial. Partial functions must specify its domain by means of the PRE clause that indicates what conditions the function´s arguments must satisfy to belong to the function’s domain. NEREUS allows us to specify operation signatures in an incomplete way. NEREUS supports higher-order operations (a function f is higher-order if functional sorts appear in a parameter sort or

A Formal Foundation for Metamodeling

183

the result sort of f). In the context of OCL Collection formalization, second-order operations are required. In NEREUS it is possible to specify any of the three levels of visibility for operations (public, protected and private) and incomplete functionalities denoted by underscore. NEREUS provides the construction LET… IN to limit the scope of the declarations of auxiliary symbols by using local definitions. CLASS className [<parameterList>] IMPORTS INHERITS IS-SUBTYPE-OF GENERATED-BY ASSOCIATES DEFERRED TYPES ATTRIBUTES OPERATIONS EFFECTIVE TYPES OPERATIONS AXIOMS END-CLASS

Fig. 2. NEREUS: Class syntax

BinaryAssociation

Aggregation

Simple

Shared

Unidirectional

Composition Bidirectional

0..1. *..* 1. 1..1 Fig. 3. The Component Association

184

4. 2

L. Favre

Defining Associations

NEREUS provides a component Association, a taxonomy of constructor types, that classifies binary associations according to kind (aggregation, composition, ordinary association), degree (unary, binary), navigability (unidirectional, bidirectional) and, connectivity (one-to-one, one-to-many, many-to-many). Fig. 3 depicts the component Association. Generic relations can be used in the definition of concrete relations by instantiation. New associations can be defined by means of the syntax shown in Fig. 4 The IS paragraph expresses the instantiation of with classes, roles, visibility, and multiplicity. The CONSTRAINED-BY clause allows the specification of static constraints in first order logic. Relations are defined in a class by means of the ASSOCIATES clause. ASSOCIATION IS […:class1;…:class2;…:role1; …:role2; …:mult1;…:mult2; …:visibility1;…:visibility2] CONSTRAINED-BY END-ASSOCIATION

Fig. 4. NEREUS: Association syntax

4. 3 Defining Packages The package is the mechanism provided by NEREUS for grouping elements. Fig. 5 shows the syntax of a package. Like MOF, NEREUS provides mechanisms for metamodel composition and reuse [11]. The IMPORTING clause lists the imported packages; the GENERALIZATION clause lists the inherited packages; NESTING clause lists the nested packages and CLUSTERING clause list the clustering ones. <elements> are classes, associations and packages. PACKAGE packageName IMPORTING GENERALIZATION NESTING CLUSTERING <elements> END-PACKAGE

Fig. 5. NEREUS: Package syntax

Several useful predefined types are offered in NEREUS, for example Collection, Set, Sequence, Bag, Boolean, String, Nat and Enumerated types.

5 Formalizing MOF Metamodels In this section we examine the relation between MOF and algebraic languages. We show how to integrate both MOF with NEREUS, and NEREUS with algebraic languages using CASL as a common algebraic language [2]. Fig. 6 depicts the

A Formal Foundation for Metamodeling

185

translation process from different DSLs that can be expressed by MOF metamodels, to formal languages. In 5.1 and 5.2 we describe the different steps of this process.

Fig. 6. A bridge between MOF and algebraic languages

5.1 Integrating MOF Metamodels with NEREUS We define a bridge between metamodels and NEREUS. The NEREUS specification is completed gradually. First, the signature and some axioms of classes are obtained by instantiating reusable schemes. Associations are transformed by using the reusable component ASSOCIATION. Next, OCL specifications are transformed using a set of transformation rules. Then, a specification that reflects all the information of MOF metamodels is constructed. The OCL basic types Boolean, Integer, Real and String are associated with NEREUS basic types with the same name. Like OCL, NEREUS provides enumeration types that are aligned to the OCL semantics. NEREUS provides classes for collection type hierarchies. The types Set, Bag and Sequence are subtypes of Collection(x). Collection(Type1) conforms to Collection(Type2) when Type1 conforms to Type2. This is also true for Set(Type1), Bag(Type1) and Sequence(Type1), each one with Collection(Type2). Type1 conforms to Type2 both when they are identical or Type1 is subtype of Type2. The transformation process of OCL specifications to NEREUS is supported by a system of transformation rules. By analyzing OCL specifications we can derive axioms that will be included in the NEREUS specifications. Preconditions written in OCL are used to generate preconditions in NEREUS. Postconditions and invariants allow us to generate axioms in NEREUS. We define a system of transformation rules that only considers expressions based on Essential OCL. The following metaclasses defined in complete OCL are not part of the EssentialOCL: MessageType, StateExp, ElementType, AssociationClassCallExp, MessageExp, and UnspecifiedValueExp. Any well-formed rules defined for these classes are consequently not part of the definition of the transformation rule system. The system includes a small set with around fifty rules. It was built by means of an iterative approach through successive refinements. The set of rules was validated by analyzing the different OCL expression attached to the UML metamodels [16] [17], MOF [11] and QVT [15]. Fig. 7 shows some rules of the system. In each rule the shaded text denotes an OCL expression that can be translated by the non-shaded text in NEREUS.

186

L. Favre Rule

R1 R2 R3 R4

R5

OCL NEREUS v. operation(parameters) operation(TranslateNEREUS(v),TranslateNEREUS (parameters)) v->operation (parameters) operation(TranslateNEREUS(v),TranslateNEREUS (parameters)) v.attribute attribute (v) context Assoc object.rolename Let a:Assoc get_rolename (a, object) e.op e: expression op(TranslateNereus(e))

R6

exp1 infix-op exp2 TranslateNereus(exp1)TranslateNereus(infix-op) TranslateNereus(exp2) TranslateNereus(infix-oper)(TranslateNereus(exp1),TranslateNereus(exp2))

R7

A.allInstances ->forAll (e│bool-expr-with-e) Translate NEREUS (bool-expr-with-e) Fig. 7. A system of transformation rules

5.2 Integrating NEREUS with CASL CASL is an expressive and simple language based on a critical selection of known constructs such as subsorts, partial functions, first-order logic, and structured and architectural specifications. A basic specification declares sorts, subsorts, operations and predicates, and gives axioms and constraints. Specifications are structured by means of specification building operators for renaming, extension and combining. Architectural specifications impose structure on implementations. It allows loose, free and generated specifications. NEREUS and MOF-metamodels follow similar structuring mechanisms of data abstraction and data encapsulation. We define a way to automatically translate each NEREUS construct into CASL, including classes, different kinds of relations and packages [4]. In particular, the NEREUS semantics was given in terms of translation into CASL. We select CASL due to it is at the center of a family of specification languages. It has restrictions to various sublanguages, and extensions to higher-order, state-based, concurrent, and other languages. CASL is supported by tools and facilitates interoperability of prototyping and verification tools. An interesting problem is how to translate associations due to algebraic languages do not follow the MOF structuring mechanisms. In this paper we exemplify this process describing how to translate associations. The graph structure of a class diagram involves cycles such as those created by bidirectional associations. However, the algebraic specifications are structured hierarchically and cyclic import structures between two specifications are avoided. An association in UML can be viewed as a

A Formal Foundation for Metamodeling

spec A&B= Assoc then ops num A: Assoc x A –>Nat num B: Assoc x B -> Nat select: collect: pred forall:… . end

A&B spec Assoc= collection-A and collection-B and BinaryAssociation[A][B] w ith BinaryAssociation-> Assoc… ops get-role1: get_role2: end

spec collection-A… end

spec A given… then ops getA-attr1: getA-attr2: setA-attr1: end

Asso c

C ollec tio n A

A

187

spec collection-B… end

C olle ctio n B

spec B given … then ops getB-attr1: getB-attr2: setB-attr1:

B

end

Fig. 8. CASL: Specifying associations

local part of an object and this interpretation can not be mapped to classical algebraic specifications which do not admit cyclic import relations. We propose an algebraic specification that considers associations belonging to the environment in which an actual instance of the class is embedded. Let Assoc be a bidirectional association between two classes called Asource and Bsource the following steps can be distinguished in the translation process: Step1: Regroup the operations of classes Asource and Bsource distinguishing operations local to Asource, local to Bsource and, local to Asource and Bsource and Assoc. Step 2: Construct the specifications A and B from Asource and Bsource where A and B include local operations to Asource and Bsource respectively. Step 3: Construct specifications Collection [A] and Collection [B] by instantiating reusable schemes. Step 4: Construct a specification Assoc (with A and B) by instantiating reusable schemes in the component Association (Fig. 3) Step 5: Construct the specification A&B by extending Assoc with A, B and the operations local to A, B and Assoc. Fig. 8 shows the relations among the specifications built in the different steps and partially depicts the structure of CASL specifications in the shaded text.

6 QVT Core Formalization We show the formalization of the QVT Core metamodel. The Core language is as powerful as the Relation language and may be used as a reference for the semantics

188

L. Favre

of relations, which are mapped to Core. Fig. 9 shows the QVT-BASE package [15, pp. 26]. A transformation defines how one set of models can be transformed into another. It is composed by a set of rules that specify its execution behavior. Fig. 9 also shows an OCL constraint linked to the package specifying that the rules of the extended transformation are included in the extending transformation and the extension is transitive. A rule domain is the set of model elements of a typed model that are of interest to it. A domain may be marked as checkable or enforceable [15, pp. 27]. An analogy between a virtual machine-based architecture and QVT is described in [15, pp. 10]. The Core language is like JAVA byte code and the Core semantics is like the behavior specification for the Java Virtual Machine (JVM). The Relation language is like the Java language, and the standard transformation from Relations to Core is like the Java compiler which produces byte code. In this paper we go beyond that showing an analogy between the semantics of the JVM byte code and the core of QVT. The semantics of Java, that includes object-oriented features, is hard to formalize. However, JVM byte code is defined more precisely. [9] shows that Java program verification via a deep embedding of the JVM into the logic of ACL2 is a viable approach. Analogously, the semantics of QVT, that includes mechanisms for involving imperative implementations of transformations, is hard to formalize. The Core package that is based on QVT Base package, EMOF and Essential OCL (see Fig. 1) is more simply and more precisely defined. Then, we

,

Transformation.allInstances ->forAll (t⎥ t.extends.size=1 implies t.extends.rule -> include (t.rule)) Transformation.allInstances-> forAll (t1,t2,t3 ⎥ t1.extends.size=1 and t2.extends.size=1 and t3.extends.size=1 and (t1.extends.rule-> includes (t2.rule) and t2.extends.rule-> includes (t3.rules)) implies t1.extends.rule -> includes (t3.rule) Fig. 9. The QVT-Base package

A Formal Foundation for Metamodeling

189

decided to formalize QVT transformations via the QVT core and QVT base formalization. We can reason about transformations by reasoning about the corresponding core transformation. Fig. 10 partially shows the specification in NEREUS of Fig. 9. As an example, the OCL specification in Fig. 9 can be translated into the shaded axioms of Fig. 10 by using the rules of Fig. 7. PACKAGE QVTBase CLASS Transformation IMPORTS EMOF::Tag INHERITS EMOF::MetaClass, EMOF::Package ASSOCIATES <> <> <>, <> AXIOMS ass1 :<>; ass2 : <> ; t :Transformation ;… size(get_extends (ass1,t)) = 1 implies includes (get_rule (ass2, get_extends(ass1,t)), get_rule (ass1, t)) END-CLASS CLASS TypedModel IMPORTS EMOF::Package IS-SUBTYPE-OF EMOF::NamedElement ASSOCIATES <> <> <>, <> END-CLASS CLASS Domain IS-SUBTYPE-OF EMOF::NamedElement ASSOCIATES <> <> DEFERRED ATTRIBUTES isCheckable: Domain-> Boolean isEnforceable: Domain-> Boolean END-CLASS CLASS Rule IS-SUBTYPE-OF EMOF::NamedElement ASSOCIATES <> <> <> END-CLASS ASSOCIATION Transformation-Transformation IS Unidirectional-2 [Transformation:class1; Transformation:class2; extendedBy: role1; extends: role2; *: mult1; 0..1:mult2; +:visibility1; + : visibility2] END-ASSOCIATION ASSOCIATION Transformation-Rule IS Composition-2 [Transformation:class1; Rule:class2; transformation:role1; rule:role2; 1:mult1; *:mult2; +:visibility1; +:visibility2] END-ASSOCIATION ASSOCIATION Transformation-TypedModel… END-PACKAGE

Fig. 10. NEREUS: QVT BASE package

190

L. Favre

7 Conclusions This paper describes a formal foundation for metamodeling techniques. We show how to formalize MOF in terms of NEREUS and, how NEREUS can be integrated with other formal languages. Our approach allows generating formal specification starting from a small system of transformation rules. Formal specification should be integrated with different formalisms depending of the abstraction level and transformation domain. We also show how to integrate NEREUS with CASL. We propose the formalization of the QVT core. Our proposal is based and aligned with OMG standards such as UML 2.0 Superstructure, UML 2.0 Infrastructure, MOF 2.0 and QVT. Although we define foundations for metamodeling, it still needs to use them in the validation of standard metamodels. To date, we are analyzing how the use of NEREUS can facilitate the incremental validation of metamodels with cost proportional to size of units of change in the validation processes. We foresee to validate transformations defined in terms of the QVT Relation language by using the proposed QVT Core formalization as a reference for the semantics of relations. We also foresee to integrate our results in the existing MDA Case tools. This work contributes to a more general goal. We are working in the definition of a generic framework based on a common metamodeling language that allows us to validate/verify MDA models in rigorous MDA-based processes. Within this approach, we defined rigorous reverse engineering processes [5], refactoring techniques [7] and reuse processes [3].

References 1. Akehurst, D., Kent, S., Patrascoiu, O.: A Relational Approach to Defining and Implementing Transformations between Metamodels. Software and System Modeling 2(4), 215–239 (2003) 2. Bidoit, M., Mosses, P.: CASL User Manual- Introduction to Using the Common Algebraic Specification. LNCS, vol. 2900. Springer, Heidelberg (2004) 3. Favre, L., Martinez, L.: Formalizing MDA Components. In: Morisio, M. (ed.) ICSR 2006. LNCS, vol. 4039, pp. 326–339. Springer, Heidelberg (2006) 4. Favre, L.: A Rigorous Framework for Model Driven Development. In: Siau, K. (ed.) Advanced Topics in Database Research, ch. I, vol. 5, pp. 1–27. Idea Group Publishing, USA (2006) 5. Favre, L.: Formalizing MDA-based Reverse Engineering Processes. In: Proceedings of the 6th ACIS International Conference on Software Engineering Research, Management and Applications, SERA 2008, pp. 153–160. IEEE Computer Society, New York (2008) 6. Favre, L.: Foundations for MDA-based Forward Engineering. Journal of Object Technology (JOT) 4(1), 129–153 (2005) 7. Favre, L., Pereira, C.: Formalizing MDA-based Refactorings. In: 19th Australian Software Engineering Conference (ASWEC 2008), pp. 377–386. IEEE Press, New York (2008) 8. Gogolla, M., Bohling, J., Richters, M.: Validating UML and OCL Models in USE by Automatic Snapshot Generation (2005), http://db.informatik.uni-bremen.de/publications

A Formal Foundation for Metamodeling

191

9. Liu, H., Strother Moore, J.: Java Program Verification via JVM Deep Embedding in ACL2. In: Slind, K., Bunker, A., Gopalakrishnan, G.C. (eds.) TPHOLs 2004. LNCS, vol. 3223, pp. 184–200. Springer, Heidelberg (2004) 10. MDA: The Model Driven Architecture (2003), http://www.omg.org/mda 11. MOF: Meta Object facility (MOF) 2.0. OMG Specification: formal/2006-01-01 (2006), http://www.omg.org/mof 12. OCL: Object Constraint Language. Version 2.0. OMG Specification: formal/06-05-01 (2006), http://www.omg.org 13. OMG (2007), http://www.omg.org 14. Poernomo, I.: The Meta-Object Facility Typed. In: Proceedings of the 2006 ACM Symposium on Applied Computing (SAC), Dijon, France, pp. 1845–1849 (2006) 15. QVT. MOF 2.0 Query, View, Transformation. Formal/2008-04-03 (2008), http://www.omg.org 16. Unified Modeling Language: Superstructure. Version 2.1.2. OMG Specification: formal/2007-02-05 (2007), http://www.omg.org 17. Unified Modeling Language: Infrastructure. Version 2.1.2. OMG Specification formal/0702-04 (2007)

Modeling AADL Data Communication with BIP Lei Pi, Jean-Paul Bodeveix, and Mamoun Filali IRIT - University of Toulouse 118 route de Narbonne F-31062 Toulouse {pilei,bodeveix,filali}@irit.fr

Abstract. This paper presents translation schemas for some constructs of the Architecture Analysis & Design Language (AADL) in the formal language BIP(Behavior, Interaction, Priority). We focus here on deterministic data communications and show how BIP can support them. BIP provides a language and a theory for incremental composition of heterogeneous components. As a full-size exercise, we deal here with the modeling of immediate and delayed data communications supporting undersampling and oversampling of AADL.

1

Introduction

The current embedded system engineering practices are more and more based on modeling approaches and the use of architecture description languages (ADL). This evolution is driven by the need for stronger methods to handle the increasing complexity of embedded systems. The use of ADLs is coupled with techniques and tools to help in the development: performing veriﬁcations, automatic generation, etc. One of the main ADLs currently considered by industry in system engineering for embedded systems is AADL (Architecture Analysis & Design Language) [1]. This language provides a means to model both software and the execution platform architectures. It relies on an execution model which makes AADL speciﬁcations largely implicit. We look for specifying formally relevant fragments of the AADL execution model. For this purpose, we have used BIP[2]. BIP is a language for the description and composition of components as well as associated tools for analyzing models and generating code on a dedicated platform. The language provides a powerful mechanism for structuring interactions involving rendezvous and broadcast. AADL applications comprise threads, often of a periodic nature, connected through event or data ports. Data communications can be immediate or delayed. As can be seen here, the same model provides structural information (the thread connections) together with a crude abstraction of behaviors usually needed for schedulability analysis. Delayed communications are needed in particular to break down cyclic propagation of data. They implicitly impose a partial order on how various threads (and their containing processes) can be executed/ simulated in a simultaneous step. The AADL thread modeling and the various F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 192–206, 2009. c Springer-Verlag Berlin Heidelberg 2009

Modeling AADL Data Communication with BIP

193

protocols (immediate/delayed) can be formally speciﬁed in BIP. This is the topic of the current paper. The rest of this paper is organized as follows: Section 2 introduces AADL and some of AADL features that we are interested in, and the BIP language, Section 3 presents the translation of the thread execution semantics and the communication semantics in BIP. Finally, we draw conclusions.

2 2.1

Background AADL Overview

In this section, we provide a quick overview of the AADL modeling language. AADL is a versatile modeling language that can provide a basis to model all aspects of a system. AADL (Architecture Analysis & Design Language) [1] is an architecture description language (ADL) standardized by the Society of Automotive Engineers (SAE). It is particularly targeted at the description of distributed real-time and embedded systems. An AADL model can incorporate non-architectural elements: embedded or real-time characteristics of the components (execution time, memory usage, etc.), behavioral descriptions, etc. Hence it is possible to use AADL as a backbone to describe all the aspects of a system. An AADL description is made of components. The AADL standard deﬁnes software components (data, thread, thread group, subprogram, process), execution platform components (memory, bus, processor, device) and hybrid components (system). Components describe well identiﬁed elements of the actual architecture. Subprograms model procedures like in C or Ada. Threads model the active part of an application (such as POSIX threads). Processes are memory spaces that contain threads. Processors model microprocessors and a minimal operating system (mainly a scheduler). Memories model hard disks, RAMs. Busses model all kinds of networks, wires. Devices model sensors, etc. Unlike other components, systems do not represent anything concrete; they actually create building blocks to help structuring the description. The interface of a component is called component type. It provides features (e.g.; communication ports). Components communicate one with another by connecting their features. To a given component type correspond zero or several implementations. Each of them describes the internals of the components: subcomponents, connections between those subcomponents, etc. AADL deﬁnes the notion of properties that can be attached to most elements (components, connections, features, etc.). Properties are attributes that specify constraints or characteristics that apply to the elements of the architecture: clock frequency of a processor, execution time of a thread, bandwidth of a bus, etc. Some standard properties are deﬁned; but it is possible to deﬁne one’s own properties.

194

L. Pi, J.-P. Bodeveix, and M. Filali

Last, AADL supports an annex mechanism to extend the description capabilities of the language by introducing a dedicated sub-language. A behavior annex[3] is currently being deﬁned by the SAE committee. A more detailed introduction to the AADL can be found in [1]. 2.2

AADL Threads and Communications

One of the real-time patterns that is oﬀered by the core of the AADL standard[1] could be called pre-emptive scheduling with synchronous dataﬂow communications. This pattern consists in a set of periodic threads communicating via data ports. In such a situation, the default run-time execution model that is proposed by the standard will ensure a complete predictability of the real-time behaviour of the application. This rare property is a strong beneﬁt for real-time architects and should fully justify the choice of the AADL among other model driven solutions. From an AADL model, each thread periodically is periodically invoked. This periodic thread is deﬁned by ﬁve parameters: the Dispatch P rotocol is supposed to be Periodic, with period given by the Period property, its deadline (Di ), its best case execution time (Bi ) worst case execution time (Ci ). Pi is a ﬁxed delay between two release times of the task i. Each time the thread i is released, it has to do a calculus whose execution time takes between Bi and Ci units of time. This thread has to be ended before Di units of time after the thread wake up time. Real-time attributes of each thread can be described individually in Listing 1.1 by a set of pre-deﬁned properties: Listing 1.1. AADL Thread Description thread implementation T1 . o t h e r s p r o p er ti es D i s p a t c h P r o t o c o l => P e r i o d i c ; P e r i o d => 29ms ; D e a d l i n e => 29ms ; Compute Execution Time => 3ms . . 7 ms ; end T1 . o t h e r s ;

In this paper, we only consider data-based communication to ensure deterministic processing of data streams. Thus event-based or shared data-based communications are ignored. In order to ensure deterministic data communication between periodic threads, AADL oﬀers two communication mechanisms: immediate(mid-frame) and delayed(phase-delayed) connections. In the case of an immediate connection, data transmission is initiated when the source thread completes and enters the suspended state. The value delivered to the in data port of a receiving thread is the value produced by the sending thread at its completion. For an immediate connection to occur, the threads must share a common (simultaneous) dispatch, which happens at each multiple of the two periods of the communicating threads. In this case, the receiving thread’s execution is postponed until the sending thread has completed its execution. This aspect can be seen in Figure 1, where the immediate connection speciﬁes

Modeling AADL Data Communication with BIP

195

Fig. 1. An Immediate Connection

that the thread control must execute after the thread read data, within every 50 ms (20Hz) period. In addition, the value that is received by the thread control is the value output by the most recent execution of the thread read data. For the two threads illustrated in Figure 1, a partial textual speciﬁcation is shown in Listing 1.2. The connection immediate C1 is declared as immediate using the single-headed arrow symbol (− >) between the out data port of the read data thread and the in data port of the control thread. Notice the period property association within each if the thra Listing 1.2. AADL Speciﬁcation of an Immediate Connection thread r e a d d a t a fea tu r es i n d a t a : i n data port ; o u t d a t a : out data port ; p r o p er ti es P e r i o d => 50 ms ; end r e a d d a t a ; −− thread c o n t r o l fea tu r es i n d a t a : i n data port ; o u t d a t a : out data port ; p r o p er ti es P e r i o d => 50 ms ; end b a s i c c o n t r o l ; −− process implementation c o n t r o l s p e e d . i m p l subcomponents r e a d d a t a : thread r e a d d a t a ; c o n t r o l : thread c o n t r o l ; connections immediate C1 : data port r e a d d a t a . o u t d a t a− > c o n t r o l . i n d a t a ; end c o n t r o l s p e e d . i m p l ;

In the case of a delayed connection, the value from the sending thread is transmitted at its deadline and is available to the receiving thread at its next dispatch. For delayed port connections, the communicating threads do not need to share a common dispatch. In this case, the data available to a receiving thread is that value produced at the most recent deadline of the sending thread that preceeds receiver dispatch. If the deadline of the sending thread and the

196

L. Pi, J.-P. Bodeveix, and M. Filali

Fig. 2. An Delayed Connection

dispatch of the receiving thread occur simultaneously, the transmission occurs at that instant. The impact of a delayed connection can be seen in Figure 2, where the thread control receives the value produced by the thread read data in the previous 50 ms (20Hz) frame. So, we actually consider only periodic threads with data port communication. These two protocols apply on the four conﬁgurations of communicating threads and give a deterministic semantics to all of them: synchronous threads with the same period, over-sampling (the period of the receiver is evenly divided by the period of the sender), under-sampling (the period of the sender is evenly divided by the period of the receiver) and even threads with uncorrelated periods. 2.3

The BIP Language

The BIP language supports a methodology for building components from: – Atomic components, a class of components with behavior speciﬁed as a set of transitions and having empty interaction and priority layers. Triggers of transitions include ports which are action names used for synchronization. – connectors used to specify possible interaction patterns between ports of atomic components. – priority relations used to select an interactions among possible ones according to conditions depending on the state of the integrated atomic components. We provide a description of the main features of the language. Atomic Component. An atomic component consists of: – A set of ports P = {p1 ...pn }. Ports are action names used for synchronization with other components. – A set of control states S = {s1 ...sk }. Control states denote locations at which the components await for synchronization.

Modeling AADL Data Communication with BIP

197

– A set of variables V used to store (local) data. – A set of transitions modeling atomic computation steps. A transition is a tuple of the form (s1 , p, gp , fp , s2 ), representing a step from control state s1 to s2. It can be executed if the guard (boolean condition on V ) gp is true and some interaction including port p is oﬀered. Its execution is an atomic sequence of two microsteps: 1) an interaction including p which involves synchronization between components with possible exchange of data, followed by 2) an internal computation speciﬁed by the function fp on V . That is, if v is a valuation of V after the interaction, then fp (v) is the new valuation when the transition is completed. Listing 1.3 shows an atomic reactive component with two ports in, out, variables x, y, and control states empty, f ull. At control state empty, the transition labeled in is possible if 0 < x. When an interaction through in takes place, the variable x is possibly modiﬁed and a new value for y is computed. From control state f ull, the transition labeled out can occur. The omission of guard and function for this transition means that the associated guard is true and the internal computation microstep is empty. Remarks. The reading of a transition is not as simple as we could expect: composition can insert side eﬀects between the guard and the action part. Listing 1.3. An atomic component component R e a c t i v e port i n , o u t data i n t x , y behavior i n i t i a l x = 3 ; to empty s t a t e empty on i n provided 0 < x do y := f ( x ) to f u l l s t a t e f u l l on o u t to empty end end

Connectors and Interactions. A connector γ is a non empty set of ports of atomic components which can be involved in an interaction. They preﬁxed by the name of the component instance. It contains at most one port from each atomic component. An interaction of γ is any non empty subset of this set. For example, if p1 , p2 , p3 are ports of distinct atomic components, then the connector γ = p1 |p2 |p3 has seven interactions: p1 , p2 , p3 , p1 |p2 , p1 |p3 , p2 |p3 , p1 |p2 |p3 . Each non trivial interaction i.e., interaction with more than one port, represents a synchronization between transitions labeled with its ports. There is a typing mechanism to specify the feasible interactions of a connector γ, it distinguishes between complete and incomplete interactions with the following restriction: All the interactions containing some complete interaction are complete; dually, all the interactions contained in incomplete interactions are incomplete. An interaction of a connector is feasible if it is complete or if it is maximal for inclusion. A connector description includes its set of ports followed by an optional list of its minimal complete interactions and its behavior. If the list of the minimal

198

L. Pi, J.-P. Bodeveix, and M. Filali

complete interactions is omitted, then it is considered to be empty. Connectors may have a behavior speciﬁed, as for transitions, by a set of guarded commands associated with feasible interactions. If α = p1 |p2 |...|pn is a feasible interaction then its behavior is described by a statement of the form: on α provided Gα do Fα , where Gα and Fα are respectively a guard and a statement representing a function on the variables of the components involved in the interaction. As for atomic components, guards and statements are C expressions and statements respectively. The execution of α is possible if Gα is true. It atomically changes the global valuation v of the synchronized components to Fα (v). Remarks. In the context of individual components, this update is performed after the guard of the transition has been evaluated and before the execution of the action. Thus, the action can be evaluated even if the guard has become false after the synchronization. In the example of Listing 1.3, in the assignement y = f (x), x < 0 can not be asserted. Priorities. Given a system of interacting components, priorities are used to ﬁlter interactions among the feasible ones depending on given conditions. So they reduce the non determinism of the system by restricting the set of enabled transition. They are a set of rules, each consisting of an ordered pair of interactions associated with a condition (cond). The condition is a boolean expression depending on the variables of the components involved in the interactions. When the condition holds and both interactions are enabled, only the higher one is possible. Conditions can be omitted for static priorities. The rules are extended for composition of interactions. That is, the rule p1 < p2 means that any interaction of the form p2|q has higher priority over interactions of the form p1|q where q is an interaction. Furthermore, priorities are compatible with interaction containments an interaction p|q has higher priority than p or q. Compound Components. A compound component allows deﬁning new components from existing sub-components (atoms or compounds) by creating their instances, specifying the connectors between them and the priorities. Listing 1.4. An compound component component System contains R e a c t i v e r1 , r2 , r 3 connector C1 = r 1 . i n complete = r 1 . i n connector C2 = r 1 . o u t | r 2 . i n behavior on r 1 . o u t | r 2 . i n do r 2 . x := r 1 . y end connector C3 = r 1 . o u t | r 3 . i n behavior on r 2 . o u t | r 3 . i n do r 3 . x := r 1 . y end connector C4 = r 2 . o u t connector C5 = r 3 . o u t complete = r 2 . o u t complete = r 3 . o u t p r i o r i t y P1 C3 : r 1 . o u t | r 3 . i n < C2 : r 1 . o u t | r 2 . i n end

Modeling AADL Data Communication with BIP

199

Fig. 3. A compound component

An example of a compound component named System is shown in Figure 3. It is the serial composition of three reactive components, as in Listing 1.4. C1 acts as a client sending requests to one of the servers C2 and C3. We use connector priorities to specify that component r2 must be used prioritary if both component are empty. The following section illustrates the expression of AADL data port communication in BIP.

3

Expression of AADL Connections in BIP

In AADL the communication code is part of the runtime executive together with task dispatch code. This ensures that the time of transfer between the ports is well-deﬁned and deterministic with respect to sampling the data stream. While the application code operates on the content of port variables, system buﬀers may have to be used to ensure that port variables are not aﬀected by other tasks during task execution. In this paragraph, we propose an expression in BIP of the immediate and delayed communication protocols. They rely on a modeling of the notion of periodic thread, which is a simpliﬁed version of the one proposed by [4]. Then, we detail the two protocols.

timed_thread(T, DL, WCET) dispatch

deadline

dispatch

execution

completion

execution

get_immediate

tick

c=0 tick

dispatch tick, t=(t+1)%T

t=0

IDLE

READY

WAITING

deadline IDLE

execution

deadline

completion c=0

execution preempt

ERROR deadline [t=DL-1]

execution

dispatch [t=0]

deadline SUSPENDED completion

tick

deadline

release_exec

FINISH

COMPUTE

get_immediate

Fig. 4. Composition of periodic thread

preempt

COMPUTE tick c<=WCET tick completion

200

L. Pi, J.-P. Bodeveix, and M. Filali Listing 1.5. BIP Speciﬁcation of a periodic thread

component t h r e a d port d i s p a t c h , e x e c u t i o n , c o m p l e t i o n , deadline , r e l e a s e e x e c , get immediate data int in data , out data behavior i n i t i a l do o u t d a t a = 0 ; i n d a t a = 0 ; to IDLE s t a t e IDLE // w a i t f o r d i s p a t c h on d i s p a t c h to READY s t a t e READY on e x e c u t i o n to COMPUTE on g e t i m m e d i a t e to READY // g e t t h e v a l u e s t r a n s f e r e d by immediate c o n n e c t i o n s on d e a d l i n e to ERROR s t a t e COMPUTE // s i m u l a t e p r e e m p t i b l e c o m p u t a t io n on c o m p l e t i o n do o u t d a t a = f ( i n d a t a ) ; to SUSPENDED on e x e c u t i o n to COMPUTE on d e a d l i n e to ERROR s t a t e SUSPENDED on d e a d l i n e to IDLE end end component p r e e m p t i b l e c o m p u t a t i o n ( i n t WCET) // a p r e e m p t i b l e c o m p u t a t io n l a s t i n g WCET time u n i t s port e x e c u t i o n , c o m p l e t i o n , t i c k , preempt data i n t c // e x e c u t i o n time behavior i n i t i a l do c = 0 ; to WAITING s t a t e WAITING on t i c k to WAITING on e x e c u t i o n to COMPUTE s t a t e COMPUTE on t i c k do c = c + 1 ; to FINISH i f c <= WCET; COMPUTE on preempt to WAITING s t a t e FINISH on c o m p l e t i o n do c = 0 ; to WAITING end end component t i m e r ( i n t P , i n t DL) // Period , DeadLine port d i s p a t c h , d e a d l i n e , t i c k data i n t t // time e l a p s e d s i n c e d i s p a t c h behavior i n i t i a l do t = 0 ; to IDLE s t a t e IDLE on t i c k do t = ( t+1)% P ; to IDLE on d i s p a t c h provided ( t = 0 ) to IDLE on d e a d l i n e provided ( t = DL − 1 ) to IDLE end end

3.1

AADL Periodic Threads in BIP

Compared to [4], we ignore initialization states as well as the support for the behavior annex. An AADL periodic thread is modeled in BIP by a compound component shown in Figure 4. One atomic component presents the execution model of a thread, one manages time and another a preemptible computation lasting WCET time units. They are synchronized on the tick port. The life of a thread is described by a ﬁve states automaton. The initial state of the thread is IDLE. It is waiting to be dispatched through an interaction on the dispatch port. When dispatched, the thread enters the READY state. If the thread is ready for a computation through the execution port, then it enters the COMPUTE state. It completes the computation with a synchronization and releases the processor through the completion port and enters the SUSPENDED state. The thread

Modeling AADL Data Communication with BIP

201

returns to the initial state through the deadline port. All the untimed ports are declared to be more prioritary than the tick port to ensure that execution is as fast as possible and the liveness of enabled transitions. Furthermore, completions must be declared with greater priority than deadlines to permit completion at deadline. Listing 1.5 shows the BIP code for the AADL speciﬁcation of a periodic thread. AADL processor components are an abstraction of hardware and software that are responsible for scheduling and executing threads. [2] proposes a BIP model for a round robin scheduler partially written in C. Here, we only focus on scheduling aspects linked to immediate communications and thus do not develop this part. 3.2

Immediate Communications in BIP

Figure 5 describes the automaton associated to an immediate connection. When time is aligned to the LCM (Least common multiple) of the periods of the two interacting threads, the data transfer is allowed through the synchronization on the port completion immediate. In this case, the execution of the receiving thread is delayed until the completion of the sender thread: execution is not allowed in the SYNC state. Otherwise(ASYNC state), completion of the ﬁrst thread and execution of the second thread are not synchronized and no data transfer is performed. Listing 1.6 shows the BIP code for the AADL speciﬁcation of an immediate connection. Listing 1.6. BIP Speciﬁcation of a immediate connection component i m m e d i a t e c o n n e c t i o n ( i n t P1 , i n t P2 ) // P e r io d o f t h r e a d 1 , P e r io d o f t h r e a d 2 port c o m p l e t i o n , c o m p l e t i o n i m m e d i a t e , e x e c u t i o n , t i c k data int t , P behavior i n i t i a l do P = LCM( P1 , P2 ) ; // L e a st common m u l t i p l e t = 0 ; // s c h e d u l e r time to SYNC // s y nc h r o no u s s t a t e s t a t e SYNC on t i c k do t = ( t +1)%P ; to SYNC on c o m p l e t i o n i m m e d i a t e to WAIT RECV s t a t e WAIT RECV // w a i t i n g t h e immediate communication on t i c k do t = ( t +1)%P ; to WAIT RECV on c o m p l e t i o n to WAIT RECV on e x e c u t i o n to ASYNC s t a t e ASYNC // a sync h r o no u s s t a t e on t i c k do t = ( t +1)%P ; to SYNC i f t = 0 ; ASYNC on c o m p l e t i o n to ASYNC on e x e c u t i o n to ASYNC end end

3.3

The Whole System in BIP

A system component represents an assembly of software and execution platform components. All subcomponents of a system are considered to be contained in

202

L. Pi, J.-P. Bodeveix, and M. Filali

immediate_connection(P1, P2)

completion

completion_immediate

execution

t = 0

tick

tick, t=t+1 SYNC

tick [t=lcm-1] t=0

completion_immediate

completion

completion ASYNC

WAIT_REC execution

execution tick, t=t+1

tick, t=t+1

Fig. 5. BIP model of an immediate connection timed_thread2.in_data = timed_thread1.out_data timed_thread1 completion_immediate completion

tick

completion

immediate_connection

timed_thread2 get_immediate tick

execution execution tick

Fig. 6. BIP system

that system. A system is modeled as a compound component in BIP. Figure 6 shows the connections between a BIP component representing an immediate data transfer and two threads. The main point is the management by the connector completion immediate of the data transfer between the sender and the receiver. The connector induces a side eﬀect on the scheduling protocol as it delays the execution of the receiver thread when dispatch events of the two communicating threads are synchronous. Listing 1.7 shows the BIP code for a system.

Modeling AADL Data Communication with BIP

203

Listing 1.7. BIP Speciﬁcation of a system component sy st e m contains t i m e d t h r e a d t h 1 ( P1 , DL1 , WCET1) contains t i m e d t h r e a d t h 2 ( P2 , DL2 , WCET2) contains i m m e d i a t e c o n n e c t i o n i m m e d i a t e ( P1 , P2 ) connector Ti c k = t h 1 . t i m e r . t i c k , t h 2 . t i m e r . t i c k , i m m e d i a t e . t i c k behavior end connector d i s p a t c h 1 = t h 1 . t h . d i s p a t c h behavior end connector d i s p a t c h 2 = t h 2 . t h . d i s p a t c h behavior end connector c o m p l e t i o n i m m e d i a t e = t h 1 . t h . c o m p l e t i o n , immediate . completion immediate , th2 . th . get immediate behavior do t h 2 . t h r e a d . i n d a t a = t h 1 . t h r e a d . o u t d a t a ; end connector c o m p l e t i o n = t h 1 . t h . c o m p l e t i o n , i m m e d i a t e . c o m p l e t i o n behavior end connector e x e c u t i o n 2 = t h 2 . t h . e x e c u t i o n , i m m e d i a t e . e x e c u t i o n behavior end connector d e a d l i n e 1 = t h 1 . t h . d e a d l i n e behavior end connector d e a d l i n e 2 = t h 2 . t h . d e a d l i n e behavior end end

3.4

Delayed Communications in BIP

The speciﬁcation of a delayed communication in BIP is speciﬁed by the automaton shown in Figure 7 with the associated BIP code given in Listing 1.8. The component declares two variables: the variable next is transmitted by the sender thread at completion. It is copied to the variable courent at sender deadline. This variable is transmitted to the receiver thread at its dispatch. Thus, two variables are needed to manage delayed communication. So in case of a communication between synchronous processes, the reader will get the new input at the start of the next period. It is therefore necessary to keep the last data to send it at the end of period. Data are always sent with nearly a period of delay. Listing 1.8. BIP Speciﬁcation of an Delayed Connection component d e l a y e d c o n n e c t i o n port c o m p l e t i o n , d e a d l i n e , d i s p a t c h data i n t c o u r e n t , n e x t // o l d and new v a l u e s behavior i n i t i a l to INIT s t a t e INIT on c o m p l e t i o n to INIT on d e a d l i n e do c o u r e n t = n e x t ; to INIT on d i s p a t c h to INIT end end

The ﬁgure 8 represents the connections between the component managing delayed data transfer and the two threads. Listing 1.9 shows the deﬁnition of the BIP connectors and the two data transfers respectively synchronized on sender completion and on receiver dispatch. As sender deadline and receiver dispatch can occur at the same time instant, the deadline event must be declared more prioritary than the dispatch event.

204

L. Pi, J.-P. Bodeveix, and M. Filali

delayed_connection

dispatch

deadline

dispatch

completion

completion INIT

deadline/current=next

Fig. 7. BIP model of a delayed connection Listing 1.9. BIP Speciﬁcation of an system component sy st e m contains t i m e d t h r e a d t h 1 ( P1 , DL1 , WCET1) contains t i m e d t h r e a d t h 2 ( P2 , DL2 , WCET2) contains d e l a y e d c o n n e c t i o n d e l a y e d connector Ti c k = t h 1 . tim . t i c k , t h 2 . tim . t i c k behavior end connector d i s p a t c h 1 = t h 1 . t h . d i s p a t c h behavior end connector complete = t h 1 . t h . c o m p l e t i o n , d e l a y e d . c o m p l e t i o n behavior end connector d e a d l i n e 1 = t h 1 . t h . d e a d l i n e , d e l a y e d . d e a d l i n e behavior do d e l a y e d . n e x t = t h 1 . t h . o u t d a t a ; end connector d i s p a t c h 2 = d e l a y e d . d i s p a t c h , t h 2 . t h . d i s p a t c h behavior do t h 2 . t h . i n d a t a = d e l a y e d . c o u r e n t ; end connector d e a d l i n e 2 = t h 2 . t h . d e a d l i n e behavior end p r i o r i t y p0 dispatch1 : th1 . th . d i sp a t c h < d e a d l i n e 2 : th2 . th . d e a d l i n e p r i o r i t y p1 d i sp a t c h 2 : delayed . dispatch , th2 . th . d i sp a t c h < d e a d l i n e 1 : th1 . th . d e a d l i n e , delayed . d e a d l i n e end

4

Related Work

[4] proposes a translation from AADL to BIP taking into account threads, processes and processors as well the behavioral annex but do not present the management of AADL communication protocols. [5] studies a TLA speciﬁcation of the AADL execution model. It takes into account a ﬁxed priority scheduling protocol with preemption, communication through ports and shared data, and the management of modes. [6]presents timing semantics of the AADL behavior annex using TASM which is based on abstract state machines extended with resource consumption annotations. [7] proposes an expression of AADL data communication with UML MARTE to which they give an explicit time model with powerful logical time constraints, but targeting a formal analyzable language remains a perspective. Another interesting study is the validation of port communication

Modeling AADL Data Communication with BIP

205

delayed_connection.next = timed_thread1.out_data timed_thread1 deadline

deadline

completion

completion

delayed_connection

timed_thread2

dispatch

dispatch

timed_thread2.in_data = delayed_connection.courent

Fig. 8. BIP system

optimization as for instance proposed in [8]. In the TOPCASED[9] project, we have deﬁned the FIACRE[10] language as a target language for veriﬁcation of high level models, compared to BIP, FIACRE has less powerful constructs but has good compositional and real-time properties, it oﬀers basic concepts comming from timed transition system [11] which permit the expression of real-time features quite easily. The lack of locality in BIP makes diﬃcult compositional reasoning [12]. Although shared variables exist in FIACRE, it remains possible to communicate through ports. Thanks to this feature local safety properties can be preserved by composition. An interesting study would be to deﬁne an inbetween language.

5

Conclusion

The BIP language has appeared to be powerful enough to take into account the various parts of the AADL language: structural, behavioral description and execution model semantics. This study has enabled us to describe the translation rules concerning periodic threads, immediate and delayed communications. This work has made us much more conﬁdent about the understanding of some basic AADL execution model mechanisms. This work was also an opportunity to study the adequation of the BIP as a target language for expressing high level models; the validation of the proposed BIP speciﬁcations remains: a logical framework with BIP concepts would be a challenging work. Even if its expressive power is adequate, compositional veriﬁcation appears to be diﬃcult because of its connector capabilities. [13] proposes a method to perform such a veriﬁcation, but restricted to multi-party interaction without data transfer. The study of this method to verify AADL components through the BIP translation remains to be considered. Another perspective of this work would be to construct reﬁnements of high level BIP speciﬁcations towards executable code and associated proof rules.

206

L. Pi, J.-P. Bodeveix, and M. Filali

References 1. SAE: Architecture Analysis & Design Language (AADL), AS-5506. SAE International (2004) 2. Basu, A., Bozga, M., Sifakis, J.: Modeling heterogeneous real-time components in bip. In: SEFM 2006: Proceedings of the Fourth IEEE International Conference on Software Engineering and Formal Methods, Washington, DC, USA, pp. 3–12. IEEE Computer Society Press, Los Alamitos (2006) 3. Franca, R.B., Bodeveix, J.P., Filali, M., Rolland, J.F., Chemouil, D., Thomas, D.: The AADL behaviour annex – experiments and roadmap. In: ICECCS 2007: Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems, Washington, DC, USA, pp. 377–382. IEEE Computer Society Press, Los Alamitos (2007) 4. Chkouri, M., Robert, A., Bozga, M., Sifakis, J.: Translating AADL into BIP application to the veriﬁcation of real-time systems. In: MoDELS 2008 ACES-MB Workshop Proceedings, pp. 39–53 (2008) 5. Rolland, J.F., Bodeveix, J.P., Chemouil, D., Filali, M., Thomas, D.: Towards a formal semantics for aadl execution model. In: European Congress on Embedded Real-Time Software (ERTS), Toulouse, 29/01/08-01/02/08 6. Yang, Z., Pi, L., Hu, K., Ma, D.: Towards a Formal Semantics for the AADL Behavior Annex. In: The Design, Automation, and Test in Europe (DATE) conference. IEEE, Los Alamitos (2009) 7. Andr´e, C., Mallet, F., de Simone, R.: Modeling of immediate vs. delayed data communications: from aadl to uml marte. Forum on speciﬁcation & Design Languages (2007) 8. Feiler, P.: Eﬃcient embedded runtime systems through port communication optimization. In: 13th IEEE International Conference on Engineering of Complex Computer Systems, pp. 294–300 (2008) 9. Topcased: toolkit in open-source for critical apllications and systems development, http://www.topcased.org 10. Berthomieu, B., Bodeveix, J.P., Farail, P., Filali, M., Garavel, H., Gauﬁllet, P., Lang, F., Vernadat, F.: Fiacre: an intermediate language for model veriﬁcation in the topcased environment. In: Proceedings of the 4th European Congress on Embedded Real-Time Software ERTS 2008, Toulouse, France (January 2008) 11. Henzinger, T.A., Manna, Z., Pnueli, A.: Timed transition systems. In: Huizing, C., de Bakker, J.W., Rozenberg, G., de Roever, W.-P. (eds.) REX 1991. LNCS, vol. 600, pp. 226–251. Springer, Heidelberg (1992) 12. Bliudze, S., Sifakis, J.: The algebra of connectors — structuring interaction in BIP. Technical Report TR-2007-3, VERIMAG (2007) 13. Bensalem, S., Bozga, M., Nguyen, T.H., Sifakis, J.: Compositional veriﬁcation for component-based. systems and application. In: Cha, S(S.), Choi, J.-Y., Kim, M., Lee, I., Viswanathan, M. (eds.) ATVA 2008. LNCS, vol. 5311. Springer, Heidelberg (2008)

Formal Verification of AADL Specifications in the Topcased Environment Bernard Berthomieu1,3, Jean-Paul Bodeveix2,3, Christelle Chaudet2,3 , Silvano Dal Zilio1,3 , Mamoun Filali2,3 , and François Vernadat1,3 1

2 3

CNRS; LAAS; 7 avenue colonel Roche, F-31077 Toulouse, France CNRS; IRIT; Université de Toulouse, 118 route de Narbonne, F-31062 Toulouse, France Université de Toulouse ; UPS, INSA, INP, ISAE, UT1, UTM ; F-31062 Toulouse, France

Abstract. We describe a formal verification toolchain for AADL, the SAE Architecture Analysis and Design Language, enriched with its behavioral annex. Our approach is based on tools that are integrated in the Topcased environment. We give a high-level view of the tools involved and illustrate the successive transformations that take place during the verification process.

1 Introduction Aeronautics and space are sectors that produce and rely on complex, critical, hardware and software systems. These systems typically have a long life cycle of development and maintenance, spanning several decades. In this process, design is the main phase of a project since code, tests and documentations are generated from the models. Moreover, the tools supporting the design process should be reliable and readily available, so as to avoid obsolescence or technology lock-in. The Architecture and Analysis Design Language (AADL) [1] is a standard, promoted by the Society of Automotive Engineers (SAE), for the specification and analysis of complex real-time embedded systems. AADL is a textual and graphical language, designed for model-based engineering, which can be used to describe both the software and hardware components of a system. In order to support model-based development, companies from the French Aeronautics, Space and Embedded Systems competitivity pole (AESE) have joined their efforts to develop a common set of methods and tools. The goal is to deliver an industrial strength system/software development platform for embedded systems. The Topcased [18] initiative is part of this effort and AADL is among the first languages supported in this project. Topcased is also the name of a toolkit based on the Eclipse platform and concepts that provides an open source, model oriented set of tooling and standard implementations. Our main objective in this paper is to present a verification toolchain for AADL specifications that is fully integrated in the Topcased environment. We give a highlevel view of the tools involved and illustrate the successive transformations required by

This work was partly supported by the French AESE project Topcased, The ANR project OpenEmbeDD, and by region Midi-Pyrénées.

F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 207–221, 2009. c Springer-Verlag Berlin Heidelberg 2009

208

B. Berthomieu et al.

our verification process. These tools include a semantic editor of AADL and a modelchecking platform based on Time Petri-Net, Tina [11]. The generation of Tina models from an AADL description relies on the Fiacre intermediate language. First, the AADL description is translated in the Fiacre format, which offers a formal intermediate model to represent both the behavioral and timing aspects of the system. Then, we compile the Fiacre model into an abstract Timed Transition Systems that can be directly analyzed by Tina. Therefore, Fiacre is designed both as the target language of model transformation engines from various models such as SDL, UML, AADL, . . . and as a front end to targeted verification toolboxes, namely CADP and Tina in the first step. After a brief review of AADL, we present the Fiacre language and describe the fundamentals of our translation from AADL to Fiacre. The transformation is illustrated on a small example. Before concluding, we introduce the Tina verification platform and give examples of properties that can be verified on the models.

2 AADL The SAE Architecture and Analysis Design Language is a standard used to describe both the software and hardware components of a system. Specifications based on an architecture description language have the benefit to provide support for an early analysis of the properties of a system. These properties are supposed to be obtained before the coding or the actual deployment of the system. Model-based system engineering (MBE) lets you focus on the analysis of system architecture — and detect problems with availability, security, and timeliness early on. AADL descriptions pertain to the functional interfaces of components, such as data inputs and outputs, as well as to non-functional aspects, such as timing properties. The language can describe how components are combined, such as how data inputs and outputs are connected or how software components are allocated to hardware components. Release 1.0 of the AADL standard (SAE AS5506) has been issued in November 2004. Since then, many extensions have been proposed. Some of them, like the Error Model Annex, have been adopted by the standardization committee. Tools have also been developed, like the initial OSATE environment, which has been merged with Topcased. AADL includes all the standard concepts of an Architecture Description Language: components, connectors (used to describe the interface of components), and connections (used to link components). The set of AADL components can be divided in three partitions, the software components (process, thread, thread group, subprogram, and data), the hardware components (processor, bus, memory, device), and system components. Components can communicate through ports, synchronous calls, and shared data. A process represents a virtual address space, or a partition; this address space includes the program defined by its sub-components. A process must contain at least one thread or thread group. A thread group is a logical organization of threads in a process. A thread represents a sequential flow of execution; it is the only AADL component that can be scheduled. A subprogram represents a piece of code that can be called by a thread or another program. A data models a static variable used in the code; threads and processes can share data.

Formal Verification of AADL Specifications

209

An AADL model can incorporate non-architectural elements: embedded or real-time characteristics of the components (execution time, memory usage, etc.), behavioral descriptions, etc. Hence it is possible to use AADL as a backbone to describe all the aspects of a system. To this end, AADL defines the notion of properties that can be attached to most elements (components, connections, features, etc.). Properties are attributes that specify constraints or characteristics that apply to the elements of the architecture: clock frequency of a processor, execution time of a thread, bandwidth of a bus, etc. Some standard properties are defined but the definition can be extended with user-defined properties. Finally, AADL supports an annex mechanism to extend the description capabilities of the language by introducing a dedicated sub-language. A behavior annex [4] is currently being defined by the SAE committee. 2.1 The Execution Model Threads are the only components that have an execution semantics. AADL supports the classical types of dispatch protocols: a thread can be declared as periodic, aperiodic, sporadic or background. All the standard properties (WCET, deadline, . . . ) used to describe a real-time system exist in AADL. Threads have two predeclared event ports : dispatch and complete. The dispatch port is used for aperiodic or sporadic threads. If this port is connected all other ports of the thread do not trigger the dispatch. It is a very common behavior for an aperiodic or a sporadic thread to send an event on completion. In AADL, we do not specify when an event is sent. The complete event port is used to send an event at the end of the execution. All threads have the same life cycle. This cycle can be represented as an automaton (see Fig. 1). All threads start in the awaiting_dispatch state. The dispatch condition depends on the thread type. If the thread is periodic it will be dispatched at every period. At this time, delivery occurs for all its input ports. An aperiodic or a sporadic thread that does not have its dispatch ports connected is dispatched each time it receives an event. Delivery occurs only for the port that triggers the dispatch and the data ports. If its dispatch port is connected, it is dispatched each time it receives an event on this port, and delivery occurs for all its others ports. The thread in the active state that has the maximum priority starts or continues its execution. The priority of the thread is determined by the chosen scheduling policy (RMA, EDF, LLF). This policy is specified by a property of the model. When a thread is dispatched it can have a higher priority than the executing thread. In this case, the executing thread is preempted and goes back to the active state. When a thread ends its execution it goes to the awaiting_dispatch state until the next dispatch. At this time, all the output data ports of the thread are read and their content sent to the destination ports. The scheduling behavior we just described is slightly different if shared resources are used. When an executing thread tries to access a locked shared resource, it goes to a special state, labeled awaiting_resource in our automata, where it blocks until the resource (its lock) is released. The process by which a variable is locked depends on the kind of implementation used for the AADL specification. In the most general case, the basic implementation is to lock a shared resource during the whole execution of the thread that accesses it.

210

B. Berthomieu et al. complete(t) executing

awaiting_dispatch

block_on_resource(t)

maxPrio(t) preempt(t)

dispatch(t) active

awaiting_resource

unblock_on_release_resource(t)

Fig. 1. Thread automaton with (and without) shared resources

2.2 A Toy Example In this section, we illustrate AADL by encoding a simple token ring example (Listing 1.1). It is a network of processes (AADL threads), logically organized in a ring topology, which synchronize their communication by means of a token that circulates among them, controlling access to the communication channels. The goal is to implement mutual exclusion among all threads. We suppose that threads communicate only through ports: each thread is connected to a successor (resp. predecessor) thread by its port named succ (resp. pred). A thread enters mutual exclusion once it owns the token. The proposed AADL model consists in a thread Start that chooses non-deterministically the Node that initially owns the token (actions start0!, . . . , start2!). Each node communicates with its predecessor and successor nodes over its ports named prev and succ. Each thread is supposed to be sporadic with a minimal period of 10ms. The behavior of a node is described through the behavioral annex. Initially, threads are in the idle state. When it receives the token (action prev?), it forwards it (action succ!) then it can, non-deterministically, either remain idle or become waiting. When a waiting thread receives the token, it enters mutual exclusion (state cs). After a computation, which can elapse between 5 and 10 ms, it leaves mutual exclusion, transfers the token to its neighbour and becomes idle again.

3 AADL to Fiacre Translation The modeling language of model checkers must be kept simple enough for the tool to be efficient. It is therefore preferable to reuse existing model checkers (e.g. Tina [11] and CADP [12]) to check properties of high-level languages (UML, SysML, AADL), which leads to the introduction of a transformation phase between the two levels. In order to simplify the connection of model checkers to those languages, we have introduced the pivot language Fiacre [13] so that the expression of the run-time semantics of high-level languages can be factorized and expressed using the pivot. It must be powerful enough to support the expression of the semantics of real time preemptible systems even if back-end model checkers do not take into account all the aspects of the model. The tools are implemented and/or integrated in the Topcased environment. Topcased offers the metamodel of the high-level modeling languages together with graphical editors. The abstract syntax of the Fiacre intermediate language is defined through its metamodel. Transformation languages are used to generate Fiacre models

Formal Verification of AADL Specifications

thread Start features start0 : out event port ; start1 : out event port ; start2 : out event port ; properties Dispatch_Protocol => Background ; end Start ; thread implementation Start . i annex behavior_specification {∗∗ states s0 : initial state ; s1 : complete state ; transitions s0 −[ ]→ s1 { start0 ! ; } ; transitions s0 −[ ]→ s1 { start1 ! ; } ; transitions s0 −[ ]→ s1 { start2 ! ; } ; ∗∗}; end Start . i ; thread Node features prev : in event port ; succ : out event port ; start : in event port ; properties Dispatch_Protocol => Sporadic ; Period => 10 ms ; end Node ; thread implementation Node . i annex behavior_specification {∗∗ states idle : initial complete state ; wait : complete state ; cs : state ; transitions idle −[start ?]→ idle { succ ! ; } ; idle −[prev ?]→ idle { computation( 3 ms ) ; succ ! ; } ; idle −[prev ?]→ wait { computation( 3 ms ) ; succ ! ; } ; wait −[prev ?]→ cs ; cs −[ ]→ idle { computation ( 5 ms , 10 ms ) ; succ ! ; } ; ∗∗}; end Node . i ; process network end network ; process implementation network . i subcomponents s : thread Start . i ; n0 : thread Node . i ; n1 : thread Node . i ; n2 : thread Node . i ; connections event port s . start0 −> n0 . start ; event port s . start1 −> n1 . start ; event port s . start2 −> n2 . start ; event port n0 . succ −> n1 . prev ; event port n1 . succ −> n2 . prev ; event port n2 . succ −> n0 . prev ; end network . i ; system root end root ; system implementation root . i subcomponents p : process network . i ; end root . i ;

Listing 1.1. A token ring in AADL

211

212

B. Berthomieu et al.

process Start [ start0 : none , start1 : none , start2 : none ] is states s0 , s1 from s0 select start0 [ ] start1 [ ] start2 end ; to s1 process Node [ prev : none , succ : none , start : in none ] is states idle , wait , cs , st_1 from idle select start ; to st_1 [ ] prev ; to st_1 end from st_1 succ ; select to idle [ ] to wait end from wait prev ; to cs from cs succ ; to idle component root is port s0 : none , s1 : none , s2 : none , p0 : none , p1 : none , p2 : none , par ∗ in Start [ s0 , s1 , s2 ] | | Node [ p0 , p1 , s0 ] | | Node [ p1 , p2 , s1 ] | | Node [ p2 , p0 , s2 ] end root

Listing 1.2. A token ring in Fiacre

from modeling languages. At this step, some semantics choice must be performed to identify relevant subsets of sources languages and reduce the complexity of intermediate models. Then, source code generators are used to produce the text representation of the Fiacre model and communicate with the external Fiacre front-end. The Fiacre tool performs static analysis of its entry and generates Tina and CADP models, which are analyzed by the corresponding tools. 3.1 The Fiacre Language Fiacre offers a formal representation of both the behavioral and timing aspects of systems for formal verification and simulation purposes. The design of the language is inspired from decades of research on concurrency theory and real-time systems theory. For instance, its timing primitives are borrowed from Time Petri nets [10], while the integration of time constraints and priorities into the language can be traced to the BIP framework [2]. For what concerns the compositionality of the language, Fiacre incorporates a parallel composition operator and a notion of gate typing which were previously adopted in E-Lotos and Lotos-NT. Fiacre programs are stratified in two main notions: processes, which describes the behavior of sequential components and components, which describes a system as a composition of processes, possibly in a hierarchical manner. Listing 1.2 gives an example of a Fiacre program for the token ring example described in Sect. 2.2. Fiacre is a strongly typed language, meaning that type annotations are exploited in order to guarantee the absence of unchecked run-time type errors. A program is a sequence of declarations. A process is defined by a set of control states and parameters, each associated with a set of complex transitions, which are programs specifying how parameters are updated and which transitions may fire. For example, the process declaration:

Formal Verification of AADL Specifications

213

process T[p : bool, q : none](v : int, &u : array 5 of bool) is ... expresses that T is a process that may interact over two ports: p, which transmits boolean values, and q, which can only be used for synchronization. The processT has two parameters: v, which is an integer, and u, which is a (reference to a) shared variable. Complex transitions are built from expressions and deterministic constructs available in classical programming languages (assignments, conditionals, while loops and sequential compositions), nondeterministic constructs (nondeterministic choice and assignments) and communication events on ports. For example, the transition: from s0 select (p!5 ; to s1) []

(v :=v + 1 ; to s2)

end

expresses that, in state s0, the process may choose nondeterministically between two alternatives. Either send the value true over the port p and move to state s1, or increment the value of the variable v and move to s2. A process definition may declare several transitions for the same state. Each can equally be fired. A component is defined as the parallel composition of processes and/or other components, expressed with the operator par ... || ... end. While components are the unit of composition, they are also the unit for process instantiation and for ports and shared variables creation. The syntax of components allows to restrict the access mode and visibility of shared variables and ports, to associate timing constraints with communications and to define priority between communication events. For example, in a component C, the declaration port p : none defines a port called p that is private to (cannot be used outside of) C. The declaration port p : none in [min,max] defines a port that can only interact min time units after it has been activated and must be used or deactivated before max time units (min and max should be float or integer constants). 3.2 Translation Principles The transformation of AADL code into Fiacre relies on AADL properties and on the behavioral annex of AADL that has been developed and integrated to the OSATE AADL environment within Topcased. We follow a model-driven approach. Alongside a metamodel of AADL, we have developed a meta-model of the Fiacre language that is integrated in the Topcased tool-chain. Hence, the transformation from AADL to Fiacre can be obtained through model transformation. This translation is based on the formal semantics of the (default) AADL execution model that was previously defined. In the particular instance studied in this paper we illustrate this framework with the translation of AADL models to Fiacre. The transformation is implemented in the Topcased environment using a model to model transformation approach performed using Kermeta. Kermeta is a model transformation language that combines features coming from Eiffel, Java and OCL. Moreover, it offers an Aspect Oriented Programming style that makes easy the access to EMF model repositories. Two main features are heavily used in the translation: high-level iterators on lists and aspect oriented annotations. These annotations allow to specify extensions of existing classes with new attributes and operations. Attributes are used to memorize the Fiacre objects resulting from the transformation of the AADL objects and avoid the use of external data structures such as hash tables.

214

B. Berthomieu et al.

...

thread 1

thread n

glue Fig. 2. Threads and the glue Complete!D Dispatch!... Thread

Glue Event_i EventData_i

Fig. 3. Communication with the glue

3.3 Structure of the Generated Code The code generator has a flatten view of the AADL model as a set of communicating threads. Thus, it associates a Fiacre process to each AADL thread. They do not communicate directly: a glue process manages communication and scheduling protocols. Threads communicate with their environment through the glue process. A thread receives from the glue the values of its input ports and sends to the glue its output events or data ports at specific times. In a first approximation, the glue sends a dispatch message to a thread at its logical dispatch time. It takes as parameters the values of the thread input data ports and the value of the triggering event (data) port if any. If the thread is periodic, the value of all the input ports is transmitted. During execution, the thread sends to the glue events with their potential value. When the execution completes, the thread sends a complete message to the glue with the values of the output data ports and of the modified (yet not already sent) event data ports. The following code specifies an AADL thread having event, data and event data input or output ports and a data access feature (see Fig. 4). thread T features idp : in data port Tidp ; odp : out data port Todp ; iep : in event port { Queue_Size => Q } ; oep : out event port ; iedp : in event data port Tiedp { Queue_Size => Q } ; oedp : out event data port Toedp ; m : requires data access Tm ; end T ;

The interface of the corresponding Fiacre process depends on the way the thread is triggered. If it is timed triggered, the contents of all its input ports is transfered while if it is event triggered, only the contents of the triggering port is transfered: The translation of thread scheduling is based on Fiacre temporized ports and port priorities. Such ports are used to manage periodic dispatch of threads and non deterministic execution times. Since Fiacre does not offer any support for preemption yet,

Formal Verification of AADL Specifications

215

Fig. 4. Thread interface

we only consider a non preemptive fixed priority scheduler. For the Fiacre translation to remain simple, priorities cannot depend on AADL modes. Only the set of active threads can be mode dependent. process T [ dispatch : in . . . , complete : out . . . , oep_port : out none , oedp_port : out Toedp ] (&tab_Tm : array N of Tm , &m : 0 . . N −1) ...

Listing 1.3. Translation of time triggered threads type T_events is union C_iep of 0 . . Q | C_iedp of queue Q of Tiedp end process T [ dispatch : in T_events # . . . , complete : out . . . , oep_port : out none , oedp_port : out Toedp ] (& tab_Tm : array N of Tm , &m : 0 . . N −1) ...

Listing 1.4. Translation of event triggered threads

The scheduler manages periodic, sporadic and background tasks. It must ensure data access synchronization as described by the AADL execution model. The following events are managed in our translation. Dispatch. Dispatch occurs at a multiple of the period (for periodic thread), when a triggering event arrives (for sporadic threads), or at system startup (for background threads). On that event, data are transferred to the thread port variables. A thread can run if all threads that must dispatch at the same time have their data. Execution. The scheduler allows thread execution. Data received through an immediate connector are transmitted to the thread and thread priorities are encoded using priorities between execution ports. Completion. The thread ends its execution and transmits its output data connected via immediate connectors and event data not already transmitted. Deadline. The thread transmits delayed data. Completion must occur before deadline otherwise a schedule error happens.

216

B. Berthomieu et al.

We have only presented the interface of the main components. Due to the lack of space, we do not describe the implementation and the related state machines. An important aspect of the implementation is the interaction between user threads and AADL execution model. This will be detailed in a forthcoming paper. 3.4 The Considered Subset Basic properties are considered when generating a Fiacre model. More particularly, (1) AADL modes and priorities are taken into account, as well as (2) access to shared variables. For the moment, while periods can change, we assume that priorities are fixed. We take into account that connections are determined by the current mode. On the other hand, there is currently no support for multiprocessor architecture in our translation from AADL to Fiacre. As a result, we do not take into account the value of the Actual_Processor_Binding property. We also do not handle preemption. This last feature will be added in a forthcoming version of the Fiacre language.

4 Behavioral Verification with Tina Tina [11], the TIme Petri Net Analyzer, provides a software environment to edit and analyze Petri Nets and Time Petri Nets. It is particularly well suited to the verification of systems subject to real time constraints, such as those modeled using AADL. Beside the usual analysis facilities of similar environments, the essential components of the Tina toolbox are state space abstraction methods and model checking tools that can be used for the behavioral verification of systems. This is in contrast with the broader notion of functional verification, in that we attempt to use formal techniques to prove that requirements are met, or that certain undesired behaviors cannot occur — like for instance deadlocks — without resorting to actual tests on the system. The approach followed here is that commonly referred to as model-checking, which basically consists in two abstract steps: (1) the generation of a formal model from a description of the system, followed by (2) a systematic exploration of the states space of this model. This involves exploring states and transitions in the model, relying on smart abstraction techniques to reduce the number and size of these states and therefore reducing the computing time. The properties to be verified are often described in temporal logics, such as linear temporal logic (LTL) or computational tree logic (CTL). We give some examples of LTL properties related to our running example in Section 4.2. The result of the verification may lead to an accepting status, meaning that the model of the system satisfies the requirements, or exhibit an error. In the last case, it is often possible to extract a counterexample, which is an explanation at the level of the model (generally an execution trace), which leads to a problematic state. Such counterexamples could be stored alongside an AADL model. 4.1 The Tina Toolbox The functional architecture of Tina is shown in Fig. 5. The core of the Tina toolset is an exploration engine used to generate state space abstractions that are fed to dedicated model checking and transition system analyzer tools.

Formal Verification of AADL Specifications

217

Fig. 5. Tina Architecture

The front-ends to the exploration engine convert models into an internal representation — the abstract Timed Transition Systems (TTS) — that is an extension of Time Petri nets handling data and priorities. The frac compiler, which converts Fiacre description into TTS and is part of the Topcased environment, is an example of such front-end. State space abstractions are vital when dealing with timed systems, that have in general infinite state spaces. Tina offers several abstract state space constructions that preserve specific classes of properties like absence of deadlocks, linear time temporal properties, or bisimilarity. A variety of properties can be checked on abstract state spaces: general properties — such as reachability properties, deadlock freeness, liveness, . . . — specific properties relying on the linear structure of the concrete space state — for example linear time temporal logic properties, test equivalence, . . . — or properties relying on its branching structure – branching time temporal logic properties, bisimulation, . . . Tina provides several back-ends to convert abstract state spaces into physical representations readable by the proprietary or external model checkers and transition system analyzers. Tina can present its results in a variety of formats, understood by model checkers like MEC, a mu-calculus formula checker, or behavior equivalence checkers like Bcg, part of the CADP toolset. Hence we can apply all these tools to the verification of systems modeled in AADL. In addition, several model-checkers are being developed specifically for Tina. The first available, selt, is a model-checker for an enriched version of State/Event-LTL, a linear time temporal logic supporting both state and transition properties. (The logic is rich enough to encode marking invariants.) For the properties found false, a timed counter example is computed and can be replayed by the simulator. 4.2 Verification The Tina toolbox provides a native model checker, selt, which allows to check more specific properties than the generic properties (boundedness, deadlocks, liveness) that

218

B. Berthomieu et al.

may directly be checked during state space generation. This tool implements an extension of linear time temporal logic known as State/Event LTL [15], a logic supporting both state and transition properties. The modeling framework consists of Kripke transition systems (corresponding to the state class graph of a Petri net in our case), which are directed graphs in which states are labelled with atomic propositions and transitions are labelled with actions. State/Event-LTL formulas are interpreted over the computation paths of the model and may express a wide range of state and/or transition properties. Formulas p, q, ... of the logic are expressions built from the classical logical operators: negation (-p), conjunction (p /\ q), . . . and the basic LTL modalities: [], <>, () and U. A formula is said to be true if it holds on all computation paths. The formula p holds (relative to a computation path) if p holds now. That is at the start of the path. The meaning of the temporal modalities is described below. () p [] p <> p p U q

holds if holds if holds if holds if

p holds at the next step p holds all along the path p holds in a future step p holds until the first moment that q holds

(next) (always) (eventually) (until)

We can define some examples or formulas to be checked against the system obtained from our running examples. For instance, the formula -<>(cs_Node_1 /\ cs_Node_2) states that it is not the case that, eventually, the first two processes in the token ring are in critical section (state cs) at the same time. Formula (1), which states that at most one Node process may be in the critical section at any given moment, offers a more versatile way for expressing mutual exclusion. [](cs_Node_1 + cs_Node_2 + cs_Node_3 <= 1)

(1)

Likewise, we can express that a node in the token ring cannot wait eternally before accessing the critical section. For example, Formula (2) states that “it is always the case that if Node waits then, eventually, it enters state cs.” [](wait_Node_1 => <> cs_Node_1)

(2)

Formulas (1) and (2) can be evaluated (and are true) on the token ring example of Listing 1.2 and on the Fiacre program obtained from the translation of the AADL program in Listing 1.1. Realtime properties, like those expressed in so-called timed temporal logics, are checked using the standard technique of observers, encoding such properties into reachability properties. The technique is applicable to a large class of realtime properties and can be used to analyze most of the “timeliness” requirements found in practice.

5 Related Work A number of studies have explored how to interpret the AADL standard in a formal setting. A specification of the AADL execution model in the Temporal Logic of Actions (TLA) is given in [16] that defines one of the earliest formal semantics for AADL.

Formal Verification of AADL Specifications

219

This encoding takes into account a fixed priority scheduling protocol with preemption, the management of modes and communication through ports and shared data. Our approach is based on an interpretation of AADL specifications, including the behavior annex, in the Fiacre Language, which is one of the input languages of the Tina toolbox. A direct encoding from AADL to Petri net is studied in [23] that takes into account a more limited subset of AADL (it restricts the behavior of software components and omits realtime properties of elements). Other target formalisms have also been studied. An encoding of AADL in BIP is presented in [3] that focuses on the behavioral annex as well as on threads, processes and processors. The approach is improved in [14] by taking into account the management of AADL communication protocols. When compared to BIP, the current version of Fiacre provides less high-level constructs – therefore encodings are less direct – but offers better compositional and real-time properties. An interesting study would be to define an intermediate language. In our work, the behavior of software components can be described using the behavior annex [4], which is currently being defined by the SAE committee. In [6], the authors study the case where behaviors are described in a synchronous language, such as Scade or Lustre. In this case, they define a direct translation that generate an executable model of the software behavior, deployed on the architecture, from an AADL specification. Such a model is usable for early simulation, but also for formal verification, using tools available for Scade and Lustre. Finally, other works [21,22] have focused on AADL data communication handling but leave the connection with a formal verification tool as a perspective. While we focus our attention on the use of the Fiacre intermediate language and the Tina verification toolset, our work relies also significantly on the Model-Driven Architecture approach promoted in Topcased. Currently, a metamodel for AADL is provided by the OSATE [24] tool, which is integrated in Topcased. A metamodel for Fiacre, build using the Topcased environment, is also available.

6 Conclusion and Future Work This paper describes a formal verification toolchain for AADL that is currently made available in the Topcased environment. We give a high-level view of the tools involved and illustrate the successive transformations required by our verification process. Work is still ongoing to improve the tools involved in our verification toolchain. A number of extensions to Tina are being evaluated, concerning new tools, new frontends, and new back-ends. For instance, we are experimenting with the addition of suspension/resumption of actions to Time Petri nets, which is of great value for modeling scheduled real-time systems. Alongside these works on tools, our current efforts are directed toward three main objectives: (1) Simplifying the definition of logical properties. End users of verification tools should not be required to master temporal logic. To improve the usability of our approach, we are currently investigating the proposition of a kit of predefined AADL requirements. This kit will enable expressing general properties of an AADL component — absence of deadlock, absence of divergence, . . . — in a straightforward way. (2) Improving error reporting. We plan to provide a “debugging” procedure, which should take as input a counter-example produced during the model-checking stage and

220

B. Berthomieu et al.

convert it to a trace model of the initial AADL description. These traces should be played back using simulation tools. (3) Improving the Verification Process. We are currently investigating extensions to the Fiacre language in order to ease the interpretation of high-level description languages and to optimize the verification process. One envisioned addition would be to integrate the notion of modes [17] — which is found in a number of ADL, like Giotto and AADL — directly in Fiacre. We also plan to address the problem of specifying scheduling and time-constrained behaviors within Fiacre. These aspects should have a great impact on the overall performance of the analysis tool.

References 1. SAE Aerospace. Architecture Analysis & Design Language (AADL).AS-5506, SAE International (2004) 2. Basu, A., Bozga, M., Sifakis, J.: Modeling heterogeneous real-time systems in BIP. In: Proc. of SEFM – IEEE Software Engineering and Formal Methods (2006) 3. Chkouri, M., Robert, A., Bozga, M., Sifakis, J.: Translating AADL into BIP – application to the verification of real-time systems. In: Proc. of MoDELS ACES-MB – Model Based Architecting and Construction of Embedded Systems (2008) 4. Franca, R.B., Bodeveix, J.-P., Chemouil, D., Filali, M., Thomas, D., Rolland, J.-F.: The AADL behaviour annex, experiments and roadmap. In: Proc. of ICECCS – IEEE International Conference on Engineering of Complex Computer Systems (2007) 5. Muller, P.-A., Fleurey, F., Vojtisek, D., Drey, Z., Pollet, D., Fondement, F., Studer, P., Jézéuel, J.-M.: On executable meta-languages applied to model transformations. In: Proc. of MoDELS – Model Transformations In Practice (2005) 6. Jahier, E., Halbwachs, N., Raymond, P., Nicollin, X., Lesens, D.: Virtual Execution of AADL Models via a Translation into Synchronous Programs. In: Proc. of EMSOFT – ACM & IEEE international conference on Embedded software (2007) 7. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Proc. of MoDELS – Model Transformations in Practice (2005) 8. OAW, http://www.openarchitectureware.org/ 9. OCL, UML 2.0 Object Constraint Language 10. Merlin, P.M., Farber, D.J.: Recoverability of communication protocols: Implications of a theoretical study. IIEEE Transactions on Computers 24(9), 1036–1043 (1976) 11. Berthomieu, B., Ribet, P.-O., Vernadat, F.: The tool TINA – Construction of Abstract State Spaces for Petri Nets and Time Petri Nets. International Journal of Production Research 42(14) (2004) 12. Garavel, H., Lang, F., Mateescu, R., Serve, W.: CADP: A Toolbox for the Construction and Analysis of Distributed Processes. In: Proc. of CAV – Int. Conf. On Computer Aided Verification (2007) 13. Berthomieu, B., Bodeveix, J.P., Filali, M., Garavel, H., Lang, F., Peres, F., Saad, R., Stoecker, J., Vernadat, F.: The syntax and semantics of Fiacre.Research Report LAAS 07264 (2007) 14. Pi, L., Bodeveix, J.-P., Filali, M.: Modeling AADL Data Communication with BIP (preprint, 2009) 15. Chaki, S., Clarke, E.M., Ouaknine, J., Sharygina, N., Sinha, N.: State/Event-based Software Model Checking. In: Boiten, E.A., Derrick, J., Smith, G.P. (eds.) IFM 2004. LNCS, vol. 2999, pp. 128–147. Springer, Heidelberg (2004)

Formal Verification of AADL Specifications

221

16. Rolland, J.-F., Bodeveix, J.-P., Chemouil, D., Filali, M., Thomas, D.: Towards a formal semantics for AADL execution model. In: Proc. of ERTS – European Congress on Embedded Real-Time Software (2008) 17. Rolland, J.-F., Bodeveix, J.-P., Filali, M., Thomas, D., Chemouil, D.: Modes in asynchronous systems. In: Proc. of UML&AADL (2008) 18. Topcased: Toolkit in OPen-source for Critical Applications and SystEms Development, http://www.topcased.org 19. Berthomieu, B., Vernadat, F.: State Space Abstractions for Time Petri Nets. In: Handbook of Real-Time and Embedded Systems. Chapman and Hall, Boca Raton (2007) 20. Farines, J.-M., Berthomieu, B., Bodeveix, J.-P., Dissaux, P., Farail, P., Filali, M., Gaufillet, P., Hafidi, H., Lambert, J.-L., Michel, P., Vernadat, F.: The Cotre Project: Rigorous Software Development for Real Time Systems in Avionics. In: Proc. of FMICS – Formal Methods for Industrial Critical Systems. ENTCS, vol. 80 (2003) 21. André, C., Mallet, F., de Simone, R.: Modeling of immediate vs. delayed data communications: from AADL to UML Marte. In: Forum on specification & Design Languages (2007) 22. Feiler, P.: Efficient embedded runtime systems through port communication optimization. In: Proc. of ICECCS – IEEE International Conference on Engineering of Complex Computer Systems (2008) 23. Vergnaud, T.: Modélisation des systèmes temps-réel répartis embarqués pour la génération automatique d’applications formellement vérifiées.PhD Thesis, École nationale supérieure des télécommunications (2006) 24. The SEI AADL Team. An Extensible Open Source AADL Tool Environment (OSATE). Software Engineering Institute (2006)

Process-Algebraic Interpretation of AADL Models Oleg Sokolsky1 , Insup Lee1 , and Duncan Clarke2 1

Department of Computer and Info. Science, University of Pennsylvania, Philadelphia, PA, U.S.A. 2 Fremont Associates, Camden, S.C., U.S.A.

Abstract. We present a toolset for the behavioral verification and validation of architectural models of embedded systems expressed in the language AADL. The toolset provides simulation and timing analysis of AADL models. Underlying both tools is a process-algebraic implementation of AADL semantics. The common implementation of the semantics ensures consistency in the analysis results between the tools.

1

Introduction

Distributed real-time embedded (DRE) systems, which once were conﬁned to a few advanced domains such as avionics systems, are now aﬀecting our lives in many ways. DRE systems are used in cars, medical and assisted living devices, in home appliances and factory automation systems. Functionality of such systems if greatly expanded and quality of service requirements remain quite stringent. At the same time, the use of DRE systems in mass-produced systems has unleashed market pressures to compress development time and reduce costs. New development and veriﬁcation and validation (V&V) methods are needed to produce safe, eﬃcient, and competitive DRE systems. Early evaluation of the system design is important for successful and timely development. Correction of errors in the design becomes progressively more expensive later in the design process. Of course, many details of the system are not know in the early stages of development, and only high-level evaluation is possible. Architectural modeling oﬀers a structured way to collect available in information about the system and incrementally reﬁne it as the design progresses. An architectural model also allows developers to apply high-level analysis techniques that can quickly uncover problems. Since architecture-level analysis tend to be approximate and eﬃcient, design-space exploration can be performed by varying diﬀerent aspects of an architectural model and comparing outcomes of analysis for diﬀerent architecture variants. AADL [6,13] is a standard for the architectural modeling of DRE systems. It allows developers to describe a system as a collection of interacting components and connections between them, abstracting away the functionality of components that is not precisely known at early stages of system development. The

This research has been supported in part by grants AFOSR STTR AF04-T023, NSF STTR IIP-0712298, NSF CNS-0720703, and AFOSR FA9550-07-1-0216.

F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 222–236, 2009. c Springer-Verlag Berlin Heidelberg 2009

Process-Algebraic Interpretation of AADL Models

223

standard deﬁnes interchangeable textual and graphical modeling notations and gives precise, if mostly informal, semantics for the components and connections. AADL modeling is supported by an open-source development environment OSATE, which provides an extension API for the development of analysis plugins that operate on the OSATE internal representation of AADL models. In this paper, we describe two analysis techniques for AADL models and present their implementation in the Furness toolset, implemented as an OSATE plugin. One technique is an AADL simulator that allows the user to visually follow the high-level execution of the system and track resource utilization. The other technique is schedulability analysis that determines whether the system has enough resources to satisfy the timing constraints. Both analysis technique, along with many other analysis techniques developed for AADL, rely on AADL semantics. We argue that tools that implement these analysis techniques need a common interpretation engine to ensure that all tools treat AADL semantics consistently. Furness toolset uses an encoding of AADL semantics in a real-time process algebra ACSR [9], which provides a common semantic foundation for for diﬀerent analysis tool in the toolset. The paper is organized as follows. Section 2 presents an overview of AADL and its behavioral semantics. Section 3 presents the real-time process algebra ACSR and formal schedulability analysis. In Section 4 we turn to the architecture of the Furness toolset and present the translation of an AADL model into ACSR. Finally, Section 5 concludes with a discussion.

2

Introduction to AADL

Components. The main modeling notion of AADL is a component. Components can represent a software application or an execution platform. A component can have a set of externally accessible features and an internal implementation that can be changed transparently to the rest of the model as long as the features of the component do not change. Implementation of a component can include interconnected subcomponents. The features of a component include data and event ports and port groups, subroutine call entries, required and provided resources. Interacting components can have their features linked by event, data, and access connections. In addition, application components can be bound to execution platform components to yield a complete system model. Properties, speciﬁc to a component type, can be assigned values that describe the system design and used to analyze the model. Main component types are illustrated in Figure 1. Diﬀerent component types are shown as diﬀerent shapes. Solid lines represent connections, while dashed lines represent bindings. Execution platform components include processors, buses, memory blocks, and devices. Properties of these components describe the execution platform. Processors are abstractions of hardware and the operating system. Properties of processors specify, for example, processing speed and the scheduling policy. Buses can represent physical interconnections or protocol layers. Their properties identify the throughput and the latency of data transfers, data formats, etc.

224

O. Sokolsky, I. Lee, and D. Clarke

100ms

100ms

Decode

Display

Compensate phase1

phase2 proc1

internal

proc2

Fig. 1. A simple AADL model

Application components include threads and systems. Threads are units of execution. A thread can be halted, inactive, or active. An active thread can be waiting for a dispatch, computing, or blocked on resource access; etc. We discuss thread semantics in more detail below. Properties of the thread specify computation requirements and deadlines in active states of the thread, dispatch protocol, etc. Threads are classiﬁed into periodic, aperiodic, sporadic, and background threads. They diﬀer in their dispatch protocol and their response to external events. A system component is a unit of composition. It can contain application components along with platform components, and speciﬁes bindings between them. Systems can be hierarchically organized. Figure 1 shows a simple AADL model of a stream processing system. The system component contains two processors connected by a bus, and two software subsystems, one of which contains a single periodic thread and the other one contains two threads, one periodic, the other aperiodic. Each of the subsystems is bound to a separate processor, while the connection between threads bound to diﬀerent processors is bound to the bus. Threads communicate via data or event ports, denoted by ﬁlled and blank angles, respectively. Features of a component are mapped by connections to features of its subcomponents. Semantics of AADL threads. The AADL standard speciﬁes semantics for each AADL component, most of which are precise and detailed but informal. An exception is the thread component. Semantics of a thread are formalized using a hierarchical stopwatch automaton that describes thread states and conditions on transitions between thread states. Figure 2 shows the main part of the thread automaton, omitting initialization, error recovery, and mode switching. The automaton uses two clocks, t and c, which represent elapsed time and accumulated execution time, respectively. First derivatives of the clock functions are denoted δt and δc. Elapsed time always evolves at the same speed (δt = 1). When the thread is not executing – for example, preempted by another thread – the clock c is stopped (δc = 0). The invariant of the suspended state and the predicate Enabled(t) depend on the dispatch protocol property. For example, for a periodic thread, the invariant is t ≤ P eriod and Enabled(t) is t = P eriod. Connections. Event and data connections between AADL components form semantic connections. Each semantic connection has an ultimate source and

Process-Algebraic Interpretation of AADL Models

225

suspended awaiting dispatch c←0 t←0

c ≥ M in(Exec Time) assert t ≤ Deadline

Enabled(t) resume

unblock

ready

running

δc = 0

c ≤ M ax(Exec Time) δc = 1

preempt

block on resource

call remote

return

subprogram

awaiting resource

awaiting return

δc = 0

δc = 0

performing thread computation Fig. 2. Semantic automaton for an AADL thread

ultimate destination, which can be thread or device components. Starting from an ultimate source, a semantic connection follows connections up the component containment hierarchy via the outgoing ports of enclosing components, includes one “sibling” connection between two components, and then follows connections down the hierarchy to the ultimate destination. One semantic connection in Figure 1 is between threads Decode and Display. This data connection contains three syntactic connections and is mapped to the bus component. A semantic event connection exists between threads Display and Compensate. Compensate, being an aperiodic thread, is dispatched by the arrival of each event via that connection. By contrast, periodic threads are dispatched by a timer. Similarly, semantic access connections describe resources required by a thread that is the ultimate source of an access connection. A resource that serves as the ultimate destination of an access connection is typically a data component. Properties of access connections specify concurrency control protocol for a shared resource. Modes. AADL can represent multi-modal systems, in which active components and connections between them can change during an execution. Mode changes occur in response to events, which can be raised by the environment of the system or internally by one of the system components. For example, a failure in one of the components can cause a switch to a recovery mode, in which the failed component is inactive and its connections are re-routed to other components. The AADL standard prescribes the rules for activation and deactivation of components during a mode switch. Currently, Furness toolset does not support multiple modes and we do not discuss this aspect of AADL any further.

3

Overview of ACSR

ACSR [9] is a real-time process algebra that makes the notion of resource explicit in system models. Restrictions on simultaneous access to shared resources are

226

O. Sokolsky, I. Lee, and D. Clarke

a)

∅

b) Simple1

{(cpu, 1)}

{(cpu, 1), (bus, 1)}

Simple2

{(cpu, 1)}

{(cpu, 1), (bus, 1)}

done!

done!

Fig. 3. ACSR process with computation and communication steps

T

∅

T imeoutHandler Simple

{(cpu, 1)}

{(cpu, 1), (bus, 1)}

interrupt?

Interrupt done

Handler

ExceptionHandler

∅ interrupt

done!

SimpleDriver

{(bus, 2)}

{(bus, 2)}

∅

{(bus, 2)}

{(bus, 2)}

interrupt!

∅

{(cpu, 2)}

{(cpu, 1), (bus, 1)} {(cpu, 1), (bus, 1)}

{(bus, 2)} {(cpu, 1), (bus, 1)}

{(bus, 2)}

τ @interrupt

interrupt

done! exception

Fig. 4. Parallel composition of ACSR processes

introduced into the operational semantics of ACSR, which allow us to perform analysis of scheduling properties of the system model. An ACSR model consists of a collection of processes that evolve during the execution of the model. The operational semantics of ACSR deﬁnes a transition a relation, in which transitions P1 −→ P2 describe how process P1 can evolve into P2 by performing a step a. Rather than giving a formal description of syntax and semantics, which can be found in several publications [9,10], we show a pictorial representation for processes. We also use an example that becomes more complex as features of the formalism are introduced. Computation and communication. ACSR processes can execute two kinds of steps: computation steps and communication steps. Computation steps, which we call here timed actions, or simply actions, take time and require access to a set of resources in order to proceed. Access to resources is controlled by priorities that are associated with each resource access. Formally, an action is a set of pairs (ri , pi ), where pi is the priority of access to the resource ri . For an action A, we denote the set of resources to be ρ(A). Communication steps, on the other hand, consist of sending or receiving an instantaneous event. To avoid confusion with event manipulation in AADL models, we will refer to events in ACSR processes as ACSR events. Communication also have priorities associated with them. Figure 3, a shows a simple process that performs a computation step using the processor resource cpu, then performs another computation step that

Process-Algebraic Interpretation of AADL Models

227

requires, in addition, access to a shared bus represented as the resource bus, and ﬁnally announces its completion by sending an event done before restarting. Resource contention and alternative behaviors. According to ACSR semantics, a timed action cannot be performed if the necessary resources are not available. The process that tries to execute the step will be deadlocked, unless alternative steps are available. To allow processes wait for resource access, ACSR models introduce idling steps, which do not consume resources but let the time progress, to allow a process to wait for resources, as shown in Figure 3, b. Temporal scope. A process can operate in a temporal scope, which we represent as a shaded background for the process, as shown in Figure 4. The scope can be exited in one of the three ways: an exception represents a voluntary release of control by the process, which is transferred to its exit point, represented pictorially as a white circle; an interrupt represents an involuntary release of control, when the control is transferred to a handler process and the activity within the scope is abandoned; the last means of exit is a timeout, which occurs a speciﬁed duration of time passes since the scope was entered. Parallel composition and preemption. ACSR processes can be combined in parallel and interact in two ways. Processes can instantaneously send and receive ACSR events. Event communication follows the CCS style of synchronization. The sender and the receiver of matching events take the event step synchronously, performing together an internal step labeled by a special ACSR event τ . For clarity, we also specify the name of the ACSR event that generated the internal step, writing the label as τ @name. Alternatively, a process can perform the step individually, unless the event is restricted. Event restriction, therefore forces synchronization of the processes within the scope of the restriction operator. The second means of interaction is implicitly represented by resource conﬂicts. Processes can perform actions, which take time to execute and require access to a set of resources. Because time progress is global, all processes have to perform action steps together. The following rule for parallel composition speciﬁes that two processes can perform action steps concurrently as long as resources used in each step are disjoint: 1 2 P1 −→ P1 , P2 −→ P2

A

(Par3)

A

A ∪A

1 2 P1 P2 −→ P1 P2

, ρ(A1 ) ∩ ρ(A2 ) = ∅

Access to resources is guarded by priorities, and a process with a higher priority of access can preempt the execution of another process. The preemption relation is deﬁned on actions and events. For two actions A1 and A2 , A2 preempts A1 , denoted A1 ≺ A2 , if every resource used in A1 is also used in A2 with greater or equal priority, and at least one resource has a strictly greater priority. As a result of this deﬁnition, any resource-using step will preempt an idling step (with an empty set of resources). In addition, an internal step with a non-zero priority will preempt any timed action to ensure progress in the behavior of an ACSR model. The prioritized transition relation for an ACSR process removes preempted transitions from the transition relation.

228

O. Sokolsky, I. Lee, and D. Clarke

Figure 4 places our running example into a temporal scope that composed in parallel with a driver process, which lets Simple complete one iteration. The ﬁrst action of the driver uses disjoint resources with the ﬁrst action of Simple and thus they can proceed together. However, the second action uses the same resource bus with a higher priority of access and preempts the execution of Simple for one time step. Then, the driver has two alternative behaviors that prevent the process Simple from completing the second iteration. One behavior forces an interrupt by synchronizing with the trigger of the interrupt handler. The other behavior preempts Simple at the initial state on the second iteration. The alternative idling step takes Simple to the exception handler. Parameterized processes. An ACSR process can be associated with parameters that are changed during an execution of the process. These dynamic parameters are used as variables that keep the history of the execution – for example, the progress of time. Syntactic rules limit the range of each parameter and thus ensure that the parameterized model remains ﬁnite-state. The use of parameters in an ACSR process is illustrated in the next section. Tool support. Modeling and analysis of real-time systems using the ACSR formalism is supported by the tool VERSA [5]. Originally designed as a rewrite engine for ACSR terms with respect to the strong prioritized bisimulation [9], VERSA is primarily used as a state-space exploration and reachability analysis tool. VERSA uses eﬃcient explicit-state representation of the state space, identifying each state with a normalized ACSR term, extended with a timeout value for each temporal scope operator. Because of explicit state representation, construction of the state space takes time at tool startup, however state transitions take constant time, making VERSA an eﬃcient simulator. 3.1

Schedulability Analysis with ACSR

We adopt the schedulability analysis approach described in [3]. In this approach, a real-time system that consists of a collection of tasks is modeled by a parallel composition of ACSR processes constructed in the following way. Each task is represented as an ACSR process that captures task states – such as inactive, ready, running, preempted, etc. – and reﬂects dependencies on other tasks in the system. In addition, a separate ACSR process models the task dispatcher. The dispatcher models the pattern of task dispatches, either by a clock or by incoming events. The scheduler of the real-time system is not represented explicitly. Instead, it is encoded in the priorities of actions that access the processor resource in task models. For ﬁxed-priority scheduling, the value of thread priority is used. To encode dynamic-priority schedulers, parametric expressions are used as priorities. We give a concrete example of such parametric expressions in Section 4.1. As shown in [3], the resulting ACSR model is deadlock-free if and only if the respective collection of tasks is schedulable by the speciﬁed scheduler. Thus, schedulability analysis is reduced to deadlock detection.

Process-Algebraic Interpretation of AADL Models

4

229

The Furness Toolset

The Furness toolset provides behavioral analysis of AADL models using VERSA as a state-space exploration engine. The overall architecture of the tool is shown in Figure 5. In the ﬁgure, tools from the underlying development framework are shown shaded, while modules that comprise the Furness toolset are white. Furness is a plugin for the OSATE development environment for AADL, which is in turn a plugin into the popular open-source Eclipse framework. The tool operates on AADL instance models, which are created by OSATE from declarative AADL models. When Furness is invoked, the translation module produces an ACSR model from the AADL instance model, which is given as input to the VERSA tool. VERSA processes the generated model and builds its state space. At this point, Furness is ready to perform analysis. An important requirement in the design of the tool was that the user needs to be unaware of the underlying VERSA implementation of the AADL semantics. By hiding VERSA, we achieve to desirable goals. On the one hand, we will be able to employ a diﬀerent implementation of AADL semantics and make the switch transparent to the end user. More importantly, the user will be spared the details of the ACSR formalism. The target user of the Furness toolset is an engineer, who is unlikely to be well versed in formal methods. Shielding the user from the formal details will help the adoption of the tool. To achieve this, we introduced the state interpretation module, an abstraction layer over the ACSR model that transforms ACSR execution traces into AADL-level traces. Both simulation and timing analysis involve state space exploration of the ACSR model. The state interpretation module maintains the correspondence between states of the ACSR model and states of the AADL model. When a transition in the ACSR model is taken, the state interpretation model identiﬁes whether the transition corresponds to an AADL-level event (such as tread dispatch or completion) and updates the AADL model state. Note that

Eclipse environment OSATE

Eclipse debug perspective

Schedulability analysis view

Simulator interface

Schedulability analysis

instantiation

translation State interpretation

VERSA Fig. 5. Furness toolset architecture

230

O. Sokolsky, I. Lee, and D. Clarke

multiple ACSR transitions may correspond to a single AADL-level step. In this case, chains of transitions are collapsed by the module into a single step. The presentation layer of the Furness toolset consists of the standard Eclipse debug perspective, which is used as the user interface for the simulator, and several custom views that present timing analysis result and show the unfolding simulation trace. The simulator interface module handles user requests and manages the simulation state such as breakpoint status. It converts user requests into state interpretation commands and passes the outcome of state interpretation to the user interface, maintaining a bi-directional communication with the state interpretation module. By contrast, timing analysis displays only the results produced by VERSA, resulting in a one-way interaction. Translation of AADL into ACSR and schedulability analysis have been described in [14]. We reproduce some of this description here for the sake of completeness, concentrating primarily on examples that illustrate the translation. 4.1

Translation of AADL into ACSR

Assumptions and restrictions. The translation applies to systems that are completely instantiated and bound. This means that: 1) The system contains at least one thread and at least one processor components. Each thread has to be bound to a processor; and 2) If the thread is non-periodic (that is, aperiodic, sporadic, or background), each in event port and in event data port must have an incoming connection. In addition, each thread is required to specify properties Dispatch Protocol, Compute Execution Time, and Compute Deadline. Each processor component that has any threads bound to it must have the property Scheduling Protocol speciﬁed. The current version of the standard AADL assumes that threads in the system are synchronized with respect to a discrete global clock. These assumptions match the timing model of ACSR. We also assume that the time of data and event delivery across connections in the AADL model is signiﬁcantly smaller than the scheduling quantum. This assumption allows us to model communication between threads as instantaneous. ACSR skeleton of a thread component. Each thread is translated into an ACSR process independently, based on 1) its timing parameters and other properties; 2) its associated connections; and 3) its shared resources. We refer to this process as the thread skeleton, because steps within this process can be extended depending on the event and access connections of the thread, scheduling protocol property, etc. The overall structure of the thread skeleton, excluding initialization and mode switching parts, is shown in Figure 6. It directly corresponds to the thread semantic automaton given in Figure 2. Reﬁnements of the skeleton are discussed below, when we consider event and data connections. The skeleton has two static parameters: minimum cmin and maximum cmax execution times. They are taken from the property Compute Execution Time of the thread component, which gives the range of the execution times. The process is indexed by two dynamic parameters, e and t. Parameter e represents the amount of

Process-Algebraic Interpretation of AADL Models

t := t + 1 e := e + 1

dispatch?

AwaitDispatch

Computing cmin ≤ e < cmax

done!

{(cpu, π)}

t := t + 1

{(cpu, π)}

∅

t := t + 1

231

∅

P reempted

e < cmax − 1 t := t + 1 e := e + 1

{(cpu, π)}

Fig. 6. ACSR process for thread computation

execution time that has been accumulated by the thread in the current dispatch. Parameter t represents the total amount of time elapsed since the dispatch. As the process executes, it performs computation steps that require resource cpu, representing the processor to which the thread is mapped. Each computation step increases both dynamic parameters of the process. When the thread is preempted by a high-priority thread, it cannot perform the computation step and takes the alternative that leads to the Preempted state. There, it performs idling steps, which increase parameter t, but not e. After the number of computation steps exceeds cmin , the process can exit its scope via the complete exit point and return to the AwaitDispatch state. Once the cmax has been reached, the process is forced to leave the scope an return to AwaitDispatch. Tread dispatcher. An AADL thread is dispatched according to its dispatch policy. This policy is captured by the dispatcher process that is generated for each thread in addition to the thread skeleton. The dispatcher sends the dispatch event to the thread skeleton that advances the skeleton from the AwaitDispatch state to Compute state. In addition to thread dispatch, the dispatcher process keeps track of thread deadlines and signals deadline violations by inducing a deadlock into the model execution. Figure 7 shows dispatcher processes for AADL dispatch policies. Figure 7,a shows a dispatcher for a periodic thread. In the initial state, Dispatcherp sends the dispatch event. Note that the dispatcher cannot idle in this state and has to send this event immediately, ensuring that dispatches happen precisely every p time units. Once the event is sent, the dispatcher idles while the thread process is executing. If execution is completed and the ACSR event done is received before the timeout d (the deadline of the thread), the dispatcher idles until the next period and repeats the dispatch cycle. Otherwise, the deadline timeout happens and the dispatcher process is blocked, inducing a deadlock in the ACSR model that denotes a timing violation. Aperiodic threads are dispatched by events taken from a queue. The dispatcher process Dispatchera , shown in Figure 7,b, receives the ACSR event e deq from the event queue process E q that corresponds to an incoming event a)

dispatch!

∅

∅

done?

Dispatcherp p

∅

b)

edeq ?

Fig. 7. Thread dispatchers

∅ d

Dispatchera

d

dispatch!

done?

232

O. Sokolsky, I. Lee, and D. Clarke

connection of the thread (see below). When this event is received, the dispatcher sends the dispatch event to the thread skeleton and waits for the ACSR event done, which should arrive before the deadline. Note that here the dispatcher can idle waiting for an event to arrive. The dispatcher process for a sporadic thread is a combination of the two dispatcher processes discussed above. A dispatch happens when an ACSR event from the queue process is received. However, the next dispatch cannot happen until the minimum separation interval p elapses. Event connections. Sending and receiving AADL events is represented in ACSR by communication steps. Each semantic event or data event connection e in the AADL model is represented by an auxiliary ACSR process E that handles queuing of events at the destination. We introduce two ACSR events: e q, sent by the source thread and received by E, and e deq, sent by E and received by the dispatcher for the destination thread. The process E implements a counter, which is suﬃcient for the representation of the queue, since we do not model the attributes of individual events. Therefore, we need to know only the number of events in the queue at any moment during the execution. The size of the queue and overﬂow handling logic are obtained from the properties of the port feature. An AADL thread that is the ultimate source of a semantic event or data event connection e can raise an event during its computation. We reﬁne the skeleton of this thread with a communication step with the output ACSR event eq , added as a self-loop to the Computing state of the skeleton process in Figure 6. Data connections. Data connections in AADL model sampled communication and thus do not require queues. However, AADL introduces the notion of an immediate connection that has the following semantics. Whenever the two threads that are the source and the target of an immediate data connection are dispatched logically simultaneously, the execution of the target thread is delayed until the source thread completes its execution and the data is made available to the source thread. In order to implement the prescribed semantics, ﬁrst reﬁne the dispatcher of the target thread to accept a special event blockd before activating the thread, and the skeleton of the source thread is reﬁned with an auxiliary event to announce its completion. Then, we introduce an auxiliary ACSR process that interacts with the dispatchers of the two threads to detect simultaneous dispatches and, if so, delays sending blockd until the source thread completes. Otherwise, blockd is oﬀered immediately. 4.2

Trace Abstraction

During the analysis, VERSA maintains the current state of the model. Interacting with VERSA, the state interpretation module observes execution traces of the ACSR model, but not the state directly. To help identify state changes through trace steps, we add to the ACSR model transitions that do not directly correspond to any activity on the AADL level. We call such transitions bookkeeping steps. For example, an ACSR timed step speciﬁes what resources were used in the step, but not which process was using the resource. We thus had to introduce a bookkeeping step that occurs immediately after the time step and whose

Process-Algebraic Interpretation of AADL Models

233

event identiﬁes the thread that used the resource. Internal synchronization between processes in the AADL model – for example, between the thread process and an auxiliary process that implements a data connection – also introduce internal bookkeeping steps. The state interpretation module has to abstract away bookkeeping steps. A single AADL-level step reported by the module corresponds to a sequence of bookkeeping steps followed by a relevant step. This means that, in the context of a simulator, a single step request from the user results in multiple calls to VERSA until the right step is found. When multiple alternative steps are possible from the current state, the module has to ﬁgure out, which selections need to be made. To do this, when the state of the model changes, the module preprocesses available alternatives, converting them into tuples of numbers that encode selections. Consider the following example. Let the current state of the model be represented by the ACSR term τ.dispatch t1 + τ.(raise e1 + receive e2 ). The term has three alternative AADL-level steps, ﬁrst represents dispatch of a thread, the second one model event handling. Before presenting the choices to the user, the module internally represents them as tuples (1, 1), (2, 1), and (2, 2), respectively. Then, if the user requests to raise event e1 , the module will request two steps from VERSA, selecting the second alternative for the ﬁrst one and the ﬁrst alternative for the second step. 4.3

Timing Analysis

Timing analysis in the Furness toolset combines two techniques: schedulability analysis and response time calculation. To present results to the user, we introduce two new Eclipse views. One for presenting a failing scenario when the AADL model is not schedulable; the other is for displaying thread response times. We use the deadlock detection capability of VERSA to perform schedulability analysis. If a deadlocked state is found, VERSA produces a counterexample in the form of an execution trace that leads to the deadlocked state. This trace is lifted to the AADL level and is presented to the user as a failing scenario using the schedulability analysis view. Representation of the failing scenario is similar to the simulation trace, which is discussed in the next section. We can, in fact, use the simulation engine to let the user replay the scenario - however, this feature is currently not implemented. Furness toolset also performs response analysis for a schedulable task set and presents results graphically to the user. For each execution path in the system, response time of every thread is calculated. Then, a histogram is constructed showing the number of execution paths that exhibit a given response time. The histograms are presented to the user through the time bounds view. An example is shown in Figure 8. Intuitively, a thread that has response times along the majority of its execution paths close to its deadline may not be robust enough and can be the target for improvement. This analysis implicitly assumes that all execution paths are equally likely. One can capture the likelihood of diﬀerent paths to come up with a more precise characterization of thread robustness. For example, PACSR [12], a probabilistic extension of ACSR, can be used for this

234

O. Sokolsky, I. Lee, and D. Clarke

Fig. 8. Response time analysis report

purpose. However, the necessary information, such as probability distributions of thread execution times and event arrivals, cannot be extracted from AADL without introducing new properties into the model. 4.4

AADL Simulation

The Furness simulator is based on the Eclipse debug perspective, familiar to anyone who has used Eclipse to develop code. The perspective provides standard controls to start, pause, resume, and stop simulation, as well as views to display variable values during simulation and manage breakpoints. We also created a custom view that shows the execution trace of the model up to the current state. The view is shown in Figure 9. At left, threads involved in the simulation are listed, grouped by the processor they are bound to. To concentrate on a particular subsystem, the user can hide threads of a selected processor. Each thread and each processor has a line in the trace, which shows its color-coded state at every time instance. A thread is shown as running, blocked waiting for input/preempted, or inactive. A processor is shown as idle or busy. The simulator oﬀers two modes, interactive and continuous. In the interactive mode, the user manually requests the execution of a step, which can be either a micro-step or a macro-step. A micro-step corresponds to a single change in the state of the AADL model, that is, a thread being dispatched or completed, an event being raised or delivered to a queue, etc. Multiple micro-steps can occur simultaneously and observing them individually can be tedious. A macro-step, then, is a sequence of micro-steps, followed by a time-consuming step.

Fig. 9. Execution trace view

Process-Algebraic Interpretation of AADL Models

235

When a micro-step is invoked, the user interface layer invokes the simulator interface module that, in turn, passes it to the state interpretation module. It interacts with VERSA and processes its output and returns the new available steps to the user. Macro-steps are performed by internally setting a breakpoint at the next time step and switches to the continuous mode. In the continuous mode, the simulator keeps executing steps until a deadlock in the model is reached or some pre-deﬁned condition, such as a breakpoint, occurs. Currently, the simulator oﬀers only time breakpoints, when an execution is stopped after a ﬁxed number of time steps. Other kinds of breakpoints, for example upon raising a speciﬁc event, can be easily added through the breakpoint interface of the Eclipse debug perspective. An important option for the continuous mode is the resolution of alternative steps. Alternatives can be resolved randomly, or the execution can be paused to let the user select the alternatives.

5

Discussion and Conclusions

We have presented a representation of AADL semantics using a real-time process algebra. This semantic representation is used as a common foundation for an AADL simulator and a schedulability analysis tool. It also can be used by any other tool that requires exploration of the state space of the AADL model. The semantic representation is based on the hybrid automaton describing states of thread components and utilizes a number of relevant properties of thread and processor components and semantic connections in the model. The semantic representation presented in this paper reﬂects the fragment of AADL supported by the Furness toolset. Many of the restrictions can be lifted in the future. Most notably, the assumption that communication is instantaneous is unrealistic when connections are mapped to buses. By treating buses as resources in the system and incorporating bus scheduling protocols into the translation, the semantic representation can be made more realistic. Other formalisms can be used to create a similar semantic representation for AADL. In [4], the authors describe a translation of AADL into BIP [2]. Petri nets are used to capture the semantics of AADL in the Ocarina toolset [8] and also in [11]. Linear hybrid automata in the TIMES tool [1] are used in [7] to provide simulation of AADL threads without execution time uncertainty. We believe that ACSR is a more suitable semantic representation, since is it incorporates the notion of a resource directly in the formalism. Resources in the generated model correspond to platform components, making the translation more direct.

References 1. Amnell, T., Fersman, E., Mokrushin, L., Pettersson, P., Yi, W.: TIMES - a tool for modelling and implementation of embedded systems. In: Katoen, J.-P., Stevens, P. (eds.) TACAS 2002. LNCS, vol. 2280, pp. 460–464. Springer, Heidelberg (2002) 2. Basu, A., Bozga, M., Sifakis, J.: Modeling heterogeneous real-time systems in BIP. In: 4th IEEE International Conference on Software Engineering and Formal Methods (SEFM 2006), pp. 3–12 (September 2006)

236

O. Sokolsky, I. Lee, and D. Clarke

3. Ben-Abdallah, H., Choi, J.-Y., Clarke, D., Kim, Y.S., Lee, I., Xie, H.-L.: A Process Algebraic Approach to the Schedulability Analysis of Real-Time Systems. RealTime Systems 15, 189–219 (1998) 4. Chkouri, M., Robert, A., Bozga, M., Sifakis, J.: Translating AADL into BIP – application to the verification of real time systems. In: Workshop on Model Based Architecting and Construction of Embedded Systems, pp. 39–54 (September 2008) 5. Clarke, D., Lee, I., Xie, H.-L.: VERSA: A Tool for the Specification and Analysis of Resource-Bound Real-Time Systems. Journal of Computer and Software Engineering 3(2), 185–215 (1995) 6. Feiler, P., Lewis, B., Vestal, S.: The SAE AADL standard: A basis for model-based architecture-driven embedded systems engineering. In: Workshop on Model-Driven Embedded Systems (May 2003) 7. Gui, S., Luo, L., Li, Y., Wang, L.: Formal schedulability analysis and simulation for AADL. In: 2nd International Conference on Embedded Software and Systems, pp. 429–435 (July 2008) 8. Hugues, J., Zalila, B., Pautet, L., Kordon, F.: From the Prototype to the Final Embedded System Using the Ocarina AADL Tool Suite. ACM Transactions in Embedded Computing Systems (TECS) 7(4) (July 2008) 9. Lee, I., Br´emond-Gr´egoire, P., Gerber, R.: A Process Algebraic Approach to the Specification and Analysis of Resource-Bound Real-Time Systems. Proceedings of the IEEE, 158–171 (January 1994) 10. Lee, I., Philippou, A., Sokolsky, O.: Resources in process algebra. Journal of Logic and Algebraic Programming 72, 98–122 (2007) 11. Monteverde, D., Olivero, A., Yovine, S., Braberman, V.: VTS based specification and verification of behavioral properties of AADL models. In: Workshop on Model Based Architecting and Construction of Embedded Systems (September 2008) 12. Philippou, A., Cleaveland, R., Lee, I., Smolka, S., Sokolsky, O.: Probabilistic resource failure in real-time process algebra. In: Sangiorgi, D., de Simone, R. (eds.) CONCUR 1998. LNCS, vol. 1466, pp. 389–404. Springer, Heidelberg (1998) 13. SAE International. Architecture Analysis and Design Language (AADL), AS 5506 (November 2004) 14. Sokolsky, O., Lee, I., Clarke, D.: Schedulability analysis of AADL models. In: Workshop on Parallel and Distributed Real-Time Systems (April 2006)

O CARINA : An Environment for AADL Models Analysis and Automatic Code Generation for High Integrity Applications Gilles Lasnier, Bechir Zalila, Laurent Pautet, and Jérome Hugues Institut TELECOM – TELECOM ParisTech – LTCI 46, rue Barrault, F-75634 Paris CEDEX 13, France {firstname.name}@telecom-paristech.fr

Abstract. Developing safety-critical distributed applications is a difficult challenge. A failure may cause important damages as loss of human life or mission’s failure. Such distributed applications must be designed and built with rigor. Reducing the tedious and error-prone development steps is required; we claim that automatic code generation is a natural solution. In order to ease the process of verification and certification, the user can use modeling languages to describe application critical aspects. In this paper we introduce the use of AADL as a modeling language for Distributed Real-time Embedded (DRE) systems. Then we present our tool-suite O CARINA which allows automatic code generation from AADL models. Finally, we present a comparison between O CARINA and traditional approaches.

1 Introduction Distributed Real-time Embedded (DRE) systems are used in a variety of safety-critical domains such as avionics systems, medical devices, control systems, etc. Traditionally, their development process is based on manual work for requirement analysis, software design, verification and certification. Defining an automatic development framework for DRE is a challenge, potential building blocks are AADL and the Ravenscar Profile. The Architecture Analysis and Design Language (AADL) [SAE04] is an architecture description language that defines system constructs such as threads, processes or processors to model real-time, safety-critical embedded systems. AADL provides a potential backbone to model DRE systems, to analyse their schedulability, safety and security properties and automatically produce the executable code. The Ravenscar Profile [WG05] defines a subset of Ada to guarantee schedulability and safety properties by restricting the features of the language. A similar approach can be applied to restrict the features of a modeling language. Such an approach is promising as long as automatic code generation can be performed. In this paper, we present our work on a development process for building DRE systems from architecture descriptions. The tool-suite O CARINA [TEL08] allows syntactic and semantic analysis from AADL models. An AADL subset helps us applying the Ravenscar Profile restrictions in order to perform real-time analysis through both O CARINA and C HEDDAR[SLNM04]. Then we combine both AADL, O CARINA and F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 237–250, 2009. c Springer-Verlag Berlin Heidelberg 2009

238

G. Lasnier et al.

P OLY ORB-HI [ZPH08], a light distribution middleware designed and targeted to highintegrity systems, to produce C and Ada code compliant with the Ravenscar Profile. The contents of this paper is structured as follows: Section 2 presents related works aimed at building DRE systems from their models. Section 3 points out the rationale for our approach. Section 4 gives an overview of the AADL. Section 5 introduces our proposed development process and describes the architecture of our tool-suite O CARINA. In Section 6, we present a case study we carried using and validating our approach. Section 7 concludes this presentation and gives some future works.

2 Related Work In this section, we present a couple of projects that aim at specifying, analyzing and producing DRE applications from their models. 2.1

C OSMIC

C OSMIC: Component Syntheses using Model Integrated Computing [LTGS03] is a tool suite to build DRE applications based on the OMG C CM [OMG06a] specification. It uses the MIC (Model Integrated Computing) [SK97] paradigm and conforms to the OMG D&C [OMG06b] specification. Applications in C OSMIC are modeled using a set of description languages: PICML to describe the components of the application, their interfaces and their QoS parameters, CADML to describe how components are deployed and configured and OCML to describe the middleware configuration options. C OSMIC allows the expression of constraints on the application components and supports the integration of analysis modules. The applications are built on top of the component middleware C IAO. In [SSK+ 07], the benefits of this middleware are presented. C IAO offers capabilities to separate the development of the application from its deployment and configuration. C OSMIC uses R ACE (Resource Allocation and Engine Control), a framework placed at the topmost layer of the middleware that controls and refines dynamically the use of resources by the application. The fact that C OSMIC is based on several different languages to specify an application means that each representation must be consolidated after any change on the application model. This increases the development time. The topmost-layer used to refine dynamically the properties of components is problematic for critical systems where all resources must be allocated statically. In addition, the use of UML and XML introduces a scalability issues when it comes to model applications with a large number of components [SBG08]. All these drawbacks restrict the use of C OSMIC for DRE systems where correctness by construction is required. 2.2

AUTOSAR

AUTOSAR (AUTomotive Open System ARchitecture) is the result of a partnership between several automotive constructors. It allows developing DRE applications for the automotive domain while optimizing their maintainability and development cost [SnG07]. It allows the standardization of the exchange format of specifications, the abstraction of the micro-controller to avoid redeveloping a system when only the platform changes and the standardization of the interfaces of different components.

O CARINA : An Environment for AADL Models Analysis

239

A component in AUTOSAR is an atomic unit that cannot be distributed. It contains operations and data that are required and provided by the component, the needs of the component (access to sensors, bus...) and the resources the component uses (memory, CPU...). The main components categories are: software components and sensors. Several instances of the same component may exist on the system. In [SVN07], the authors provide a set of limitations identified during their use of AU TOSAR. These problems are present in many modeling languages: (1) lack of separation between the functional part and the architecture, (2) lack of support for task definition and resources, (3) lack of support for analyzability and for retro-annotations through an iterative process of design. Moreover, to incorporate the user code, AUTOSAR generates skeletons that must be completed by the user. However, the possibility of automatic edition of the skeletons modified by the user is left to the implementations [aG06]. Therefore, after each update, the new skeletons must be filled or at least edited, (4) lack of preservation of semantics after code generation. It should be noted here that the code is generated in the C language on which most compilers do not provide semantic and consistency analysis. All this makes questionable the use of AUTOSAR in the context of increasingly complex HI systems. Indeed, the static analyzability of these systems is crucial and the absence, of capabilities such as the definition of properties of tasks (ie. period, priority, etc.) makes difficult this kind of analysis.

3 Motivations In Section 2, we presented several approaches for designing DRE systems with their limitations. In this section, we expose the rationale for a new approach. We claim that it is critical to take the architecture into account very soon in the design process. Knowing the hardware specifications the designer can deduce that some redundancy requirements cannot be achieved. Changing the architecture and in particular the deployment of some software pieces has a great impact on the system schedulability. We also want to follow guidelines that ensure system analysis. With this respect, system schedulabibility is a major issue for DRE system. Therefore, we want the user to follow a concurrency model that eases the applicability of real-time scheduling theory in particular the Rate Monotonic Analysis. Finally, we want to be able to perform a seamless integration of user components into the global framework. To do so, we claim that massive code generation is a reachable goal and preserves the user from manual and error-prone coding. It also helps him in following the design guidelines. For instance, we may prevent him from messing around with mutexes and therefore violating the concurrency model. Code generation also gives the opportunity to dramatically optimize code. In Section 3.1 we present AADL as description language to model DRE systems. Section 3.2 points out the motivations for the use of Ada and the Ravenscar Profile. Finally, Section 3.3 gives the motivations for the use of massive code generation.

240

G. Lasnier et al.

3.1 AADL for a Model-Based Design Model-based approaches have radically improved the system design. Reuse of existing components, refining and extension techniques, rapid system prototyping, separation of functional and non functional aspects, allow designers to explore efficiently design alternatives and early analyze system properties during the development cycle. Section 2 describes a couple of projects that aim at specifying, analyzing and producing DRE applications from their models. We have also seen that work needed several description languages, specific frameworks and middlewares which increased the development time and were not convenient for DRE applications. We propose the use of AADL as unique description language to model DRE applications. AADL was designed and targeted to DRE systems and has all features mentioned above concerning model-based development. In addition, it allows the designer to specify all aspects required by DRE systems and integrates both functional and non functional aspects of applications using an efficient property mechanism. AADL also allows us to configure and deploy the components in the context of the target DRE system. 3.2 Ravenscar Profile for Concurrency Model For our approach we chose to design our own tools suite O CARINA in Ada. Firstly, the Ada programming language owned historically a legacy about the theory of compilation (tree manipulation, etc.) and efficient compiler (as G NAT). Secondly, contrary to heavy Java frameworks, Ada is more maintainable. As a first step, we also chose to generate Ada code. It provides a rich set of tasking constructs and is well-suited to real-time system development. In addition, the Ravenscar Profile [WG05] defines a subset of Ada that provides schedulability and safety guarantees by restricting the features of the language. These restrictions make Ada even more amenable to the development of DRE systems. 3.3 Code Generation for an Optimized and Seamless Integration In our approach we focus on massive code generation because it allows us to reduce system development (time and cost) and break down the complexity of DRE system. Code generation provides facilities to integrate and deploy components automatically. It is also an efficient mechanism to analyze and verify consistency between initial models and the final code. In addition, it automatically enforces (coding) guidelines to preserve system analysis. The development of our own environment allowed us to have a fine control over the production framework and take advantages from it (see Section 5). For analysis concerns, the code generation avoids object-oriented constructs, indirections and dynamic allocations. We chose to design our own specific execution platform P OLY ORB-HI as these complex constructs. It may also be introduced by a COTS middleware (executing the generated code). In our approach, the code generation aims at producing the glue code for wrapping application components but also a large part of the execution platform ; the other part being independant from the application. These facilities also help us optimizing the system integration and the code generated.

O CARINA : An Environment for AADL Models Analysis

241

4 An Overview of AADL AADL [SAE08] is an architecture description language standardized by SAE (Society of Automotive Engineers) that was first developed in the field of avionics. AADL is used to model safety-critical and real-time embedded systems. It uses a componentcentric model and defines the system architecture as a set of interconnected components. Modeling components consists of describing their interfaces, their implementations and their properties. The standard defines the textual, graphical, and XMI representation of the language to facilitate model interchange between tools. Furthermore, AADL is an extensible language: external languages can be used to define annexes. Besides, the standard proposes annexes to specify the detailed behavior of applications, data representation and error modelling as well as code generation directives. 4.1 Components Components in AADL represent elements providing and requiring services according to their specification. AADL gives support only for the specification of the non-functional aspects of the component. Behavioral or functional aspects of components must be given separately. For example, users can specify the source code of software components in a programming language such as Ada by means of the use of properties. The specification of a component consists in the declaration of the component type and if necessary one or several component implementations. Component types define the interface of the component through the declaration of features. Component implementations define the internal aspect of a component, the subcomponents it contains and the connections between features and those subcomponents. AADL gives the possibility to specify properties for all components. AADL allows the modelling of software components (process, thread, thread group, data, subprogram and subprogram group) , execution platform components (processor, virtual processor, memory, bus, virtual bus and device) and an hybrid component (system). AADL entities allow us the description of the software and the hardware architecture of the system: 1. Software components – Data represents a data type (if it is in the declarative part) or a data instance (if it is a subcomponent of another component). Data components may contain other data, subprograms and subprogram-groups. – Subprogram is an abstraction of the procedure from imperative languages. – Thread represents the basic unit of execution and schedulability in AADL. Threads may contain data and subprogram subcomponents, as well as subprogram call sequences. – Process represents a virtual address space. Process components may contain threads, data and thread-groups. 2. Execution platform components – Processor represents a microprocessor together with a scheduler. – Virtual Processor represents logical resource as virtual machine or scheduler able to schedule and execute threads. – Memory represents a storage space (RAM/ROM or disk).

242

G. Lasnier et al.

– Bus represents a hardware communication channel that links execution platform components. – Virtual Bus represents communication protocol. – Device represents a hardware with a known interface that can interact with the environment and/or the system under consideration (e.g. sensors/actuators). 3. System component – System is a hybrid component with no semantics that is used to group hierarchically software and hardware components. In addition, AADL defines a generic component (the abstract component) which allow us the description of high-level abstract components of the architecture at early stages of the system modeling. thread Slow properti es D i s p a t c h _ P r o t o c o l => P e r i o d i c ; Peri od => 1 sec ; end Slow ;

process Sl ow er_Fast er end Sl ow er_Fast er ;

thread Fast extends Slow properti es −− The val ue o f D i s p a t c h _ P r o t o c o l −− i s i n h e r i t e d from t h r e a d Slow . Peri od => 100 ms ; end Fast ;

process implementation Sl ow er_Fast er . I m pl subcomponents S : thread Slow { Peri od => 2 sec ; } ; −− New val ue o f Peri od F : thread Fast { Peri od => 10 ms ; } ; −− New val ue o f Peri od end Sl ow er_Fast er . I m pl ;

process Slow_Fast end Slow_Fast ;

system Root end Root ;

process implementation Slow_Fast . I m pl subcomponents S : thread Slow ; F : thread Fast ; end Slow_Fast . I m pl ;

system implementation Root . I m pl subcomponents P1 : process Slow_Fast . I m pl ; P2 : process Sl ow er_Fast er . I m pl ; end Root . I m pl ;

Listing 1.1. AADL description

Listing 1.2. AADL description (2)

Listings 1.1 and 1.2 show the use of AADL to model a system. In this example, we describe two threads Slow, Fast and their properties. Root and Root.impl represent respectively the interface and the implementation of the system. This system is composed of two processes that have two threads. 4.2 Component Interfaces Component types in AADL may declare features to define communication points exposed by the component and give it the possibility to communicate with its environment or other components. We describe here the different features: Ports are data or control transfer-points. A data port is used to transfer only data. An event port is used to transfer only control; they send events corresponding to signals with no associated data type. Event data ports transfer control with accompanying data; they correspond to signals with an associated data type. Furthermore, ports may have Ada-like directional qualifiers for the flow (in, out or in out). Parameters can be declared as features of subprograms.

O CARINA : An Environment for AADL Models Analysis

243

Data accesses represent access to a data subcomponent by an external component. This feature is used to model shared/protected data among remote components. Data accesses may be provided or required. Subprograms accesses declared as features of data components represent access procedures (similar to methods of a class). When they are declared as features of threads they represent RPCs. 4.3 Properties AADL allows the system designer to attach properties to any component: type, implementation, subcomponent, connection or port [SAE08]. Properties are used to define functional aspects of the system, for instance Dispatch_Protocol and Period for threads; Data_Type for data; as well as Compute_Entrypoint for specifying subprograms attached to ports. AADL has predefined standard property sets which express real-time, communication protocol, program, memory, time, thread or deployment aspects [SAE08]. The AADL property mechanism also allows the description of new functionnal aspect or overriding properties applied to components. 4.4 Modes AADL provides modes that allow dynamic system reconfiguration. Modes represent the active states of the software and the execution platform components of a system. An initial mode may be specified for a component and mode transitions give the possibility to change the current mode. Mode transitions may be triggered by the reception of an event or data in ports of the component features.

5 The Tool Suite O CARINA O CARINA [TEL08] is a tool suite designed in Ada by the S3 team at TELECOM ParisTech. It aims at providing model manipulation, syntactic/semantic analysis, scheduling analysis (C HEDDAR), verification and code generation from AADL models. O CARINA is designed as a traditional compiler with two parts: a frontend and a backend. A central library has been developed to provide builder and finder routines that manipulate entities used in the compiler. Figure 1 represents the architecture of the tools suite O CARINA. 5.1 Frontends The frontend of O CARINA is conceived around a modular architecture and give the possibility to use different modeling language. Currently, we have developed four modules corresponding to the AADL language. Those modules have been developed in accordance with the AADL 1.0 [SAE04] and the AADLv2 [SAE08] standards. The lexical analyzer (lexer). Recognizes a sequence of lexical elements as reserved keywords, identifier, separator and operator, which are specified by the AADL 1.0 and the AADLv2 standards.

244

G. Lasnier et al.

Fig. 1. Architecture of the compiler O CARINA

Fig. 2. O CARINA frontends architecture

The syntactic analyzer (parser) uses the lexer and calls the corresponding functions relative to the analysis of the sequence of lexical elements in accordance with the AADL grammar. Warning and errors relatives to the AADL syntax are raised and pointed our to the user. The result of this analysis leads to the construction of an Abstract Syntax Tree (AST) which is a representation of the AADL model. The semantic analyzer scans the AST and checks the semantics of the AADL model. First, it proceeds to a resolution phase which adds different information to the AST and make easier it use (example, the resolution of property constant with the correct value).

O CARINA : An Environment for AADL Models Analysis

245

Fig. 3. Example of an AADL instance tree

Secondly, the standard AADL defines a set of semantic rules which allow to check the semantic of the AADL model. The result of this analyze leads to an AST that conforms to the AADL semantics. Figure 2 represents the architecture of the frontends and shows when syntactic, semantic and instance warnings and errors are detected and pointed out to the user. The AADL standard [SAE08] specifies a set of rules which describe how to instantiate an AADL model. In AADL, an instance model defines an arborescent hierarchic representation of the system, its components and its subcomponents. The instantiation step computes the definitive values of properties referring to an instance component and detect some incoherence of the system (for example, a process must contain at least one thread). The result of this step leads to the construction of AADL instance tree corresponding to ’legal’ AADL models that are used later for code generation purposes. Figure 3 represents the AADL instance tree relative to the AADL model described in the listing 1.1. 5.2 Backends O CARINA has a modular architecture that allows users the use of several backends for different target languages. Three backends have been developed to support Ada, C and AADL code generation. We describe here the different steps needed for code generation. The first stage of the backend, called expansion, simplifies complex structures of the instance model and decorates the AST with information associated with our code generation mapping rules. For example, one of our mapping-rules adds an event port in hybrid thread for facilitate their communication protocol implementation. The result of this step leads to an expanded AADL instance tree which allows us further analysis and make code generation easier.

246

G. Lasnier et al.

The second step transforms an expanded AADL instance tree in the syntax tree of a target language called intermediate tree. Then, we scan this syntax tree in order to produce the code. This architecture is different than traditional compilers which produce code directly from the model. It allows us to make the maintainability of the compiler easier and give us more flexibility for code generation. Finally, for code generation purposes we use both the intermediate tree and the P O LY ORB-HI middleware. P OLY ORB-HI is a minimal middleware targetted to DRE systems (designed by TELECOM ParisTech). It provides only those services required by the DRE system. It is consituted of two parts: the first part corresponds to services lowly customizable and used for each applications; the second part corresponds to services highly customizable automatically generated by the backend. P OLY ORB-HI supports construction for AADL entities describe in the AADL model and produce code for those entities.

6 Case Study: Ravenscar Example Several case studies have been carried out to prove the correctness of our tool suite and validate our development process. Some of have been presented in previous publications [ZPH08, HZPK08] or elaborated in the context of the A SSERT European project. This section presents a new case study based on the classical example provided by the Ravenscar Profile guide [BDV04]. It illustrates the expression capacities of the profiles as well as some aspects covered by our production process. 6.1 Presentation The Ravenscar Profile guide example illustrates a workload management system. The system has four processes: a light sporadic process External Event Server receives external interrupts and records them in a specific buffer; a light periodic process Regular Producer performs the regular workload (under specific conditions, the process delegates the additional workload and the treatment of external interrupts to other light processes); a light sporadic process On Call Producer performs the additional workload; a light sporadic process Activation Log Reader is the interrupt handler. Three shared and protected data were defined: a Request Buffer filled by Regular Producer and used by On Call Producer; an Event Queue for external interrupts used by External Event Server; an Activation Log Reader for interrupts treatment, filled by External Event Server and used by Activation Log Reader. Finally, the systems contains one passive entity, Production Workload which performs the Small Whetstone operation which treats the workload asked by a light process. Figure 4 illustrates the workload management system in an AADL graphical representation. 6.2 Adaptation for AADL and Distributed Application The Ravenscar Profile guide example describes a local application. In our context, we model it using the AADL language and we also adapt it for DRE system.

O CARINA : An Environment for AADL Models Analysis

247

Fig. 4. AADL Adaptation of Ravenscar Profile guide example

Active components of the system are modelled by thread components in AADL. The Ravenscar Profile example gives us all the information needed for specifying the properties of the different threads (ie. priority, period, etc). O CARINA’s compiler and the P OLY ORB-HI middleware support the two kinds of thread components specified in the example. The behavior of threads is modelled by the properties Compute_Entrypoint associated directly with the thread or with the event port of the thread component type. We could gain advantages of the use of AADL concerning shared and protected data model. Indeed, in AADL it was not necessary to specify explicitly the components Request Buffer, Event Queue and Activation Log. We could use the features of thread component type for it. Figure 4 gives an AADL graphical representation of the Ravenscar Profile guide example adapted for DRE systems. This example has been adapted for distributed application. To simulate external interrupts we added process Interruption_Simulator which generates and sends random messages to the Workload_Manager process. The two processes ran on a L EON 2 processor and communicate through a S PACE W IRE bus. 6.3 Results and Metrics To analyze the AADL model, we used the tools suite O CARINA and the C HEDDAR tool1 . The analysis with O CARINA guaranteed the coherence of the model and the compliance to the restrictions of Ravenscar Profile. C HEDDAR uses the O CARINA libraries to process the model, then performs a response time analysis. Both analyses have been carried out successfully. After that, we proceeded to the automatic code generation and the deployment and configuration of the application with O CARINA and P OLY ORB-HI. We ran with 1

O CARINA invokes C HEDDAR.

248

G. Lasnier et al. Table 1. Binary footprint (in Kbytes) for L EON 2 Workload_Manager User code 4 Generated code 482 Minimal middleware 245 Compiler runtime 475 Total object files 1215 Executable footprint 2217

Interruption_Simulator 1 123 143 467 734 1745

success the code generated using the T SIM [Aer08] a L EON 2 simulator processor. To simulate the distributed application, we used an I/O module developed by S CI S YS 2. This module simulates the S PACE W IRE bus communication that connects the application nodes. The table 1 gives the memory footprint for the nodes of the application. A large part of this footprint is due to the threads stack sizes. The compiler we use, G NAT for L EON is a development version that requires 100 KB as a minimal task stack size. The ORK [dlPRZ00] kernel and the S PACE W IRE driver contribute also in increasing the footprint of the executables. Table 2. Memory footprint (in Kbytes) GNU/LINUX

Table 3. Line number and binary footprint (in Kbytes) for the Workload_Manager

Workload Manager P OLY ORB 2026 P OLY ORB-HI 579

AADL example SLOCs 3352 Executable footprint 1535

Interruption Simulator 1994 527

Ravenscar example 488 1441

We wanted to compare the results obtained using P OLY ORB-HI with those we got using P OLY ORB [Qui03]. We recompiled our case study to a native platform. We then used an existing backend in O CARINA to produce Ada code for P OLY ORB. The table 2 gives the executable footprints. We see that using P OLY ORB-HI reduces considerably the memory footprint of the executables compared to P OLY ORB (26%28%). This can be explained by the dynamic nature of P OLY ORB deployment and configuration. We finally compared our case study with the original Ravenscar example (all the code is provided in the Ravenscar profile guide). To do this, we removed the Interruption_Simulator to get a local application. Table 3 gives the number of lines and the executable footprint for the Workload_Manager. We see that the Ravenscar example is 6% smaller than the example built automatically using O CARINA and P OLY ORB-HI. This difference of size is acceptable since almost all the code of the application is produced automatically thanks to our production process, and the model is also analysable; whereas the Ravenscar example was fully handwritten. 2

S CI S YS is one of the industrial partners of the A SSERT project. http://www.scisys.co.uk

O CARINA : An Environment for AADL Models Analysis

249

7 Conclusion and Future Work In this paper we introduced O CARINA3 , a tool developped in Ada that gives support to a new approach for building DRE systems from AADL descriptions. We proposed the use of the Architecture Analysis and Design Language (AADL) to model and validate efficiently DRE systems. AADL also allows to include functional and non-functional aspects of DRE systems in the description architecture. Thanks to automatic code generation, the application components are easily integrated with the execution platform. We also designed P OLY ORB-HI, a highly-configurable middleware for the HighIntegrity domain. Some middleware components are automatically generated by O CA RINA from the system AADL models when the other components are selected from a minimal P OLY ORB-HI library. This approach allows us to produce deterministic executable with a very small footprint. We showed how O CARINA has been designed for allowing external tool integration. Besides, some tools had been integrated to our tools suite as C HEDDAR to validate specific properties concerning real-time systems. We defined an AADL subset to ensure that systems are Ravenscar compliant by construction in order to analyse their schedulability. A case study has been presented to illustrate the approach and validate our tool-suite O CARINA. This concrete example showed that our approach can be used to generate code for DRE systems compliant with the Ravenscar Profile. Finally, we assessed our work on a complete example to evaluate each step of our approach. Future directions for our work include updating the AADLv2 support in O CARINA. We also intend to extend O CARINA and P OLY ORB-HI to address security and safety issues in DRE partitioned systems. These systems aim at being compliant with A RINC 653 and M ILS standards.

References [Aer08] [aG06] [BDV04] [dlPRZ00]

[HZPK08] [LTGS03]

3

Aeroflex Gaisler AB. TSIM ERC32/LEON Simulator (2008), http://www.gaisler.com AUTOSAR Gbr. Technical Overview. Technical report (2006) Burns, A., Dobbing, B., Vardanega, T.: Guide for the use of the Ada Ravenscar Profile in High Integrity Systems. Ada Lett. XXIV(2), 1–74 (2004) de la Puente, J.A., Ruiz, J.F., Zamorano, J.: An Open Ravenscar Real-Time Kernel for GNAT. In: Keller, H.B., Plödereder, E. (eds.) Ada-Europe 2000. LNCS, vol. 1845, pp. 5–15. Springer, Heidelberg (2000) Hugues, J., Zalila, B., Pautet, L., Kordon, F.: From the Prototype to the Final Embedded System Using the Ocarina AADL Tool Suite. ACM TECS 7(4), 1–25 (2008) Lu, T., Turkay, E., Gokhale, A., Schmidt, D.C.: CoSMIC: An MDA Tool suite for Application Deployment and Configuration,. In: Proceedings of the OOPSLA 2003 Workshop on Generative Techniques in the Context of Model Driven Architecture, Anaheim, CA (October 2003)

Available at http://ocarina.enst.fr

250

G. Lasnier et al.

[OMG06a]

OMG. CORBA Component Model Specification Version 4.0. OMG, OMG Technical Document formal/06-04-01 (April 2006) [OMG06b] OMG. Deployment and Configuration of Component-based Distributed Applications Specification, Version 4.0. OMG. OMG Technical Document formal/06-0402 (April 2006) [Qui03] Quinot, T.: Conception et Réalisation d’un intergiciel schizophrène pour la mise en oeuvre de systèmes répartis interopérables. PhD thesis, École Nationale Supérieure des Télécommunications (March 2003) [SAE04] SAE: Architecture Analysis & Design Language (AS5506) (September 2004) [SAE08] SAE: Architecture Analysis & Design Language v2.0 (AS5506) (September 2008) [SBG08] Sriplakich, P., Blanc, X., Gervals, M.P.: Collaborative Software Engineering on large-scale models: requirements and experience in ModelBus. In: Proceedings of the 2008 ACM symposium on Applied computing, pp. 674–681. ACM, New York (2008) [SK97] Sztipanovits, J., Karsai, G.: Model-Integrated Computing. Computer 30(4), 110– 111 (1997) [SLNM04] Singhoff, F., Legrand, J., Nana, L., Marc, L.: Cheddar: a flexible real time scheduling framework. In: ACM SIGAda Ada Letters, ACM Press, New York (2004) [SnG07] Schreiner, D., Goschka, K.M.: A Component Model for the AUTOSAR Virtual Function Bus. In: COMPSAC 2007: Proceedings of the 31st Annual International Computer Software and Applications Conference (COMPSAC 2007), Washington, DC, USA, 2007, vol. 2, pp. 635–641. IEEE Computer Society Press, Los Alamitos (2007) [SSK+ 07] Shankaran, N., Schmidt, C., Koutsoukos, X.D., Chen, Y., Lu, C.: Design and performance evaluation of configurable component middleware for end-to-end adaptation of distributed real-time embedded systems. In: ISORC 2007: Proceedings of the 10th IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing, pp. 291–298. IEEE Computer Society Press, Los Alamitos (2007) [SVN07] Sangiovanni-Vincentelli, A., Di Natale, M.: Embedded System Design for Automotive Applications. Computer 40(10), 42–51 (2007) [TEL08] TELECOM ParisTech. Ocarina: An AADL model processing suite (2008), http://aadl.enst.fr [WG05] Ada Working Group. Ada Reference Manual. ISO/IEC (2005), http://www.adaic.com/standards/05rm/RM-Final.pdf [ZPH08] Zalila, B., Pautet, L., Hugues, J.: Towards Automatic Middleware Generation. In: 11th IEEE International Symposium on Object-oriented Real-time distributed Computing (ISORC 2008), Orlando, Florida, USA, May 2008, pp. 221–228 (2008)

Conceptual Modeling for System Requirements Enhancement Eric Le Pors1,2,3 and Olivier Grisvard1,2,3 1

Institut T´el´ecom; T´el´ecom Bretagne UMR CNRS 3192 Lab-STICC Technopˆ ole Brest-Iroise - CS 83818 29238 Brest Cedex 3 - FRANCE {eric.lepors|olivier.grisvard}@telecom-bretagne.eu 2 THALES Airbone Systems Radar and Warfare Systems 3 Universit´e europ´eenne de Bretagne, France

Abstract. Systems designers have to cope with the ever growing complexity of nowadays systems. This issue becomes dramatic in the aeronautics domain, due to the huge number of functions the systems have to support, the signiﬁcant number of sub-system elements required to implement these functions and their inter-connections. Although requirements engineering is a good answer to the issue of system speciﬁcation, as it enables the deﬁnition of a contract specifying the constraints the system architecture has to take into account, it does not scale very well when the size and the complexity of the systems increase signiﬁcantly. Model Driven Engineering (MDE) approaches are currently used by software engineers to enhance software quality and increase capitalization in product line delivery for complex systems, but are not yet widely used at the system architecture level. As such, there is still a big gap between the system engineering world and the software engineering world, that is particularly obvious in requirement processing, leading to misreadings and misinterpretations of the system requirements by software engineers, with important consequences at the software architecture level. In this paper, we propose an MDE approach to address this issue at the system architecture level, contributing to bridge the gap between system and software architectures. In particular, we will describe an approach to deal with the expression of requirements in a MDE context, which relies on the notion of system conceptual modeling. Keywords: System engineering, conceptual modeling, requirements, complex systems.

1

Introduction

In the initial stages of the building process of large and complex systems, software architects have to identify system requirements and this is achieved through iterative discussions with the client. These requirements are considered as a F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 251–265, 2009. c Springer-Verlag Berlin Heidelberg 2009

252

E. Le Pors and O. Grisvard

contract and constitute an input for the system engineer. Therefore, requirements deﬁnition and identiﬁcation require care and precision. We also need to ensure that the terms and vocabulary used are understood without ambiguity by the various parties. System requirements are composed of various information, functionalities, models and constraints which are to be understood and taken into account. This form of complexity and diversity makes it diﬃcult for a single user to manage the entire system. Based on our former experience, we know that system requirements identiﬁcation is critical and that they will be used throughout the software development and the duration of the project (including its maintenance). Described in [19] by the IEEE Software Engineering Committee, a system requirement does not describe precisely the system functionalities, behavior and constraints. And since poor requirements can be potentially catastrophic for a system design, the IEEE committee indicates ’good’ properties that requirements must meet: system requirements have to be abstract (a system requirement has to be implementation independent), unambiguous (only one interpretation should be possible), and can be traced and validated. Our aim in this research is to assist both the client and the software architects when identifying and expressing requirements. The approach we have selected is to design a set of tools which can represent the requirements in a graphical way that can support and enhance cooperation between the stakeholders. The approach is incremental since it aims at building concepts and relationships from the information that is extracted when analyzing the requirements one at a time. Once a complete model is established, our purpose is to check properties on the model and to bring an added value to the approaches that are commonly used for requirement management. Moreover, with such an approach we intend to capitalize knowledge throughout projects; we believe in particular that the availability of models and data from previous projects will make it easier to initiate the requirement identiﬁcation and will increase their quality. The paper is organized as follows. In the ﬁrst section we present our view on system requirements and their importance and give an overview on the current approaches that are being used. In the second section, we investigate how information can be extracted from the requirements and how it can be modeled and presented. In the third section, we present the tools and the approaches we have selected for their design. In the fourth section, we indicate how the tools can be used. Finally, the concluding remarks are given with perspectives on our future work.

2

Modeling Knowledge

Modeling and metamodeling techniques are currently used in software or system engineering in order to enhance the quality of products or to support communication between members of the design team. Software based systems are more and more complex: customers always need systems with more functionalities to support their professional tasks, the number of artifacts (software and hardware)

Conceptual Modeling for System Requirements Enhancement

253

grow rapidly and each of them can provide complex functions, diﬀerent concerns like performance, fault tolerance, availability, etc. can also be addressed). We call them “complex systems” because they are the results of a team of experts and cannot be managed any longer by only one individual. As stated by Bezivin et al. [2] models are used to make abstractions of a studied system, to highlight particular viewpoints and to give a synthetic view, thus enhancing communication and reasoning. In our approach, we decided to use modeling techniques to enhance communications between designers of the system, customers and end-users, and to better meet user needs. Our goal is multiple and we aim to: – Enhance communication between stakeholders, and facilitate exchanges between members of the design / development teams and the customer. – Provide a common communication medium (the model) that will be used to convey information between the members of the teams. – Make available analyses on produced models (so that early checks can detect ﬂaws and errors as early as possible). – Design and develop tools that help system engineers to use and access a model. – Design a model easy to handle and easily computable to recover semantics and relationships between concepts. Based on our former experience in designing and developing complex systems, we believe that modeling techniques are one of the key elements to manage the growing complexity of the future systems. This complexity often arises from the growing number of requirements derived from the customer needs. Requirements engineers have to collect formalized sentences elicited from users and customers needs. These requirements must express all functional and non-functional properties which characterize the system to be developed. Christel and Kang [4] exposed three main categories (over ten elicitation problems) of diﬃculties in requirement elicitation and proposed a methodology to overcome these issues: they propose a new requirement elicitation process model which can enhance the production of pertinent requirements. They also expressed that domain model and architecture model are useful for this phase and their availability “provide ’map’ for organizing information in a requirements document, and for presenting this information”. This information has to be presented to members of the system designing teams, to software developers and to hardware engineers. Presenting this information to the customer or the ﬁnal user of the system, may reduce misunderstanding about what is going to be designed. Hammond et al. [12] expressed that “Requirements Engineering begins with a description of the whole application domain” and that the failure to understand the domain can be catastrophic. These models can be used to verify that sentences describing what the system does are correct or not. Requirements are parts of these sentences. For this purpose, and as a starting point to improve requirement management, we chose to deﬁne domain entities with all their expected functionalities. This deﬁnition stage is intended to extend architects’ vision of the artifacts they design. The graphic representation of the requirements is there to go beyond their textual and ﬂat description.

254

E. Le Pors and O. Grisvard

Fig. 1. Conceptual Hierarchy

A component is a well known entity in software engineering, described by Kermarrec [13] as entities which enable highest software production capacity, lower maintenance eﬀort and ensuring reuse of the entities over numerous projects. We chose a hierarchical component based approach to represent domain knowledge (components with their functions and properties) in order to take into account design practices: Architects currently used modeling tools or languages like AADL [5,6] which propose components modeling approaches. Our approach aim is multiple. We propose to building of a consensual structural model of the concepts used by requirement engineer. Another aspect of the approach is the veriﬁcation of missing information and errors in concepts used in requirements. Finally, we invite to go beyond a single project and capitalize concepts for product line deliveries. 2.1

Building a Model

Models enable engineers and architects to communicate during the project lifespan. UML models, AADL schema or ﬁnite state automata for example, are solutions widely used to share knowledge about system elements or components. In our opinion, it is essential to use graphical models to interact and communicate a shared and consensual vision of the system, the domain and the business. Following these ideas, we propose to build a structural conceptual model inspired from Grisvard [10]. The ﬁgure 1 represents the conceptual hierarchy used to analyze natural language associated with classes of our metamodel (which are described in the next section). This metamodel allows to describe: – System element deﬁnitions and uses: What is a Virtual Private Network (VPN), a RADAR... how can these concepts be generalized? (one is a NetworkService, the other a Sensor)

Conceptual Modeling for System Requirements Enhancement

255

– Identiﬁcation of these systems elements: What are the parts of these concepts? (Direct subparts of a RADAR can be: Emitter, Antenna...) We propose to deﬁne each system artifacts using this approach and to associate a short description to them. The aim of these descriptions is to enhance knowledge sharing for new members in design teams. This deﬁnition process, associated to the requirement engineering process, is iterative. We propose to associate the requirement writing phase to a conceptual modeling update phase (when needed): Each time a concept is created or enhanced, the system engineers build or extend the associated conceptual model. Each word in a requirement speciﬁcation has to be deﬁned in the conceptual model: the greater the domain knowledge, the better the requirements precision and quality. 2.2

Semantic Verifications

One of our goals was to be able to verify properties on the model elements and to detect as early as possible ﬂaws and errors in: – Functional properties of these systems: a Functional property is what the system does or what the system requires to work. e.g.; What a RADAR is able to do (Scan zones, Scan targets ...)? Is a controller operator able to switch oﬀ a sensor? Is a tactical operator able to disconnect a network cable (we can imagine that some tactical operators are able to do it, but this is not a prerequisite for the concept of “Tactical operator”). We propose to verify that all described concepts in a requirement are compatible in terms of function. – Execution chains: Chains represent a sequence of function call on multiple sub-concepts (e.g.; When switching oﬀ a computer, the operating system closes, the hard disk stops... When the operator designates a target, ﬁrst of all, he/she points a tactical object, he/she clicks on the Designation button...) – Component attributes: these features are identiﬁed as important/pertinent descriptions of the system concept. (e.g.; The RADAR range, the RADAR frequency...). The conceptual modeler can restrict the possible values by associating a type (like a distance or a duration type) Our approach aims at providing a formalism to verify these properties at the earliest steps of the system design, so our metamodel has to provide a way to check if what is written on the system (e.g.; a requirement) is compatible with the conceptual models that have been developed in previous project or with the one that is currently built. For these reasons we propose a component based support for conceptual modeling: we make it possible to represent system artifacts linked ones to the others and to attach to each of them their description, properties, functions and their composition. Over projects, the number of items and artifacts in the “building blocks” database will increase, thus capitalization on previous systems designs and descriptions will be possible for system architects. They will be able to reuse,

256

E. Le Pors and O. Grisvard

modify, extend or reﬁne existing blocks in order to fulﬁll the new expected functionalities. Therefore, we envision a new role in the design team: the Concept Architect whose role is to ensure consistency of conceptual models, and to control their contents (e.g.; addition, modiﬁcation, or extension of an existing concept). We also propose to use the requirement traceability link currently used in requirement engineering phases: as deﬁned in [8] “The requirements traceability is the ability to describe and follow the life of a requirement, in both a forward and backward direction, i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases.” The traceability link between requirements and the model elements of the system architecture enables us to transfer to the architecture level a list of constraints from system requirements.

3

Our Metamodel

The OMG MDA approach is to build multiple metamodels (one for each perspectives or viewpoint) using a metamodeling language like MOF [14]. Each of these metamodels makes it possible to build models in the selected system perspectives. In our approach, we propose to focus on one of the perspective which is the conceptual modeling of system entities/components that we described earlier in the document. Our approach is strongly inspired by the Software Factories [9] and by Model Driven Engineering (MDE) [1,17]. These approaches propose to automate processes and tasks which are traditionally done by expert engineers. Following this idea, we proposed an MDE approach which aims at assisting the engineer during the requirement analysis phase. This task is currently performed without computer support, and requires costly iterations between writing and reviewing stages of the requirement engineering process. In the previous section, we explained our choice for a component based metamodel. We designed this metamodel taking into account previous works on conceptual modeling techniques: the hierarchical view of concepts and the links between concepts are inspired from Ontologies [11] and Frame languages [7] but also from component based architecture design languages (AADL, SysML [16], CCM [22], etc.). Our metamodel has to represent and manage concepts which are described in system requirements. Sommerville [20] wrote that natural language, traditionally used in system requirements is often leading to misunderstandings and confusions, he also wrote that “a structured language is a good alternative to natural language”. A structured language parser can be used to analyze and extract valuable information from the sentence itself: e.g.; reference to a conditional context, an interval, a limitation. An analyzer can also extract lexical terms, names and verbs that are used: e.g.; a FLIR (Forward Looking InfraRed), a RADAR, a Buoy, activate. A simple analysis can then establish links between these terms and therefore we can determine that “an operator can activate a radar” or that “a track position is displayed on the screen every second”, for example. Once the concept manager has introduced and validated a new entry in the conceptual model, this entity can then be used during the checking phase

Conceptual Modeling for System Requirements Enhancement

257

and we can determine that a sentence like “the operator can display a cartoon” is not relevant because “cartoon” is not in the conceptual model. When validated, a conceptual model establishes a consensus that is available for a community of users in a speciﬁc business context. We can consider it is an organized and structured knowledge and each of its elements can be reﬁned in sub-entities. Our approach represents system artifacts (e.g.; components, functions, services) and we call this metamodel SCCM (System Conceptual Component Model). The latter proposes to build concepts as: – A Hierarchical representation of business system components: this enables the classiﬁcation of system elements related to a set of abstract generic concepts (sensor, computer, interface, bus, ...). It also enables to capitalize on previously deﬁned concepts in a product line development. – A Hierarchical representation of component interactions: it represents the required and provided functions proposed by a system component. Each component refers to groups of hierarchised functions (e.g.; UpdateDatabase function inherits from ManageDatabase). The hierachical deﬁnition helps to generalize functional concepts and enables to manage and access families of functions. As an example, you can deﬁne a constraint on all “database management functions” of a component. – A Hierarchical representation of component states: this category regroups a hierarchy of states used in components (SystemState, PowerState, FailureState). A component can have multiple states in its deﬁnition. The hierarchy is used to represent common states in components (e.g.; AquisitionState inherits from OperationalState) – A Hierarchical representation of “actors”: it is a speciﬁc family of components with no provided functions representing a limited deﬁnition of a system environment. This category of concepts interacts with the system using its provided functions. An actor is a source for events (Operator, external stimulator...) We also propose to build the deﬁnition of components using properties, states, sub-components, “interfaces”: A property represents valued concept deﬁning property of the object itself. A state characterizes a component at execution time. A sub-component is (at a conceptual level) a category deﬁning the concept associated to a cardinality. An interfaces is a named list of provided functions of the conceptual component. (e.g.; FLIRControlInterface: the control functions of the FLIR). A subclass of a component is able to redeﬁne the deﬁnition of these elements. The metamodel is associated to a query tool and to a set of functions used to manage insertions, modiﬁcations and deletions in the model. The prototype is built in Smalltalk: this language oﬀers a good ﬂexibility for prototyping phases and enabled us to modify rapidly the metamodel structure. We can see that the models (which are compliant with our SCCM metamodel) contain valuable information that can be used and accessed by the various members of the team. For this, we have designed and implemented a set of tools which make it possible to browse, inspect and manipulate the models.

258

E. Le Pors and O. Grisvard

Fig. 2. Conceptual Component Graphical Representation

In ﬁgure 2 we give a reduced view of a conceptual model that is intended for maritime patrol systems architectures. The component is a simple and explicit entity which allows composition of concepts, assembly (and connexions) of artifacts.

4 4.1

Our Instrumented Approach Requirement Analysis

We have built a set of tools which support our SCCM modeling approach in order to highlight and demonstrate the beneﬁts of our approach for maritime patrol systems, which are developed at THALES. Our tool parses requirements with a simpliﬁed grammar with the help of Smalltalk SmaCC [3]. The semantic analysis identiﬁes referenced elements of the conceptual model, their attributes and their functions. For example: Req 1. “In long range mode, the X RADAR shall have a detection range of 1 to 200 Nautical Miles” The Requirement analyzer and parser convert requirements to model elements through syntactical and semantical analysis. In this example, “X RADAR” is a component of our system, and the semantic analyzer veriﬁes if a “detection range” is a known entity (i.e.; “detection range” is an attribute of this radar). In the conceptual model, the “long range” reference should be deﬁned as a possible State of the “X Radar”. Our tool uses the SCCM conceptual browser to retrieve the corresponding component and to verify if the radar supports a detection range property. If this is the case, the interval of 1 to 200 nautical miles can be compared to the interval deﬁned for the X Radar in order to check the fulﬁllment of this constraint. In the industry, system designer uses speciﬁc tools like DOORS [21] to manage requirements. These requirements are grouped by category and level (e.g.; the system speciﬁcation level). Requirements are “traced” with sub-level requirements or with architectural elements. This traceability link from a requirement to an architecture element makes it possible to retrieve the constraint. On the example, the constraint is made on X Radar detection range element of the model. The system design tool can detect incoherent constraints (e.g.; detection of another constraint on the same property which has been set already).

Conceptual Modeling for System Requirements Enhancement

4.2

259

SCCM Modeling Tool

The SCCM metamodel has been built in conjunction with numerous related tools, still in development. These prototypes help to build conceptual models and play a central part in our modeling approach. We detail in this paper a few features of the tools. In the following example, we chose a metamodel to illustrate the features and potentials of our tools. In ﬁgure 3, we have the main panel of the tool which represents the hierarchy of the already deﬁned concepts and their textual properties. In the left part of this panel, the system engineer is able to browse the tree of components, he also has the possibility to select one of them in order to inspect, modify or delete parts of the concept or the whole concept. Contextual menus or the main edit menu enable hierarchical modiﬁcations and searches in the repository. In the concept detailed view on the right side of the panel, the user can modify the concept description and its properties (attributes, required or provided functions). Inherited properties are shown with a (i) preﬁx and are not removable but can be overloaded (e.g.; a speciﬁc bicycle wheel shall be an redeﬁned property for a speciﬁc sport bicycle). The “attributes” editor enables to control and access each component attributes required kind (e.g; a bicycle wheel attribute shall be a kindOf “BicycleWheel” ...). This information is used for static or dynamic veriﬁcations and when concept are instantiated. We use the composition of concepts to represent textual composite declarations like “The modem radio emitter frequencies...”. Like in object or component paradigm, the modem has an attribute called “radio” which has an attribute called “emitter” which “understands” frequencies as an instance of “Frequency” (with a multiple and unknown cardinality). Our main metaclass is a ConceptualComponent which deﬁnes every abstract or concrete concept used in systems. Attributes of a Conceptual Component can be the following: 1. Undeﬁned: an Unspeciﬁed kind: When the attribute is not deﬁned. 2. Properties: (a) a SimpleKind: Integer, String, Float... (b) a MeasurementUnit: Meters, Miles, Miles per Hours, Seconds... (c) an Interval of SimpleKind or MeasurementUnit (d) an Enumerated value (e.g.; { monday, tuesday, ... sunday }) 3. Sub-components: (a) a ConceptualComponent: RADAR, Motorbike, Modem, DSLModem ... (b) a set of ConceptualComponent: A partition discriminated by a list of properties. 4. States: List of “State” elements used to represent the states of the component. Our tool can be extended with code to provide additional checks/veriﬁcations on the parsed requirements. In our case study, we have considered constraints which are related to time and distance measures: our tool integrates a veriﬁcation speciﬁc to the context of measures. We make a distinction between simple types and measurement units in order to be able to diﬀerentiate the numbers expressed in constraints. e.g.; an altitude will never be expressed in seconds. Even if this example seems obvious, we need to check units consistencies. Based

260

E. Le Pors and O. Grisvard

Fig. 3. SCCM Hierarchy Browser

on SI standard units [15], we have built a MeasurementUnit metamodel in order to categorize constraints expressed in requirements (e.g; bandwidth constraints, frequency constraints ... ). This measure metamodel makes it possible to handle all SI (International System of Units) in our requirements and to combine them (e.g.; a speed in m/s or km/h). This unit model is dynamically extensible by adding unit classes in our measurement unit meta model. This enables easy conversion and comparison between them (e.g; a “meter” versus a “nautical mile”). In order to parse a requirement, we had to build artifacts in a composite way but also to determine which function each artifact requires and proposes in order to correspond to his conceptual deﬁnition. The Functions editor enables to visualize every provided or requested function for the currently selected component. The editor proposes to model functions as hierarchic concepts: a “DisplayVideo” function can be designed as sub-concept of “Display” function. The function editor enables to create (or delete) functions for a conceptual component. Moreover, the function editor also enables to redeﬁne a super concept function on a newly designed component. The function name represents the main name of the function and some alternatives (e.g.; “switchOﬀ” function shall be equivalent to “powerOﬀ”). We propose to write function category names using classical Smalltalk method naming convention [18]: “switch oﬀ” concept function is deﬁned as “switchOﬀ” and is linked to the conceptual function “SwitchOﬀ”. Each concept function name attached to a component can be diﬀerent from the conceptual function name (e.g.; “DisplayVideo” function can be called “display” as required function for this concept. The name “display” is the name which connects the conceptual component to its required function). In ﬁgure 4, we have the panel called “Concept ﬁnder and builder” which is used to query the model and to extend it when needed (e.g.; to add a new concept).

Conceptual Modeling for System Requirements Enhancement

261

Fig. 4. Graphical Finder and Builder

1. The query mode: The system engineer is able to search among the component database for concepts using keywords in description, attributes, functions names. By selecting the “Search” button, the tool builds a request on the model with the speciﬁed search indexes. Two lists are accessible: the fully compliant concepts list (100 percent of matching criteria) and the partially compliant concepts list (lower than 100 percent). The two lists are sorted by priority according to the matching percentage and the compliance level (which is pertinence factor that we compute (and can adapt) ). The engineer, when using the tool, can inspect concepts using contextual menus. 2. The building mode: The building mode is used to create new concepts when no corresponding concept is found by the engineer in the database. In this case, the tool can create a new conceptual component using the search criteria elements and settings as its attributes. If the concept is near a found concept, the engineer can select (after inspection on deﬁnitions, functions, attributes) the best one as the deﬁnition for the new concept. A new concept can also be created from an existing one as a sub-concept or as a sibling. A sub-concept is a component which will capitalize on deﬁnition of the super concept (with additions of the non-corresponding attributes or functions) the engineer will be able to specialize it with the previous panel. A sibling concept is a component near from the selected concept deﬁnition (the common attributes and functions are grouped in an new abstract or in a currently existing super-concept; the two concepts will inherit from this concept).

5

A Requirement Rewriting Example

During this work, we conducted several studies from system speciﬁcations documents within THALES. One of these documents covers the speciﬁcations of

262

E. Le Pors and O. Grisvard

a subsystem called FLIR, which displays day or night images of the mission environment. This sensor is used for maritime patrol missions. We began the experiment by attempting to reconstruct the conceptual model through reverse engineering. But despite the documentation and the speciﬁcations that were provided, the modeling expert could not rebuild a coherent conceptual model. The speciﬁcations were lacking of comments and the knowledge of a domain expert. We’ll take a few examples from this study and follow the process of reconstruction of the model (The requirements are expressed in Natural Language by system engineers): Req. 2. “The FLIR sensor video shall only be displayed on the Controller Operator and on the User Operator workstation.”. This requirement contains multiple parts and must be rewritten. In our application context, we have built a complete conceptual model of the FLIR (the subsystem). The FLIR subsystem integrates a sensor component, which has a video component itself. Each system can be activated by one operator, and in the requirement expression, there is a reference to two kinds of operators: the controller and the user. Each operator has a “workstation”. Here we have two solutions to rewrite the initial requirement: 1. Two requirements: – FLIR/TV system Controller Operator shall Display FLIR/TV sensor Video on workstation using TCS User Interfaces on. – FLIR/TV system User Operator shall Display FLIR/TV sensor Video on workstation using TCS User Interfaces. 2. One unique requirement which exploits the operator concept hierarchy: Both controllers and user operators inherit from operator concept (as seen in Fig. 5) . – Any FLIR/TV system Operator shall Display FLIR/TV sensor Video on workstation using TCS User Interfaces. The video display is available only on the operator’s workstations. We indicate clearly what is involved in the requirement: which operator, which video, and which is the triggering event. By indicating the content of the requirements, the software engineers can then translate more easily system requirements to

Fig. 5. Extract from the conceptual model

Conceptual Modeling for System Requirements Enhancement

263

software requirements (a lack of clarity by implicit deﬁnition may induce eventually additional software development which will impact the global cost and the project schedule). Another example: Req. 3. “The control response time for HCU entry shall be less or equal than 200 ms.” The HCU device for manual control of the FLIR sensor. When reading the requirement, one cannot ﬁgure out the precise target of the time constraint. The concept of “control response time” is vague and may constraint many operations of the HCU. We propose to enhance this requirement by using the conceptual model: “Every FLIR/TV Sensor HCU Control function shall have a response time less or equal to 200 ms” We have stated here that all “control functions” of the HCU (group of function of the device, which do not include maintenance, calibration or power functions) will be constrained by their attribute “response time” which is set to a maximum of 200 milliseconds. We identify the concept element which is involved by the requirement. When tracing this requirement to an architectural element (produced by the system engineering process), the concept element constraint can be retrieved. An analysis of the generic attribute “response time” of the functions contained in the constraint may induce the production of an automatic model checking on the architecture. In section 4.2, we introduced unit metamodel included in SCCM (which we do not detail in this paper) and which deals with diﬀerent measures used in the constraints (altitude, time, velocity ...). For example, two inconsistent requirements with constraints in terms of type or values can be detected. For example, in a team of engineers, one engineer speciﬁes a constraint on a function which is part of the “Control functions” of the FLIR, indicates a response time higher than 1 second, which is in conﬂict with requirement 2. We detect the incompatibility of the constraint values for this function, and once this conﬂict is detected, the system architect can take corrective action at an early stage of the development process. Completeness of requirements may be checked by observing the number of elements of the conceptual model used in relation to those which are required for the construction of the system: We must then verify the functions and the number of component properties which have not been impacted by the requirement parsing. Indeed, the system is constrained by the system-level requirements, they describe all the functional and non-functional properties which apply to this system. Once the requirement analysis is performed, it should verify that every elements of the conceptual model used are linked by at least one constraint. The semantic analysis uses elements of the conceptual model of the system being developed (components, functions, states, properties ...). This analysis identiﬁes the set of requirements which are incomplete, so that the system engineer can ﬁx.

264

6

E. Le Pors and O. Grisvard

Conclusions

In this paper, we have shown how our current investigation on requirement engineering can be used as an entry point when designing complex systems. The approach we propose is to center the processes on the various stakeholders who can interact, construct a concept model and sketch the elements of the future architecture to be developed. We believe that requirements are key elements because they convey many information. Any missed item may impact the functionalities of the system, the project itself (due to delay and ﬁnancial deviations) and the credibility of the business. We have indicated how the approach can be instrumented in order to contribute to the so-called requirement engineering. Originally, we have worked in the context of maritime surveillance and control: the target platform combines various equipments (e.g.; radars, cameras, sonar), numerous software pieces and components (e.g.; parts of the GUI, part of the data synthesis) and the complexity of the environment (e.g.; tactical conditions, mobility and critical situations). In the example, we indicate the current application in the context of maritime surveillance. We propose to rebuild requirements using speciﬁc conceptual models. These models are domain and business speciﬁc models and must be used (and reused) in the same company, even in the same business of this company. However, we propose to use a generic approach that can be adapted to many complex system architecture design methodologies. The perspective and the on going eﬀorts will be concentrated on the completion of the instrumented tools and on the building of diﬀerent conceptual models. We have indicated how requirement concepts can be represented, searched, how they can be traced and analyzed (taking into account elements of the model). We intend to go beyond and to provide tools so that these requirements and their outcomes can be capitalized over time.

Acknowledgments The authors would like to thank Jean-Luc Voirin, Vincent Verbeque, Alexandre Skrzyniarz and Jean-Pierre Mevel from THALES Airbone Systems and Yvon Kermarrec and Vanea Chiprianov for their contributions to our approach.

References 1. B´ezivin, J.: Model Driven Engineering: An Emerging Technical Space. In: L¨ ammel, R., Saraiva, J., Visser, J. (eds.) GTTSE 2005. LNCS, vol. 4143, pp. 36–64. Springer, Heidelberg (2006) 2. B´ezivin, J., Blay, M., Bouzhegoub, M., Estublier, J., Favre, J.-M., G´erard, S., J´ez´equel, J.-M.: Rapport de synth`ese de l’AS CNRS sur le MDA. CNRS (November 2004) 3. Brant, J., Roberts, D.: SmaCC, a Smalltalk Compiler-Compiler 4. Christel, M., Kang, K.: Issues in Requirements Elicitation. Software Engineering Institute, Carnegie Mellon University CMU/SEI-92-TR-12 (1992)

Conceptual Modeling for System Requirements Enhancement

265

5. Dissaux, P.: Using the AADL for mission critical software development. In: 2nd European Congress ERTS, Embedded Real Time Software-21, p. 22 (2004) 6. Feiler, P., Gluch, D., Hudak, J., Lewis, B.: Embedded System Architecture Analysis Using SAE AADL (2004) 7. Foster, J., Juell, P.: A visualization of the frame representation language. In: OOPSLA 2006: Companion to the 21st ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, pp. 708–709. ACM Press, New York (2006) 8. Gotel, O., Finkelstein, C.: An analysis of the requirements traceability problem. In: Proceedings of the First International Conference on Requirements Engineering, pp. 94–101 (1994) 9. Greenﬁeld, J., Short, K., Architects, V., et al.: Moving to Software Factories. Software development, Juillet (2004), http://www.sdmagazine.com 10. Grisvard, O.: Mod´elisation et gestion du dialogue homme-machine de commande. Phd, Universit´e Henry Poincar´e - Nancy 1 (2000) 11. Gruber, T.: A translation approach to portable ontology speciﬁcations. Knowledge Acquisition 5(2), 199–220 (1993) 12. Hammond, J., Rawlings, R., Hall, A.: Will it work? In: RE 2001: Proceedings of the 5th IEEE International Symposium on Requirements Engineering, Washington, DC, USA, pp. 102–109. IEEE Computer Society Press, Los Alamitos (2001) 13. Kermarrec, Y.: Approches et experimentations autour des composants: applications aux composants logiciels, aux objets d’apprentissage et aux services distribu´es. Habilitation a ` diriger des recherches, Universit´e de Bretagne Occidentale (March 2005) 14. Object Management Group (OMG). Meta object facility (MOF) speciﬁcation 2.0 mof 2.0 to omg idl mapping. ad/04-01-16 (January 2004) 15. I. B. of Weights, Measures, B. Taylor, N. I. of Standards, and T. (US). The International System of Units (SI). US Dept. of Commerce, Technology Administration, National Institute of Standards and Technology (2001) 16. OMG. System modeling language (SysML) speciﬁcation. Technical report, OMG (2005) 17. Schmidt, D.C.: Guest Editor’s Introduction: Model-Driven Engineering. COMPUTER, 25–31 (2006) 18. Skublics, S., Thomas, D., Klimas, E.: SmallTalk with Style. Prentice-Hall, Englewood Cliﬀs (1996) 19. I. C. Society. IEEE guide for developing system requirements speciﬁcations (1998) 20. Sommerville, I.: Software Engineering, 8th edn. Pearson Addison Wesley (2007) 21. Telelogic, A.: Telelogic DOORS (2006), http://www.telelogic.com/corp/products/doors/doors/index.cfm 22. Wang, N., Schmidt, D.C., O’Ryan, C.: Overview of the CORBA component model, pp. 557–571. Addison-Wesley Longman Publishing Co., Inc, Boston (2001)

Coloured Petri Nets for Chronicle Recognition Christine Choppy1 , Olivier Bertrand2 , and Patrice Carle2 1

LIPN, CNRS UMR 7030, Institut Galil´ee - Universit´e Paris XIII, France [email protected] 2 Onera, Chatillon, France {olivier.bertrand,patrice.carle}@onera.fr

Abstract. An activity is described by a chronicle that expresses relationships between events in a sequence ordered in time. A chronicle language provides a syntax for the diﬀerent chronicle operators considered. The recognition of chronicles is used in the processing of complex system simulations so as to detect activities or analyse behaviours. This work models formally the chronicle recognition, and coloured Petri nets (CPN) are used to model the recognition of a chronicle within a ﬂow of events. The occurrence of an event to be detected is modelled by the ﬁring of the corresponding transition. We provide coloured Petri nets to model the recognition of chronicles expressed with logical and temporal operators, as well as minimum and maximum time delays. We show how the composition of operators can be modelled by a composition of the coloured subnets associated with the diﬀerent operators. The algebraic properties of the operators are reﬂected in the coloured nets. In this work, composition is achieved through place fusion, and a comprehensive modelling is provided, including more delicate issues such as chronicle with repetitions, and the absence of sub-chronicles. Keywords: coloured Petri nets, chronicle recognition formal modelling, distributed simulation processing.

1

Introduction

The context of our work is the complex systems simulation. Complex systems modelling and simulation require to take into account the interactions between the diﬀerent components. For instance, an airport ground traﬃc simulation requires to model the planes with the pilots, the control tower, the weather, etc. together with their interactions, e.g. the communications between the pilots and the control tower (authorizations and acknowledgements), the weather impact on the routing rules, etc. The French Aerospace Lab (Onera) is participating in this eﬀort through the design of a modeling and simulation infrastructure for the acquisition and analysis of airport operational concepts and equipment. Figure 1 shows an airport simulation where an airplane T gets on a taxiway and an airplane R gets across the runway threshold, this is an hazardous

F. Kordon and Y. Kermarrec (Eds.): Ada-Europe 2009, LNCS 5570, pp. 266–281, 2009. c Springer-Verlag Berlin Heidelberg 2009

Coloured Petri Nets for Chronicle Recognition

267

STOP Event: T Event: R

Fig. 1. Ground traﬃc of an airport

situation if there is no order S to stop from the ground control. If another plane gets on another taxiway (again T) then two hazardous situations should be detected. We chose this example because it is representative of the simulations that are used at Onera. Indeed, it is a complex system simulation for the evaluation of the performances of the simulated system. The analysis of this kind of simulation requires the availability of a search process for undesired behaviours (in this example, collisions or simultaneous uses of a runway), and of a measurement process for the realization of some behaviours (for instance, the time elapsed between the landing of a plane and its stop at its gate). For this purpose, we chose a temporal approach that provides a better expression power, and the possibility to detect behaviour realisations through the observation of their characteristic traces. We consider each interaction as an event. The characteristic traces are expressed through events correlations. We chose to use chronicles for a ﬁne detection of event correlations that represent behaviour realisations. In this approach, events cannot occur simultaneously, and durations are not associated with events, events are thus considered as instantaneous. The events timestamps are achieved by the observation process, and are therefore expressed in terms of the observer time that is independent of the observed system own time. Hence chronicles do not express absolute dates, but delays between two events that are relative to the observer. Chronicles are used to model activities to be detected, for instance because they are undesired or dangerous (an example is an airport monitoring). An activity is described by a combination of event occurrences. When these events are identiﬁed within a ﬂow of events and in the described combination, then this activity is detected. A chronicle describes relationships between the events of a sequence ordered with respect to time. The goal is to identify all instances of the chronicle schema within an observed event ﬂow (where events are ordered and time-stamped). The chronicle identiﬁcation is achieved through the matching between events of the ﬂow and events in the chronicle description, while ﬂow events that do not contribute to the chronicle recognition are simply ignored. In addition, it may

268

C. Choppy, O. Bertrand, and P. Carle Event name: Event index

A:1

Ch=(A B)-[C D]

C:2

A:3

B:4 A:1 B:4 A:3 B:4

D:5

B:6

Time

A:3 B:6

Fig. 2. Three occurrences of the chronicle (A B)-[C D] in the event ﬂow a c a b d b

be of interest to save the piece of information stating which events in the ﬂow contributed to the chronicle recognition, because it may help to ﬁnd which are the causes of the observed events. The relationships between the events may be logical or temporal, and are expressed in a chronicle language (cf. Section 2). One of the issues in chronicle recognition is to ﬁnd all instances of the studied chronicle(s). For instance Figure 2 shows that three occurrences of the chronicle denoted (A B)-[C D], that is the sequence of events a and b without any sequence c d between a and b, should be found in the events ﬂow a c a b d b. The basic principles of our modelling with coloured Petri nets [20] are that we associate a transition to each event that should be detected1 (and this transition is ﬁred whenever this event occurs), and places are used to store (in a single token) a list of all chronicle (partial or total) instances identiﬁed. In addition, some control places are used to ensure that the desired sequencing is followed, or to model discrete time. For each operator expression of the chronicle language we provide a coloured Petri net modelling its recognition, in other words its semantics in terms of coloured Petri nets (or more precisely in the subset of coloured Petri nets that we use). After introducing the operators of the chronicle language we use in Section 2, we show in Section 3 how we model them using coloured Petri nets. In sections 3.3 and 4, we show diﬀerent examples of chronicle models and their executions.

2

Chronicle Language

M. Ornato and P. Carle [10] (Chronicle Recognition System CRS/Onera), and C. Dousson [15,16], introduced the notion of a chronicle language together with an associated recognition system. The CRS/Onera chronicle language [10] introduces the operators &, || and ( )-[ ], and the sequence (implicit operator). A convention is to use uppercase in a chronicle expression, and lowercase for the corresponding event instances. The conjunction A&B denotes the occurrence of both a and b events in any order, the disjunction A||B denotes the occurrence of either a or b, and the expression (A B)-[C] denotes the occurrence of a followed by the occurrence of b (that is the sequence) without any occurrence of c in between (absence). Let us note that these operators have some (algebraic) properties: 1

Note that events that do not contribute to the chronicle recognition are ignored.

Coloured Petri Nets for Chronicle Recognition

269

– the sequence is associative: A (B C) = (A B) C = A B C – the sequence is not commutative – the conjunction and disjunction are commutative and associative. The chronicle language is deﬁned as follows. – – – –

E : set of basic events t : an integer denoting the time units elapsed EV ::= E ∪ t the chronicle expressions C ::= e | C C | C&C | C || C | (C C) − [C], where in (C1 C2 ) − [C3 ], a partial recognition of C2 should not entail a C3 recognition.

These operators may be combined, for instance, the chronicle C1: chronicle C1 is (A (B & C)); describes a pattern where an event a is followed by both b and c events in any order, and the chronicle C2: chronicle C2 is (A||B)(C||D); is a sequence of events a or b, followed by c or d. A duration of (discrete) time is considered as an event, for instance chronicle C3 is (A 5 B); denotes a sequence of an event a followed by ﬁve units of time followed by an event b, in other words there should be a delay of (at least) ﬁve units of time between the events a and b (we refer to this as a minimum delay). Similarly a notion of maximum delay is expressed using the absence operator chronicle C4 is (A B)-[5]; expresses that there should be strictly less than ﬁve units of time between the events a and b (while four units would still be all right). Let us note that the delay constructs are always associated with a sequence or an absence operator. It could be tempting to think of this problem in terms of regular expressions and standard automata, however this unfortunately does not work well here. One reason is that, if the activity to be detected is expressed by the occurrence of an event a followed (not necessarily immediately) by an event b, then we could think that the chronicle A B is to be found in a ﬂow of events expressed by the regular expression [∧a]∗ a[∧b]∗ b but, since we need to ﬁnd all occurrences, this is not adequate. The ﬂow of events a a a b would lead to only one recognition while there are three occurrences to be found. As we show in [4,2], counter automata can be used to count the multiple occurrences, but we also need to retrieve the events that contributed to a recognition. With coloured Petri nets we provide a modular model with a composition that is visually readable, and that can be built using CPN tools (with various checks). In the following, we provide a coloured net model for the chronicle recognition on the basis of these operators, starting with a single event recognition and time delay. The diﬀerent operators will be built with the composition of basic elements.

270

C. Choppy, O. Bertrand, and P. Carle cpt 0

0 End

N Num [] Start

cpt+1

Num INT

cpt curr

[curr!=[] orelse act] []

NCList true

INT

Num

act

A

instance^^NH1st((E(a),cpt),curr)

Success

instance

First

NCList

BOOL

Fig. 3. Coloured net for a chronicle A

3 3.1

Coloured Petri Nets Models and Composition Basic Elements

Let us ﬁrst brieﬂy introduce coloured Petri nets (CPN) [20]. Coloured Petri nets (see e.g. Figure 3) are bipartite graphs with two kinds of nodes, places (drawn as ellipses with the name inside) and transitions (drawn as rectangles with the name inside). Directed arcs connect places to transitions (input arcs), and transitions to places (output arcs). The arcs are labelled with an expression where some variables of the corresponding place type may appear. Places are typed (the type name is usually below the place, e.g. in our examples most places types are NClist) and contain multisets of tokens that may be complex data of the place type. In Figure 3, the place Success contains one token (written 1‘) with the value [], and 1‘[] is the current marking of the place Success. The transitions may have a guard, that is a condition where the input arc expressions and variables may occur, and that is written usually above or below the transition. A transition can be ﬁred when (i) if there is a guard, it can be satisﬁed, (ii) all input arc labels can be matched with a token value from the corresponding input places. The diﬀerent Petri nets are modelled and executed with CPN tools [14]. The language used for types and functions is an ML like functional language. As reﬂected in the colour declarations below, a chronicle is represented by a list of events, and a chronicle instance is a list of events. colset NChronInst=list NEvent; colset NCList=list NChronInst; In Figure 3, places Start and Success contain one token that is a list of chronicle instances. The colours (i.e. types) we use here for events are: colset colset colset colset

Event=with a|b|c|d|th; Tevt=int with 0..130; NewEvent=union E:Event+T:Tevt; NEvent=product NewEvent*INT

Coloured Petri Nets for Chronicle Recognition

271

The basic Event type is an enumerated type with the names of events that we want to detect. Tevt is an integer for modelling delays (the limitation 0..130 is for an easy modelling with CPN tools). NewEvent is a union type of Event with Tevt. In NEvent, the product (a couple) of NewEvent and an integer INT is used for event numbering. For example, event a with number 1 is denoted by (E(a),1), further on written Ea1 . Similary T52 denotes an event of 5 time units with number 2. The net for an event recognition is in Figure 3, and the function NH1st is: fun NH1st(eE:NEvent,tT:NCList) = if tT=[] then [[eE]] else NHAdd(eE,tT) where function NHAdd is used to number the event occurrence. If the occurrence number of event eE is greater than the last event eE occurrence number, then it is added. The event numbering is used to diﬀerenciate all event instances with only one number. fun NHAdd(eE:NEvent,tT:NCList) = if (tT!=[]) then if ((#2 eE)>(#2 (hd (hd tT)))) then ( (hd tT)^^[eE])::NHAdd(eE,(tl tT)) else NHAdd(eE,(tl tT)) else [] The execution of Figure 3 with event ﬂow a a is

M0

⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ [] []1

[]1

1 [] 2

1 [] 2

Success⎢ [] ⎥ A ⎢ Ea ⎥End⎢ Ea ⎥ A ⎢ Ea , Ea ⎥End⎢ Ea , Ea ⎥ ⎢ ⎥ →⎢ ⎥ ⎢ ⎥ ⎢ ⎥→⎢ ⎥ ⎣ 0 ⎦ → ⎣ 1 ⎦→⎣ ⎦ ⎣ ⎦ N ⎣ 0 ⎦ 1 2 First true true true true true Start

⎡

The token of place Success contains the two recognitions of event a. The evolution of place N is due to transition End ﬁring, it will be illustrated in the execution of Figure 9. This transition is ﬁred when an event is recognized. The chronicle semantics requires to take into account delays and temporal constraints, thus a ﬁrst concern is about modelling time so as to recognize chronicles such as A 3 B (minimum delay: a sequence with at least three time units between events of type A and B) and (A B)-[3] (maximum delay: a sequence with less than three time units between events of type A and B). In this modelling, time elapse is considered as an event, that is a tick that increments time by an integer representing the time units. Of course, the speciﬁcity here is that there is no “repetition” (which would mean going back in time, that is of course impossible). The consequence is that time elapse cannot be considered in several instances of a chronicle (contrary to what is shown for any event that is not a time elapse in Figure 2, where a given a may be associated

272

C. Choppy, O. Bertrand, and P. Carle 0

0

N []

Num Start

Date

0

cpt Tevt

INT currDate

End

Num cpt+1

Num INT

cpt

curr

currDate+i

NCList NH1st((T(i),cpt),curr) act true

tConst(NH1st((T(i),cpt),curr),theDel)

Time

theDel

[curr!=[] orelse act]

[] Success

instance

NCList

5 First

Delay BOOL

Tevt

Fig. 4. Coloured net for time delay recognition

with several b’s and this yields several instances of the chronicle A B). In the case of time elapse, we should not create partial instances to take into account the speciﬁcity of time in our modelling. In the context of distributed simulation processing, the notion of time is considered as relative to the observer of the event ﬂows in the simulation. Our choice to model discrete time elapse by integers is thus relevant. In our modelling, the time elapse event is an integer that represents the time elapsed since the previous time elapse event. Thus, type NEvent is either a “standard” event, or a time elapse event. Now the recognition of the time elapse event is modelled in the net of Figure 4. In this net, places Start and Success are needed for composition with other nets. The token value in place Date is the current time elapsed since the initial marking. The (constant) token value in place Delay is the required delay (here 5). When the transition Time is ﬁred, variable i takes the appropriate elapse value, the time increment is added to the chronicle partial instances in place Start token, and if the required delay is reached, the chronicle valid partial instances are added to the Success token (with function tConst encoding). Therefore, the recognition of a delay of ﬁve time units with the net of Figure 4 after time elapses T(3) and T(4) is as follows.

M0

⎤ ⎡ 1 ⎤ ⎡ 1 ⎤ ⎡ 1 2 ⎤ ⎡ 1 2 ⎤ [] T3 T3 T3 , T4 T3 , T4 ⎢ [] ⎥ ⎢ [] ⎥ ⎢ T13 , T24 ⎥ ⎢ T31 , T42 ⎥ Success⎢ [] ⎥ ⎢ ⎥ Time ⎢ ⎥ ⎢ ⎥ Time ⎢ ⎥ ⎢ ⎥ ⎥ ⎢ ⎥ Date ⎢ 0 ⎥ (×3) ⎢ 3 ⎥End⎢ 3 ⎥ (×4) ⎢ 7 ⎢ ⎥ →⎢ ⎥→⎢ ⎥ → ⎢ 7 ⎥End ⎢ ⎥ ⎢ 5 ⎥ ⎢ 5 ⎥ ⎢ 5 ⎥→⎢ ⎥ Delay ⎢ 5 ⎥ 5 ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎣ 0 ⎦ ⎣ 1 ⎦ ⎣ 1 ⎦ ⎣ 2 ⎦ N ⎣ 0 ⎦ First true true true true true Start

⎡

This kind of net can be of course adapted to other delay values (simply changing the marking of place Delay), and composed to recognize chronicles such as A 3 B (minimum delay: a sequence with at least three time units between events of type A and B), and (A B)-[3] (maximum delay: a sequence with less than three time units between events of type A and B). An example of maximum delay is in Figure 9.

Coloured Petri Nets for Chronicle Recognition

Start

C

273

Success

First

Fig. 5. Abstract coloured net for chronicle recognition

C

Start

Success

Fusion

C

Start

First

Success

First

Fig. 6. Abstract coloured net recognising a chronicle sequence

We use Petri net composition to obtain more complex nets from these basic nets. We compose coloured Petri nets using the place fusion as introduced in [18,20]. The place fusion may be used to “synchronise” several places content. The merged places should have the same type (token colour), and get the same label (see in Figure 9 where the labels are the shaded rectangles in places N and Num for example). The merged places are Start, Success and sometimes First. The fusion corresponds to speciﬁc rules to obtain the corresponding net. The diﬀerent nets are detailed in the next subsection. 3.2

Operator Subnets and Composition

We would like here to sum up the various composable nets we propose for the diﬀerent operators of the chronicle language. In all ﬁgures, we use a special subnet C for the recognition of the chronicle C. In the following, we shall leave as an option to use the numbering to event occurrences as introduced above in particular for handling repetition in chronicles, so places N or Num and transition End are not shown although they can always be added. – – – –

Event e is recognised by the net in Figure 3 similarly, the basic net for a chronicle C recognition is in Figure 5 The net in Figure 6 deals with sequence C C recognition The absence (C1 C2 )-[C3 ] where a partial recognition of C2 should not entail a C3 recognition, is recognised in Figure 7 – The disjunction C || C is recognised in Figure 8.

274

C. Choppy, O. Bertrand, and P. Carle

[] Start

C

Success

Temp

NCList

Fusion

curr

Success

First

[curr!=[]]

notFun(curr,instance)

sub

instance

C

instance

First [curr!=[]]

Start

Fusion

Not

instance^^notFun(instance,curr)

curr

[]

[]

Start_Sub

Success_sub NCList

Fusion

First

Fusion

NCList

Start

C

Success

Fig. 7. Abstract coloured net for the absence operator

Start

C

Success

First

Fusion

Fusion

Fusion

First

Start

C

Success

Fig. 8. Abstract coloured net for the disjunction operator

We have also an operator for the conjunction but we do not use it in this article. In these ﬁgures, the End transition and N place are not represented because, they are all merged for all chronicles like in Figure 9. An important point is the management of ﬁring transitions. We use the following rules : for each event we ﬁre all corresponding transitions (i.e. with the event name), if we have an operator transition (like sub or Not in the absence net), it is ﬁred, and to ﬁnish the End transition is ﬁred. In the following section

Coloured Petri Nets for Chronicle Recognition

275

we model with nets an example of chronicle detection used in the Future Airport simulation. 3.3

Experiments with an Airport Ground Traﬃc Chronicle

In this section, the chronicle composition is illustrated with an example for the Future Airport simulation. This example is the recognition of an hazardous situation when the delay between two airplanes taking oﬀ is too short. In the following chronicle we consider an update of an airplane position when the airplane reaches the runway threshold with a take oﬀ mode (denoted Th). With the CRS/Onera language the chronicle is (Th Th)-[120] that is a sequence of two Th events without 120 time units between them. The corresponding Petri net is in Figure 9. The net in the center is for the absence operator (an instance of Figure 7), and it deletes from place Temp all the partial instances for which the absence constraint is violated (this is visible through a partial instance cpt 0 Num

End cpt+1

Num INT

0

0 N

N Num [] Start

[curr!=[] orelse act] Th1

act

[] Start SuccessTh

cpt

curr

NCList true

INT

Num

Success SuccessTh

instance

curr

NCList

[]

instance^^NH1st((E(Th),cpt),curr)

INT cpt [curr!=[] orelse act]

false

NCList

instance^^NH1st((E(Th),cpt),curr)

Th2

act

NCList

instance First

First

BOOL

BOOL

[] NCList Temp SuccessTh instance

curr

[curr!=[]]

[curr!=[]]

notFun(curr,instance)

sub

instance

Not

instance^^notFun(instance,curr)

curr

[]

[]

Start_Sub StartT NCList

Success_sub SuccessT NCList 0

0

N []

Num

Start StartT

Date

cpt

curr

Tevt

INT currDate currDate+i []

NCList NH1st((T(i),cpt),curr) act true

tConst(NH1st((T(i),cpt),curr),theDel)

Time

theDel

[curr!=[] orelse act]

instance

Success SuccessT NCList

120 First

Delay BOOL

[] Success

Tevt

Fig. 9. Coloured net for chronicle (Th Th)-[120] recognition

276

C. Choppy, O. Bertrand, and P. Carle

in place Success sub). Transition sub is ﬁred when an instance is present in place Temp (similarly for transition Not with place Success sub). Let us consider an event ﬂow where three planes arrive at the runway threshold in a sequence without any time delay in between (thus dangerous activities). This is represented by the event ﬂow th th th2 , and the execution of the net in Figure 9 is (from now on, the places First that keep the same marking will not be represented): M0

⎡

⎤

⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ []1

[]1

[]1

[]1

⎥ ⎢ E ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ SuccessTh⎢ ⎢ ⎥ ⎢ th ⎥ ⎢ Eth

⎥ ⎢ Eth

⎥ ⎢ Eth

⎥ 1 ⎥ Th1⎢ [] ⎥Sub⎢ E1 ⎥End⎢ E 1 ⎥Th2⎢ ⎥Th1 StartT ⎢ E th th ⎥ ⎢ ⎥ →⎢ ⎥ ⎢ th ⎥ ⎢ ⎢ ⎥→ ⎥ ⎢ [] ⎥ → ⎢ [] ⎥ → ⎢ [] ⎥ → ⎢ ⎥ SuccessT ⎢ [] ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 1 ⎥

⎦ ⎣ [] ⎦ ⎣ [] ⎦ ⎣ [] ⎦ ⎣ Eth , E2th ⎦ Success ⎣ Num 0 0 1 1 ⎡ ⎤ ⎡ ⎤ ⎡ ⎤

[]

[]

[]

⎢ E 1 , E2 ⎥ ⎢ E 1 , E 2 ⎥ ⎢ E 1 , E 2 ⎥ th th ⎥ th th

⎥ th th

⎥ ⎢ ⎢ ⎢

1 ⎢ ⎥Sub⎢ E 1 , E2 ⎥End⎢ E 1 , E 2 ⎥Th2 Eth th th ⎥ → ⎢ th th ⎥ → ⎢ ⎥→⎢ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ [] [] [] ⎢ 1 ⎥ ⎢ ⎥ ⎢

⎥ 2 1 2 1 2 ⎣ Eth , Eth ⎦ ⎣ Eth ⎦ ⎣ Eth ⎦ , Eth , Eth 1 1 2 ⎡ ⎤ ⎡ ⎤ 1 [] 2

1 []2 3

⎢ ⎥ ⎢ ⎥ E th , E ⎢ ⎥ ⎢ ⎥ Eth

, Eth

th ,2 E

th 1 2 1 ⎢ ⎥Th1⎢ ⎥Sub E , E E , E th th th th ⎢ ⎥→⎢ ⎥→ ⎢ ⎥ ⎢ ⎥ [] [] ⎢ ⎥ ⎢ ⎥ 1

⎣ E , E 2 , E 1 , E3 , E 2 , E 3 ⎦ ⎣ E 1 , E 2 , E 1 , E 3 , E 2 , E 3 ⎦ th th th th th th th th th th th th 2 2 ⎡ ⎤ ⎡ ⎤ 1 []2 3

1 []2 3

⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ E1th , Eth

, E3th

Eth

, Eth

, Eth

2 1 2 3 ⎢ ⎥End⎢ ⎥ E , E , E E , E , E th th th th th th ⎢ ⎥→⎢ ⎥ ⎢ ⎥ ⎢ ⎥ [] [] ⎢ 1 ⎥ ⎢ ⎥

⎣ E , E 2 , E 1 , E 3 , E 2 , E 3 ⎦ ⎣ E 1 , E2 , E 1 , E 3 , E 2 , E3 ⎦ th th th th th th th th th th th th 2 3 Start

[] [] [] [] [] 0

At the end of this execution we have three recognitions of the chronicle in place Success. We have three times the hazardous activity, the ﬁrst instance is due to the ﬁrst plane with the second plane, the second is due to the ﬁrst plane and the third plane, and the last is due to the second plane and the third plane. This example illustrates the multirecognition of chronicles. Let us now consider an event ﬂow where two planes arrive at the runway threshold with a 130 units of time delay in between, the execution with the event ﬂow th 130 th is: 2

Following our notation convention mentioned is Section 2 an event instance is denoted th.

Coloured Petri Nets for Chronicle Recognition

277

M0

⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ [] [] []1

[]1

[]1

[]1

⎢E ⎥ ⎢ ⎥ ⎢ ⎥ SuccessTh⎢ [] ⎥ ⎢ Eth ⎥ ⎢ Eth ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ Time ⎢ 1 Eth2

⎥ ⎢ ⎥ 1

th

1 [] 2

1 ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ StartT [] Th1 Eth ⎥End⎢ Eth ⎥ (×130) ⎢ Eth , T130

Not⎢ Eth , T130 ⎥ ⎢ ⎥ →⎢ [] ⎥sub ⎢ ⎥ ⎥ → →⎢ ⎥ → ⎢ E1 , T2 ⎥ → ⎢ ⎥ SuccessT⎢ [] ⎥ ⎢ [] ⎥ ⎢ [] ⎥ [] ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ [] ⎥ ⎢ th 130 ⎥ ⎢ ⎥ ⎣ [] ⎦ ⎣ ⎦ ⎣ ⎦ Success ⎣ [] ⎦ ⎣ [] ⎦ ⎣ [] ⎦ [] [] Num 0 0 0 1 1 1 ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ [] []3

[]3

[]3

⎢ ⎥ ⎢ E ⎥ ⎢ ⎥ ⎢ ⎥ th th ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ 1 [] 2

1 th 2

1 E

3

1 E

2 2 3 ⎥ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ E , T E , T E , T , E E , T , E End⎢ Th1 sub End 130 130 130 130 th th th th th th ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ →⎢ ⎥→⎢ ⎥→⎢ ⎥→⎢ ⎥ [] [] [] [] ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎣ ⎦ ⎣ ⎦ ⎣ ⎦ ⎣ ⎦ [] [] [] [] 2 2 2 3 In this execution, when the recognition of time event 130 occurs, the partial 1 instance with Eth in place Temp is deleted by ﬁring of transition Not because the delay is elapsed. Thus no hazardous activity is detected ([] in Success). Other chronicles to dectect activities in the Future Airport simulation are found in [5]. Start

4

Chronicle Complex Absence Processing

Our framework also applies to the complex/sub-chronicle absence processing as shown by Figure 10 for the chronicle (A B)-[C D] (see also Figure 2). The execution of this net for the event ﬂow a c a d b is as follows.

M0

⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ [] []1

[]1

[]1

[]1

[]1

⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ SuccessA⎢ [] ⎥ ⎢ ⎥ ⎢ Ea ⎥ ⎢ Ea1

⎥ ⎢ Ea1

⎥ ⎢ Ea1

⎥ ⎢ Ea1

⎥ ⎢ [] ⎥ ⎢ Ea ⎥ ⎢ Ea ⎥ ⎢ Ea ⎥ ⎢ ⎥ StartC ⎢ [] ⎥ E ⎢ ⎥ A⎢ ⎥Sub⎢ ⎥End⎢ ⎥ C ⎢ 1 2

⎥End⎢ 1 a 2

⎥ ⎥→⎢ E , E ⎥ → ⎢ E , E ⎥ SuccessC⎢ [] ⎥ →⎢ [] ⎥ → ⎢ [] ⎥ → ⎢ [] a c ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ a c ⎥ ⎢ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ SuccessD⎢ [] ⎥ [] [] ⎢ ⎥ ⎢ [] ⎥ ⎢ [] ⎥ ⎢ [] ⎥ ⎢ ⎥ ⎢ ⎥ ⎣ [] ⎦ ⎣ [] ⎦ ⎣ [] ⎦ ⎣ ⎦ ⎣ ⎦ Success ⎣ [] ⎦ [] [] Num 0 0 0 1 1 2 ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ 1 [] 3

1 [] 3

1 [] 3

1 [] 3

⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ 1

⎥ ⎢ 1 3

⎥ ⎢ 1 3

⎥ ⎢ 1 3

⎥ ⎢ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ Ea

⎥ ⎥Sub⎢

⎥ ⎢ 1 2

⎥ D ⎢ 1 2

⎥Not A ⎢ 1 2 ⎥ → ⎢ E 1 , E 2 ⎥End ⎢ ⎥ ⎢ ⎥ →⎢ E , E a c a c ⎢ ⎥ ⎢ ⎥ → ⎢ Ea , Ec ⎥→⎢ 1Ea , 2Ec 4

⎥ → ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ E ,E ,E ⎥ [] [] [] ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ a c d ⎥ ⎣ ⎦ ⎣ ⎦ ⎣ ⎦ ⎣ ⎦ [] [] [] [] 2 2 3 3 ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ ⎡ ⎤ []3

[]3

[]3

[]3

⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ 1 Ea 3

⎥ ⎢ 1 Ea 3

⎥ ⎢ 1 Ea 3

⎥ ⎢ 1 Ea 3

⎥ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ Ea , Ea ⎥ ⎢ 1 2

⎥End⎢ 1 2

⎥ B ⎢ 1 2

⎥End⎢ 1 2

⎥ ⎢ ⎥ ⎢ ⎥ ⎢ ⎥ ⎢ Ea , Ec ⎥ ⎢ Ea , Ec

⎥ → ⎢ Ea , Ec

⎥→⎢ 1Ea , 2Ec 4

⎥ → ⎢ ⎥

⎢ E1, E2, E4 ⎥ ⎢ E1, E2, E4 ⎥ ⎢ E , E , E ⎥ ⎢ E1, E2, E4 ⎥ a c a c c

d ⎥ d ⎥ ⎢ a d ⎥ d ⎥ ⎢ ⎢ ⎢ a c

⎣ ⎦ ⎣ ⎦ ⎣ ⎦ ⎣ Ea3 , E 5 ⎦ [] [] E3a , E5b b 3 4 4 5 Start

278

C. Choppy, O. Bertrand, and P. Carle cpt 0 Num

End cpt+1 0

0

Num INT N

N

Num

Num [] Start

curr

Start

Success

SuccessA

act

[curr!=[] orelse act]

NCList

[] instance^^NH1st((E(a),cpt),curr)

cpt curr

SuccessA

[curr!=[] orelse act] A

INT

[]

cpt

NCList

true

INT

NCList

act

false

instance

instance^^NH1st((E(b),cpt),curr)

B

[] Success NCList

instance

First

First

BOOL BOOL

[] Temp NCList SuccessA notFun(curr,instance)

curr

instance

[curr!=[]]

[curr!=[]] sub

Not

instance instance^^notFun(instance,curr)

curr

[]

[]

Start_Sub StartC

Success_sub SuccessD NCList

NCList 0 0

N Num

N [] Start

Num curr

StartC

[] C

false

act

First BOOL

instance^^NH1st((E(c),cpt),curr)

curr

SuccessC

[curr!=[] orelse act]

NCList

Success

SuccessC instance

cpt

Start

cpt [curr!=[] orelse act]

NCList

INT

[]

INT

D NCList

false

[]

instance^^NH1st((E(d),cpt),curr)

act

Success

SuccessD instance

NCList

First BOOL

Fig. 10. Coloured net for the chronicle (A B)-[C D] recognition

The chronicle is recognized once with the second a and b, since there is no c d in between (note that the event ﬂow in Figure 2 is slightly longer). Let us note that the handling of sub-chronicle absence is a diﬃcult issue in this kind of modelling, and is not taken into account in chronicle recognition systems as [6] or the ﬁrst versions of [15]. This example shows again that our composition framework is easily applied to model complex chronicle recognition.

5

Conclusion, Related and Future Work

In this work, coloured Petri nets are used to model the recognition of a chronicle within a ﬂow of events, and the occurrence of an event to be detected is modelled by the ﬁring of the corresponding transition. Chronicles were ﬁrst used for system diagnosis, and Petri nets of various kinds were used for dynamic systems diagnosis. In [17], place-bordered Petri nets (with associated diagnosers) are used to model the components of modular dynamic systems, and fault diagnosis is achieved through a distributed algorithm.

Coloured Petri Nets for Chronicle Recognition

279

The goal in [1,13], is to diagnose asynchronous distributed systems using Petri nets. A full model of the system in timed Petri nets (not coloured) is designed. Then an observation model of the system is used to determine the possible executions of the system, via unfolding the timed Petri net. Let us note that diﬀerent models are available to take time into account within Petri nets, using either the notion of a time duration or a delay between two events. Places are either timed [29] or temporal [22], and transitions are either timed [28] or temporal [25]. In another work [7] both places and transitions are timed. Particle Petri nets [24] were developed for hybrid systems monitoring. In another approach [6,7] chronicle recognition is modelled through timed place transition nets. A. Boufaied [7] duplicates the nets upon an event recognition in order to recognize all chronicle instances. However, it seems that absence is not taken into account. Other issues of this paper are the design of Petri net patterns, the composition of nets, and its use to provide a semantics to a language. These issues were addressed in various ways. For instance, [8] provides a semantics for a security protocol language using composable high level Petri nets. A diﬀerent purpose is pursued in [9] where grid workﬂows are modelled with coloured Petri nets, and Petri net patterns are provided e.g. for parallel execution or multiple resource allocation (as workﬂow patterns in [27,26]). Note that these works are aimed at modelling a process execution, while we are concerned with process observation. We reﬂect causal relations in a diﬀerent way from [21], or [23], since, in our coloured Petri nets, places always have a (single) token (that may be the empty list), so the control has to be achieved through guards. In [12], the event patterns diﬀer from ours in the following points, events have a duration, there is no event associated with the time elapse, two events may be simultaneous. Another diﬀerence is that some restrictions on multiple matching are set to restrict the memory used by the algorithm. In [4,2], we compare various kinds of automata (counter automata, duplicating automata) and coloured Petri nets for expressing and recognizing some basic chronicles operators, and found that coloured Petri nets comply with the speciﬁc needs associated with chronicle recognition, in particular multiple occurrences recognition, and the possibility to trace the events that contributed to a recognition. The goal is to perform analysis of system simulations of type High Level Architecture (HLA) [19], to be used e.g. in airport control, and in [3], we started to perform oﬀ line analysis of distributed HLA simulations using chronicles. In this work, we pursued to reach an extensive expression of the chronicle language operators, and then worked out coloured nets that could be composed to express complex chronicle expressions. The composition could be achieved either via transition substitution, or via place fusion, and in both cases the algebraic properties of the operators are reﬂected. Our model thus encompasses all logical and temporal operators, including the absence operator. Indeed our model evolved to provide an elegant way to deal with the diﬃcult issue of subchronicle absence. This work thus provides elements to model complex chronicles

280

C. Choppy, O. Bertrand, and P. Carle

recognition, and to deﬁne a semantics of the chronicle language in terms of the used subset of coloured nets. Having a full coloured Petri nets (CPN) model for our chronicle language sets a ﬁrm basis from which its semantics can be fully determined. The CRS/Onera tool was designed on the basis of duplicating automata so as to comply with performance (it was successfully used for intrusion detection in a network trafﬁc [11]) and interoperability requirements. This coloured Petri net modelling was worked out later to take advantage of the abstraction and modularity of CPN as well as of the visual presentation and checks provided by CPN Tools. This now sets the grounds on which the CRS/Onera tool correction can be studied. In a near future, we plan to model the transition ﬁring with Petri net to comply the “classical” rules of Petri nets.

References 1. Benveniste, A., Fabre, E., Jard, C., Haar, S.: Diagnosis of asynchronous discrete event systems: A net unfolding approach. In: WODES 2002: Proceedings of the Sixth International Workshop on Discrete Event Systems (WODES 2002), Washington, DC, USA, 2002, p. 182. IEEE Computer Society Press, Los Alamitos (2002) 2. Bertrand, O., Carle, P., Choppy, C.: Chronicle modelling using automata and colored Petri nets. In: The 18th International Workshop on Principles of Diagnosis (DX 2007), pp. 229–234 (2007) 3. Bertrand, O., Carle, P., Choppy, C.: Vers une exploitation des simulations distribu´ees par les chroniques. In: 8e Rencontres nationales des Jeunes Chercheurs en Intelligence Artiﬁcielle (RJCIA 2007), pp. 15–30 (2007) 4. Bertrand, O., Carle, P., Choppy, C.: Mod´elisation compar´ee de chroniques ` a l’aide d’automates a ` ´etats ﬁnis ou de r´eseaux de Petri color´es, 50 pages. Technical report, ONERA (2008) 5. Bertrand, O., Carle, P., Choppy, C.: Reusing simulation through processing tools. In: Simulation Interoperability Workshop (June 2008) 6. Boufaied, A., Subias, A., Combacau, M.: Chronicle modeling by Petri nets for distributed detection of process failures. In: Second IEEE International Conference on Systems, Man and Cybernetics (SMC 2002). IEEE Computer Society Press, Los Alamitos (2002) 7. Boufaied, A.: Contribution ` a la surveillance distribu´ee des syst`emes ` a ´ev´enements discrets complexes. PhD thesis, Universit´e Paul Sabatier (2003) 8. Bouroulet, R., Klaudel, H., Pelz, E.: A semantics of security protocol language (spl) using a class of composable high-level petri nets. In: ACSD 2004: Proceedings of the Fourth International Conference on Application of Concurrency to System Design, Washington, DC, USA. IEEE Computer Society Press, Los Alamitos (2004) 9. Bratosin, C., van der Aalst, W., Sidorova, N.: Modeling Grid Workﬂows with Colored Petri Nets. In: CPN 2007, Eighth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, Aarhus, Denmark, October 2007, pp. 67–86 (2007) 10. Carle, P., Benhamou, P., Dolbeau, F.-X., Ornato, M.: La reconnaissance d’intentions comme dynamique des organisations. In: 6`emes Journ´ees Francophones pour l’Intelligence Artiﬁcielle Distribu´ee et les Syst`emes Multi-Agents (JFIADSMA 1998), Pont a ` Mousson (France) (November 1998)

Coloured Petri Nets for Chronicle Recognition

281

11. Carle, P.: Rapport Mirador - D´etections d’intrusions par chroniques. Technical report, Onera (2001) 12. Carlson, J.: Event Pattern Detection for Embedded Systems. PhD thesis, M¨ alardalen University, Department of Computer Science and Electronics (June 2007) 13. Chatain, T., Jard, C.: Time Supervision of Concurrent Systems using Symbolic Unfoldings of Time Petri Net. In: Pettersson, P., Yi, W. (eds.) FORMATS 2005. LNCS, vol. 3829, pp. 196–210. Springer, Heidelberg (2005) 14. The CPN Tools Homepage (2007), http://www.daimi.au.dk/CPNtools 15. Dousson, C., Gaborit, P., Ghallab, M.: Situation Recognition: Representation and Algorithms. In: International Joint Conference on Artiﬁcial Intelligence (IJCAI), Chamb´ery, France, August 1993, pp. 166–172 (1993) 16. Dousson, C., Le Maigat, P.: Improvement of chronicle-based monitoring using temporal focalization and hierarchization. In: The International Workshop on Principles of Diagnosis (2006) 17. Genc, S., Lafortune, S.: Distributed Diagnosis of Place-Bordered Petri Nets. IEEE Trans. on Automation Science and Engineering 4(2), 206–219 (2007) 18. Huber, P., Jensen, K., Shapiro, R.M.: Hierarchies in Coloured Petri Nets. In: Rozenberg, G. (ed.) APN 1990. LNCS, vol. 483, pp. 313–341. Springer, Heidelberg (1991) 19. IEEE. IEEE standard for modeling and simulation (M & S) High Level Architecture (HLA)-Object Model Template (OMT) speciﬁcation (2001) 20. Jensen, K.: Coloured Petri nets: basic concepts, analysis methods and practical use, vol. 1, 2, 3. Springer, London (1995) 21. Katoen, J.-P.: Causal Behaviours and Nets. In: DeMichelis, G., D´ıaz, M. (eds.) ICATPN 1995. LNCS, vol. 935, pp. 258–277. Springer, Heidelberg (1995) 22. Khansa, W.: R´eseaux de Petri p-temporels: contribution ` a l’´etude des syst`emes ` a ´ev`enements discrets. PhD thesis, Universit´e de Savoie (1997) 23. Klaudel, H., Pommereau, F.: M-nets: a survey. Acta Informatica (2008) 24. Lesire-Cabaniols, C., Tessier, C.: Particle Petri net-based estimation in hybrid systems to detect inconsistencies. In: DCDS 2007, 1st IFAC Workshop on Dependable Control of Discrete Systems (2007) 25. Merlin, P.: A study of the recoverability of computer system. PhD thesis, Universit´e de Californie ` a Irvine (1974) 26. Mulyar, N., van der Aalst, W.M.P.: Patterns in colored Petri nets. In: BETA Working Paper Series, Eindhoven University of Technology, Eindhoven (2005) 27. Mulyar, N., van der Aalst, W.M.P.: Towards a pattern language for colored Petri nets. In: Jensen, K. (ed.) Sixth Workshop on the Practical Use of Coloured Petri Nets and CPN Tools (CPN 2005), Aarhus, Denmark, October 2005, vol. 576, pp. 39–48. University of Aarhus (2005) 28. Ramchandi, C.: Analysis of Asynchronous Concurrent Systems by Timed Petri Net. PhD thesis, MIT (February 1974) 29. Sifakis, J.: Use of Petri Nets for Performance Evaluation. In: Measuring, Modelling and Evaluating Computer Systems, Proc. of the Third Int. Symposium, Bonn - Bad Godesberg, Germany, October 3-5, 1977, pp. 75–93. North-Holland, Amsterdam (1977)

Author Index

Aldea Rivas, Mario

105

Bernat, Guillem 134 Berthomieu, Bernard 207 Bertrand, Olivier 266 Bodeveix, Jean-Paul 192, 207 Buchs, Didier 59 Burns, Alan 119 Carle, Patrice 266 Chaudet, Christelle 207 Chen, Ang 59 Choppy, Christine 266 Clarke, Duncan 222 Crespo, Alfons 149

Lasnier, Gilles 237 Lau, Man Fai 44 Lee, Insup 222 Le Pors, Eric 251 Lorente, Vicente 149 Lucio, Levi 59 M´ armol Acitores, Gloria 164 Marref, Amine 134 Montoya-Dato, Francisco J. 75 Pautet, Laurent 30, 237 Pi, Lei 192 Pradat-Peyre, Jean-Fran¸cois Ruiz, Jos´e F.

Dal Zilio, Silvano 207 Delange, Julien 30 de la Puente, Juan A. 16

105

S´ aez, Sergio 149 Sokolsky, Oleg 222 Terrasa, Silvia

Favre, Liliana 177 Feiler, Peter 30 Fern´ andez-Alem´ an, Jos´e Luis 75 Fern´ andez S´ anchez, Jos´e L. 164 Filali, Mamoun 192, 207 Garc´ıa-Mateos, Gin´es 75 Gonz´ alez Harbour, Michael Grisvard, Olivier 251 Hugues, J´erome Kaiser, Claude

237 90

149

Urue˜ na, Santiago

Vardanega, Tullio 1 Vernadat, Fran¸cois 207 Wellings, Andy J.

105

16

Yu, Yuen Tak

119

44

Zalila, Bechir 237 Zamorano, Juan 16 Zhang, Fengxiang 119 Zovi, Alessandro 1

90

Component-Based Software Engineering: 12th International Symposium, CBSE 2009 East Stroudsburg, PA, USA, June 24-26, 2009 Proceedings (Lecture Notes ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2011: 16th Ada-Europe International Conference on Reliable Software Technologies, Edinburgh, UK, June ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe '97: 1997 Ada-Europe International Conference on Reliable Software Technologies, London, UK, June 2-6,

Software Language Engineering: Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009 Revised Selected Papers (Lecture Notes ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2008: 13th Ada-Europe International Conference on Reliable Software Technologies, Venice, Italy, June 16-20,

Reliable Software Technologies -- Ada-Europe 2006: 11th Ada-Europe International Conference on Reliable Software Technologies, Porto, Portugal, June

Software and Data Technologies - ICSOFT 2009

Reliable Software Technologies - Ada-Europe 2010: 15th Ada-Europe International Conference on Reliabel Software Technologies, Valencia, Spain, June ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2007: 12th Ada-Europe International Conference on Reliable Software Technologies, Geneva, Switzerland, June ... (Lecture Notes in Computer Science)

Theory and Practice of Model Transformations: Second International Conference, ICMT 2009, Zürich, Switzerland, June 29-30, 2009, Proceedings (Lecture ... Programming and Software Engineering)

Runtime Verification: 9th International Workshop, RV 2009, Grenoble, France, June 26-28, 2009, Selected Papers (Lecture Notes in Computer Science Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2009: 14th Ada-Europe International Conference, Brest, France, June 8-12, 2009, Proceedings (Lecture Notes ... Programming and Software Engineering)

Component-Based Software Engineering: 12th International Symposium, CBSE 2009 East Stroudsburg, PA, USA, June 24-26, 2009 Proceedings (Lecture Notes ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2011: 16th Ada-Europe International Conference on Reliable Software Technologies, Edinburgh, UK, June ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe '97: 1997 Ada-Europe International Conference on Reliable Software Technologies, London, UK, June 2-6,

Software Language Engineering: Second International Conference, SLE 2009, Denver, CO, USA, October 5-6, 2009 Revised Selected Papers (Lecture Notes ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2008: 13th Ada-Europe International Conference on Reliable Software Technologies, Venice, Italy, June 16-20,

Reliable Software Technologies -- Ada-Europe 2006: 11th Ada-Europe International Conference on Reliable Software Technologies, Porto, Portugal, June

Software and Data Technologies - ICSOFT 2009

Reliable Software Technologies - Ada-Europe 2010: 15th Ada-Europe International Conference on Reliabel Software Technologies, Valencia, Spain, June ... Programming and Software Engineering)

Reliable Software Technologies - Ada-Europe 2007: 12th Ada-Europe International Conference on Reliable Software Technologies, Geneva, Switzerland, June ... (Lecture Notes in Computer Science)

Theory and Practice of Model Transformations: Second International Conference, ICMT 2009, Zürich, Switzerland, June 29-30, 2009, Proceedings (Lecture ... Programming and Software Engineering)

Runtime Verification: 9th International Workshop, RV 2009, Grenoble, France, June 26-28, 2009, Selected Papers (Lecture Notes in Computer Science Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Programming and Software Engineering)

Model checking software: 16th International SPIN Workshop, Grenoble, France, June 26-28, 2009; proceedings

Recommend Documents